[kubernetes] 쿠버네티스 아키텍처

 

 

[kubernetes] 쿠버네티스 목차

 

ㅁ 들어가며

 쿠버네티스의 개념과 기능에 대해서 알아보았다. 이 글에서는 쿠버네티스를 이해할 수 있는 아키텍처를 정리하였다. 전반적인 이해를 위해서는 아키텍처를 이해해야한다. 최고 상위 개념인 Cluster과 그에 종속하는 하위의 개념들을 차례로 나열하고, 역할에 따라 모듈화된 객체들의 개념을 설명하도록 하겠다.

 

ㅁ Cluster, Node, Pod, Container 관계

클러스터에 대한 가장 단순한 구조이다. 애플리케이션 컨테이너가 실제로 배포되는 위치를 보여준다.

클러스터 안에는 여러 노드로 구성되어 지는데, 물리적 서버 혹은 VMS으로 구성할 수 있다.

흔히 이야기하는 서버의 단위가 Node이다. 이 서버에 여러 Pod가 구동하고 그 안에 애플리케이션 컨테이너가 구동된다.

 

클러스터의 제어역할을 기준으로 아케텍처를 살펴보자.

 

ㅁ 클러스터와 마스터

 

 

쿠버네티스는 물리 리소스를 클러스터 단위로 관리한다. 전체 클러스터를 관리하고 제어권한 역할을 하는 Control Plane와 컨테이너를 생성하는 역할의 Node로 구성된다. 컨트롤 플레인이 기동하는 Master Node와 컨테이너를 생성하는 Work Node로 구분된다. 클러스터는 물리적으로 여러 대의 서버가 분리되어 있지만, 모든 명령은 마스터의 API 서버를 통해서 작업을 수행하기 때문에 사용자가 하나의 서버처럼 사용할 수 있게 한다.

 

ㅁ Master 

마스터 서버는 역할에 따라 모듈화하여 기능별로 구분되어 있다. etcd, kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager 등이 마스터 노드에 속해 있습니다. 클러스터 관리의 안정성을 위해 마스터노드는 보통 3대를 구성합니다. AWS EKS 같은 경우 안정성을 위해 마스터를 자체 관리하기 때문에 접근이 불가한데, 개발환경이나 소규모 환경에선 마스터와 노드를 분리하지 않고 하나의 서버에 구성할 수 있습니다.

 

ㅇ API server

- API server는 쿠버네티스 클러스터의 API를 사용할 수 있도록하는 컴포넌트입니다.

- API 서버에 대한 모든 요청은 인증 및 승인 확인을 거친다. 

- API 서버에 온 요청의 유효성을 검사하여 클러스터에 필요한 변경 사항을 적용한다.

 

ㅇ etcd(Cluster Storage)

- etcd는 키-값 저장소로, 쿠버네티스에서 필요한 모든 데이터를 저장하는 데이터베이스 역할을 한다. 

- 널리 사용되는 RAFT 합의 알고리즘을 사용하여 스토리지에 대한 쓰기 일관성을 유지한다.

- 여러 개로 분산하여 복제할 수 있기 때문에 안정성이 높고 속도도 빠른 편이다.

- watch 기능을 통해 변경되면 바로 체크하여 로직을 실행할 수 있다.

- etcd는 오직 API 서버와 통신하고 다른 모듈은 API 서버를 거쳐 etcd 데이터에 접근한다. 

 

ㅇ scheduler

- 스케줄러는 할당 가능한 노드 중 알맞은 노드를 선택해서 Pod를 할당한다. 

- taint, affinify, 조건에 따라 Node를 할당할 수 있다.

 

ㅇ Controller Manager(CM)

https://sunitc.dev/2020/12/24/a-simplified-view-of-kubernetes-cluster-and-its-components-architecture/

 

 쿠버네티스는 파드들을 관리하는 컨트롤러가 있다. 컨트롤러 관리자는 선언적 요구사항, desired state에 맞추기 위해 클러스터를 모니터링하고 이벤드에 응답하여 조치를 한다. 

 

