쿠버네티스(2) - 컨트롤러 ReplicaSet, Deployments

• 실습환경: 마스터 1개 노드 2개
• 쿠버네티스 환경을 VM으로 구현함

 

ReplicaSet

프로덕션에서 Naked Pod를 사용하지 않는 이유는 팟이 고장 났을 때 스스로 살려내지 못하기 때문이다.

Replica Set은 팟 상위의 개념으로 몇개의 팟이 항상 동작함을 보장 줌으로써 고가용성을 제공한다.

팟이 크래시가 되면 Replica Set은 새로운 팟을 만들고 원하는 상태로 돌려 놓는다.

 

 

2개의 레플리카가 클러스터에서 항상 동작하도록 설정

# replicaset.yml 
apiVersion: apps/v1
kind: ReplicaSet # 배포할 오브젝트 종류
metadata: # 배포할 오브젝트의 정보
  name: nginx-replicaset
spec:  # 배포할 오브젝트 명세
  replicas: 2 # 항상 떠있을 팟의 갯수 지정
  selector: # 레플리카셋이 보장할 팟
    matchLabels:
      app: nginx # 레플리카셋이 담당할 팟의 라벨
  template: # 배포될 팟의 템플릿
    metadata:
      labels: # 생성될 팟의 라벨
        app: nginx  # selector 의 라벨과 똑같아야함
    spec:
      containers:
      - name: nginx-container # 팟안에 들어갈 컨테이너 이름
        image: nginx # pull 받을 컨테이너 이미지
        ports:
        - containerPort: 80 #팟에서 컨테이너가 가져갈 포트번호
 
 

D:\15_DandK\step08>kubectl apply -f replicaset.yml
replicaset.apps/nginx-replicaset created

manifest 파일 실행

 

D:\15_DandK\step08>kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-replicaset-9sggd   1/1     Running       0          2m2s
nginx-replicaset-zh25r   1/1     Running        0          2m2s

파드 두개가 생성 되었다

 

D:\15_DandK\step08>kubectl delete pod
nginx-replicaset-9sggd pod "nginx-replicaset-9sggd" deleted

수동으로 레플리카셋으로 동작하는 팟중 하나를 지운다 

 

D:\15_DandK\step08>kubectl get pod
NAME                      READY    STATUS    RESTARTS    AGE
nginx-replicaset-lwft9     1/1        Running        0         14s
nginx-replicaset-zh25r    1/1        Running        0        6m21s

지운 팟은 Terminating 상태가 되며 지워지고, 새로운 팟이 running 되었다

Replica set 에 두개의 팟이 필요하다고 명시했기 때문이다. Replica set은 팟 하나가 실패하더라도 항상 여러개가 동작 한다는 것을 보장한다.

 

 

Deployments

Deployments는 우리의 어플리케이션의 변경사항을 다루는 훌륭한 오브젝트이다. replica set이 고가용성을 위해 항상 원하는 개수의 팟을 보장해주었다면, Deployments는 서버 다운없이 새로운 버젼의 팟으로 교체해주는 것을 보장해준다. 새로운 버젼의 팟에 문제가 발생한다면 기존의 팟으로 롤백하는 것 까지 지원해준다.

1. Rollout

쿠버네티스에서의 롤아웃은 컨테이너의 업데이트를 의미한다

 

# deployment1.yml
apiVersion: apps/v1
kind: Deployment # 배포할 오브젝트 종류
metadata:
  name: web-deploy
spec: # 배포할 오브젝트 명세
  replicas: 10
  selector:  # 디플로이먼트가 보장할 팟
    matchLabels:
      app: web
  template: # 배포될 팟의 템플릿
    metadata:
      labels:
        app: web
      spec:
        containers:  # 배포될 팟의 컨테이너 정보 
        - name: nginx
          image: nginx:1.16

nginx 1.16 버전의 컨테이너를 배포 

 

D:\15_DandK\step08>kubectl apply -f deployment1.yml
 
