시골쥐의 공부생활

위와 같이 pod에 특정 환경변수를 설정하려면 어떻게 하는게 편할까?

pod definition YAML에 설정할 수 있다.

하지만, pod definition file이 많다면 query files 내에 저장된 environment data 관리에 어려움이 있다.
그래서, 이 configuration들을 묶어 pod-definition 파일 밖에서 ConfigMap과 Secrets 파일을 만든다.

1. ConfigMap: 일반적인 plain text를 별도의 파일에 저장. 
  pod가 생성될 때, ConfigMap이 pod 내부로 추가되고, 해당 파일에 있는 환경 변수들을 사용할 수 있다.

 1) ConfigMap의 두 가지 phase

   (1) Create ConfigMaps
      -  imperative way (command로 생성. file 미작성)

         . kubectl create configmap 명령어

# kubectl create configmap <config-name> --from-literal=<key>=<value>
ex. app-config --from-literal=APP_COLOR=blu
                   --from-literal=APP_MOD=prod  (추가로 원하는 속성이 있다면)

    - Declarative way (file 작성)

      . kubectl create -f  [file Name]
       ex. config-map.yaml 생성

   (2) Inject them into the POD (다른 object들 처럼)
    - (ENV의 경우) "envFrom:" key 추가 
    envFrom:
      - configMapRef:
            name: app-config // 여기에 configmap의 name 넣기

 - (Single Env의 경우) valueFrom:
 - (Volume의 경우) configMap:

  * ConfigMap 조회

2. Kubernetes Secrets

위에서 ConfigMap을 알아봤는데, ConfigMap은 모든 data를 plain 형태로 저장했다.

그런데, id/pw와 같이 민감한 값을 저장해야 한다면 configMap이 적합할까?

당연히 아니다.

그래서, 이런 민감한 정보들은 Screts 파일에 암호화하여 저장한다.

Secrets 역시 2가지 Phase로 나눠진다.

1) CREATE Secret
2) Inject them into the POD 

하나씩 알아보자.

먼저 이 역시 명령형(imperative)와 선언형(Declarative)로 나뉜다.

먼저 명령형 부터.

# kubectl create secret generic <secret-name> --from-literal=<key>=<value>
ex. kubectl create secret generic \
       app-secret --from-literal=DB_Host=mysql app-secret
                      --from-literal=DB_User=root ...

설정이 많아지면, file로 가져오는 명령어도 있다.
# kubectl create secret generic <secret-name> --from-file=<path-to-file>
ex. kubectl create secret generic \ app-secret --from-file=app_secret.properties

다음은 역시, 선언형이다.

kubectl create -f secret-data.yaml
 * 단, secret은 민감한 정보를 다루기 때문에, plain text말고 encoded된 형식으로 "직접" 작성해야함.

어떻게 encoded된 형식으로 변환?   'echo -n' 명령어 사용!

# echo -n 'mysql' | base64 
# echo -n 'root' | base64 

그럼 decode 방법은!?

#'echo -n 'bXlzcWw=' | base64 --decode 

2) Inject them into the POD 
 ConfigMap과 동일하게 아래와 같은 key를 추가한다

- (ENV의 경우) "envFrom:" key 추가 
    envFrom:
      - secretRef:
            name: app-config // 여기에 configmap 이름 넣기

 - (Single Env의 경우) valueFrom: secretKeyRef:
 - (Volume의 경우) secretName:

위는 정말 secret파일이 container에 포함되는지 확인하는 명령.

* Note)
# explain kubectl explain [--recursive=false] [flags]
파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
출처: https://kubernetes.io/ko/docs/reference/kubectl/overview/

controller-0:~$ kubectl explain pods --recursive | grep Volume -A3

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

컨테이너는 OS를 점유하지 않고 특정한 task나 process를(ex.webserver, app server, db) 실행하기 때문에,
task가 완료되면 컨테이너는 exit 된다. 

즉, 컨테이너는 프로세스가 동작중일 때만 살아있는다.
예를 들어, 컨테이너 내부의 web server가 중지되거나 crash되면, 컨테이너도 종료된다. 
(위 그림을 보면, ubuntu를 run했으나 곧내 Exit 된걸 볼 수 있다)

그럼, 컨테이너 내에서 어떤 프로세스가 구동될지는 누가 정의할까?

docker file을 보면(여기서는 nginx), 'CMD'(=command)라는 instruction을 볼 수 있다.
즉, 해당 프로그램이 컨테이너가 시작되면, 컨테이너 내에서 구동될 것이라는 것을 의미한다. 
mysql에는 mysqld가 있다.

Ubuntu 파일의 docker file도 보면, 'bash' 라는 default cmd가 있다.
그런데, bash는 webserver와 db와 같은 프로세스가 아니라 쉘이다.
* shell: 터미널로부터 input을 listen. 없으면 종료.

우리가 우분투 컨테이너를 생성할 때,

docker는 우분투 img로부터 container를 생성하고, bash program을 구동한다.
그런데, 기본적으로 docker는 터미널이 포함되어 있지 않기 때문에,

bash program은 터미널을 찾을 수 없고, 이내 프로세스는 시작되자마자 종료될 것이다. 

1. 'docker run' command 

: 컨테이너가 생성되자마자 종료되지 않기 위해서는 어떻게 해야할까?

sleep 5초를 줘보자.
# docker run ubuntu sleep 5 // ubuntu 컨테이너를 시작할 때, sleep program을 함께 구동, 5초간 기다렸다가 exit

