시골쥐의 공부생활

1. Monitoring: K8s에서는 어떻게 Node간 Resource를 체크할까?

위 Prometheus, Elastic Stack 등 Monitoring에 대한 OpenSource를 사용한다.

세부 동작 과정은, Node의 Kubelet 안에  cAdvisor라는 subcomponent가 있다.

cAdvisor는 pod로부터 성능 metrics들을 조회하고, kubelet API를 통해 이것을 metric server로 노출시킨다.

메트릭 서버는 위와 같은 명령어로 설치하며, 설치 후에는 kubectl top node, top pod 명령어를 통해

각 node, pod의 사용량을 알 수 있다.

그럼, Logging에 대해서도 알아보자.

2. Logging:

Docker의 경우 이미 app에 의해 standard output으로 event를 생성하고 있다. 

docker container를 background 모드로 사용하고 싶다면, -d 옵션을 사용하면 된다.

이러면 log를 볼 수 없다.

만약 로그를 보고 싶다면, container ID를 이용한 logs -f 옵션을 사용하면 된다.

docker logs -f [Container ID]

그럼 K8s를 알아보자.

일단 위와 동일한 image를 사용하여 pod를 하나 만든다. 

pod가 생성된 후에는, kubectl logs -f event-simulator-pod 옵션을 통해 log를 볼 수 있다.

(-f 옵션은 docker cmd처럼 라이브로 로그를 보겠다는 의미.)

그런데, 이 로그는 pod 내 container마다 다르다.

pods는 여러 개의 docker container를 가질 수 있으므로, 'image-processor'라는 추가적인 컨테이너를 만들어 본다.

그러면, logs를 조회할 때도 2개의 container를 한 번에 조회할 수 있다.

# kubectl logs -f event-simulator-pod event-simulator

kubectl logs -f [Container ID 1] [Container ID 2] ...

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

K8s에는 Scheduler도 1개 이상을 생성할 수 있다.

왜 1개 이상의 생성이 필요할까?

이전에 Taint&Toleration, Affinity, Selector를 이용하여 Scheduler가 특정 pod에 특정 Node를 생성하게 했다.

그런데, 복합적인 절차들이 맞물려서, 여러 개의 Schedule 조건도 필요할 수 있다.

예를 들어, 이 pod는 특정 작업이 끝난 후 생성되게 해달라. 등의 작업 말이다.

그래서 k8s에는 Multiple Scheduler를 생성한다. 

Deploy는 위와 같은 방법으로 진행한다.

YAML파일을 하나 더 만들어서, spec: containers: command 아래에 2개의 값을 별도로 추가해준다.

-- leader-elect=false
-- scheduler-name=my-custom-scheduler 

그리고 kubectl create -f YAML파일을 통해 각 Scheduler를 생성한다.

이제부터는 pod에도 어떤 scheduler를 쓸 건지 'schedulerName'을 명시해줘야 한다. 

(명시해주지 않으면, 이전에 설정했던 -- leader-elect=true 값을 가진 scheduler가 default로 설정될 것이다.)

이후 pod를 생성해서 k8s의 events를 조회해보면,

my-custom-scheduler를 통해 생성된 pod의 event를 확인할 수 있다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

Daemon Sets: K8s의 ReplicaSet과 거의 동일한 object.

ReplicaSet은 2개 이상의 pod를 생성하는 반면, Daemon Sets은 1Node에 1pod만을 생성한다.

그럼, 어떤 app이 1 Node 1pod를 사용할까?

K8s Architecture를 배울 때, 각 Node는 kube-proxy를 하나씩 가지고 있었다.

이것도 예시가 될 수 있고, Networking (weave-net)에서 사용되던 인스턴스들도 1Node 1pod면 된다.

kubeMonitoring solution이나 Logs Viewer(Collector)도 Daemon Sets을 사용한다고 한다.

daemonsets에 관련된 명령어는 위와 같고, 설정이 딱히 없다 :)

근데, 어떻게 1 Node 1 pod에 할당하지?

v1.12 전까지는 scheduler에서 해당 pod가 아무 node로나 할당되지 않게끔

각 pod에 이전에 scheduler에서 배운 'Nodename'을 명시했다고 한다.

https://countrymouse.tistory.com/entry/CKA-3-1?category=1016093 

하지만, v1.12부터는 NodeAffinity와 default scheduler를 사용한다고 한다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

