[인프런 복습] 쿠버네티스 어나더클래스(1) - 컨테이너 한방 정리

✅ 아래 글의 내용 및 이미지는 인프런 "쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2" 강의를 듣고 정리한 글입니다.

시작

이 대화에는 3가지 정도 잘못된 내용이 있다. 강의를 듣고 나중에 정답을 알려줌!

 

최초의 OS로는 Unix가 있었다. (유료)

리누스 토르발즈가 커널을 재배포해서 Linux를 만들었다.

리눅스 배포판을 다시 한번 수정? 해서 나온게 Debian 계열(무료)과 RedHat 계열(유료)이 있다.

Debian 계열에서 편의기능을 추가한게 지금까지도 계속 발전되고 있는 Ubuntu 이다.

 

Redhat 에서 리눅스 배포판이 만들어지는 순서

 

1. 페도라 리눅스 (새로운 기능을 개발하는 버전) 무료이다.

2. 기능이 안정화되면 RHEL 로 바꿔서 릴리즈. 유료이다.

3. RHEL 을 복사해서 만든게 centOS 배포판이다.

 

centOS는 곧 지원 종료된다.

RHEL은 IBM에게 인수가 되었다. 기존 centOS 사용자들을 RHEL로 끌어들이려고 배포판을 만드는 순서를 변경했다.

 

1.페도라 리눅스를 통해서 기능 개발

2.centos stream 이라는 기능을 테스트하는 배포판을 만듦. 여전히 무료지만 바이너리 호환성이 안될 수 있다는 이야기를 한다.

3.안정화버전인 RHEL 을 출시한다.

 

RHEL을 복제해서 새로 만드는 Project가 Rocky Linux와 AlmaLinux가 있다.

리눅스 기억해야 될 사항

1. 주로 사용하는 리눅스에는 Debian과 Redhat 계열이 있다.

2. 쿠버네티스 설치도 크게 이 두가지 계열을 지원한다.

3. Redhat 계열의 하나인 CentOS는 곧 종료가 된다.

4. Rocky Linux는 CentOS의 대체채 중 하나다.

Rocky Linux는 쿠버네티스 설치할 때 Redhat 계열을 보면 된다.

컨테이너에 대한 이야기

리눅스는 꾸준히 발전. 내부적으로도 많은 기술이 발전인데 그중 하나가 격리 기술이다.

 

격리 기술들을 집약해서 나온 것이 LXC라고 해서 Linux Container의 줄임말이다.

이 LXC기반으로 만들어진 컨테이너가 Docker이다.

 

chroot

chroot는 특정 프로세스와 그 자식 프로세스들의 루트 디렉토리를 변경하는 시스템 호출입니다. 이를 통해 프로세스는 변경된 루트 디렉토리 외부의 파일 시스템에 접근할 수 없게 되어, 보안성이 강화됩니다. 예를 들어, 서버에서 여러 서비스를 격리하여 실행하고자 할 때 'chroot'를 사용하여 각 서비스의 파일 시스템 접근을 제한할 수 있습니다. 이는 일종의 가벼운 격리 메커니즘으로, 보다 강력한 격리가 필요한 경우에는 'namespace'와 함께 사용됩니다.

 

cgroup

cgroup(Control Groups)은 프로세스 그룹의 시스템 자원 사용량(예: CPU 시간, 시스템 메모리, 네트워크 대역폭 등)을 모니터링하고 제한하는 기능을 제공합니다. 이를 통해 시스템의 자원을 효율적으로 분배하고, 한 애플리케이션이 전체 시스템 자원을 독점하는 것을 방지합니다. 'cgroup'은 시스템의 안정성을 유지하고, 컨테이너별 자원 사용을 세밀하게 조절할 수 있게 합니다.

 

namespace

namespace는 프로세스에게 독립된 시스템 리소스의 뷰(예: 파일 시스템, 네트워크 스페이스, 사용자 ID)를 제공하여, 프로세스가 시스템의 다른 부분과 격리되도록 합니다. 이는 각 컨테이너가 마치 별도의 물리적 서버에서 실행되는 것처럼 독립적인 실행 환경을 가질 수 있게 해 줍니다. 'namespace'는 여러 격리 수준을 제공하여, 컨테이너가 서로를 방해하지 않고 독립적으로 실행될 수 있도록 합니다.

 

컨테이너와 컨테이너 오케스트레이션

컨테이너의 종류는 몇 가지가 있다. 여기서 설명하는 건 3가지

 

