쿠버네티스 패턴 - 3장 선언적 배포

오정재·2021년 4월 19일

Design Pattern kubernetes 디자인 패턴 쿠버네티스

쿠버네티스 패턴

목록 보기

4/12

👉 선언적 배포

어플리케이션 버전에 대한 업그레이드 및 롤백이 자동화 되지 않으면 많은 어려움이 있습니다.
쿠버네티스는 Deployment를 사용하여 업그레이드 및 롤백을 자동화하였습니다.

이번 글에서는 Deployment를 활용하여 다양한 배포 전략을 소개할 것입니다.

🍏 문제점

쿠버네티스는 네임스페이스를 통해서 격리된 환경을 제공합니다.
이에 따라서 사용자의 개입을 최소화 하면서 서비스를 배포할 수 있습니다.

하지만 마이크로서비스 수가 증가하면 새로운 버전을 배포하거나 롤백하는 것은 부담이 되게 됩니다.
만약 이 과정을 수동으로 수행한다면 다음과 같은 순서가 될 것입니다.

1) 새로운 버전의 파드를 시작
2) 이전 버전의 파드를 안전하게 중지
3) 새로운 파드가 성공적으로 시작되었는지 대기 및 확인
4) 실패할 경우 이전 버전으로 롤백

간단해 보이지만 어플리케이션에 적합한 스크립트를 만드는 것은 많은 노력이 필요하며,
사람에 의한 오류가 발생할 수 있기 때문에 관리 포인트가 늘어나게 됩니다.

🍏 해결책

쿠버네티스는 이를 해결하기 위해서 Deployment 를 제공합니다.
Deployment 는 어플리케이션 업데이트 방법, 개별 전략 활용, 다양한 업데이트 프로세스 조정 등을 제공합니다.

따라서 어플리케이션에 적합한 스크립트를 만드는 비용을 절감할 수 있으며,
오류가 있을 때 디버깅해야하는 관리 포인트가 줄어들게 됩니다.

이번 글은 Deployment를 활용하여 다양한 배포 전략에 대해서 설명하고 장단점을 알아보려고 합니다.

1) 롤링 배포

롤링 배포 전략은 무중단 배포를 위한 전략입니다.

즉, 이전 버전의 파드를 조금씩 신규 버전의 파드로 교체하는 전략입니다.

아래 그림과 함께 단계별로 설명하겠습니다.

Step 1) POD v1 의 일부를 제거하고, POD v2 를 실행시킵니다.
Step 2) 실행된 POD v2 가 정상적으로 실행이 되었다면 POD v1 이 전부 POD v2 로 교체될 때까지 반복합니다.

쿠버네티스에서 어플리케이션을 업데이트하는 가장 기본적인 방법은 RollingUpdate입니다.
따라서 RollingUpdate를 위한 Deployment yaml을 통해 자세한 내용을 정리하고 넘어가겠습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    selector:
      matchLabels:
        app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
          - containerPort: 80

가장 먼저 쿠버네티스의 .spec.startegy.type 에는 RollingUpdate와 Recreate 가 있습니다.
만약 .spec.startegy 가 없다면 기본적으로 RollingUpdate 로 간주하며, 이외의 다른 전략은 다른 방법을 사용해야합니다.

그 다음 알아야 할 필드는 maxSurge, maxUnavailable 이며 새로운 컨테이너 생성 비율을 조절할 수 있습니다.
maxSurge 는 생성할 수 있는 최대 파드의 수를 지정할 수 있습니다.
maxUnavailable 는 업데이트 중에 사용할 수 없는 최대 파드의 수를 지정할 수 있습니다.
두 필드 모두 선택적 필드이며 숫자(2) 또는 비율(10%) 이 될 수 있습니다.

장점

Down Time이 발생하지 않습니다.

단점

여러 버전의 파드를 관리해야합니다.

2) 고정 배포

고정 배포 전략은 하나의 버전을 가진 컨테이너만 사용하기위한 전략입니다.

