[Study Jam] Managing Deployments Using Kubernetes Engine - 2

✔️ Rolling update

Deployments는 Rolling Update 메커니즘을 통해 이미지를 새 버전으로 업데이트할 수 있다.

Deployment가 새 버전으로 업데이트될 때, 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본 수를 줄이면서 새 ReplicaSet의 복제본 수를 천천히 늘린다.

Rolling update - Googole Study Jam

✔️ Trigger a rolling update

Deployment를 업데이트하려면 다음을 실행한다.

kubectl edit deployment hello

Deployment의 컨테이너의 섹션의 이미지를 변경한다.

...
containers:
  image: kelseyhightower/hello:2.0.0
...

한번 에디터에서 저장하면 업데이트된 Deployment가 Cluster에 저장되고 Kubernetes는 rolling update를 시작한다. 

kubernetes가 생성한 새로운 ReplicaSet을 확인하자

kubectl get replicaset

rollout history에서 새로운 entry를 확인할 수도 있다.

kubectl rollout history deployment/hello

✔️ Pause a rolling update

실행 중인 rollout에서 문제가 발견되면 일시 중지해서 업데이트를 중지한다. 

kubectl rollout pause deployment/hello

rollout의 현재 상태를 확인한다.

kubectl rollout status deployment/hello

Pods를 직접적으로 확인할수도 있다.

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

✔️ Resume a rolling update

rollout이 일시중지된다. 즉, 일부 파드는 새 버전이고 일부 파드는 이전 버전이다. 

resume 명령을 사용해 rollout을 계속 진행할 수 있다.

kubectl rollout resume deployment/hello

rollout이 완료되면, status 명령을 실행해 확인할 수 있다.

kubectl rollout status deployment/hello

✔️ Rollback a rolling update

새 버전에서 bug가 검출되었다고 가정하자.

새 버전에 문제가 있는 것으로 추정되므로 새 Pods에 연결된 모든 사용자에게 같은 문제가 발생할 것이다.

이전 버전으로 롤백해 조사한 후 적절히 수정된 버전을 릴리스할 수 있다.

 

roll out 명령을 사용해 이전 버전으로 롤백한다.

kubectl rollout undo deployment/hello

history를 통해 roll back을 확인한다.

kubectl rollout history deployment/hello

마지막으로, 모든 Pods가 이전 버전으로 롤백되었는지 확인한다.

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Kubernetes deployments를 위한 롤링 업데이트와 다운타임없이 애플리케이션을 업데이트하는 방법에 대해 배웠다.

---

✔️ Canary deployments

사용자의 subset을 사용해 운영 환경에서 새 deployment를 테스트하려면 canary depolyment를 사용한다.

Canary deployments는 사용자의 작은 서브셋의 변경에 대한 릴리스를 허용해 새로운 릴리스와 관련된 위험을 완화시킨다.

 

✔️ Create a canary deployment

Canary deployment는, 새로운 버전의 개별의 deployment와 통상의 안정된 deployment 및 canary deployment를 모두 대상으로 하는 서비스로 구성된다.

첫번째로 새로운 버전을 위한 새로운 canary deployment를 생성한다.

cat deployments/hello-canary.yaml

이제 canary deployment를 생성한다.

kubectl create -f deployments/hello-canary.yaml

canary deployment가 생성된 후 hello와 hello-canary 두개의 deployments를 가진다.

kubectl 명령을 통해 확인한다.

kubectl get deployments

✔️ Verify a canary deployment

canary deployment를 확인한다.

요청에 의해 처리되고 있는 hello 버전을 확인할 수 있다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

이 작업을 여러번 실행하면 일부 요청은 hello 1.0.0에 의해 처리되고 작은 서브셋 (1/4 = 25%)은 2.0.0에 의해 처리된다는 것을 알 수 있다.

✔️ Canary deployments in production - session affinity

이 실습에서는 Nginx 서비스로 전송되는 각 요청들이 canary deployment에 의해 처리될 기회가 있었다. 

그러나 사용자가 Canary deployment에서 서비스를 받지 않도록 하려면 어떻게 해야할까 ?

