시골쥐의 공부생활

이때까지 배운 내용을 한 번에 모아 실습하는 내용이다.
투표시스템(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 입니다!

* Pod: K8s에서 만들 수 있는 최소 단위. application의 single instance.

  - k8s에서는 컨테이너를 워커노드에 직접 만들지 못하며, 이는 pod에 encapsulate 되어 있음. 

pod 내부에는 컨테이너가 1개 이상으로 구성되어 있는데,

강의에서는 대부분 pod:container 구성은 1:1 비율이고, multi-pods 사례가 rare한 케이스라고 한다. (helper container가 있는)

하지만, 우리 현업에서는.. 한 pod안에 여러 개의 container가 있다..ㅋㅋ  

그래서 pod를 하나 생성하면, 그 안에 여러 개의 컨테이너가 동시에 생성된다.

pod를 삭제하면, 당연히 그 안에 컨테이너도 모두 삭제된다.

그리고, 부하가 증가할 때 scale in/out 하는 단위는, 컨테이너가 아니라 pod이다. K8s에서는 만들 수 있는 smallest한 단위는 pod이다!

간단한 실습이 추가되어 있는데,

Docker hub에서 nginx 이미지를 불러와서 pods를 생성하고 조회하는 과정이다.

pod는 개념이 단순하다보니 내용이 여기까지인데, 

이제는 외부에서 어떻게 이 pods와 통신을 할 것인지의 문제가 남아있다.

이건 다음 차시에 다루기로 한다! 

이번엔 정리하지 않고도 다 맞추었다! 

그만큼 pod 내용이 간단하기 때문이다. ㅎㅎ

+ pod를 다룬 김에, pod 생성 후 조회가능한 Events 에 대해서도 알아보자.

events 에러별 원인은 아래 링크에 잘 정리되어 있으니 문제가 발생하면 찾아보도록 하자.

https://www.bluematador.com/blog/kubernetes-events-explained

kubectl get events   # events 조회 명령어

개념 없이 현업에서 명령어를 접하다가 기본 개념을 공부하니 더 재미있고 정리가 잘 된다 :)

얼른 완료해볼 예정이다!

출처)

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

Kubernetes를 setup하는 방법은 여러 가지가 있다. 

1) Minikube / Kubeadm 툴을 사용하여 랩탑 or VM에 setup을 할 수 있다.

 - Minikube: All-in-one으로 single instance 셋업을 위해 사용되는 툴

 - Kubeadm: multi-node setup에 사용되는 툴

2) Hosted solutions in a cloud environment (ex. GCP, AWS)

3) play-with-k8s.com에 checkout

 - 리소스가 없거나, 복잡한 셋업 과정을 거치고 싶지 않은 경우

다시 하나씩 보자. Minikube부터.

Minikube는 위 그림에서보면, master/worker node가 분리된 것처럼 보이지만,

ppt 효과가 들어가 있어서 분리되어 있는 것이고

실제론 Master와 Worker Node가 하나로 All-in-one 버전이다.

Minikube는 아래 링크에서 Minikube와 VirtualBox를 다운 받아서 셋업하면 된다.

Install MiniKube: https://kubernetes.io/docs/tasks/tools/install-minikube/

VirtualBox: https://www.virtualbox.org/wiki/Downloads

MiniKube Download page for  Windows: https://github.com/kubernetes/minikube/releases

More about it here: https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver

이 외는 데모하는 부분이라 여기서 마무리 :)

퀴즈는 3개 중 2개를 맞췄는데, 틀린 부분 역시.. 지금 티스토리에 정리를 하다보니 답이 바로 보인다.

앞으로도 열심히 정리해봐야겠다.

출처)

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

Udemy의 Kubernetes for the Absolute Beginners - Hands-on 과정을 요약한다.

오늘은 두 번째 주제로 Kubernetes Overview이다. (첫 번째는 강의소개라서 생략)

* Kubernetes(K8s): Container + Orchestration

(구글에서 만든, 요즘 시대에 가장 유명한 컨테이너 오케스트레이션 기술)

1. Container, 컨테이너는 무엇이고 왜 필요할까?

(컨테이너는 최근 기술이 아니라, 10년 전에도 있었던 기술이다.)

과거에는 서버 위 여러 app들을 올리면, 각 app들에서 호환되는 OS나 Library 버전들이 모두 달라 많은 이슈가 있었다.

그래서 이 호환성 문제의 해결책으로 컨테이너(Container) 라는 개념이 나왔다.

컨테이너는 Docker 위에 올라가는데, 각 Container는 독립된 라이브러리와 dependency를 가질 수 있다.

그래서 Container가 뭐냐면, 완벽히 독립적으로 구분된 환경(completely isolated environments) 이다.

컨테이너는 각자 독립된 network interface와 VM같은 마운트를 가지는데, 동일한 os 커널을 사용한다. 

* 동일한 os 커널을 사용하는 게 단점은 아니냐고?

Docker는 가상화를 하기 위한 수단이 아니라, 동일한 hw에 다른 os와 커널을 실행시키는 것이다.

 - Docker의 주된 목적: 앱들을 컨테이너화 시키고, 이동, 실행 시키는 데에 있음

