시골쥐의 공부생활

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 강의

이때까지 배운 내용을 한 번에 모아 실습하는 내용이다.
투표시스템(voting app)을 만드는데, 총 5개의 POD를 생성한다.
먼저 첫 번째 목표는
1. Deploy Containers, 2. Enable Connectivity, 3. External Access.

1. Deploy Containers
1) voting-app: user가 투표하는 앱
2) redis: user가 투표한 내역을 저장하는 db
3) worker: redis에 저장된 투표내역 + db 업데이트를 위해 전달하는 앱
4) PostGresSQL db: persistant DB, 최종 결과가 업데이트되는 db
5) result-app: 결과를 띄워주는 앱
Demo 영상에서 각 pod들의 yaml 파일을 작성하는데, 영상은 화면캡쳐가 막혀있어서 제외한다.

2. Enable Connectivity
각 pod는 다른 Node에 있을 수도 있는데, 서로간 통신을 어떻게 할까?
이전에 배웠던 Service를 통해 진행한다!
그럼, Pod뿐만 아니라, Service를 위한 YAML도 별도로 만들어야 한다.
여기서 사용하는 Service Type은, 내부 통신이므로 Cluster IP 타입이다.

3. External Access
그럼 외부에서 접근하기 위해서는?
외부에서 접근이 필요한 app은 두 가지. voting-app과 result-app.
따라서, 이 두 가지 pod를 위해 NodePort type의 Service를 생성한다.

즉, 여기까지 정리하자면 pod는 총 5개, Service는 4개가 생성된다.
* Service는 Cluster IP 타입이 2개(redis, PostGresSQL), NodePort 타입이 2개(voting-app, result-app)이다.

그런데, 위와 같이 생성하면 pod가 각 1개였기 때문에, 하나라도 죽는 경우 통신이 불가한 문제가 있다.
따라서, Deployment를 통해 여러 개의 pod를 띄워준다.

아래는 실습 중에 진행했던 pod, service, deploy YAML인데,
각 pod당 비슷한 내용들이므로 voting-app에 대해 필요한 yaml만 1개씩 작성해보았다.

* voting-app의 pod, deployments, service YAML 파일
1. voting-app-pod.yaml

apiVersion: v1
kind: Pod
metadata:  
name: voting-app-pod
labels:
name: voting-app-pod
app: demo-voting-app
spec:
containers:
- name: voting-app
image: kodekloud/examplevoteapp_vote:v1
port:
- containerPort: 80

2. voting-app-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-app-deploy
labels:
name: voting-app-deploy
app: demo-voting-app
spec:
replicas: 3
selector:
matchLabels:
name: voting-app-pod
app: demo-voting-app
template:
metadata:  
name: voting-app-pod
labels:
name: voting-app-pod
app: demo-voting-app
spec:
containers:
- name: voting-app
image: kodekloud/examplevoteapp_vote:v1
port:
- containerPort: 80

3. voting-app-service.yaml

apiVersion: v1
kind: Service
metadata:
name: voting-service
labels:
name: voting-service
app: demo-voting-app
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
nodePort: 30005
selector:
name: voting-app-pod
app: demo-voting-app

강의의 끝이 보인다.
처음 이 강의를 시작하기 전에는, YAML파일을 많이 접하긴 했으나 어떤 구조로 되어 있는지 개념을 잘 몰랐다.
그런데, 이제는 아주 조금씩 보이기 시작한다... 오 예

출처)
자료의 기반은 모두 Udemy의 'Kubernetes for the Absolute Beginners - Hands-on' Course 입니다!

Single Node로 K8s가 구성되어 있다고 생각해보자.

그럼 Node는 192.168.1.2 IP를 가지고 있고, Pod는 내부적으로 10.244.0.0/16 대역을 가지고 있다.

Node의 192.168.1.2 ip의 경우, ssh를 통해 접속이 가능하지만, Pod의 경우 내부 10.244.0.0/16 대역은 외부에서 접근할 수 없다. 

그럼 Multi-Node로 구성되어 있을 때는?

동일한 Cluster 내에서 각 Node가 동일한 대역을 갖고있으면 IP 충돌이 일어난다. 

그런데, K8s cluster가 setup될 때, k8s는 이런 이슈를 해결하기 위한 networking 종류를 자동으로 셋업하지 않는다.

그럼 All nodes가 NAT 없이 통신할 수 없는 방법은 무엇일까? 

Calico, cisco ACI networks, Cilium 등 pre-built solutions을 사용할 수 있다.

이건 각 플랫폼의 환경에 따라 달라지는 부분으로 (ex. VMware를 쓴다면 NSX-T가 good option)

각자 환경에 맞춰 맞는 networking solution을 선택하면 된다.

위는 Calico networking setup을 한 것인데, Node간 다른 network 를 할당했다. 

이런 Networking은 모든 pod 및 노드의 가상 network가 유니크한 ip를 할당받게 만든다. 

