Deployments

지난번 포스트까지 잘 따라왔다면 이제 고 가용성의 팟을 배포하는것에 대해 자신이 붙었을 것 입니다. 팟들의 가용성을 높이기 위해서 naked pod보단 replica set 이 낫다는 것을 이미 알고 있을 겁니다. 하지만 팟의 새로운 버젼을 만들기 위해서 뭘 해야되는지는 아직 배우지 않았습니다. 팟이 새로운 버젼으로 교체될 때 서버가 다운되는 것을 원하는 사람은 없을 것 입니다. 이것을 위해 Deployments 가 등장합니다.

이론편

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

실전편

이 시리즈의 이전 편들에서 했던 것 처럼 우리가 원하는 상태의 설정을 위해 매니페스트 파일을 만들겁니다. 쿠버네티스는 매니페스트 파일에 따라서 우리가 원하는 상태로 동작할 것을 보장합니다.

예전에 작성한 Replica set 매니패스트에다 Deployment 정보를 추가하는 것으로 시작합니다. Deployment는 Replica set의 상위 개념이라는 것을기억해주세요. 이전에 작성한 Replica set 명세위에 Deployment를 추가해줍니다. 항상 그렇듯이 쉽게 따라올 수 있도록 주석이 달려있습니다.

apiVersion: apps/v1 #version of the API to use  
kind: Deployment #What kind of object we're deploying  
metadata: #information about our object we're deploying  
  name: nginx-deployment #Name of the deployment  
  labels: #A tag on the deployments created  
    app: nginx  
spec: #specifications for our object  
  replicas: 2 #The number of pods that should always be running  
  selector: #which pods the replica set should be responsible for  
    matchLabels:  
      app: nginx #any pods with labels matching this I'm responsible for.  
  template: #The pod template that gets deployed  
    metadata:  
      labels: #A tag on the replica sets created  
        app: nginx  
    spec:  
      containers:  
      - name: nginx-container #the name of the container within the pod  
        image: nginx #which container image should be pulled  
        ports:  
        - containerPort: 80 #the port of the container within the pod

항상 그렇듯이 쿠버네티스 클러스터에 이 설정을 배포해 봅시다

kubectl apply -f [manifest file].yml

배포된 것 확인

kubectl get deployments

배포 결과는 아래 스샷과 비슷할 것입니다.

• DESIRE - 우리 설정에 2개의 어플리케이션 레플리카가 있음
• CURRENT - 2개의 레플리카가 지금 돌아가고 있음
• UP-TO-DATE - 2개의 레플리카가 우리가 지정한대로 업데이트 되었음
• AVAILABLE - 2개의 레플리카가 사용가능한 상태임

이 정보는 당장은 별로 재밌어보이지 않을 수 있습니다. 하지만 Deployment가 기존의 세트들을 가져와서 업데이트를 진행 할 수 있다는 것을 기억해주세요. 업데이트를 진행해보면 여기에 나온 정보들이 좀 더 재밌어 보일 수 있습니다.

Deployments에 업데이트를 진행하고 무슨일이 일어나는지 한번 확인해 봅시다. 레플리카 갯수를 늘리고, 배포될 nginx 버젼이 바뀌도록 deployment 매니페스트 파일을 수정해 보겠습니다. 그런 변경사항이 적용된 매니페스트 파일이 아래에 있습니다.

apiVersion: apps/v1 #version of the API to use
kind: Deployment #What kind of object we're deploying
metadata: #information about our object we're deploying
  name: nginx-deployment #Name of the deployment
  labels: #A tag on the deployments created
    app: nginx
spec: #specifications for our object
  strategy:
    type: RollingUpdate
    rollingUpdate: #Update Pods a certain number at a time
      maxUnavailable: 1 #Total number of pods that can be unavailable at once
      maxSurge: 1 #Maximum number of pods that can be deployed above desired state
  replicas: 6 #The number of pods that should always be running
  selector: #which pods the replica set should be responsible for
    matchLabels:
      app: nginx #any pods with labels matching this I'm responsible for.
  template: #The pod template that gets deployed
    metadata:
      labels: #A tag on the replica sets created
        app: nginx
    spec:
      containers:
      - name: nginx-container #the name of the container within the pod
        image: nginx:1.7.9 #which container image should be pulled
        ports:
        - containerPort: 80 #the port of the container within the pod

설정파일을 다시 적용하고 우리 Deployments가 어떻게 변경되었는지 확인해봅시다.

kubectl apply -f [new manifest file].yml
kubectl get deployments

이제 우리는 좀더 흥미로운 정보를 볼 수 있습니다. 커맨드를 얼마나 빨리 쳤냐에 따라 아래 보이는 스크린샷과 조금 다른 결과가 나올 수 있습니다.

업데이트가 다 끝나기전에 get deployments 커멘드를 입력했기 때문에, current state가 desire state까지 도달하지 못했습니다. current state가 desire state 보다 더 많은 수의 레플리카를 가지고 있는것을 볼 수 있습니다. 이것은 새로운 버젼의 팟이 먼저 배포가 되고 예전 버젼의 팟이 나중에 삭제되기 떄문입니다.

아래의 예시에서 version 2 의 컨테이너를 띄우는동안 version 1의 컨테이너를 삭제하려고 하는것을 볼 수 있습니다. 새 버전(2)의 팟을 띄우고 나서 이전 버젼(1)의 팟을 지워야합니다. 이게 다 되면 다음 팟은 버젼 2로 띄우고 그다음 버젼 1의 팟을 지울 겁니다.

desire state 이상으로 배포될 팟의 갯수는 매니페스트 파일의 maxSurge 항목에서 조절할 수 있습니다. 만약 이걸 2로 했다면 2개의 팟이 새로 생성될것이고 2개의 팟이 지워질 겁니다.

위 데모에서 진행한것보다 더 큰 업데이트를 진행해야 할때도 있을 것입니다. 그럴때 계속 get deployments 커맨드를 치는걸 원하지 않는다면 다음 커맨드를 쳐보세요

kubectl rollout status deployment [deployment name]

이 커맨드는 롤아웃동안 무슨일이 일어나는지에 대한 리스트를 보여줍니다. 배포하는동안 위 커맨드를 치면 무슨일이 일어나는지 봅시다.

정리

Deployments를 배우는것으로 쿠버네티스 마스터의 길에 한발짝 다가갔습니다. 여기서 우리는 제법 괜찮은 한발을 디뎠고, 쿠버네티스 클러스터를 어떻게 배포하고 업데이트하는지를 알게 되었습니다. 여전히 클러스터에 접근할 수는 없지만 , 조금만 더 기다려보세요. 우리는 제대로 동작하는 클러스터에 거의 다 왔습니다.

클러스터를 뒤집어 헤쳐 놓았으니 항상 그렇듯이 deployment를 삭제해놓고 돌아갑시다.

kubectl delete -f [manifest file].yml