[Kubernetes] 쿠버네티스 설치하기 (7) - Performing a Rolling Update

Performing a Rolling Update

Objectives

• Perform a rolling update using kubectl.

---

오늘의 목표 kubectl을 통해 rolling update를 해보자!

rolling - (장기간에 걸쳐) 규칙적인 단계로 이뤄진 ( naver 사전 )

 

 

Updating an application

Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. Rolling updates allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.

---

우리가 제공하는 서비스를 User들은 지속적으로 이용가능해야하고, 우리는 서비스가 업데이트 됨에 따라 지속적인 배포를 하고싶다. 과거에 배포를 할 경우에는 일정 시간동안 업데이트를 한다는 공지를 날리고 배포를 진행 했을 것으로 예상되는데 요즘에는 기술이 좋아져서 무중단 배포!!가 가능하다. 쿠버네티스에도 이와 같은 기술이 Rolling updates라고 하는 것 같다.

 

In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods). In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.

---

이전 챕터에서 kubernetes-bootcamp 를 여러개의 replicas로 실행 시켜놓았다. 오늘은 이것을 끊김없이 update를 해볼 것이다.

기본적으로 업데이트 중에 사용할 수없는 최대 Pod 수와 만들어 질 수 있는 새 Pod의 최대 수는 1이라고 한다.

이 두개의 옵션은 숫자 or %로 설정이 가능하다. 쿠버네티스에선 이러한 업데이트를 version으로 관리하고 있는데, update를 했어도 이전 (stable) version으로 되돌아 가는것도 가능하다. 형상관리가 version으로 되는 것 같다.

 

---

위와같이 새로운 IP가 할당되면서 update된 app이 배포되는 형식인 것 같다.

 

Similar to application Scaling, if a Deployment is exposed publicly, the Service will load-balance the traffic only to available Pods during the update. An available Pod is an instance that is available to the users of the application.

Rolling updates allow the following actions:

• Promote an application from one environment to another (via container image updates)
• Rollback to previous versions
• Continuous Integration and Continuous Delivery of applications with zero downtime

---

이전챕터에서 Scaling 했던 것과 같이 Pod가 update중이라면 Service에 있는 load-balancer기능이 사용할 수 있는 Pod에 트래픽을 분산시켜서 전달해 줄 것이다!

Rolling updates 는 아래의 3가지 일을 한다.

1. container image가 update를 1번만 하면 연결되있는 모든 Pod에 적용된다.

2. 이전버전으로 Rollback이 가능하다.

3. 무중단 배포가 가능하다.

 

그럼 시작해보자.

deployments, pods 확인 총 3개의 replicas가 떠있다.

 

kubectl describe pods

pod들의 상세 내용을보면 kubernetes-bootcamp의 Image version이 v1으로 되어있다.

 

현재 deployments의 CONTAINERS, IMAGES 확인

아래의 명령어를 통해 deployments/kubernetes-bootcamp의 image를 변경하고 versios을 v2로 변경하자!

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2

IMAGES가 변경된 것이 확인되고, kubectl get pods 로 변경되고 있는 모습을 확인할 수 있다.

 

최종적으로 아래와 같이 새로운 pod가 떴다!

 

kubectl describe services/kubernetes-bootcamp

기존에 172.16.0.5, 172.16.0.68, 172.16.0.69 로 할당 되어있던 Endpoints가 변경되었다!

 

그럼 변경된 Image가 잘 동작되었는지, 그리고 update되었는지 확인해보자

실제 pod속 server.js를 확인해보면 제대로 변경되어 있음을 확인할 수 있다.

 

kubectl rollout status deployments/kubernetes-bootcamp

해당 명령어로 delpoyments가 rollout 된 상태를 확인할 수 있다.

실제 describe를 통한 pod의 Image도 version이 v2로 올라간 것을 확인가능하다.

 

---

rollback을 배워보기위해 아래와 같이 image를 다시 update 해보자.

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

그러면 위와같이 에러가 뜰것이다.

kubectl describe pods {에러뜬 POD_NAME}

위의 명령어를 통해 확인해보면 "gcr.io/google-samples/kubernetes-bootcamp:v10"를 pull 받을 수 없어서 생긴 오류이다.

rollout을 통해서 되돌리도록 하자!

kubectl rollout undo deployments/kubernetes-bootcamp

위의 명령어를 실행하게되면 이전에 v2 바로 이전버전의 image로 rollback 될 것이다.

--to-revision 옵션을 통해서 원하는 revision으로 rollback 할 수도 있다.

 

kubectl rollout history deployments/kubernetes-bootcamp

rollout history 명령어를 통해 REVISION 확인가능하다. CHANGE-CAUSE는 set image를 할 시 -- record-true 옵션을 주면 기록된다.

 

또는 edit 명령어를 통해서 현재 deployments의 정보를 수정하여 남길 수도 있다.

kubectl edit deployments/kubernetes-bootcamp

 

metadata.annotations.kubernetes.io/change-cause 추가

 

이후에 deployments를 .yaml로 생성할 경우 주석을 남길 때 용이하겠다.

 

이렇게 edit를 통해 수정해도 update가 진행된다!

도중에 몇번 테스트해서 77, 9, 10으로 변경

 

아래의 블로그를 참고해서 변환과정을 살펴보면

쿠버네티스 #10 - 배포

kubectl describe deployments/kubernetes-bootcamp

deployment-controller를 통해서 replica set 에 연결되어있는 pod들의 갯수를 컨트롤 하고 있다.

위의 이미지를 보면 kubernetes-bootcamp-769746fd4, kubernetes-bootcamp-57978f5f5d 2개의 replica set을 볼 수 있다.

kubectl get replicaset -o wide

확인을 해보면 update될 jocatalin/kubernetes-bootcamp:v2 이미지와 연결되어있는 kubernetes-bootcamp-769746fd4 replica set을 먼저 scaled up 하여 0 -> 1, 1 -> 2개를 생성하고 이전 gcr.io/google-samples/kubernetes-bootcamp:v1이미지와 연결되어있는 kubernetes-bootcamp-57978f5f5d replica set을 3 -> 2개로 줄이면서 말 그대로 rolling 규칙적인 단계로 교차하면서 생성, 삭제되고 있음을 확인할 수 있다.

 

이로서 Kubernetes Tutorials Learn Kubernetes Basics(kubernetes.io/docs/tutorials/kubernetes-basics/)의 6단계가 끝이났다!

이후에는 AutoScaling, Service Type, Selector 등에 대해 공부를 하고 .yaml을 통한 설정으로 배포를 하는 등 좀더 발전된 방향으로 나아가겠다.