D:\15_DandK\step08>kubectl get pod
NAME READY STATUS RESTARTS AGE
web-deploy-7c74bc9bb8-2vpg9 1/1 Running 0 106s
web-deploy-7c74bc9bb8-5qhfd 1/1 Running 0 106s
web-deploy-7c74bc9bb8-8q77l 1/1 Running 0 106s
web-deploy-7c74bc9bb8-ctd24 1/1 Running 0 106s
web-deploy-7c74bc9bb8-gqvmf 1/1 Running 0 106s
web-deploy-7c74bc9bb8-hlx95 1/1 Running 0 106s
web-deploy-7c74bc9bb8-k7hkg 1/1 Running 0 106s
web-deploy-7c74bc9bb8-lnm7s 1/1 Running 0 106s
web-deploy-7c74bc9bb8-shh98 1/1 Running 0 106s
web-deploy-7c74bc9bb8-tf4xz 1/1 Running 0 106s

manifest 파일에 의해 10개의 팟이 배포가 되었다 

 

D:\15_DandK\step08>kubectl describe deployment web-deploy
Name: web-deploy
Namespace: default
CreationTimestamp: Sat, 15 May 2021 17:20:05 +0900
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=web
Replicas: 10 desired | 10 updated | 10 total | 10 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge

롤아웃의 기본 설정을 확인

• RollingUpdateStrategy 항목의 25% max unavailable 은 최대 25% 의 파드를 정지할 수 있다는 것으로 유지되는 최소 파드수를 정하는 항목이다
• RollingUpdateStrategy 항목의 25% max surge 은 최대 25% 만큼의 파드를 초과할 수 있다는 것으로 생성되는 최대 파드수를 정하는 항목이다
• 현재 레플리카의 값을 10으로 설정했으므로, 최소 파드수는 7.5개를 반올림해서 8개이고 최대 파드 수는 12.5를 반올림해서 13개가 된다

 

 

# deployment2.yml
apiVersion: apps/v1
kind: Deployment # 배포할 오브젝트 종류
metadata:
  name: web-deploy
spec: # 배포할 오브젝트 명세
  replicas: 10
  selector:  # 디플로이먼트가 보장할 팟
    matchLabels:
      app: web
  template: # 배포될 팟의 템플릿
    metadata:
      labels:
        app: web
      spec:
        containers:  # 배포될 팟의 컨테이너 정보 
        - name: nginx
          image: nginx:1.17 # 버전 업데이트 

버전을 업데이트해서 nginx 1.17 버전을 배포해보자 

 

 

D:\15_DandK\step08>kubectl apply -f deployment2.yml
 
D:\15_DandK\step08>kubectl get pod
NAME READY STATUS RESTARTS AGE
web-deploy-6d6465dbbf-7ss8m 0/1 ContainerCreating 0 2s
web-deploy-6d6465dbbf-c7s8p 0/1 ContainerCreating 0 2s
web-deploy-6d6465dbbf-mc8l6 0/1 ContainerCreating 0 3s
web-deploy-6d6465dbbf-mjhjv 0/1 ContainerCreating 0 2s
web-deploy-6d6465dbbf-zzzmc 0/1 ContainerCreating 0 2s
web-deploy-7c74bc9bb8-2vpg9 1/1 Running 0 14m
web-deploy-7c74bc9bb8-5qhfd 1/1 Running 0 14m
web-deploy-7c74bc9bb8-8q77l 1/1 Running 0 14m
web-deploy-7c74bc9bb8-ctd24 0/1 Terminating 0 14m
web-deploy-7c74bc9bb8-gqvmf 0/1 Terminating 0 14m
web-deploy-7c74bc9bb8-hlx95 1/1 Running 0 14m
web-deploy-7c74bc9bb8-k7hkg 1/1 Running 0 14m
web-deploy-7c74bc9bb8-lnm7s 1/1 Running 0 14m
web-deploy-7c74bc9bb8-shh98 1/1 Running 0 14m
web-deploy-7c74bc9bb8-tf4xz 1/1 Running 0 14m

보이는대로 ContainerCreating가 5개 생기고 Terminating가 2개 생겨서 총 13개의 파드가 생성되었다

 