Docker
Docker는 컨테이너 플랫폼의 선두주자로, 이미지 생성, 배포, 실행을 위한 전체 생태계와 툴셋을 제공합니다. Docker는 사용자가 컨테이너를 쉽게 다룰 수 있도록 하는 고수준의 인터페이스와 편리한 명령어 집합을 제공합니다. Docker 엔진은 Dockerd 데몬, REST API, 그리고 CLI (명령줄 인터페이스)로 구성됩니다. 초기에는 Docker 자체가 컨테이너의 라이프사이클을 전부 관리했지만, 시간이 지나면서 이런 기능들이 더 낮은 수준의 컴포넌트로 분리되기 시작했습니다.

containerd
containerd는 Docker Inc.에 의해 개발되었고, Docker의 핵심 컴포넌트를 기반으로 합니다. containerd는 OCI(Open Container Initiative) 표준을 준수하는 컨테이너 런타임으로, 이미지 관리, 컨테이너 실행, 스토리지, 네트워킹 등 컨테이너의 핵심 기능을 제공합니다. containerd는 Docker 엔진에서 분리되어 독립적으로 발전하며, Kubernetes 같은 컨테이너 오케스트레이션 시스템에서도 널리 사용됩니다. containerd는 더 낮은 수준의 API를 제공하며, 컨테이너의 라이프사이클을 관리하는 데 집중합니다.

CRI-O
CRI-O는 Kubernetes Container Runtime Interface(CRI)를 구현한 컨테이너 런타임입니다. CRI-O는 Kubernetes와 컨테이너 런타임 사이의 인터페이스로 설계되었으며, Kubernetes가 컨테이너를 직접 관리하고 오케스트레이션할 수 있게 해줍니다. CRI-O의 개발은 Red Hat을 비롯한 여러 조직과 개발자들의 협력으로 이루어졌으며, Kubernetes 생태계 내에서 컨테이너를 관리하는 표준화된 방법을 제공하기 위한 목적으로 시작되었습니다. CRI-O는 OCI 호환 컨테이너 이미지를 사용하며, 이미지 관리, 컨테이너 실행, 스토리지, 네트워킹 등을 처리합니다. CRI-O는 Kubernetes에 최적화되어 설계되었기 때문에, Kubernetes 환경에서 컨테이너를 실행할 때 가볍고 효율적입니다.

 

컨테이너와 컨테이너 오케스트레이션이 한 몸처럼 움직이기 시작했다. 컨테이너를 직접 다룰 일이 줄어들고 있다. 왜냐면 쿠버네티스가 컨테이너 런타임을 알아서 조절해주기 때문이다.

 

컨테이너 오케스트레이션이 무엇이냐?

컨테이너 오케스트레이션은 컨테이너화된 애플리케이션의 배포, 관리, 확장, 네트워킹 등을 자동화하는 과정입니다. 복잡한 현대 애플리케이션은 보통 여러 컨테이너로 구성되며, 이러한 컨테이너들은 서로 통신하면서 작동합니다. 컨테이너 오케스트레이션 도구는 이러한 컨테이너들이 효율적으로, 그리고 신뢰성 있게 실행될 수 있도록 돕습니다.

인기 있는 컨테이너 오케스트레이션 도구
Kubernetes: 가장 널리 사용되는 컨테이너 오케스트레이션 도구로, 복잡한 애플리케이션을 관리하기 위한 강력한 기능을 제공합니다.
Docker Swarm: Docker에 내장된 오케스트레이션 기능으로, 간단하고 빠르게 컨테이너를 오케스트레이션할 수 있습니다.
Apache Mesos/Marathon: 대규모 클러스터 관리에 초점을 맞춘 오케스트레이션 솔루션으로, 높은 확장성과 내결함성을 제공합니다.
컨테이너 오케스트레이션은 클라우드 환경, 마이크로서비스 아키텍처, 지속적인 통합 및 배포(CI/CD) 등 현대적인 소프트웨어 개발 및 배포 방식에 필수적입니다. 이를 통해 개발자와 운영 팀은 애플리케이션의 배포와 운영을 더욱 효율적으로 관리할 수 있습니다.

 

컨테이너 오케스트레이션 정리!

1. App을 컨테이너에 담아서 배포한다.

2. 시스템 운영 노하우를 많이 가지고 있다.

구글이 주도하고 많은 운영 노하우들의 집약체가 쿠버네티스!

기억해야될 내용

1. k8s는 현재 표준을 넘어 여러 분야에서 활용되고 있다.

2. k8s는 컨테이너를 더 쉽게 사용할 수 있게 해준다.