그리고, 다른 노드에 있다고 해도, 할당된 ip로 서로간 통신 할 수 있다. 

출처)

자료의 기반은 모두 Udemy의 'Kubernetes for the Absolute Beginners - Hands-on' Course 입니다!

* Deployment: ReplicaSet, pod보다 상위에 있는 K8s object.

                               seamless upgarde (using rolling updates) / undo changes / pause / resume changes 제공

1. 생성 배경 

1) 한 번에 여러 개의 instance를 deploy하고 싶음

2) pkg upgrade/rollback시 한 번에 모든 pod를 죽여버리고 살리면, 서비스 단절이 발생.

   seamless한 업그레이드를 원함. 

3) 다수의 환경 변경(scaling, upgrading, modifying resource)을 원함

2. Deployment 생성: ReplicaSet과 하나를 제외하고 모두 동일함.

    - 다른 것: "Kind" (ReplicaSet: ReplicaSet, Deployment: Deployment)

   Deployment는 ReplicaSet, pod의 상위 개념으로서, Deployment를 생성하면 Replicaset도 동시에 생성됨 

  (왼쪽 kubect get replicaset 참고)

3. Updates and Rollback in Deployment

* Rollout: 새로운 deployment 를 생성하거나 image를 업그레이드할 때, Rollout이 trigger되는데

이것은 점진적으로 컨테이너를 deploy하거나 upgrade함. 

예를 들어, deployment를 처음 생성하면 rollout이 trigger되는데, 이걸 revision 1이라 부름. 

이후에 해당 app이 upgrade되면 new rollout이 trigger되고, new deployment revision 2가 생성됨.

이렇게 하면 앞으로 롤백이나 history 관리 차원에서도 도움이 됨.

4. Deployment Strategy

2가지 type의 deployment strategies가 있음.

예를 들어, 5개의 replica가 있다고 가정한다면, 이를 새 버전으로 upgrade하는 방법은,

1) Recreate Strategy: 전체를 삭제 후 새 인스턴스를 생성하는 방법 (끊김O) 

2) Rolling Update: one by one으로 old version을 하나씩 down 후 새 버전으로 생성하는 방법 (끊김X)

   => Rolling Update가 default Deployment Strategy임.

5-1. kubectl apply: 실제로 어떻게 적용할까?

1) YAML파일에서 직접 수정: kubectl apply -f deplyment-definition.yaml 

2) Temperary 수정: kubectl set image deplyment/myapp-deplyment \nginx=nginx:1.9.1

5-2. 수행 결과

1) Recreate 방식: old replicaset은 0으로 전체 Scale down 후 5로 전체 Scale up이 됨

2) Rolling Update 방식: one by one으로, 하나씩 Scale Up/Down이 진행됨

5-3. Rollback

왼쪽 그림과 같이 replicaset 이 생성되었는데, pod가 0, 0, 0 상태로 무언가 잘못되어 보인다.

이때, 'rollout undo' 명령어를 통해, 이전 버전으로 복구할 수 있다.

 #kubectl rollout undo deployment/myapp-deployment

* Note: POD 생성 시 'deployment "nginx" created'가 출력되었던 이유!

사실 해당 명령어는 deployment를 먼저 생성 후, 자동으로 replicaset과 pod가 생성되었던 것이다. 

6. Deployment에서 배운 command 정리

- Deployment Create

  # kubectl create -f deplyment-definition.yaml

- Deployment 조회(get)

  # kubectl get deployments

- Update

  # kubectl apply -f deplyment-definition.yaml

  # kubectl set image deployment/myapp-deployment nginx=nginx:1.9.1

- Status

  # kubectl rollout status deployment/myapp-deployment

  # kubectl rollout history deployment/myapp-deployment

- Rollback

  # kubectl rollout undo deployment/myapp-deployment

출처)

자료의 기반은 모두 Udemy의 'Kubernetes for the Absolute Beginners - Hands-on' Course 입니다!

https://joont92.github.io/kubernetes/%EB%B0%B0%ED%8F%AC-%EC%A0%84%EB%9E%B5/

https://www.cncf.io/wp-content/uploads/2020/08/CNCF-Presentation-Template-K8s-Deployment.pdf

* Controller: K8s object들을 모니터링하는, K8s의 뇌

그 중에서도, 오늘은 Replication Controller에 대해 정리할 예정이다.

1. Replication이란?

Replica가 무엇이고, 왜 replication controller가 필요할까?

 1) High Availability

이전 공부했던 것 처럼, 우리 app이 single로 돌아가고 있는데, 문제가 발생하면 access가 중단된다.

그래서 하나 이상의 instance or POD를 구성하는데,