D:\15_DandK\step08>kubectl get pod
NAME READY STATUS RESTARTS AGE
web-deploy-6d6465dbbf-7ss8m 1/1 Running 0 21s
web-deploy-6d6465dbbf-c7s8p 1/1 Running 0 21s
web-deploy-6d6465dbbf-cfflf 1/1 Running 0 18s
web-deploy-6d6465dbbf-h4658 1/1 Running 0 18s
web-deploy-6d6465dbbf-jzg8d 1/1 Running 0 18s
web-deploy-6d6465dbbf-mc8l6 1/1 Running 0 22s
web-deploy-6d6465dbbf-mjhjv 1/1 Running 0 21s
web-deploy-6d6465dbbf-wtvsf 1/1 Running 0 17s
web-deploy-6d6465dbbf-wvlf4 1/1 Running 0 18s
web-deploy-6d6465dbbf-zzzmc 1/1 Running 0 21s

나머지 3개의 파드도 지워지고 10개의 파드가 running 상태이다

이처럼 디플로이먼트 롤아웃 기능은 새로운 버전의 파드를 먼저 생성하고 예전 버전의 파드를 종료시킨다 

 

 

2. Rollback

• kubectl rollout undo deployment [디플로이먼트 이름]

쿠버네티스에서는 롤아웃 전에 사용하던 예전 컨테이너로 되돌리는 것을 의미한다 롤백을 할 때도 롤아웃과 마찬가지로 사용자의 요청을 처리하면서 파드를 점진적으로 교체한다하지만 데이터베이스 등에 적재된 데이터까지 롤백되는 것은 아니라서 데이터 리커버리는 별도로 구현해야 한다

# 직전 버전으로 롤백
D:\15_DandK\step08> kubectl rollout undo deployment web-deploy 

 

3. 자동복구

파드는 컨테이너가 죽으면 해당 컨테이너를 살린다

단독파드가 배포되어진 노드가 중지되어도 다른쪽으로 이동하지 않지만 디플로이먼트가 배포되어진 노드가 중지되면 다른쪽 노드로 이동한다 

# 단독파드(kind: Pod)
D:\15_DandK\step08>kubectl apply -f pod.yml 
pod/test1 created

# 디플로이먼트(kind: Deployment)
D:\15_DandK\step08>kubectl apply -f deployment4.yml 
deployment.apps/test2 created

두개의 manifest 파일 실행

 

D:\15_DandK\vagrant-kubernetes>kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test1 1/1 Running 0 11m 10.244.2.39 node2 <none> <none>
test2-964b8f864-8ch8l 1/1 Running 1 11m 10.244.1.42 node1 <none> <none>
test2-964b8f864-cdhw8 1/1 Running 0 11m 10.244.2.40 node2 <none> <none>
test2-964b8f864-n22nn 1/1 Running 1 11m 10.244.1.44 node1 <none> <none>
test2-964b8f864-sbzlv 1/1 Running 0 11m 10.244.2.41 node2 <none>

test1 파드가 배포되어진 node2를 삭제 해보겠다

 

D:\15_DandK\vagrant-kubernetes>vagrant halt node2

5분정도는 node2을 중지시켜도 바로 파드를 삭제시키지 않는다 

 

D:\15_DandK\vagrant-kubernetes>kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test1 1/1 Terminating 0 14m 10.244.2.39 node2 <none> <none>
test2-964b8f864-8ch8l 1/1 Running 1 14m 10.244.1.42 node1 <none> <none>
test2-964b8f864-9xswp 1/1 Running 0 7s 10.244.1.45 node1 <none> <none>
test2-964b8f864-cdhw8 1/1 Terminating 0 14m 10.244.2.40 node2 <none> <none>
test2-964b8f864-m2zpx 1/1 Running 0 7s 10.244.1.46 node1 <none> <none>
test2-964b8f864-n22nn 1/1 Running 1 14m 10.244.1.44 node1 <none> <none>
test2-964b8f864-sbzlv 1/1 Terminating 0 14m 10.244.2.41 node2 <none> <none>

Naked Pod 는 node1로 이동시키지 못하고 terminating 되었다

Deployment 는 node2에 배포되어진 파드를 terminating 시키고 node1에 2개의 파드를 running 시켰다(파드갯수유지)

 

 

위 그림처럼 Deployment 가 가장 상위의 컨트롤러 이기 때문에 이것을 가장 많이 사용한다 

 

 

참고

https://ozt88.tistory.com/63?category=362157