쿠버네티스 배포 방식

 

 다양한 목적에 맞게 사용할 수 있는 Deployment, StatefulSets, DaemonSet, Job, CronJob등이 있어 다양한 배포 방식을 지원한다. Deployment는 새로운 버전의 애플리케이션을 다양한 전략으로 무중단 배포할 수 있다. Replicaset은 지정한 숫자만큼파드가 실행하도록 관리하는 가장 기본적인 컨트롤러이다. StatefulSets은 실행 순서를 보장하고 호스트 이름과 볼륨을 일정하게 사용할 수 있어 순서나 데이터가 중요한 경우에 사용할 수 있다. 노드의 로그나 모니터이 필요한 경우엔 DaemonSet을 이용하고 배치성 작업은 Job이나 CronJob을 이용한다.

 

ㅇ Cloud Controller Manager(CCM)

- 클러스터가 AWS, Azure, GCP 등과 같은 지원되는 퍼블릭 클라우드 플랫폼에서 실행 중인 경우 제어 플레인은 클라우드 컨트롤러 관리자를 실행한다.

- 인스턴스, 로드밸런스, 스토리지 등 기본 클라우드의 자원과 서비스를 통합 관리하는 역할을 한다.
 ㄴ 노드 컨트롤러: 클라우드 서비스 안에서 노드를 관리하는 데 사용한다.

 ㄴ 라우트 컨트롤러: 각 클라우드 서비스 안의 네트워크 라우팅을 관리한다.

 ㄴ 서비스 컨트롤러: 각 클라우드 서비스에서 제공하는 로드밸런서를 생성, 갱신, 삭제하는 데 사용한다.

 ㄴ 볼륨 컨트롤러: 클라우드 서비스에서 생성한 볼륨을 노드에 연결하거나 마운트하는 데 사용한다.

 

- 예를 들어 애플리케이션이 인터넷 연결 로드밸런서를 요청하면 CCM은 클라우드 플랫폼에 적절한 로드밸런서를 프로비저닝하도록 한다.

- Kubernetes 클러스터가 온프레미스 배포에서 호스팅되거나 로컬 클러스터를 실행하는 경우(예: minikube, kind 등을 사용하는 경우) 이 관리자는 표시되지 않는다.

 

ㅁ Node 

노드 서버는 마스터 서버의 제어를 받아 컨테이너화된 애플리케이션을 실행하고 네트워크와 볼륨을 설정하여 서비스가 구동한다. 서비스의 확장성을 고려하여 Node는 확장되며, 각각의 서버에 라벨을 붙여 사용목적(배치를 위한 메모리 특화, 머신러닝을 위한 GPU 특화, SSD 서버)에 따라 자원을 관리할 수 있다. 노드는 클러스터에 따라 가상 머신일 수도 있고 물리적 머신일 수도 있다. 

 

클러스터에 새로운 노드가 추가되면, 노드를 제어하기 위한 구성요소가 자동으로 설치된다. 노드의 주요 구성 요소는 다음과 같다.

 

ㅇ Kubelet

Kubelet은 클러스터의 모든 노드에서 실행되는 에이전트이다. 파드 컨테이너들의 실행을 직접적으로 관리한다.

신규 파드가 생성되면 kubectl은 파드스펙을 API server로부터 받아서 컨테이너를 실행하고 컨테이너가 정상적으로 실행되는지 헬스체크를 한다. 

 

ㅇ kube-proxy

쿠버네티스는 클러스터 안에 별도의 가상 네트워크를 설정한다. kube-proxy는 호스트의 네트워크 규칙을 관리하거나 연결을 전달한다. 예를 들어 각 노드가 고유한 IP 주소를 갖도록 하고 로컬 IPTABLES 또는 IPVS 규칙을 구현하여 포드 네트워크에서 트래픽 라우팅 및 로드 밸런싱을 처리한다.

 

