1. 배포 방식

서버를 업데이트하고 배포하는 방식은 다양하다.
이번엔 Kubernetes로 패키지를 업데이트하고 배포하는 방식에 대해 알아본다.

배포 방법	설명
Canary Deployment	기존 버전을 유지한 채로 일부 버전만 신규 버전으로 업데이트해 버그나 이상이 없는지 확인
Rolling Update	서비스 중단없이 하나씩 업데이트 하는 방법
Blue-Green Update	Blue와 Green을 모두 띄워놓고 테스트에서 이상이 없으면 Blue -> Green으로 전환하여 Update하는 방식

2. 배포 실습

1. Canary Deployment

mainui-stable.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mainui-stable
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mainui
      version: stable	  
  template:
    metadata:
      labels:
        app: mainui
        version: stable
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
          - containerPort: 80

mainui-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: mainui-svc
spec:
  selector:
    app: mainui
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

mainui-canary.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mainui-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mainui
      version: canary	  
  template:
    metadata:
      labels:
        app: mainui
        version: canary
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
          - containerPort: 80

1-1. canary-update namespace로 변경

kubectl config set-context --current --namespace=canary-update

1-2. mainui pod 생성

kubectl create -f mainui-stable.yaml

1-3. mainui service 생성

kubectl create -f mainui-service.yaml

1-4. mainui-canary 생성

kubectl create -f mainui-canary.yaml

다음을 보면 stable 버전과 canary 버전이 함께 존재한다.

1-5. canary replica 개수 추가

kubectl scale deployment mainui-canary --replicas=2

1-6. canary deployment 삭제

kubectl delete deployment mainui-canary

방금까지 했던 Canary Deployment 방식은 stable 버전과 canary 버전이 있었다. 위를 보면 canary개수가 1개에서 업데이트가 잘 됬음을 확인하고
Canary개수를 2개로 변경해주고 기존에 존재하던 stable버전의 Pod를 지웠다.

2. Rolling Update

RollingUpdate.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iksoon-deployment
  labels:
    app: iksoon-tomcat
spec:
  replicas: 10
  minReadySeconds: 1
  strategy:  
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: iksoon-pod
  template:
    metadata:
      labels:
        app: iksoon-pod
    spec:
      containers:
      - name: iksoon-tomcat
        image: peksoon/iksoon_tomcat:1.0.3
        ports:
        - containerPort: 8080

UpdateDeployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: iksoon-deployment
 labels:
   app: iksoon-tomcat
spec:
 replicas: 10
 minReadySeconds: 1
 strategy:  
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 1
     maxUnavailable: 0
 selector:
   matchLabels:
     app: iksoon-pod
 template:
   metadata:
     labels:
       app: iksoon-pod
		spec:
     containers:
     - name: iksoon-tomcat
       image: peksoon/iksoon_tomcat:1.0.4
       ports:
       - containerPort: 8080

2-1. namespace 변경

kubectl config set-context --current --namespace=rolling-update

2.2. Rolling Update.yaml 배포

kubectl create -f ./RollingUpdate.yaml

pods가 생성됬다.

2.3. UpdateDeployment.yaml 배포

kubectl apply -f ./UpdateDeployment.yaml

다음을 보면 Rolling Update가 진행되어 Pod가 하나씩 업데이트 되는걸 확인할 수 있다.

Rolling Update 방식을 살펴보았다.
참고로 yaml파일에 있는 maxSurge, maxUnavailable를 통해 업데이트 되는 Pod 개수를 조절하거나 설정할 수 있다.
maxSurge : rolling update중 정해진 Pod 이상으로 만들 수 있는 최대 개수
maxUnavailable : rolling update중 unavailable 상태인 Pod 최대 개수 설정

또한 Rolling Update할 때 다양한 명령어로 업데이트를 제어할 수 있다.
예를 들어 Rollback이나 update 취소, 상태 확인 등...

3. Blue-Green 배포

💡 Blue(현재 운영중인 Pods)와 Green(새로운 버전의 Applicatoin)을 띄워놓고 테스트가 완료되고 이상이 없음을 확인하면 Blue Application으로 가던 트래픽을 Green Application으로 변경하여 Update를 완료함

💡 이후에 지속적으로 Green을 모니터링하다가 버그/오류가 발생하면 다시 Blue로 변경하고 Green에서 장시간 정상 동작을 확인하면 Blue를 제거한 후 Green을 Blue로 사용함

blue.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name : test-deployment-blue
spec:
  replicas: 4
  selector:
    matchLabels:
      app: test-pod
      color: blue
  template:
    metadata:
      labels:
        app: test-pod
        color: blue
    spec:
      containers:
        - name: test-pod
          image: joont92/echo-version:0.1.0 # 구버전
          ports:
            - containerPort: 8080

green.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name : test-deployment-green
spec:
 replicas: 4
 selector:
   matchLabels:
     app: test-pod
     color: green
 template:
   metadata:
     labels:
       app: test-pod
       color: green
   spec:
     containers:
       - name: test-pod
         image: joont92/echo-version:0.2.0 # 신버전
         ports:
           - containerPort: 8080

patch-service.yaml

spec:
 selector:
   color: green

service.yaml

apiVersion: v1
kind: Service
metadata:
 name: test-service
spec:
 ports:
   - port: 80
     targetPort: 8080
 selector:
   app: test-pod
   color: blue

3-1. namespace 변경

kubectl config set-context --current --namespace=blue-green

3-2. blue 배포

kubectl create -f ./blue.yaml

3-3. green 배포

kubectl create -f green.yaml

3-4. service 배포

kubectl create -f service.yaml

3-5. blue -> green 변경

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

blue -> green으로 변경되었다.

Blue-Green Update를 진행했다. Blue-Green Update의 특징은 Blue, Green을 모두 띄워놓고 Blue->Green으로 변경할 수 있다. 반대로 Green->Blue로 변경할 수도 있을것이다.

정리

지금까지 다양한 배포방식에 대해 공부했다.
여기서 추가할건 Ingress로 트래픽을 제어하여 특정 서비스에 자주 접근하도록 설정하도록 설정해 패치를 진행할 수도 있다.