컨테이너 개념을 VM과 비교를 해보자면,

VM은 Docker대신 Hypervisor가 있었고, VM마다 OS를 별도로 갖고 있었다.

그러다보니 각 VM당 용량이 GB 이상으로 컸고, 이는(overhead) 많은 부하까지 야기 시켰다.

반면, 컨테이너는 앱마다 OS가 별도로 존재하지 않아 빠른 부팅속도와 작은 용량을 가지고 있다.

(전체 os를 재기동할 필요 없으니 빠를 수 밖에 없다)

컨테이너는 상대적으로 덜 고립(isolation) 되어 있고, 더 많은 리소스를 공유해서 사용할 수 있지만,

vm은 완전히 분리되어 있다고 볼 수 있다.

(이 외 image 부분 및 장단점은 기본적이라 요약에서 제외)

2. 그럼, Orchestration은 무엇일까?

- app들을 컨테이너에 넣었다고 가정하자. 그런데 이걸 어떻게 실행할까?

- 만약 특정 app이(ex. messaging app, DB, backend service..) 다른 컨테이너에 의존해야 한다면 어떻게 할까?

- 그리고 컨테이너 증감이 필요하다면 어떻게 해야할까? 

=> 이런 기능들이 가능하기 위해 리소스 및 platform이 필요하다. 이 플랫폼은 컨테이너간 connectivity와 scale up/down을 orchestrate 해야하는데, 이렇게 컨테이너를 관리하고 자동으로 deploy하는 전반적인 프로세스가 Container Orchestration다.

그래서, 쿠버네틱스(K8s)는 container orchestration technology이며,  

all public cloud service(ex. GCP, Azure, AWS 등)를 지원한다.

Container orchestration는 다양한 장점이 있다.

- app들은 highly avalable한 상태가 된다. 

  왜? app들이 각각 다른 노드에서 running 되기 때문에 (multiple instance를 갖고 있기 때문),

  hw dependancy가 없어진다.

- load balance도 가능 (cluster 구성이기 때문에),

- 노드들의 부하에 따라 자동으로 노드의 scale in/out이 가능하다. 

그럼 위에서 말한 cluster, node들은 무엇일까? Architecture에서 알아보도록 하자.

3. Kubernetes Architecture

1) Node(=minion): K8s가 설치된 physical or virtual한 machine 자체이다.

node는 worker machine이고, k8s에 의해 컨테이너가 설치된다. 과거엔 Minion라고 불리기도 했다. 

여기서, 우리 app이 설치된 Node가 죽으면 어떻게 될까? 만약 Node가 1개라면 죽을 것이다.

2) Cluster: Node들간의 구성

그림과 같이 Node가 다수 개라면?

app하나가 죽는다해도 다른 Node를 통해 여전히 accessible할 수 있다. 이는 부하분산 또한 가능하게 해준다.

그런데, 이런 Node들은 어디서 관리할까?

3) Master: 클러스트들을 관리 및 정보저장, 모니터링, 부하분산, fail-over 동작을 한다. 

4) 이외 여러 구성요소 (Components)

 -  API server acts as the front-end for kubernetes. The users, management devices, Command line interfaces all talk to the API server to interact with the kubernetes cluster. => k8s의 FE로, cluster와 통신하기 위한 입구.

 - ETCD is a distributed reliable key-value store used by kubernetes to store all data used to manage the cluster. Think of it this way, when you have multiple nodes and multiple masters in your cluster, etcd stores all that information on all the nodes in the cluster in a distributed manner. ETCD is responsible for implementing locks within the cluster to ensure there are no conflicts between the Masters. => 전체 데이터 저장소

- scheduler is responsible for distributing work or containers across multiple nodes. It looks for newly created containers and assigns them to Nodes. => 부하 분산

- controllers are the brain behind orchestration. They are responsible for noticing and responding when nodes, containers or endpoints goes down. The controllers makes decisions to bring up new containers in such cases.

 => 뇌. 컨테이너나 엔드단이 down 됐을 때 알림을 주고 새 컨테이너를 띄울지 결정하는 곳

- container runtime is the underlying software that is used to run containers. In our case it happens to be Docker. And finally kubelet is the agent that runs on each node in the cluster. The agent is responsible for making sure that the containers are running on the nodes as expected

 => 컨테이너를 띄우기 위한 sw이고, kubelet이 각 노드를 띄우기 위한 agent임

각 컴포넌트간 동작과정은 조금 복잡하므로 요약에서 제외하고, 필요할 때 보도록 하자.

5) kubectl(=kubel control): k8s에서 사용되는 command line 유틸리티 

app을 deploy하거나 조회할 때 사용하는 명령어 유틸리티.

Overview 섹션은 여기까지이고 생략한 부분도 일부 있다.

그렇게 섹션이 끝날 때마다, 퀴즈가 주어지는데, 이번 섹션(섹션 2: Kubenetes Overview)에서는 8개 중 7 문제를 맞췄다.

틀린 문제를 지금와서 보니..답이 바로 보인다. 역시 공부는 정리를 해야 내 것이 되나보다.

출처)

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