각 Node들엔 Resource(CPU, MEM, DISK)가 정해져 있다.

Node에는 pod들이 할당되면서 resource를 소비하게 되는데,

node의 resource가 다 떨어지면 해당 node에는 pod가 생성되지 않는다.

그리고, 각 app도 필요한 resource가 있기 때문에 pod에 requested / limits의 자원을 명시한다.

해당 값을 명시할 땐 이진데이터인 Xibibyte 형식을 사용한다.

- requested의 경우, pod가 생성될 때 요구되는 값이고

- limits의 경우 app이 구동 중에 자원이 더 필요하더라도, 이를 넘어가지 않도록 제한해주는 설정이다.

  cpu의 경우, limits을 넘어가면 throttling 처리되고, MEM의 경우 pod가 종료된다.

* 그리고 OOM Terminated 라는 것도 있는데, Out of Memory로 Terminated 되었다는 의미이다.  이건 app의 limits memory값을 늘려야 한다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

용량이 큰 Node1과 나머지 Node 2, 3이 있다.

그리고 많은 자원을 요구하는 pod와 적당한 pod 2개가 있다.

많은 자원을 요구하는 pod가 Node 1에 할당되게 하려면 어떻게 해야할까?

pod에 nodeSelector 라는 key를 추가해서, 원하는 node에 해당 pod가 생성되게끔 설정을 해준다.

(size: Large로 명시했음)

* 단, Node 1은 미리 size: Large 라는 value를 가지고 있어야 한다.

그래서, Node1에 해당 label 속성을 주기 위해 아래와 같은 명령어를 통해 label을 추가한다.

# kubectl label nodes <node-name> <label-key>=<label-value>
ex. kubectl label nodes node-1 size=Large
ex. kubectl label namespace <namespace> <label-key>=<label-value>

그리고 다시 'nodeSlelector'를 추가한 pod를 생성하면, Node-1에 원하던 pod가 생성된다.

그런데... 조건이 훨씬 복잡해진다면? (현재 조건은 1개 뿐이다. size:Large)

Node Affinity 라는 게 나온다. 

Node Affinity란? 여러 개의 조건을 사용하여 원하는 Node에 pod를 생성하기 위한 설정이다.

예를들어, nodeSelector는 key가 단순히 label을 비교하는 하나 였다면,

Node Affinity는 'requredDuringSchedulingIgnoredDuringExecution, match Exporessions' 등 여러 가지 조건이 있다.

내용은 생각보다 간단하다.

- requiredDuringSchedulingIgnoredDuringExecution

   : Scheduling 동안 해당 affinity 설정을 가진 node가 없다면 pod를 생성하지 않는다(=required) 

     && pod가 이미 생성된 상태에서 affinity나 label 설정들이 바뀐다면 이를 무시한다(=ignored). (pod는 정상 동작)

- preferredDuringSchedulingIgnoredDuringExecution

   : Scheduling 동안 해당 affinity 설정을 가진 node가 없다면 적당한 곳에 pod를 생성한다(=preferred) 

     && pod가 이미 생성된 상태에서 affinity나 label 설정들이 바뀐다면 이를 무시한다(=ignored). (pod는 정상 동작)

- requiredDuringSchedulingRequiredDuringExecution

   : Scheduling 동안 해당 affinity 설정을 가진 node가 없다면 pod를 생성하지 않는다(=required) 

     && pod가 이미 생성된 상태에서 affinity나 label 설정들이 바뀐다면 이를 반영한다. (pod가 삭제될 수도 있음)

그러면..

이전에 배웠던 Taint & Tolerance와 Node Affinity 차이는 무엇일까?

- Taint: Node에 설정해서, 해당 노드에 아무 pod나 생성되지 않게 한다.

- Tolerance: Pod에 설정해서, 해당 pod가 특정 node에"도" 생성될 수 있게 한다. (회색과 같은 다른 node에"도" 생성될 수 있다.)

- Node Affinity: 특정 pod는 특정 node에만 생성될 수 있게 한다! (아래 그림 참고)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

Taint & Tolerations: 각 node와 pod에 값들을 붙여 pod/node할당을 제한하는 속성 (restriction)

 - Taint: Node에 적용되며, 해당 Taint와 동일한 Toleration 설정이 있는 pod만 해당 Node에 할당될 수 있다.

 - Tolerations: Pod에 적용되며, 해당 Toleration에 따라 특정 Taint가 있는 pod에도 할당될 수 있고,

                              다른 pod에도 할당될 수 있다.

