fisache

본 포스팅은 Udemy Certificated Kubernetes Administrator 강좌를 공부한 내용입니다.

Kubernetes Data Plane 이란

Kubernetes를 설치했다면 거기에서 동작시킬 어플리케이션은 어디서 어떻게 동작이 될까?

Data Plane은 사용자의 application이 돌아갈 수 있도록 도와주는 component를 나타낸다.

Data Plane의 component는 모든 Minion(Worker) Node에 위치해 있으며 Control Plane에 응답하거나 Data Plane 간에 요청/응답 한다.

구성요소로는 kubelet, kube-proxy, runtime container등이 있다.

Runtime Container

실제 Container를 동작/정지시킬 수 있는 daemon을 의미한다.

주로 Docker를 많이 사용하며 이 밖에도 rocket, CRI-O 등이 있다.

역할

• Container lifecycle 관리

Kubelet

각 Worker Node를 배(ship)라고 생각했을 때 kubelet은 이 배의 선장을 의미한다.

역할

• Control Plane의 Scheduler(kube api-server)로부터 배정된 Container를 실행시키거나 종료한다.
• 주기적으로 Container의 상태를 kube api-server에 report한다.

예시 1. Container 생성 요청을 받았을 경우 kubelet은 Container Runtime 데몬에게 명령한다.

예시 2. 주기적으로 Container의 상태를 Control Plane에 report 한다.

kubelet은 다른 component와는 다르게 kubeadm을 통해 설치할 수 없고 오직 manual 적으로만 설치가 가능하다고 한다.

역시 설치 부분은 다음에 한다고 한다.

kube-proxy

같은 Kubernetes Cluster에 있는 WAS Pod이 Database Pod에 접근해 SQL을 사용하고 싶다면 어떻게 해야할까?

WAS Pod이 Database Pod의 IP를 알고 있으면 된다.

Worker Node의 Pod은 실행될 때 k8s cluster 내부 IP를 할당받는다.

그런데 Pod은 언제든 다른 node로 옮겨질 수 있고 그 때 다른 IP가 할당될 것이다.

이를 위해 kubernetes에서는 Service를 통해 Pod 간의 네트워크 통신을 한다.

Service는 특정 IP를 배정받아 가지고 있고 또한 연결시켜줄 Pod의 IP를 알고 있다.

그러면 WAS Pod는 Database Pod이 연결되어 있는 Service의 IP를 알면 된다.

Service IP를 매번 알아야 하고 Service IP 역시 변경될 수 있기 때문에 Service Name을 이용해 통신을 할 수 있다.

즉, WAS Pod는 Database Pod이 연결된 Service의 이름을 알면 된다.

이러한 통신을 할 수 있게 해주는게 kube-proxy의 역할이다.

kube-proxy는 모든 node에 설치되며 Service와 연결된 Pod IP에 대한 일종의 IPTABLE을 공유하고 있다.

Kubernetes Cluster에서 IP가 변경되는 특정 이벤트가 발생하게 되면 모든 node의 kube-proxy가 자신의 Table을 업데이트 한다.

간략하게 아래와 같은 Table 정보를 모든 kube-proxy가 가지고 있게되며 이를 통해 Pod 간의 네트워크 통신을 도와준다.

Kubernetes의 네트워크 부분은 이보다 더 많은 내용이 있기 때문에 다음 시간에 더 깊게 살펴본다고 한다.

kube-proxy는 kubeadm으로 설치가 가능하며 설치하게 되면 kube-proxy pod를 daemon-set으로 설치한다

정리

Data Plane의 구성요소에 대해 간략하게 살펴보았다.

kubelet과 kube-proxy의 역할에 대해 정리할 수 있었고 Control Plane과의 관계도 자세히 알 수 있었다.

본 포스팅은 Udemy Certificated Kubernetes Administrator 강좌를 공부한 내용입니다.

Kuberentes Control Plane 이란

Kubernetes에 배포되는 Container를 관리하기 위한 구성요소들을 Kubernetes Control Plane이라고 한다.

주로 master node에 배포되며 minion node의 kubelet과 통신하면서 Container를 관리한다.

Control Plane의 구성 요소

etcd : K-V 저장소이며 kubernetes cluster 정보를 저장한다.

