참고 사이트 :
참고 블로그 : 쿠버네티스 개념과 구성 컴포넌트 알아보기
쿠버네티스를 배포하면 클러스터를 얻는다.

Kubernetes Cluster 는 크게 Control Plane 과 Node 로 분류할 수 있다.
- Control Plane 은 클러스터 내부 요소들을 제어한다. 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다. 이러한 Control Plane 은 하나 이상의 Master Node 에 복제해 관리 할 수 있다.
- Node 는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터로, 각 Node 는 Node 를 관리하고 쿠버네티스 Control Plane 과 통신하는 Kubelet 과 Container 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다.
Node 는 Control Plane 이 제공하는 Kubernetes API 를 통해서 Control Plane 과 통신한다.

다음과 같이 Master Node(master.example.com) 와 Node(node1.example.com , node2.example.com) 들이 있다고 가정하면 각각의 구성요소(컴포넌트)는 크게 다음과 같다.

- API : 클러스터의 각 요소들을 모니터링하며 작업을 수행하도록 해주는 중앙 접근 포인트의 역할을 한다. 사용자가 kubectl 명령을 통해 Kubernetes 를 조작하는 것이 API 를 통해 조작한다고 생각하면 된다.
- etcd : 모든 클러스터 데이터(Node들의 상태 값, 하드웨어 리소스 값 등)를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 key-value 저장소이다. 마치 DataBase 라 비유할 수 있다. 이때 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다. (참고 : kubernetes etcd 클러스터 백업 )
- scheduler : 노드가 배정되지 않은 새로 생성된 Pod(하나 이상의 컨터이너를 묶어 실행하는 단위) 를 감지하고, 실행할 노드를 선택하는 컴포넌트이다.
- controller : 논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다. ( 참고 : kubernetes 컨트롤러 ) 이들 컨트롤러는 다음을 포함한다. ( 추가적으로 클라우드 플랫폼을 이용한다면, 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분지을 수도 있다. cloud-controller-mananer )
- 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
- 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
- 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
- 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스(pod 들을 효율적으로 묶어 관리하기 위한, 구분지을 수 있게 해주는 논리적인 공간)에 대한 기본 계정과 API 접근 토큰을 생성한다.
각각의 Node 에 존재하는 Node 컴포넌트로는 kubelet , kube-proxy , container-runtime 이 속해 있다.
- kubelet : 클러스터의 각 Node에서 실행되는 에이전트. Kubelet은 Pod에서 Container가 확실하게 동작하도록 관리한다. kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 Container 가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다. 또한 kubelet 은 데몬으로 동작하면서 c-advisor 라는 Container 모니터링을 통해 현재 Container 의 상태를 수집한다. 이렇게 수집된 데이터는 master-node 에 있는 etcd 에 저장하게 된다.
- kube-proxy : kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다. kube-proxy 는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. 쉽게 생각하면 Master Node 에서 들어오는 명령을 받아주는 역할이라 생각하면 된다. (참고 : kubernetes kube-proxy , kubernetes 서비스 )
- container-runtime : 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다. 쿠버네티스는 containerd, CRI-O , cri-dockered 와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지원한다. ( 참고 : kubernetes 컨테이너 런타임 )
'DevOps' 카테고리의 다른 글
kubernetes 개념 (2) | 2022.09.22 |
---|---|
Docker container 를 활용해 CI/CD 실습해보자 feat(Jenkin, Ansible, Minikube) (0) | 2022.09.14 |
최신 (k8s - 2022.07 기준) kubernetes 설치 (0) | 2022.07.31 |
Terraform 을 사용해 AWS EC2 Instance 를 올려보자 (0) | 2022.07.26 |
AWS를 통한 효과적인 데브옵스 구축 2/e 2장 중 AWS CLI 로 EC2 구성하기 (0) | 2022.07.20 |