그럼, node에 taint 설정이 있는데, 해당 taint 설정을 만족하는 toleration을 갖고 있는 pod가 없다면?

그에 따른 node의 동작에는 3가지 옵션이 있다.

1) NoSchedule: pod가 해당 node에 schedule되지 않는다.

2) PreferNoSchedule: 이 노드에 pod가 배치되는 것을 피할 것이지만, 개런티되진 않음.

3) NoExcute: 이미 pod가 해당 노드에 존재한다면, toleration 설정을 가질 때까지 실행되지 않음.

설정은 왼쪽처럼 cmd로 해도 되고, 오른쪽처럼 YAML파일을 직접 작성해도 된다.

단, ""를 붙여야 한다.

taint를 삭제할 때는, 명령어 가장 끝에 '-'만 붙여주면 된다.# kubectl taint nodes node1 app=myapp:Noschedule-

그러고보니, master node에는 항상 pod가 생성되지 않았다. 

그 이유는 무엇이었을까?

Master node에는 Taints 설정이 있어서 pod생성이 불가했기 때문이다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

* Lables & Selector: 여러 오브젝트(pod, service, node ...)들을 그룹(key, functionality, ... )으로 묶는 방법

lables는 YAML파일을 작성할 때, metadata 아래에 있던 key 였다. (app: myapp, type: front-end)

그럼 labels 에 따른 조회는 어떻게 할까? 아래처럼 하면 된다.

# kubectl get po --show-labels // pod들의 전체 레이블 출력
# kubectl get po --selector app=front-end // app=front-end를 label로 가진 pod들 출력  

annotation은 뭘까?

k8s 오브젝트들에 포함되는 unstructed information을 저장하는 데에 사용되는 key-values 짝이다.

labels&selector가 object들을 그룹화 할 때 사용한다면, annotation은 다른 정보들을(timestamps, sha, issue tracker links, name...) 저장하는 데에 사용된다.

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

Scheduler는 어떻게 동작할까?

pod가 생성될 때, Scheduler는 각 pod에 'nodeName'라는 key가 있는지 체크한다.

없다면, Scheduler가 자동으로 알고리즘에 의해 각 pod에 적합한 node를 bind 시켜주고, 해당 key를 생성한다.

만약, cluster에 scheduler가 없다면?

Pending 상태가 되고, 직접 YAML파일에 'nodeName:'을 작성할 수 있다.

만약 pod가 이미 running 중이라면?

K8s는 중간에 nodeName 수정을 허락하지 않기 때문에 pod-bind-definition.yaml이라는 binding object를 생성해서

API가 binding된 POST request를 보내준다.

단, curl 명령어를 사용할 땐 YAML 파일을 JSON포맷으로 변환시켜줘야 한다.

# curl --header "Content-Type:Application/json" --request POST --data '{"apiVersion":"v1", "kind": ~ ~}'

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

object를 생성하고 관리하는 방법에는 2가지 타입이 있다.

- Declarative(평서문의): 위 그림상 왼쪽

- Imperative(반드시 해야하는, 명령법의): 위 그림상 오른쪽

1. Declarative way

말그대로 yaml파일을 바꾼 후 적용하는 것

하나하나 key와 value를 직접 작성해야 하지만 파일간 동기화가 된다. 

kubectl apply -f nginx.yaml

2. Imperative way 

 - 몇 개의 인자만 수정할 때 사용하면 간편하게 수정가능하다.

 - 단, 적용된 내용은 local YAML 파일과 동기화가 이루어지지 않아

local YAML file, live object configuration, Last applied Configuration간 다른 내용을 갖고 있을 수 있다.

   . 보통 Live object configuration과 Last applied Configuration은 동일하다.

 - 해당 방법은 명령어를 수행할 때마다 도움말을 줘서 간편하게 쓰기 좋다. 

   (ex. kubectl create나 replace 명령어를 사용했을 때, pod가 존재하지 않는다면 바로 error와 reason을 띄워준다)

kubectl run --image=nginx nginx
kubectl create deployment --image=nginx nginx
kubectl expose deployment nginx --port 80
kubectl edit deployment nginx
kubectl scale deployment nginx --replicas=5
kubectl set image deployment nginx nginx=nginx:1.18
kubectl create -f nginx.yaml
kubectl replace -f nginx.yaml
kubectl delete -f nginx.yaml

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의