3. 컨테이너는 k8s와의 인터페이스가 중요하다.

 

 

기술의 흐름으로 이해하는 컨테이너

최초의 컨테이너라고 부르는 LXC는 Low Level 컨테이너이다.

High Level 컨테이너는 우리가 친숙하게 알고 있는 Docker 이다.

여기서 Low Level과 High Level은 단순히 기술 수준이 높고 낮음이 아니라 사람이 이해하기 쉽게 작성된 기술이라고 생각하면 된다.

 

도커가 LXC 기반으로 컨테이너를 만들지만 LXC와는 차이가 있다.

도커는 각 App을 독립적인 환경으로 실행하기 위함이고 LXC는 운영체제를 컨테이너 가상화로 나누기 위한 목적이다.

 

RKT는 보안에는 좋지만 Low Level로 실행하기에 사용하기 어려움이 있다.

 

쿠버네티스가 컨테이너 런타임을 어떻게 사용하는가?

k8s에는 kube-apiserver와 kublet이라는 컨테이너가 있다. k8s에는 컨테이너 하나를 생성하는 명령은 없고 pod를 만들라는 명령이 있다.

 

쿠버네티스는 클러스터의 각 노드에서 컨테이너를 실행, 관리하기 위해 kubelet과 컨테이너 런타임을 사용하며, 클러스터 전체를 관리하기 위해 kube-apiserver와 같은 컨트롤 플레인 컴포넌트를 사용합니다. 여기서 kubelet은 각 노드에서 실행되는 에이전트로, 해당 노드의 컨테이너 라이프사이클을 관리합니다. kube-apiserver는 쿠버네티스 API를 통해 사용자와 내부 컴포넌트 간의 인터페이스 역할을 합니다. 컨테이너가 컨테이너 런타임을 어떻게 사용하는지에 대한 과정은 다음과 같습니다.

1. 컨테이너 생성 요청
사용자가 컨테이너 실행 요청: 사용자는 kubectl과 같은 명령줄 도구나 API를 통해 kube-apiserver에 컨테이너를 실행하라는 요청을 보냅니다. 이 요청은 보통 Pod 리소스를 생성하는 명령을 통해 이루어집니다.

요청 처리와 스케줄링: kube-apiserver는 받은 요청을 처리하여 etcd에 상태를 저장하고, scheduler가 이를 감지하여 실행할 최적의 노드를 결정합니다. 결정된 노드 정보는 다시 kube-apiserver를 통해 업데이트 됩니다.

2. kubelet을 통한 컨테이너 실행
노드의 kubelet 감지: 각 노드에 설치된 kubelet은 주기적으로 kube-apiserver와 통신하여 해당 노드에 할당된 새로운 작업(Pods)이 있는지 확인합니다.

컨테이너 런타임 실행 요청: 할당된 작업을 발견하면, kubelet은 CRI(Container Runtime Interface)를 통해 컨테이너 런타임(예: containerd, CRI-O)에게 컨테이너 실행을 요청합니다. 이 과정에서 컨테이너 이미지 다운로드, 볼륨 마운트, 네트워크 설정 등의 작업이 이루어집니다.

 

정리하면, 컨테이너를 생성해주는 역할을 하는게 컨테이너 런타임(Docker)이고 컨테이너는 생성물이다.

컨테이너 표준이란

컨테이너 기술의 폭발적인 성장과 널리 사용됨에 따라, 다양한 컨테이너 런타임과 포맷이 등장했습니다. 이러한 다양성은 혁신을 촉진하지만, 동시에 호환성과 상호 운용성 문제를 야기할 수 있습니다. 이 문제를 해결하기 위해, 업계는 컨테이너 표준을 정의하기 시작했습니다. 대표적인 컨테이너 표준으로는 OCI(Open Container Initiative)와 CNI(Container Network Interface)가 있습니다.

OCI (Open Container Initiative)
OCI는 2015년에 Linux Foundation 산하에서 시작된 프로젝트로, 컨테이너 이미지 포맷과 런타임 사양의 표준화를 목표로 합니다. OCI 표준은 컨테이너화된 애플리케이션을 구축, 배포, 실행하는 방법에 대한 업계 표준을 제공하여, 다양한 환경에서의 호환성과 상호 운용성을 보장합니다.

OCI 이미지 사양(OCI Image Specification): 컨테이너 이미지의 포맷을 정의합니다. 이 사양은 컨테이너 이미지를 생성, 저장, 배포하는 방법에 대한 기준을 마련합니다. Docker 이미지 포맷이 OCI 이미지 사양의 기반이 되었습니다.

