시골쥐의 공부생활

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

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

K8s는 object(Pods, Replicas, Deployments, Service, etc)를 생성하기 위해 YAML File을 사용한다. 

 * Yaml 파일이 무엇인지 이해가 안된다면 이전 게시글 참고!

각 Object들은 모두 비슷한 형식을 따르는데, k8s definition 파일에는 항상 아래 4개의 상위 속성을 포함해야한다.

- apiVersion: object를 만들기 위해 사용할 k8s API version (예시는 두 번쨰 그림 속 kind/version 참고)

- kind: object type (pod, service, deployment, ...)

- metadata: 이름, label과 같은 오브젝트의 data. 

  . label은 나중에 pod가 여러 개 생겼을 때, 이를 묶어줄 수 있는 역할을 한다. tag라고 보면 쉬울듯!

   label 밑에는 추가적인 key들을 작성해도 되지만, metaData 밑에는 key를 추가할 수 없다.

- spec: specification.

  . 위 3개를 보면, 그래서 어떤 containers를, 어떤 image파일로 만들건데! 하는 정보가 없다.  

     그래서 containers 및 image 정보를 작성하고, multiple-containers가 될 경우 list로 써줄 수도 있다.

* 각 Key값 뒤 Value를 입력할 땐, 콜론(:) 뒤 띄어쓰기(space)하는 것 잊지말기

이후 k8s definition.yaml 파일을 작성 후엔,

kubectl create -f definition.yaml

kubectl apply -f definition.yaml 로 pod를 만들 수 있고, 아래와 같이 상세 조회도 가능하다.

* kubectl edit pod [pod명]을 하면, 현재 running된 pod의 config값을 변경할 수 있다.

이렇게 yaml파일을 vi를 통해 만들 수도 있지만, Visual Studio Code를 사용하면 더 쉽게 만들 수 있다.

아래와 같이 들여쓰기도 스스로 해줄 뿐더러, 첨삭(내가 뭘 틀렸는지 혹은 어떻게 입력해야하는지) 가이드라인도

제공해주기 때문이다.

그런데 검색하다보니, 구글에서도 google cloud Code를 제공한다..

즉, 별도의 프로그램 다운이 필요없는 것이다. 갓 구글 ㄷ ㄷ

https://cloud.google.com/code/docs/vscode/yaml-editing?hl=ko 

출처)

자료의 기반은 모두 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 입니다!