kube-api-server : kubernetes의 API server이며 minion node를 관리하는 kubelet, 사용자 client kubectl 등과 통신한다.

kube-controller-manager : kubernetes의 resource(node, replicaset, pod, service account, secret 등)을 모니터링하며 관리한다.

kube-scheduler : pod가 어느 minion node에 배치될지를 결정한다.

kube-api-server

kubernetes의 API server

역할 :

• Control Plane의 구성요소 및 minion node의 kubelet 사이를 통신해주는 역할을 한다.
• 사용자가 kubectl을 사용할 때 요청을 받아 처리하는 역할을 한다.

예시. kubectl create pod Process

1. Authenticate User
   - 사용자가 인증된 사용자인지 확인한다. (cert key 또는 oidc)
2. Validate Request
   - 요청이 올바른 요청인지 확인한다.
3. Retrieve data
   - 요청에 대한 결과를 응답한다. (Pod 생성 요청 완료)
4. Updatae ETCD
   - 생성 요청된 POD 정보를 ETCD에 업데이트 한다.
5. Scheduler
   - Scheduler에게 POD이 배치될 Minion Node를 요청한다.
6. Kubelet
   - Schduler에게 받은 Minion Node의 Kubelet에게 POD 생성을 요청한다.

kube-controller-manager

Kubernetes의 resource를 모니터링 및 관리

하나의 프로세스지만 각 resource를 담당하는 모듈이 다 별도로 존재함

역할 :

• Kubernetes Resource 상태 모니터링(Watch Status)
• Resource에 이슈 발생 시 조치(Remediate Situation)

예시. node-controller monitoring

1. Node Monitor Period (5s)
   - kube-api-server --> kublet을 통해 5초마다 node의 상태를 요청한다.
2. Node Monitor Grace Period (40s)
   - kubelet이 응답하지 않았을 시, unreachable 상태를 마킹하고 40초를 더 대기한다.
3. POD eviction TImeout (5m)
   - 40초 이후에도 응답하지 않을 시, 해당 node에 떠있는 POD를 다른 node로 이전시킨다.
   - POD이 replicaset이라면 replicaset-controller를 통해 POD을 이전시킨다.
   
   

예시. replicaset-controller monitoring

1. Replicaset의 POD 갯수가 유지되고 있는지 확인한다.
2. 갯수가 맞지 않을 경우 새로운 POD를 생성한다.

kube-scheduler

POD를 어느 node에 배정될지 결정

직접 POD를 실행시키지 않음, POD를 실행시키는 역할은 각 minion node의 kubelet

역할:

• 정해진 Scheduling 방식에 의해 POD이 배정될 node를 결정한다.

예시. POD Scheduling

1. 4개의 minion node가 각기 다른 가용 CPU resource를 가지고 존재한다.
   - minion 1 : CPU 4 core
   - minion 2 : CPU 6 core
   - minion 3 : CPU 12 core
   - minion 4 : CPU 16 core
2. CPU를 10 core 사용하는 POD 생성 요청이 들어와 이를 Sheduleing 함.
3. POD가 들어갈 수 없는 minion 1, minion 2를 제외함
4. POD가 생성되었을 경우 minion node의 가용 CPU를 계산함
   - minion 3 : CPU 2 core
   - mnion 4 : CPU 6 core
5. minion 4의 가용 CPU가 많기 때문에 minion 4에 POD를 배정할 것을 결정함.
6. minion 4의 Kubelet이 POD를 생성함.

Affinity, taint-and-toleration 등에 의해 스케쥴링 방식이 위 예시처럼 간단하진 않다고 한다.

더 자세한 내용은 다음에 해준다고함.

정리

control plane 구성요소를 간단하게 살펴볼 수 있었음

각 구성요소 간의 통신을 위한 certificate는 다음에 살펴본다고 함

kubeadm 또는 manaual deploy 방법 또한 다음에 살펴본다고 함

본 포스팅은 Udemy Certificated Kubernetes Administrator 강좌를 공부한 내용입니다.

ETCD란?

Distributed Reliable Key Value Store

일반적인 Key/Value Store보다 높은 안정성과 분산 환경을 제공해줄 수 있어 위와 같이 설명된 것 같다.