Udemy에서 K8s for Absolute Beginner 코스를 끝낸 후, CKA with practice 과정을 듣기로 했다.

공부는 역시 증명이 중요하니까.. 자격증으로 마무리를 해보자!

강의는 총 17개의 섹션으로 나뉘어져 있고, Introduction/Conclustion을 제외하면 15개 섹션이다.

이제부터 강의를 들은 후, 1 섹션씩 정리 해 볼 예정이다.

그럼 바로 2 번째 섹션(1번째는 Intro). Core Concepts !

K8s의 전반적인 Architecture에 대해 그래픽화 하였다.

K8s의 Architecture는 크게 MasterNode, Worker Nodes로 나뉘며,

그 안에 kube-apiserver, controller-manager, etcd, scheduler, kube-proxy, kubelet 등 다양한 요소가 있다.

아래에서 하나씩 살펴볼 예정이다.

1. Master Node - ETCD: key-value를 저장하는 DB

* Key-value가 무엇일까?

아래와 같은 여러 속성을 가진 data가 있다면, 이걸 각 key - value로 짝지어서 저장하는 것이다.

이 멀티개의 데이터를 아래와 같이 key-value 형태로 변환한다.

그럼 etcd설치는? 이렇게 하면 된다.

설치 후엔 아래와 같이 실행한다.

Manual로 Setup할 수도 있는데, 아래와 같이 url의 ip와 2379 포트가 중요하다.

셋업하고 나면, master node에서 get pod 커멘드로 etcd를 조회할 수 있다. etcd또한 하나의 pod로 생성된다.

2. Kube-api server: Primary management component

아래 그림처럼, Master-Worker Nodes간 모든 동작들의 명령이 수행되는 곳이다.

kube-api server는 아래와 같이 크게 6가지 기능이 있다.

user를 인증하고, Request를 validata하며, data를 etcd를 통해 조회 및 업데이트하고,

실제 명령어 수행을 위해 scheduler와 kubelet간 연동한다.

etcd와 유일하게 통신하는 컴포넌트이기도 하다.

설치는 아래와 같이 진행한다.

3. Kube Controller Manager: Node 감시

실제로 Controller Manager 안에는 Node-Controller, Replication-Contoller, Deployment-Controller등으로

구성되어 있으나, 크게 Kube Controller Manger라고 얘기한다.

Node-Controller의 경우 Node들의 상태를 아래와 같이 timer를 주고 관리하여,

문제가 생길경우 그에 맞는 대응을 한다. (pod 재생성 등)

Replication-Controller는 각 노드의 각 pod마다 replicaset에서 정의한 (desired된)

pod 갯수가 맞는지 계속 감시하고, 다를 경우 생성/삭제한다.

kube-controller-manager 설치는 아래와 같이 진행한다.

4. Kube Scheduler: pod의 조건에 따라, 이를 어떤 Node에 생성할지 판단, 실행

 (Resource Requirements and Limits, Taints & Tolerations, Node Selectors/Affinity)

설치는 이렇게 진행

5. Kubelet: Node 상태 체크 및 Master Node로부터 명령을 받는 곳

pod가 생성되는 절차는 kube-scheduler -> kube-apiserver -> kubelet -> runtime을 통해 생성된다.

Woker node 입구에서 Node를 등록하고, pod를 생성, node 및 pod를 감시하는 역할.

설치는아래와 같이 진행하며, kubeadm의 경우 kubelets을 자동으로 설치하진 않는다고 한다.

6. Kube-proxy: Node간 internal 통신을 가능케 해주는 컴포넌트

각 pod는 가상의 local IP를 갖고 있는데, 이를 서로 통신하게 만들어준다.

service라는 개념을 배웠는데, 실제로 service는 actual한 container 형태가 아니다.

그래서 service가 생성될 때마다 kube-proxy가 적합한 rule(iptables)을 생성하여, pod간 통신을 가능하게 한다.

설치 및 조회는 아래와 같이 진행한다.

여기까지가 CKA만의 새로운 강의였고, 나머지는 absolute beginner 코스와 동일한 강의가 remind 느낌으로 포함되어 있다.

그래서 아래 pod, deployment, service 등은 이미 정리를 했으므로, 여기서는 정리를 제외한다 :)

출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의