[TIL] k8s 배포 전략

개요

---

쿠버네틱스에서는 배포 전략들을 어떤 방식으로 진행하는 지 알아보자

k8s 배포 전략

---

1. 롤링 배포 전략

k8s 의 deployment 는 기본적으로 롤링 배포 전략을 사용한다. (링크 참조)
따라서 deployment의 이미지만 바꿔주면 롤링 배포가 가능하다.
예시)

# "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
kubectl set image deployment/frontend www=image:v2               

2. 블루/그린 배포 전략

기존에 운용중이던 블루 에 트래픽을 전달하다가 새로운 버전인 그린 을 만든 뒤 모든 트래픽을 그린에 전달하고 기존의 블루 를 제거하는 방식을 취한다.

STEP 1: 블루 배포 매니페스트(blue-deployment.yaml)를 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      version: blue
  template:
    metadata:
      labels:
        version: blue
    spec:
      containers:
        - name: my-app
          image: your-registry/my-app:blue
          # Additional container configuration goes here

STEP 2: 서비스 매니페스트(service.yaml)를 생성하여 블루에 트래픽을 라우팅하게 설정

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    version: blue
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

STEP 3: 블루 Deployment 리소스를 생성하고 서비스를 배포합니다.

kubectl apply -f blue-deployment.yaml
kubectl apply -f service.yaml

STEP 4: 생성 상태를 확인합니다.

kubectl get deployments
kubectl get services

STEP 5: 그린 Deployment 매니페스트(blue-deployment.yaml)를 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      version: green
  template:
    metadata:
      labels:
        version: green
    spec:
      containers:
        - name: my-app
          image: your-registry/my-app:green

STEP 6: 그린 Deployment 리소스 생성

kubectl apply -f green-deployment.yaml

STEP 7: 서비스 매니페스트(service.yaml) 의 selecter 를 그린으로 변경

...
  selector:
    version: blue
...

STEP 8: 서비스 새로 적용

kubectl apply -f service.yaml

3. 카나리 배포 전략

track 레이블을 이용한 방식

여러 레이블이 필요한 또 다른 시나리오는 동일한 컴포넌트의 다른 릴리스 또는 구성의 디플로이먼트를 구별하는 것이다. 새 릴리스가 완전히 롤아웃되기 전에 실제 운영 트래픽을 수신할 수 있도록 새로운 애플리케이션 릴리스(파드 템플리트의 이미지 태그를 통해 지정됨)의 카나리 를 이전 릴리스와 나란히 배포하는 것이 일반적이다.

예를 들어, track 레이블을 사용하여 다른 릴리스를 구별할 수 있다.

기본(primary), 안정(stable) 릴리스에는 값이 stable 인 track 레이블이 있다.

     name: frontend
     replicas: 3
     ...
     labels:
        app: guestbook
        tier: frontend
        track: stable
     ...
     image: gb-frontend:v3

그런 다음 서로 다른 값(예: canary)으로 track 레이블을 전달하는 방명록 프론트엔드의 새 릴리스를 생성하여, 두 세트의 파드가 겹치지 않도록 할 수 있다.

     name: frontend-canary
     replicas: 1
     ...
     labels:
        app: guestbook
        tier: frontend
        track: canary
     ...
     image: gb-frontend:v4

프론트엔드 서비스는 레이블의 공통 서브셋을 선택하여(즉, track 레이블 생략) 두 레플리카 세트에 걸쳐 있으므로, 트래픽이 두 애플리케이션으로 리디렉션된다.

  selector:
     app: guestbook
     tier: frontend

안정 및 카나리 릴리스의 레플리카 수를 조정하여 실제 운영 트래픽을 수신할 각 릴리스의 비율을 결정한다(이 경우, 3:1). 확신이 들면, 안정 릴리스의 track을 새로운 애플리케이션 릴리스로 업데이트하고 카나리를 제거할 수 있다.

보다 구체적인 예시는, Ghost 배포에 대한 튜토리얼을 확인한다.

• 장중앙의 개발창고
• xgro 님 블로그
• Ingress 정리를 포함한 카나리 디프로이먼트