2023.05.18(쿠버네티스 워크로드-디플로이먼트 (Deployment))

디플로이먼트 (Deployment)

 

쿠버네티스에서 Deployment는 한글로 번역하지 않습니다. 흔히 우리는 배포라고 하면 서비스의 노출을 떠올리지만, 쿠버네티스의 Deployment는 서비스 노출의 의미가 아닙니다. 쿠버네티스에서의 Deployment는 파드의 교체/배치(placement)와 관련된 명세입니다. 조금 더 자세히 알아봅시다.

파드의 진실

쿠버네티스에서는 사실 직접 사용자가 개별 파드를 만들 일이 그리 많지 않습니다. 왜냐하면 파드는 일시적이고, 언제나 삭제될 수 있음을 감안하고 만들기 때문입니다. 예를 들어, 파드가 실행되는 공간인 노드가 만일 실패하는 경우, 그 안에서 실행되는 파드 역시 사용할 수 없게 됩니다.

사실 컨테이너를 수동으로 만들고 관리하는 것은, 그냥 도커만 단독으로 사용해도 충분히 할 수 있는 일입니다. 쿠버네티스의 핵심은 컨테이너를 오케스트레이션하는 것으로, 파드 장애 시 자동 복구하거나, 복제하거나 하는 등의 일을 자동으로 처리하는 데에 있습니다. AWS로 따지면 ECS(Elastic Container Service)가 하는 일과 비슷합니다. 이 둘은, 컨테이너의 로드 밸런싱과 오토 스케일링과 같은 일을 담당합니다.

결론적으로, 파드는 디플로이먼트, 스테이트풀셋, 데몬셋을 이용해 관리하는 것이 바람직합니다. 해당 워크로드 리소스는 파드 템플릿을 항상 포함하고 있습니다.

아래는 디플로이먼트의 예시입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    # 여기서부터 파드 템플릿이다
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
    # 여기까지 파드 템플릿이다

디플로이먼트가 뭔가요? 어떤 일을 할 수 있는 리소스인가요?

디플로이먼트는 파드를 업데이트하기 위한 선언적 명세입니다.

디플로이먼트 리소스를 통해 다음을 할 수 있습니다.

• (레플리카셋, 즉 복제본 구성을 이용하여) 파드를 원하는 개수만큼 실행시킬 수 있습니다.
• (제어판 Control Plane을 이용하여) 파드를 업데이트할 수 있습니다.
• 마찬가지로, 파드를 롤백하는 것도 가능합니다.

리뷰: 다양한 배포 전략

애플리케이션의 여러 복제본이 존재할 경우, 이 각각의 복제본을 새 버전으로 업데이트하는 방법으로 다음과 같은 배포 전략이 있음을 배웠습니다.

• 재생성 (Recreate): 이전 버전을 삭제하고 새 버전 생성
• 블루/그린 배포: 한 번에 이전 버전에서 새 버전으로 연결을 전환
• 롤링 배포: 이전 버전을 scale down하고, 새 버전을 scale up 하는 방식으로 단계별로 교체, 롤아웃(rollout)이라고 부릅니다.
• 카나리 배포: 새 버전이 잘 작동한다고 판단되면, 이전 버전을 교체

디플로이먼트는 파드의 복제본을 자동으로 업데이트하게 해주는 명세이므로, 쿠버네티스가 지원하는 배포 전략으로는 재생성(Recreate)과 롤링 배포(RollingUpdate) 방식을 선택할 수 있습니다.

 

Q. 디플로이먼트가 지원하는 배포 전략에서 블루/그린이나 카나리는 찾아볼 수 없습니다. 어떻게 블루/그린이나 카나리 배포를 할 수 있을까요?

 

블루/그린 배포와 카나리 배포는 디플로이먼트의 내장된 기능은 아니지만, Kubernetes에서 이러한 배포 전략을 구현할 수 있는 다양한 방법이 있습니다. 여기에서는 블루/그린 배포와 카나리 배포를 구현하는 일반적인 접근 방법을 소개하겠습니다.

1. 블루/그린 배포:

• 블루/그린 배포는 새로운 버전의 애플리케이션을 배포하기 전에 현재 운영 중인 버전의 애플리케이션과 완전히 동일한 새로운 환경을 구축합니다.
• 새로운 환경에 새 버전의 애플리케이션을 배포하고, 테스트 및 검증을 진행합니다.
• 검증이 완료되면 로드 밸런서 등을 사용하여 트래픽을 새로운 환경으로 전환합니다.

2. 카나리 배포:

• 카나리 배포는 새로운 버전의 애플리케이션을 제한된 범위의 사용자 또는 트래픽에 노출시켜 테스트합니다.
• 예를 들어, 5%의 사용자 또는 트래픽이 새 버전의 애플리케이션을 사용하고, 나머지 95%는 이전 버전을 사용합니다.
• 테스트 중에 새 버전의 애플리케이션에서 예기치 않은 문제가 발생하면 로드 밸런서 등을 사용하여 트래픽을 이전 버전으로 전환할 수 있습니다.
• 테스트가 성공적으로 완료되면 모든 트래픽을 새 버전으로 전환합니다.

이러한 배포 전략을 구현하기 위해 Kubernetes에서는 다음과 같은 방법을 사용할 수 있습니다:

1. 디플로이먼트 및 서비스 사용:

• 디플로이먼트를 사용하여 블루/그린 또는 카나리 배포를 구현할 수 있습니다.
• 새로운 버전의 애플리케이션을 배포하기 위해 새로운 디플로이먼트를 생성하고, 서비스를 통해 트래픽을 분배합니다.
• 필요한 경우 롤백을 위해 이전 버전의 디플로이먼트를 유지합니다.

2. Ingress 컨트롤러 사용:

• Ingress 컨트롤러를 사용하여 블루/그린 또는 카나리 배포를 구현할 수 있습니다.
• 두 개의 서비스를 생성하여 각각 다른 버전의 애플리케이션을 배포합니다.
• Ingress 리소스를 설정하여 트래픽을 서로 다른 서비스로 라우팅합니다.
• 필요한 경우 Ingress 리소스를 수정하여 트래픽의 분배 비율을 조절하거나 롤백을 수행할 수 있습니다.

 

3. 쿠버네티스 기반의 배포 관리 도구 사용:

• Helm, Argo CD 등과 같은 쿠버네티스 기반의 배포 관리 도구를 사용하여 블루/그린 또는 카나리 배포를 구현할 수 있습니다.
• 이러한 도구는 배포 전략을 설정하고, 자동화된 롤백 기능 등을 제공하여 쉽게 블루/그린 또는 카나리 배포를 관리할 수 있습니다.

 

이러한 방법들은 일반적으로 사용되는 방법이지만, 실제 구현은 애플리케이션과 인프라스트럭처의 요구 사항에 따라 다를 수 있습니다. 블루/그린 배포와 카나리 배포에 대한 구체적인 구현 방법은 애플리케이션의 특성과 팀의 선호도에 따라 다를 수 있습니다.

 

출처:

코드스테이츠

Kubernetes 공식 문서: https://kubernetes.io/docs/concepts/cluster-administration/

Red Hat Blog: https://www.redhat.com/en/topics/devops/what-is-canary-deployment