쿠버네티스 컴포넌트
-
쿠버네티스를 배포하면클러스터를 얻는다. -
쿠버네티스 클러스터는컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합입니다. -
모든 클러스터는 최소 한 개의 워커 노드를 가집니다.
-
워커 노드는 애플리케이션의 구성요소인 파드를 호스트합니다. -
컨트롤 플레인(제어 평면)은 워커 노드와 클러스터 내 파드를 관리합니다. -
프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로
내결함성과고가용성이 제공됩니다.
Master - Node 구조
쿠버네티스는 전체 클러스터를 관리하는
마스터와 컨테이너가 배포되는노드로 구성되어 있습니다.
모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행합니다.
특정 노드의 컨테이너에 명령하거나 로그를 조회할 때도 노드에 직접 명령하는 게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답합니다.
Namespace
- 물리 클러스터 내의 복수의 가상 클러스터입니다.
- 개발/운영/테스트 등을 네임스페이스로 나누면 개발은 CPU 100개, 운영은 400개와 같이 네임스페이스별로 파드나 서비스를 나눠서 관리할 수 있습니다.
Master
- 마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있는 것이 특징입니다.
- 관리자만 접속할 수 있도록 보안 설정을 해야 하고 마스터 서버가 죽으면 클러스터를 관리할 수 없기 때문에 보통 3대를 구성하여 안정성을 높입니다.
- AWS EKS 같은 경우 마스터를 AWS에서 자체 관리하여 안정성을 높였고(마스터에 접속 불가) 개발 환경이나 소규모 환경에선 마스터와 노드를 분리하지 않고 같은 서버에 구성하기도 합니다.
Node
- kubelet, kube-proxy, 동작중인 pod를 유지시키고 런타임 환경을 제공합니다.
- 노드 서버는 마스터 서버와 통신하면서 필요한 Pod을 생성하고 네트워크와 볼륨을 설정합니다.
- 실제 컨테이너들이 생성되는 곳으로 수백, 수천대로 확장할 수 있습니다.
- 각각의 서버에 라벨을 붙여 사용목적(GPU 특화, SSD 서버 등)을 정의할 수 있습니다.
Kubectl
- API 서버는 json 또는 protobuf 형식을 이용한 http 통신을 지원합니다.
- 이 방식을 그대로 쓰면 불편하므로 보통 kubectl이라는 명령행 도구를 사용합니다.
- 어떻게 읽어야 할지 난감한데 공식적으로 큐브컨트롤(cube control)이라고 읽지만 큐브씨티엘, 쿱컨트롤, 쿱씨티엘등도 많이 쓰입니다.
Control plane 컴포넌트 - Master Node
컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것)를 감지하고 반응합니다.
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있습니다.
그러나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고, 사용자 컨테이너는 해당 머신 상에 동작시키지 않습니다.
kube-apiserver
API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트입니다.
API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드입니다.
쿠버네티스 클러스터의 중심 역할을 하는 통로입니다.
수평으로 확장되도록 디자인되었습니다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있습니다.
주로 상태 값을 저장하는 etcd와 통신하지만, 그 밖의 요소들 또한 API 서버를 중심에 두고 통신하므로 API 서버의 역할이 매우 중요합니다.
회사에 비유하면모든 직원과 상황을 관리하고 목표를 설정하는 관리자에 해당합니다.
etcd (분산 데이터 저장소)
모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소입니다.
회사의 관리자가 모든 보고 내용을 기록하는 노트라고 생각하면 됩니다.
실제로 etcd 외의 다른 구성 요소는 상태 값을 관리하지 않습니다.
etcd의 정보만 백업돼 있다면 긴급한 장애 상황에서도 쿠버네티스 클러스터는 복구할 수 있습니다.
etcd는분산 저장이 가능한 key-value 저장소이므로, 복제해 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나더라도 시스템의 가용성을 확보할 수 있습니다.
kube-scheduler
노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트입니다.
노드의 상태와 자원, 레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정 및 할당합니다.
kube-controller-manager
컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트입니다.
쿠버네티스에 있는 거의 모든 오브젝트의 상태를 관리합니다.
오브젝트별로 철저하게 분업화되어 Deployment는 ReplicaSet을 생성하고 ReplicaSet은 Pod을 생성하고 Pod은 스케줄러가 관리하는 식입니다.
cloud-controller-manager
클라우드 컨트롤러는 AWS, GCE, Azure 등 클라우드에 특화된 모듈입니다.
노드를 추가/삭제하고 로드 밸런서를 연결하거나 볼륨을 붙일 수 있습니다.
각 클라우드 업체에서 인터페이스에 맞춰 구현하면 되기 때문에 확장성이 좋고 많은 곳에서 자체 모듈을 만들어 제공하고 있습니다.
Node 컴포넌트 - Worker Node
노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작합니다.
kubelet
파드의 구성 내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링합니다.
Kubelet은 다양한 메커니즘을 통해 제공된파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 합니다.
파드를 생성하고 파드 안의 컨테이너에 이상이 없는지 확인하면서 주기적으로 마스터에 상태를 전달합니다.
Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않습니다.
API 서버의 요청을 받아 컨테이너의 로그를 전달하거나 특정 명령을 대신 수행하기도 합니다.
프록시 kube-proxy
파드로 연결되는
네트워크를 관리합니다.
쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정합니다.
TCP, UDP, SCTP 스트림을 포워딩하고 여러 개의 파드를 라운드로빈 형태로 묶어 서비스를 제공할 수 있습니다.
컨테이너 런타임
컨테이너 런타임은컨테이너 실행을 담당하는 소프트웨어입니다.
파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스입니다.
Reference