* 그런데 이것은 일시적인데... 어떻게 영구적으로 적용할까?
새 커멘드를 만들면 된다.

docker build -t ubuntu-sleeper
docker run ubuntu-sleeper

단, CMD에는 항상 키와 값을 따로따로 써줘야 한다.

ex. ["sleep", "5"]  // ["sleep 5"]하면 안됨

그럼 value(값)를 바꾸고 싶다면?
ENTRYPOINT로 명령어를 수행하고, CMD를 통해 매개변수 값을 입력한다.

런타임에 ENTRYPOINT를 sleep2.0으로 수정하고 싶다면? 
entry point option을 사용해서 override할 수 있음.
 # docker run --entrypoint sleep2.0 ubuntu-sleeper 10

그럼 위의 설정은 YAML에 어떻게 입력 할까?
args:가 CMD에 있는 매개변수 값으로, args에 value를 입력해준다.
그리고 ENTRYPOINT가 command: 이다. (Entrypoint를 수정하고 싶다면, YAML에 위와 같이 "sleep2.0"으로 바꿔도 된다)

출처: 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 강의

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

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 입니다!

Kubernetes Services는 app의 내외 컴포넌트간 통신을 가능하게 해준다.  

예를 들어, app이 다양한 섹션에 속해있는 pod 그룹을 가지고 있을 때(ex. Frontend, Backend, external data),

이런 그룹들 간 통신을 가능하게 해준다. 

한 가지 예를 들어보자면, 유저가 10.244.0.2(Internal IP)를 가진 pod에 어떻게 접속할까?

- 일단 Node IP인 192.168.1.2 까진 ssh로 접속할 수 있다. 근데 그걸 타고가서 또 다른 걸로 접속하기엔 번거롭다.

그래서, Service라는 개념이 나왔는데, Service는 pod, deployments와 같은 object이다.

Service는 크게 3가지 타입으로 구성되어 있는데, 하나씩 봐보도록 하자.

1. NodePort

 : Node에서 port를 통해 internal POD로 접근가능하게 한다.

2. ClusterIP

 : 다른 서비스(Frontend, backend 등)간 통신을 가능하게 하는 내부 virtual IP

3. LoadBalancer

 : 말그대로 LB인데, 지원되는 cloud providers(ex. GCP 등) 에서 사용할 수 있다. 

하나씩 더 자세히 알아보자.

1. NodePort

 : NodePort는 Node에서 pod port까지 port를 mapping 해준다. 

   예를 들어, Node안에는 아래와 같이 3개의 ports가 포함되어 있다.

   1) TargetPort: 실제 앱이 돌아가는 pod의 포트

   2) Port: Service itself

   3) NodePort: Node itself (외부에서 접근 가능한)

  그래서 이런 Port들을 service definition yaml에 정의해주는데, high level structure는 기존 오브젝트들과 거의 같다.

  다만, spec아래에 type, ports라는 부분이 추가되었으며 type의 default는 cluster IP이고, 

  nodePort는 service에서 30000~32767 범위로 자동 할당한다.

근데 pod가 많다면? (=multi pods)

이전에 사용했던 selector라는 key를 사용한다.

selector는 pod를 identify하는 label list를 제공하므로, 이걸 통해 multi-pods를 관리할 수 있다.

(label은 이전에 pod생성 시 사용했던 pod-definition file을 참고하자)

그리고, Service는 LB로서, 다른 pod들에게 random algorithm을 사용하여 load를 분산시켜준다.

service definition YAML 작성이 끝났으면, 아래 create명령어로 service를 만들고,

실제로 pod까지 접속이 되는지 curl 명령어로 확인해본다.

# kubectl create -f service-definition.yaml

2. Cluster IP

보통 cluster 구성은 위와 같이 다양한 group으로 구성되는데, 서로간 연결이 어떻게 될까?

심지어, pod는 재생성되면서 IP가 바뀌기도 하는데, 관리하기가 쉽지 않다.

그래서, ClusterIP는 각 Pod들이 속한 label마다 group을 만들어서 관리한다. 

예를 들어, 위 그림의 redis는 'redis'라는 service로 다른 pods들이 각 pod로 접근할 수 있게 한다. (정확히는 service)

그리고, service를 통해 pkt이 들어오면, service에서 랜덤적으로 각 pod에 분산을 해줘서 효율적인 microservice deploy가 가능하게 해준다. 

Cluster IP의 service definition YAML은 위와 같다. 

전반적으로 NodePort와 비슷하지만, 'NodePort'가 있을 필요가 없으니 이 부분이 없고,

type이 ClusterIP이다. type에 아무것도 쓰지 않더라도, ClusterIP가 default 값이라 비워놔도 된다.

3. Load Balancer

app이 2 tier를 갖고 있고, 외부에서 접근 가능하도록 Node Port를 구성했다.

그럼 end user에는 어떤 ip를 줘야할까? 깔끔하게 하나 IP를 주는 게 좋을텐데..

Single Node일 경우 NodePort를 주면 되겠지만, multi Node의 경우, Node마다 IP가 다르다.

그래서, LB VM을 새로 구성하고, DNS 설정을 해서 user hosts를 만든다. 

근데 이 작업이 너무 귀찮은데, GCP와 같은 플랫폼에서는 native load balancing fuction들을 제공한다. 

따라서, 우리가 굳이 하나씩 setup할 필요가 없고, K8s가 스스로 셋업하도록 보고만 있으면 된다 ㅋ_ㅋ 

(교육자료가 과거내용인 것 같다. 요즘엔 다 되더라...)

강의의 끝이 보인다.

출처)

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