고정 배포 전략은 maxUnavailable 개수를 레플리카와 똑같은 개수로 설정하는 효과가 있습니다.
즉, 우선적으로 이전 버전의 모든 컨테이너를 제거한 후에 신규 컨테이너를 동시에 시작하는 전략입니다.

아래 그림과 함께 단계별로 설명하겠습니다.

Step 1) POD v1 을 모두 제거합니다.
Step 2) POD v1 이 모두 제거된 것을 확인하였다면 POD v2 를 모두 실행시킵니다.

장점

RollingUpdate와 다르게 두 버전의 컨테이너가 동시에 실행되지 않습니다.
프로덕션 환경에 하나의 버전만 필요할 때 사용하면 좋습니다.

단점

Down Time이 발생할 수 있습니다.

3) 블루-그린 릴리스

블루-그린 배포 전략은 Down Time을 최소화하고 위험성을 줄여서 운영 환경에 소프트웨어를 배포하기 위해 사용하는 전략입니다.

즉, 새로운 버전의 파드(Green) 을 모두 띄운 후 실제 요청을 처리할 준비가 되었다면,
이전 버전의 파드(Blue) 의 트래픽을 새로운 버전의 파드(Green) 로 전환하는 전략입니다.

아래 그림과 함께 단계별로 설명하겠습니다.

Step 1) POD v2 를 모두 실행시킵니다.
Step 2) POD v2 가 정상적으로 실행이되었고, 실제 요청을 처리할 준비가 되었다면, POD v1 의 트래픽을 끊습니다.
Step 3) POD v2 가 모든 트래픽을 처리하면 POD v1 은 제거될 수 있습니다.

POD의 트래픽을 끊는 방법은 Service Selector를 새로운 컨테이너로 일치시키는 것을 통해서 수행됩니다.
따라서 Service Mesh, Knative 같은 확장 서비스를 사용하지 않는다면 수동으로 진행해야합니다.

장점

서비스를 통해서 트래픽을 제어하기 때문에 실제 트래픽이 전달되는 곳은 하나의 버전입니다.

단점

새로운 버전의 파드를 모두 띄운 후 이전 버전의 파드를 제거하기 때문에 어플리케이션 용량이 2배가 됩니다.

4) 카나리 릴리스

카나리 배포 전략은 작은 하위 집합만 새로운 컨테이너로 교체하여, 운영에 유연하게 배포하는 방식입니다.

즉, 이전 버전의 일부만 신규 버전으로 교체하고 문제가 없다면 점차 신규 버전을 늘려나가는 전략입니다.

아래 그림과 함께 단계별로 설명하겠습니다.

Step 1) POD v1 의 작은 하위 집합을 POD v2 로 교체합니다.
Step 2) POD v2 가 포함된 모든 파드가 정상적으로 작동한다면 신규 레플리카셋을 늘리고, 이전 레플리카셋을 줄입니다.

장점

문제 발생 시 언제든지 안전하게 롤백할 수 있습니다.
운영 환경에서 신규 버전을 테스트할 수 있습니다.

단점

여러 버전의 파드를 관리해야합니다.

🍏 정리

쿠버네티스는 Deployment를 통해서 손쉬운 컨테이너 교체작업을 지원합니다.
이는 배포를 위한 스크립트를 만드는 공수를 줄여주며, 관리 포인트를 없애줍니다.

또한, Deployment는 바로 사용 가능한 배포 전략인 롤링 배포와 고정 배포를 통해서
기존 컨테이너를 새로운 컨테이너로 교체하는 것을 제어할 수 있습니다.
그리고, 블루-그린 릴리스와 카나리 릴리스를 통해서 사용자에게 새로운 버전을 제공하는 방식을 제어할 수 있습니다.

앞으로 어떤 배포 전략을 사용할 것인지에 대해서 각 배포 전략의 장단점을 파악하고 배포 환경에 걸맞는 전략을 선택해야겠습니다.