ㅇ Container runtime

컨테이너 런타임은 실제로 컨테이너를 실행시키기 위해 이미지 가져오기, 컨테이너 시작 및 중지 등의 작업을 수행한다. 런타임에는 Docker, containerd, runc가 있다. OCI(Open Container Initiative)의 런타임 규격을 구현한 다른 컨테이너 런타임도 사용할 수 있다. CNCF재단의 containerd를 도커 없이 기본 런타임으로 사용할 수도 있다.

 Containerd는 Linux 및 Windows용 데몬으로 사용할 수 있다. 이미지 전송 및 저장부터 컨테이너 실행 및 감독, 하위 수준 저장, 네트워크 연결 및 그 이상에 이르기까지 호스트 시스템의 전체 컨테이너 수명주기를 관리한다.

 

ㅇ Pod

포드는 Kubernetes에서 가장 작은 배포 단위이며 애플리케이션을 배포하는 데 사용된다. 포드는 하나 이상의 컨테이너들의 자원을 공유할 수 있다. 같은 목적으로 실행되는 컨테이너는 자원의 공유가 필요하다. 공유자원으로는 IP 주소, 포트, 호스트 이름, 소켓, 메모리, 볼륨 등이 있다. 각 포드는 자체 네트워크를 생성한다. 컨테이너끼리 자체 통신이 가능하도록 IP, 포트 범위, 라우팅 테이블을 공유하고 전체 액세스 권한을 갖는다.  

 

ㅁ Kubernetes DNS

 쿠버네티스는 클러스터 내부에 DNS를 설정할 수 있다. 이를 통해 도메인으로 파드 간의 통신을 할 수 있다. 모든 Kubernetes 클러스터에는 내부 DNS 서비스가 있다. 클러스터의 DNS 서비스에는 클러스터의 모든 포드의 고정 IP주소가 있어서 모든 컨테이너와 Pod가 이를 찾을 수 있다. 모든 새로운 서비스는 클러스터의 DNS에 자동으로 등록되므로 클러스터의 모든 구성 요소는 이름으로 모든 서비스를 찾을 수 있다. Pod마다 .spec.dnsPolicy 필드를 사용하여 도메인 요청하는 순서를 설정할 수 있다. 
참고:
Kubernetes 네트워크 이해

ㄴ 소제목: 쿠버네티스 DNS, kube-dns 질의 구조

[kubernetes] 다른 네임스페이스에 위치한 서비스 접근방법

 ㄴ 소제목: 서비스 및 파드용 DNS 부분

 

ㅁ 마무리

 

  이전 글에서 kubernetes의 개념과 기능에 대해서 알아보고 이를 구성하기 위한  kubernetes 아키텍처를 살펴보았다. Cluster과 그 안에 종속되는 하위의 개념들을 차례로 나열하며 모듈화된 객체를 설명하였다.

 

다음 글, Pod 생성 과정에서 쿠버네티스 오브젝트 역할이해하기에서는 Pod과 생성되는 과정을 객체들의 역할을 시퀀스 다이에그램으로 설명하였다. 

 

 그 다음으로 위의 그림처럼 쿠버네티스가 수행할 수 있는 다양한 기능을 위한 쿠버네티스의 리소스에 대해서 알아보도록 하겠다.

 

ㅁ 함께 보면 좋은 사이트

ㅇ [kubernetes] 쿠버네티스 개념 정리

ㅇ Kubernetes 네트워크 이해

    ㄴ 소제목: 쿠버네티스 DNS, kube-dns 질의 구조

ㅇ [kubernetes] 다른 네임스페이스에 위치한 서비스 접근방법

    ㄴ 소제목: 서비스 및 파드용 DNS 부분

ㅇ CNCF재단의 Containerd(도커 없이 기본 런타임)