쿠버네티스의 구성에 대해 간략하게 알아봅니다.

 

 

 

1. 용어 정리

 

Container: 앱이 구동되는 환경까지 감싸 실행할 수 있도록 하는 격리 기술.
Container Runtime: 컨테이너를 다루는 도구
Docker: 컨테이너 런타임 중 가장 유명한 것.
Orchestration: 여러 서버에 걸친 컨테이너 및 사용 환경을 관리하는 행위.
Kubernetes: 컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구.

 

 

 

2. Kubernetes의 역할

 

쿠버네티스의 역할은 컨테이너를 분산 배치, 상태 관리 및 컨테이너의 구동 환경까지 관리해 주는 도구이고, 도커는 컨테이너 런타임 중 하나입니다. 쿠버네티스는 컨테이너를 다루기 위해 도커 이외에도 다양한 컨테이너 런타임을 사용할 수 있습니다.

 

 

 

3. Kubernetes의 구성

 

쿠버네티스는 다음 그림과 같이 구성되어 있으며 크게 컨트롤 플레인 컴포넌트와 노드 컴포넌트로 나뉩니다.

 

https://kubernetes.io/ko/docs/concepts/overview/components/

 

3.1. 컨트롤 플레인(Control Plane) 컴포넌트

 

⇒ kube-apiserver

쿠버네티스 컨트롤 플레인의 프론트 엔드. 예를 들어 쿠버네티스 커맨드 라인 도구인 kubectl을 사용해 각종 명령을 수행할 경우 이 명령은 kube-apiserver로 전송됩니다. 이렇게 전달된 요청에 대하여 kube-apiserver는 이 요청의 처리 흐름에 따라 적절한 컴포넌트로 요청을 전달하는 역할까지 맡고 있습니다.

 

⇒ etcd

쿠버네티스 클러스터가 동작하기 위해서는 클러스터 및 리소스의 구성 정보, 상태 정보 및 명세 정보 등이 필요합니다. etcd는 이를 키-값(key-value) 형태로 저장하는 저장소입니다. 안정적인 동작을 위해 자료를 분산해서 저장하는 구조를 채택하고 있습니다.


⇒ kube-scheduler

쿠버네티스 클러스터는 여러 노드로 구성되어 있으며 기본적인 작업 단위라고 할 수 있는 파드는 여러 노드 중 특정 노드에 배치되어 동작하게 됩니다. 이때 새로 생성된 파드를 감지하여 어떤 노드로 배치할지 결정하는 작업을 스케줄링이라고 해요. 이런 스케줄링을 담당하는 컴포넌트가 kube-scheduler입니다.


⇒ kube-controller-manager

다운된 노드가 없는지, 파드가 의도한 복제(Replicas) 숫자를 유지하고 있는지, 서비스와 파드는 적절하게 연결되어 있는지, 네임스페이스에 대한 기본 계정과 토큰이 생성되어 있는지를 확인하고 적절하지 않다면 적절한 수준을 유지하기 위해 조치하는 역할을 하고 있습니다.

 

3.2. 노드(Node) 컴포넌트

 

⇒ kubelet

쿠블릿(kubelet)은 노드에서 컨테이너가 동작하도록 관리해주는 핵심 요소입니다. 각 노드에서 파드를 생성하고 정상적으로 동작하는지 관리하는 역할을 담당합니다 실제로 우리가 쿠버네티스의 워크로드를 관리하기 위해서 내리는 명령은 쿠블릿을 통해 수행된다고 볼 수 있습니다. 우리가 파드를 관리하기 위해 작성하는 yaml은 kube-apiserver를 통해 쿠블릿에 전달됩니다. 쿠블릿은 전달받은 yaml을 통해 파드를 생성하거나 변경하고 컨테이너가 정상적으로 실행되고 있는지 확인합니다.


⇒ container runtime

컨테이너 런타임은 파드에 포함 된 컨테이너 실행을 실질적으로 담당하는 애플리케이션을 의미합니다. 컨테이너 런타임은 쿠버네티스 구성요소에 기본적으로 포함되어있거나 특정 소프트웨어를 지칭하지 않습니다. 쿠버네티스가 컨테이너를 제어하기 위해 제공하는 표준 규약인 Container Runtime Imterface(CRI)를 준수하며 쿠버네티스와 함께 사용할 수 있는 외부 애플리케이션을 지칭합니다. 이런 CRI를 준수하는 대표적인 컨테이너 런타임은 containerd 혹은 CRI-O 등이 있습니다.


⇒ kube-proxy

kube-proxy는 쿠버네티스 클러스트 내부에서 네트워크 요청을 전달하는 역할을 합니다. 만약 kube-proxy가 없다면 쿠버네티스 내부에 위치한 특정 파드로 요청을 보내기 위해선 파드의 IP를 정확히 알아야 하며 이 IP를 외부에서 접근할 수 있도록 설정해야 합니다. 하지만 파드의 IP는 배포마다 변경되기 때문에 파드의 IP를 이용하는 방법은 쉽지 않습니다. 따라서 이러한 문제를 해결하기 위해 쿠버네티스는 오브젝트를 통해 고정적으로 파드에 접근할 수 있도록 하는 방법을 제공하고 요청이 실제 파드에 접근할 수 있도록 관리합니다. 이 관리를 담당하는 컴포넌트가 kube-proxy입니다.

 

 

 

4. 파드(Pod)

 

https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

 

파드(Pod)는 쿠버네트스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위입니다. 하나 이상의 컨테이너 그룹을 의미하며 그룹 내 컨테이너는 스토리지 및 네트워크를 공유하게 됩니다. 

 

 

 

5. 워크로드

https://i.redd.it/mmauw9cprt161.png

 

워크로드는 쿠버네티스에서 구동되는 애플리케이션입니다. 워크로드가 단일 컴포넌트든 여러 컴포넌트든 관계없이 쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행합니다. 파드는 클러스터에서 실행 중인 컨테이너 집합을 의미합니다. 파드에는 정의된 라이프사이클이 있으나 사용자가 각 파드를 직접 관리할 필요는 없습니다. 대신 워크로드 리소스를 사용해 파드의 집합을 관리하게 됩니다.

 

 

 

References

 

 

 

 

반응형

+ Recent posts