본문 바로가기

DevOps

Kubernetes 구조 이해하기

728x90

 

 

참고 사이트 :

kubernetes 사이트

따라하면서 배우는 쿠버네티스

참고 블로그 : 쿠버네티스 고가용성 클러스터 구성

참고 블로그 : 따배쿠 멀티마스터 ... 정리

참고 블로그 : 쿠버네티스 개념과 구성 컴포넌트 알아보기

 

 

쿠버네티스를 배포하면 클러스터를 얻는다.

출처 : https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/

 

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 과 통신한다. 

 

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

 

 

 

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

출처 : https://youtu.be/Iue9TC13vPQ

  • 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 컨테이너 런타임 ) 

 

그럼 이제 쿠버네티스를 설치하러 가보자!

 

 

 

 

728x90