쿠버네티스 – kubernetes 구성요소

쿠버네티스 는 마스터 노드 워커노드로 구성 되어있고, 마스터 노드에는 아래와 같은 구성요소들로 이뤄져 있다. 시스템 컴포넌트는 오직 API server 와 통신한다.

쿠버네티스 마스터 노드 컴포넌트

control plane 은 cluster 를 관리하고 cluster 기능을 실행한다. 단일 마스터 노드나 여러 노드로 분할이 되고 복제돼 고 가용성을 보장해준다.

API Server

api server는 사용자와 컨트롤 플레인과 통신하는 쿠버네티스 API 서버이다. 클러스터 상태를 쿼리 및 수정할 수 있는 CRUD 인터페이스를 제공한다.

그리고 위 그림과 같이 API server 은 인증, 권한, 승인 plugin을 통해 유효성 검사를 한다.

API Server 가 클라이언트 리소스 변화를 감지하는 방법

client는 API 서버의 HTTP 연결을 통해 여러 변화를 모니터링 한다. 여기서 client 워커노드에 설치된 kubelet 이다. 그리고 클라이언트는 수정 사항을 통보 받을 수 있다. 

controller manager 는 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 등 클러스터 수준 기능을 실행한다.

etcd

etcd는 클러스터 구성을 지속적으로 저장하는 분산 데이터 스토리지이다.

etcd와 직접적으로 통신하는 유일한 컴포넌트는 API server 이다. 모든 컴포넌트는 API server를 이용하여 etcd에 데이터를 읽고 쓴다. 즉 쿠버네티스 클러스터 상태 및 메타 데이터를 저장하는 유일한 장소.

etct 저장된 데이터는 key/value 형식으로 저장되고, /registry 밑의 etcd에 모든 데이터를 저장한다.

$ etcdctl ls /register
$ etcdctl ls /register/pods
$ etcdctl ls /register/pods/default

etcd cluster

고가용성을 보장하기 위해 etcd 인스턴스를 하나 이상 실행 해야 하고, 이럴경우 실제 상태에 대한 합의를 이뤄야 하는데 RAFT 합의 알고리즘을 사용하는데, 주어진 순간에 각 노드의 상태가 현재 대부분의 노드가 동의한 상태인지 확인하거나 이전에 합의한 상태 중 하나임을 확인한다.

합의 알고리즘은 클러스터가 다음 상태로 전환될 수 있도록 과반수를 요구한다. 그 결과 클러스터가 두 개의 연결 해제 노드 그룹으로 분할되면 두 그룹의 상태가 서로 바뀔 수 없다. 이전 상태에서 새로운 상태로 전환하려면 상태 변화에 참여하는 절반 이상의 노드가 필요해진다. 하나의 그룹이 모든 노드의 대부분을 포함하는 경우라면 다른 그룹은 그렇게 될 수 없다. 첫 번째 그룹은 클러스터 상태를 수정할 수 있지만 다른 그룹은 수정할 수 없다.  두 개의 그룹이 다시 연결되면 두 번째 그룹은 첫 번째 그룹의 상태를 따라 잡을 수 있다.

etcd 인스턴스는 홀수개야 한다. 인스턴스가 두 개 있다면 두 인스턴스가 모두 있어야 과반수가 된다. 두 개 중 하나에 장애가 발생하는 경우 다수가 없으므로 etcd 클러스터를 새 상태로 전환할 수 없다. 인스턴스가 두 개인 것은 단일 인스턴스만 갖는 것 보다 더 좋지 않다.

인스턴스가 세개 일때 한 개의 인스턴스가 실패할 수 있고 과반수는 여전히 존재 한다. 네 개의 인스턴스일 때 과반수를 위해 세 개의 노드가 필요하다.

scheduler

pod가 실행될 때 클러스터 노드를 지정하지 않는다. schedule 가 하는 일은 API Server 의 감시 메커니즘을 통해 생성된 pod를 기다리고, 새로운 pod를 노드에 할당한다.

기본 schedule 알고리즘

노드의 목록을 필터링 하고 허용하는 노드를 우선순위하고 최적의 노드를 선택한다. 다수의 노드가 가장 높은 점수를 갖는다면 pod가 공평하게 배포 될 수 있도록 round robbin 이 사용된다.

schedule가 수용가능한 노드찾기

– 노드가 pod의 하드웨어 리소르 요청을 이행할 수 있을지?
– 노드에 리소스가 부족한지?
– pod가 이름으로 특정 노드에 스케줄되도록 요청을하는 경우, 이것은 노드인지?
– 노드가 pod 스펙의 노드 셀렉터에 맞는 라벨을 가질 수 있는지?
– pod가 특정 호스트 pod에 바인딩을 요청하는 경우 해당 노드에 pod가 실행되고 있는지?
– pod가 특정 볼륨 유형을 요청하는 경우, 이 보륨의 노드의 pod에 마운트할 수 있는지? 아니면 노드의 다른 pod에서 이미 동일한 볼륨을 사용하고 있는지?
– pod는 노드의 taints를 허용하는지?
– pod가 노드나 pod의 친화성과 비친화성 규칙을 설정할 수 있는지? 그렇다면 이 규칙을 어길 수 있는 노드로 pod가 스케줄 되어야 한다.

controller

– 리플리케인션 매니저(리플리케이션 컨트롤러 리소스 컨트롤러)
– 리플리카셋, 데몬셋, 잡 컨트롤러
– 디플로이먼트 컨트롤러
– 스테이트풀셋 컨트롤러
– 노드 컨트롤러
– 서비스 컨트롤러
– 엔드포인트 컨트롤러
– 네임스페이스 컨트롤러
– 볼륨 컨트롤러
– etc 컨트롤러

쿠버네티스 워커 노드 컴포넌트

kubelet

워커노드에서 실행되는 모든 것에 책임을 지는 컴포넌트이다.
API Server에서 노드 리소스를 생성해 실행하고 있는 노드를 등록한다
노드에 스케줄됐던 pod에 대해 API Server를 모니터 해야 한다.
pod의 컨테이너를 실행하고, 실행 중인 컨테이너를 모니터링 하고 정보를 API Server에 보고한다.

kube-proxy

kube-proxy는 서비스 IP 및 포트 연결을 보장한다. 서비스가 둘 이상의 port로 백업되면 프록시는 해당 port에서 load balancing을 수행한다.

애드온 컴포넌트

쿠버네티스 DNS 서버

클러스터의 모든 pod는 클러스터의 내부 DNS 서버를 사용하도록 구성되어 있다.
서비스의 IP 주소는 클러스터에 배포되는 매 컨테이너 내부 /etc/resolv.conf 파일의 내부 nameserver에 지정된다. kube-dns pod는 API 서버의 서비스와 엔드포인트로의 변화를 관찰하기 위해 감시 메커니즘을 사용하고 변화할 때마다 DNS 레코드를 갱신한다.

ingress controller

인그레스 컨트롤러는 Nginx와 같은 역프로시 서버를 실행하고 클러스터의 인그레서, 서비스 엔드포인트 리소스에 따라 구성을 유지한다.
인그레스 리소스의 정의가 서비스를 향하더라도 인그레스 컨트롤러는 트래픽을 서비스 IP를 통해 가는 것 대신, 서비스 pod 로 직접 전달한다. 외부 클라이언트가 인그레스 컨트롤러를 통해 연결할 때 클라이언트 IP 보존에 영향을 미친다.

Heapster, network interface plugin

답글 남기기