어플리케이션의 UI가 변경되어 사용자를 혼란스럽게 하고싶지 않은 경우가 있다.

이러한 경우 유저는 어느 쪽의 deployment를 '고정'할 필요가 있다.

 

sessionAffinity를 가진 서비스를 생성하여 이를 수행할 수 있다. 

이렇게하면 동일한 사용자가 항상 동일한 버전에서 서비스를 받을 수 있다. 

하단의 예에서 서비스는 이전과 동일하나 새 sessionAffinity 필드가 추가되어 Client IP로 설정되어 있다.

같은 IP 주소를 가진 모든 클라이언트들은 동일한 버전의 hello 어플리케이션으로 요청을 보낸다.

kind: Service
apiVersion: v1
metadata:
  name: "hello"
spec:
  sessionAffinity: ClientIP
  selector:
    app: "hello"
  ports:
    - protocol: "TCP"
      port: 80
      targetPort: 80

운영 환경에서 canari deployment에 sessionAffinity를 사용할 수 있다. 

---

✔️ Blue-green deployments

Rolling updates는 오버헤드를 최소화하고 성능에 미치는 영향을 최소화해 다운타임을 최소화하면서 어플리케이션을 느리게 배포할 수 있으므로 이상적이다.

완전히 deployment된 후에만 로드 밸런서가 가리키는 지점을 새로운 버전으로 변경하는 것이 도움이 되는 경우가 있다.

이 경우에는 blue-green deployments 가 적절하다.

Kubernetes는 이를 위해 2개의 개별 deployments를 작성했다. 하나는 오래된 "blue" 버전과 새로운 "green" 버전이다. "blue" 버전에는 기존 hello deployment를 사용한다. deployment는 라우터로서 기능하는 서비스를 통해 액세스된다.

새로운 "green" 버전이 가동되면 서비스를 업데이트하여 해당 버전의 사용으로 전환한다.

 

blue-green deployments의 주요 단점은 어플리케이션을 호스트하기 위해 필요한 리소스가 클러스터에 최소한 2배 이상 있어야 한다는 것이다. 두 버전의 어플리케이션을 동시에 배포하기 전에 클러스터에 충분한 리소스가 있는지 확인해야 한다. 

 

✔️ The Service

기존의 hello 서비스를 사용하되 selector app : hello, version : 1.0.0을 사용하도록 업데이트한다.

selector는 기존의 'blue' deployment와 일치한다. 그러나 다른 버전을 사용하기 때문에 'green' deployment와는 일치하지 않는다. 

 

먼저, 서비스를 업데이트한다.

kubectl apply -f services/hello-blue.yaml

 resource service/hello 가 누락되었다는 경고는 자동으로 패치되므로 무시하자.

✔️ Updating Using Blue-Green Deployment

blue-green deployment 스타일을 지원하기 위해서 새로운 버전을 위한 'green' deployment를 생성할 것이다.

green deployment는 버전 레이블과 이미지 경로를 업데이트한다.  

 

green deployment를 만든다.

kubectl create -f deployments/hello-green.yaml

한번 green deployment를 만들고 적절히 시작되면, 여전히 1.0.0 버전이 실행중인 것을 확인한다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

이제 새로운 버전을 가리키도록 서비스를 업데이트한다.

kubectl apply -f services/hello-green.yaml

서비스가 업데이트되면 'green' deployment는 즉시 사용된다. 

새로운 버전이 항상 사용되고 있는지 확인할 수 있다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

✔️ Blue-Green Rollback

필요하다면 같은 방식으로 오래된 버전을 롤백 할 수 있다. 

'blue' deployment가 여전히 실행중인 동안에 서비스를 이전 버전으로 롤백한다. 

kubectl apply -f services/hello-blue.yaml

서비스를 업데이트하면 롤백이 성공한다. 다시 올바른 버전이 사용되고 있는지 확인해보자

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

blue-green deployments 및 버전을 한번에 전환해야 하는 어플리케이션에 업데이트를 배포하는 방법에 대해 배웠다.