또한 Key/Value Store이다보다 사용이 굉장히 쉽고 적은 데이터 환경에서는 아주 빠르게 이용할 수 있다.

하지만 많은 데이터가 저장되는 용도로는 좋지 않다고 한다.

ETCD 기본 명령어

ETCD는 일반 K-V Store 처럼 Key/Value에 대한 operation을 지원한다.

ETCD 설치는 아래 링크 참조

https://github.com/etcd-io/etcd/releases

$ ./etcdctl version
etcdctl version: 3.4.9
API version: 3.4

# K-V 생성
$ ./etcdctl put key value
OK

# K-V 조회
$ ./etcdctl get key
key
value

# K-V 삭제
$ ./etcdctl del key
1

일반적인 K-V operation 이외에 지원되는 기능으로는 Key를 Directory 구조로 사용할 수 있다.

$ ./etcdctl put parent/child1 value1
OK

$ ./etcdctl put parent/child2 value2
OK

$ ./etcdctl get parent/ --prefix
parent/child1
value1
parent/child2
value2

$ ./etcdctl del parent/ --prefix
2

위처럼 --prefix option을 통해 parent의 하위 directory를 조회/삭제하는 것과 유사한 결과가 나오는 것을 확인할 수 있다.

Kubernetes의 ETCD

Kubernetes에서 ETCD이 역할은 k8s cluster의 정보를 저장하는 역할이다.

k8s cluster 정보라는 것은 nodes, pods, configs, secrets 등 kubectl get 을 사용했을 때 조회할 수 있는 resource type 등을 의미한다.

kubernetes를 위한 ETCD를 배포하기 위한 방법은 Manual 적으로 배포하는 방법과 kubeadm 이용하는 방법이 있다.

kubeadm를 사용할 경우 kube-system namespace(master node)에 etcd-master가 pod 형태로 배포된다.

kubernetes는 각 resource type을 key로 가지고 생성된 resource를 value 형태로 ETCD에 저장한다.

$ etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
get / --prefix --keys-only
/registry/apiregistration.k8s.io/apiservices/v1.

/registry/apiregistration.k8s.io/apiservices/v1.admissionregistration.k8s.io

/registry/apiregistration.k8s.io/apiservices/v1.apiextensions.k8s.io

/registry/apiregistration.k8s.io/apiservices/v1.apps

/registry/apiregistration.k8s.io/apiservices/v1.authentication.k8s.io

/registry/apiregistration.k8s.io/apiservices/v1.authorization.k8s.io

/registry/apiregistration.k8s.io/apiservices/v1.autoscaling

/registry/apiregistration.k8s.io/apiservices/v1.batch

/registry/apiregistration.k8s.io/apiservices/v1.coordination.k8s.io
...

$ etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
get /registry/pods/kube-system --prefix --keys-only
/registry/pods/kube-system/coredns-5644d7b6d9-49pb2

/registry/pods/kube-system/coredns-5644d7b6d9-98tmz

/registry/pods/kube-system/etcd-master

/registry/pods/kube-system/kube-apiserver-master

/registry/pods/kube-system/kube-controller-manager-master

/registry/pods/kube-system/kube-proxy-972kw

/registry/pods/kube-system/kube-proxy-blr9v

/registry/pods/kube-system/kube-scheduler-master

/registry/pods/kube-system/weave-net-9pzcd

/registry/pods/kube-system/weave-net-ls2gv

ETCD High Availability

ETCD는 안정성이 뛰어나다고 했는데 그 얘기는 당연히 하나가 죽어도 다른 ETCD에 의해 그 역할이 대체된다는 의미를 나타낸다.

ETCD를 실행할 때 --initial-cluster option으로 clustering할 다른 ETCD의 IP와 Port를 입력하게 되면 아래 그림처럼 ETCD Cluster가 구성된다.

정리

kubeadm을 이용한 ETCD 배포, ETCD certification 등 많은 부분이 추후에 설명될거라고 한다.

기본 개념을 정리하는 단계라 비교적 쉬운 내용이었다.

ETCD의 leader election 방법이나 data replication은 ETCD를 깊게 볼 일이 있으면 그때 확인 해 봐야겠다.