OCI 런타임 사양(OCI Runtime Specification): 컨테이너를 실행하기 위한 환경을 정의합니다. 이 사양은 컨테이너 런타임이 컨테이너를 어떻게 실행해야 하는지에 대한 기준을 제공합니다. 여기에는 컨테이너의 실행 환경, 생명주기 관리, 리소스 할당 등이 포함됩니다.

CNI (Container Network Interface)
CNI는 컨테이너의 네트워킹을 위한 표준 사양입니다. CNI는 컨테이너 오케스트레이션 시스템(예: Kubernetes)이 네트워크 플러그인과 통신하는 방법을 정의합니다. 이를 통해 컨테이너 간의 네트워크 연결과 IP 주소 할당, 네트워크 정책 적용 등이 일관되고 유연하게 처리될 수 있습니다.

CNI 사양은 다양한 네트워크 솔루션(예: Calico, Flannel, Weave)이 쿠버네티스 등의 컨테이너 오케스트레이션 시스템과 통합되도록 지원합니다. CNI를 통해 개발자와 시스템 관리자는 네트워크 구성을 보다 쉽게 관리하고, 다양한 네트워크 솔루션 간의 이동성을 확보할 수 있습니다.

컨테이너 표준의 중요성
컨테이너 표준은 개발자가 다양한 환경과 플랫폼에서 일관된 방식으로 컨테이너를 개발, 배포, 실행할 수 있게 합니다. 이는 기술적 장벽을 낮추고, 컨테이너 기술의 이식성과 호환성을 개선하여, 궁극적으로는 클라우드 네이티브 애플리케이션의 혁신과 성장을 가속화합니다. OCI와 CNI 같은 표준은 컨테이너 생태계의 건강한 발전을 위한 기반이 되며, 다양한 기술과 도구가 상호 운용 가능한 방식으로 함께 작동할 수 있는 환경을 조성합니다.

쿠버네티스와 인터페이스에 대한 이야기

쿠버네티스 1.0 ~ 1.20: 초기 발전 단계
초기 쿠버네티스와 컨테이너 런타임: 쿠버네티스 1.0 출시 당시, Kubernetes는 주로 Docker와 같은 특정 컨테이너 런타임에 의존하고 있었습니다. 이는 kubelet이 컨테이너 런타임과 직접 통신하는 구조로, 다양한 컨테이너 런타임을 지원하기 위해 kubelet 소스 코드 내에 많은 분기 로직이 필요했습니다.
분기 로직의 문제점: 컨테이너 런타임이 늘어날수록 kubelet의 코드 관리가 복잡해지고, 새로운 컨테이너 런타임을 지원하기 위해 kubelet을 지속적으로 수정해야 하는 문제가 있었습니다.

 

쿠버네티스 1.5 ~ 1.23: CRI 도입과 발전
CRI(Container Runtime Interface) 도입: 쿠버네티스 1.5에서는 이러한 문제를 해결하기 위해 컨테이너 런타임 인터페이스(CRI)가 도입되었습니다. CRI는 kubelet과 컨테이너 런타임 간의 추상화된 인터페이스를 제공함으로써, 다양한 컨테이너 런타임을 동일한 방식으로 지원할 수 있게 했습니다.
CRI의 구현과 오픈소스 기여: CRI 구현체는 컨테이너 런타임별로 개발되었으며, 이 구현체들은 쿠버네티스 프로젝트에 컨트리뷰션될 수 있습니다. 이로 인해 kubelet의 코드가 대폭 정리되고, 컨테이너 런타임의 추가나 변경이 훨씬 용이해졌습니다.

 

쿠버네티스 1.24 이후: 컨테이너 런타임과의 직접 통신
변경된 구조: 쿠버네티스는 1.24 버전 이후 컨테이너 런타임과의 통신 구조를 더욱 개선하여, kubelet이 CRI를 통해 컨테이너 런타임과 보다 직접적으로 통신할 수 있게 되었습니다. 이 변화는 쿠버네티스와 컨테이너 런타임 간의 통신을 더욱 효율적으로 만들었습니다.

 

처음 시작 시 나왔던 질문에 대한 대답.

 

이 문장이 이해가 된다면 강의를 제대로 이해한 것임. 

 

출처

https://www.inflearn.com/course/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%96%B4%EB%82%98%EB%8D%94-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%A7%80%EC%83%81%ED%8E%B8-sprint1/dashboard

쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 - 인프런

 

- GPT4