Kubernetes Deployment / 쿠버네티스, 패턴, pattern, 선언적 배포, 디플로이먼트

Kubernetes Deployment

---

Deployment는 container그룹(Pod, ReplicaSet)들의 업그레이드, 롤백 등 배포관련 프로세스를 캡슐화하고 반복, 자동화에 도움을 줌

Self-service방식으로 서비스를 배포하다보면 서비스의 수가 증가할수록 업데이트, 배포에 부담이 커짐

새로운 버전 시작, 기존 파드 안전하게 중지, 새로운 파드 상태 확인, 실패시 롤백 등의 동작이 필요

많은 서비스에 대해 앞선 동작들을 수동으로 하면 문제가 생길 포인트가 많아짐

이런 동작들을 자동화 해주는 것이 Deployment 개념

업데이트 관리, 개별 적용, 배포 프로세스 조정 등 다양한 기능을 사용가능

개발공부를 하다보면 다양한 배포전략이 존재하는 걸 알 수 있는데,

Deployment에서도 Rolling, Blue-green, Canary등 지원

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment

기본적인 Deployment 예시로 replicas: 3 을 선언하여 3개의 nginx pod를 띄우도록 하는 명세

#deployment 생성
$ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

#deployment 생성 확인
$ kubectl get deployments

#deployment rollout 상태 확인
$ kubectl rollout status deployment/nginx-deployment 

#deployment ReplicaSet 확인
$ kubectl get rs

#deployment pod확인
$ kubectl get pods --show-labels

해당 명세로 deployment를 생성하고 각각 확인할 수 있음

 

- Rolling Update

Kubernetes deployment에서 기본적으로 가져가는 배포 방식

default설정이기 때문에 따로 설정을 하지 않아도 해당 방식으로 동작

새로운 버전으로 점진적으로 전환하는 배포

3개가 있다면 차례로 하나씩 내리고, 새로운 버전으로 업그레이드 후 트래픽 전환하는 방식으로 보면 됨

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1 
      maxUnavailable: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.14.2
            ports:
            - containerPort: 80
            readinessProbe:
              exec:
                command: ~~

앞선 예시의 명세에서 Rolling Update 관련 설정을 추가로 작성한 것

maxSurge는 update중 일시적으로 추가할 수 있는 Replica의 개수를 설정하는 것

따라서 maxSurge가 1이므로 replicas 3에 더해 최대 4개까지 업데이트 중 사용할 수 있다는 뜻

maxUnavailable은 업데이트동안 사용안해도 괜찮은 pod의 수

여기서는 업데이트동안 2개의 파드만 동작한다는 의미

그리고 마지막으로 readinessProbe를 꼭 설정하여 zero downtime을 보장할 수 있어야 함

- Recreate strategy

Rolling Update 방식은 클라이언트가 새로운 버전의 변경사항과 호환이 되지 않을 때 사용하기 어려움

이럴 때 Recreate 방식은 호환이 되지 않는 변경사항을 적용할 때 사용하기 좋음

기존의 모든 container를 죽이고 새로운 버전의 container를 동시에 시작하는 방식

하지만 downtime이 존재하기 때문에 선호하지 않음

- Blue-Green deployment

앞선 Recreate 방식에서 downtime을 없애고 위험성을 줄인 배포 방식

아예 새롭게 새로운 버전의 pod를 기존 pod의 수만큼 생성한 뒤 한번에 트래픽이 옮겨가는 방식

Kubernetes에서 Strategy type으로 지원하지는 않음

따라서 새로운 Deployment를 생성하고 테스트를 진행한 뒤, Service에서 selector를 통해 새롭게 생성한 Deployment로 연결을 하는 방식으로 사용

#기존 Deployment
...
spec:
  ...
  selector:
    matchLabels:
      app: nginx
      color: blue
      
#새롭게 배포할 Deployment
...
spec:
  ...
  selector:
    matchLabels:
      app: nginx
      color: green

이런식으로 blue, green으로 Deployment내에 spec.selector.matchLabels 하위에 key-value값을 추가해준 뒤

기존의 Deployment와 새로운 Deployment로 두벌을 생성해줌

#new-nginx-service.yaml
spec:
  selector:
    color: green

$ kubectl patch service nginx-service -p "$(cat new-nginx-service.yaml)"

이렇게 label-selector을 업데이트 해주며 Service가 아예 새롭게 배포된 Deployment를 바라보게 할 수 있음

zero-downtime과 호환성 문제해결 복잡성감소등 다양한 장점이 있음

하지만 반대로 2배의 서버리소스, 장기실행 프로세스 확인, 데이터베이스 상태 변화등의 단점도 존재

- Canary release

A/B테스트의 방식으로 생각하면 됨

새로운 버전과 기존의 버전 둘 다 Service의 트래픽을 받으면서 새로운 버전에 대한 문제나 사용자 반응을 확인 가능

앞서 Blue-green 방식과 비슷하게 label-selector을 이용

#기존 Deployment
...
spec:
  ...
  replicas: 2
  selector:
    matchLabels:
      app: nginx
      version: stable
      
#새롭게 배포할 Deployment
...
spec:
  ...
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: canary

Service에서 label-selector로 nginx를 설정해두면 두개의 Deployment에 대해 접근하여 서비스 됨

#Service 명세
...
spec:
...
  selector:
    app: nginx
...

이런식으로 Service명세를 설정해두고

stable / canary 각각의 Deployment명세로 replicas 수를 조절하며 점진적 배포를 진행하면 됨

$ kubectl scale deployment/nginx-deployment --replicas=1

해당 명령어로 replicas를 scale할 수 있음

 

- Deployment Rollback

Deployment 배포 방식을 찾아봤는데, 반대로 문제가 생겼을 때는 언제든 Rollback이 가능함

 

먼저 Deployment의 수정사항을 파악

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply --filename=...
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.161

이런식으로 Deployment의 revision을 확인할 수 있음

$ kubectl rollout undo deployment/nginx-deployment --to-revision=2

이후 원하는 revision으로 rollout 명령어를 실행하면 됨

rollback을 실행한 뒤 앞서 적어둔 Deployment상태를 확인할 수 있는 명령어들로 확인