이때 Replication controller가 multiple한 instance의 구동(running)을 돕는다. 

 - 그럼, multiple한 instance 구성이 아니면 Replica는 필요 없을까?

  => No. single pod가 fail되면, replication controller는 자동으로 new pod를 생성한다.

        따라서, replicaion controller는 항상 pod가 예상했던 수 만큼 running 되고 있는지 감시하고 있다.

 2) Load Balancing & Scaling 

  - 또다른 목적은, load 분산을 위한 multiple POD를 생성할 때 필요하다.

    유저 수가 늘거나 리소스가 부족할 때, pod를 동일 클러스터 내 다른 노드로까지 확장한다.

    수요가 떨어질 때는 pod 또한 감설한다.

2. Replication Controller VS Replica Set

둘 다 동일한 목적을 갖고 있으나, 같은 것은 아니다. 

Replication Controller는 과거 기술 버전으로, 현재는 Replicat Set에 대체됐다.

현재로서는 Replica Set이 replication setup을 위한 방법으로 추천된다!

1) ReplicationController YAML

 : 현재는 사용하지 않으니 패스하도록 하자.

   크게 달라지는 것은, spec 밑에 "template", "replicas" 라는 key가 생긴다.

2) ReplicaSet YAML

Replication controller와 구성은 거의 비슷하지만, 아래와 같이 변경된 사항들이 있다.

- apiVersion: v1 -> apps/v1 으로 변경

- kind: Replication controller -> ReplicaSet 으로 변경

- spec: 에 "selector" 개념 추가

  . selector: 어떤 레이블에 속한 파드를 관리할지에 대한 설정

    -> 이걸 왜 설정해야 하냐면, ReplicaSet은, ReplicaSet이 생성하지 않은 pod에 대해서도 관리하기 때문이다. 

이전에 생성했던 pod(우측 yaml) YAML에서는 labels에 tier:Front-end를 정의해줬었다.

따라서, ReplicaSet에 selector로 해당 labels를 정의해주면,

이 pods에 대해 모니터링이 되면서 pod가 죽었는지, 수(replicas: 3)가 제대로 떠 있는지 모니터링 가능하다.

3) 'template' key는 왜 필요할까?

현재 관리되고 있는 pod 중에 한 개가 죽어서 'replicas=3'을 만족시키지 못할 경우,

동일한 pod를 띄워주기 위함이다. Replicaset은 항상 pod들을 감시하고, desired number of PODs가 유지되게 해주며, 'template' 섹션은 필수다. 

4) Replicaset을 Scale하는 방법

 : 기존 replicas 값을 3 -> 6으로 변경하고 싶다면?

 4-1) replicaset-definition.yaml에서 값을 수정한다.

        # kubectl replace -f replicaset-definition.yaml

 4-2) kubectl scale 명령을 사용한다. *단, 파일이 변경되진 않고 임시로 변경되는 것임!

        # kubectl scale --replicas=6 -f replicaset-definition.yaml

        # kubectl scale --replicas=6 [TYPE] [NAME] // ex. kubectl scale --replicas=6 replicaset myapp-replicaset

3. Command 정리

# kubectl create -f replicaset-definition.yaml // 생성

# kubectl get replicaset // 조회

# kubectl delete replicaset myapp-relicaset (이와 연관된 모든 pod도 삭제됨)

# kubectl replace -f replicaset-definition.yaml // replace/update를 위한 cmd

# kubectl scale -replicas=6 -f replicaset-definition.yaml  // 파일을 수정하지않고 설정 변경

출처)

자료의 기반은 모두 Udemy의 'Kubernetes for the Absolute Beginners - Hands-on' Course 입니다!

* YAML: XML, JSON과 같은 Data Structure format. K8s에서는 이것을 사용한다.

아래 그림은, 동일한 자료를 format만 다른 XML, JSON, YAML로 각각 나타낸 것이다.

YAML은 내부적으로도 크게 3가지 형태가 있는데, 아래와 같다.

1) Key Value Pair: 가장 간단한 형태로 별도의 복잡한 형태가 필요없을 때 사용.

2) Array/List: 추가 속성값(value)을 가지고 있을 때. "-"는 array의 element임, 단순히 정렬이라 보면 쉬움(순서 상관 O)

3) Dictionary: 속성 값을 더 갖고 있을 때.

ex. Array/Lists에서는 Fruits가 orange, banana로 끝나지만

     Dictionary는, Banana의 세부 key들을 또 정의해주고, 그에 따른 value를 가지고 있음.

   * 앞에 들여쓰기(space 갯수) 신경 잘 써야함. 이게 곧 구분자, Unordered (순서 상관 x)

순서 상관이 무슨 말이냐면, 아래를 봐보자.

이는 List 형태인데, 여기서 Mike가 첫 번째로 입력되어 있는데, 그럼 Rob와 순서가 바뀌면 안 된다는 거다.

그러면 Dictionary case를 봐보자.

여기서는, model이 in_features이나 use_bn 과 같은 key들과 순서가 바뀌어도 전혀 상관없다는 것이다.

앞으로 YAML은 계속 다룰테니, 다음 강의에서 더 복잡한 파일을 이해해보자.

출처)

자료의 기반은 모두 Udemy의 'Kubernetes for the Absolute Beginners - Hands-on' Course 입니다!