Kubernetes 배포 전략

애플리케이션에 최적화된 Kubernetes 출시 전략을 수립하세요.

Kubernetes 배포 옵션 알아보기

출시 시간 단축, 가동 중지 시간 없이 복원 가능한 배포 생성, 앱과 신규 기능의 릴리스 속도 및 빈도 향상, 운영의 유연성 확보 등 목표가 다양한 만큼 그에 따른 적절한 Kubernetes 배포 전략 선택은 탄력적인 애플리케이션 및 인프라를 제공하는 데 있어 매우 중요합니다. 각 Kubernetes 배포 전략에는 목표와 요구 사항에 따라 장점이 있습니다.

Kubernetes를 처음 사용하시나요? 기본 사항 알아보기

Kubernetes 배포 작동 방법

Kubernetes 배포 전략을 구현하기 전에 Kubernetes 배포의 각 부분이 전체적으로 작동하는 방식을 먼저 파악해야 합니다.

Kubernetes 배포의 내용

YAML 파일

설명한 Kubernetes 클러스터의 원하는 상태(Pod의 구성)로서 Kubernetes 배포의 기준으로 사용됩니다.

Pod

앱 또는 워크플로가 실행되는 데 필요한 컨테이너, 공유 리소스 및 환경입니다.

ReplicaSet

동일하게 구성된 pod 그룹을 ReplicaSet라고 하며, Kubernetes 배포를 위해 YAML 파일에 설명된 pod 유형 및 수가 항상 실행되도록 합니다. pod가 실패하면 새 pod가 생성됩니다.

Kube-controller-manager

클러스터의 현재 상태를 YAML에 설명된 원하는 상태와 일치하도록 변경하여 기존 Pod와 ReplicaSet를 업데이트하거나 제거할 뿐만 아니라 새로 만들기도 합니다.

Kube-scheduler

트래픽을 작업자 노드에 배포할 뿐만 아니라 이러한 노드 간에 pod 및 ReplicaSet가 배포되는 방식을 결정합니다.

출시

현재 상태에서 원하는 상태로 클러스터를 다시 구성하는 프로세스이며, 대부분의 경우 가동 중지 시간 없이 수행됩니다.

Kubernetes 출시 작동 방식

클러스터의 원하는 상태 구성을 설명하는 YAML 파일을 만듭니다.
Kubernetes 명령줄 인터페이스인 kubectl을 통해 YAML 파일을 클러스터에 적용합니다.
Kubectl에서 kube-apiserver에 요청을 제출하면 kube-apiserver에서 etcd 데이터베이스에 변경 사항을 기록하기 전에 요청을 인증하고 권한을 부여합니다.
kube-controller-manager는 시스템에서 새로운 요청을 지속적으로 모니터링하고 시스템 상태를 원하는 상태로 조정하여 프로세스에서 ReplicaSet, 배포 및 pod를 생성합니다.
모든 컨트롤러가 실행된 후 kube-scheduler는 아직 노드에서 실행되도록 예약되지 않았기 때문에 "보류 중" 상태인 pod가 있는 것을 확인합니다. kube-scheduler는 pod에 적합한 노드를 찾은 다음, 각 노드의 kubelet과 통신하여 배포를 제어하고 시작합니다.

Kubernetes 배포 사용 사례

Kubernetes 배포를 통해 네 가지 방법으로 컨테이너화된 앱 및 워크플로를 롤아웃합니다. 사용하는 Kubernetes 배포 전략에 하나 이상의 사용 사례를 적용할 수 있습니다.

생성

완전히 새로운 Kubernetes pod 및 ReplicaSet를 출시합니다.

업데이트

원하는 상태를 새로 선언하고 제어된 방식으로 새 pod 및 ReplicaSet를 출시합니다.

롤백

Kubernetes 배포를 이전 상태로 되돌리며 현재 상태가 안정적이지 않은 경우에 유용합니다.

크기 조정

Kubernetes 배포에서 pod 및 ReplicaSet를 변경하지 않고 그 수를 늘립니다.

Kubernetes 배포 전략

시나리오에 따라 가장 적합한 Kubernetes 배포 전략은 허용할 수 있는 가동 중지 시간(있는 경우), 배포 환경, 새 버전 또는 플랫폼의 안정성에 대한 신뢰 수준, 테스트가 필요한지 여부, 알아보고자 하는 내용, 리소스 비용 및 가용성, 비즈니스 목표 등의 여러 가지 요소에 따라 달라집니다. 다음은 조직이 프로덕션 환경에서 사용하는 네 가지 일반적인 배포 전략입니다.

단계적

Kubernetes의 기본 출시 방법은 단계적 또는 롤링 배포입니다. 이 배포에서는 pod를 한 번에 하나씩 서서히 대체하여 가동 중지 시간을 방지합니다. 이전 pod는 새 pod가 준비된 후에만 축소됩니다. 배포에서 문제가 발생하면 전체 클러스터를 오프라인 상태로 설정하지 않고도 Kubernetes 배포를 일시 중지하거나 취소할 수 있습니다.

블루/그린

블루/그린 배포에서는 현재 버전(그린)이 계속 실행되는 동안 애플리케이션 또는 워크플로의 새 버전(블루)을 릴리스합니다. 따라서 사용자를 안정적인 그린 버전에만 노출하면서 프로덕션 환경에서 블루 버전을 테스트할 수 있습니다. 테스트가 완료되면 블루 버전이 점진적으로 그린 버전을 대체합니다.

카나리아

고객이 소규모 고객 그룹에 새 버전을 릴리스하여 Kubernetes 배포를 테스트할 수 있습니다. 현재 버전과 함께 새 버전의 ReplicaSet 하나를 실행한 다음, 오류 없이 지정된 기간이 지난 후 이전 버전을 제거할 때 새 버전을 확장합니다.

A/B 테스트

A/B 테스트 전략은 카나리아 Kubernetes 배포 전략과 매우 유사하게 특정 고객 그룹을 대상으로 합니다. 그러나 A/B 테스트 배포는 버전의 안정성 이상을 설정하려고 하며, 버전이 비즈니스 목표를 달성하는 데 얼마나 효과적인지를 테스트하는 데 사용됩니다. 새 버전은 쿠키, 지리적 위치, 운영 체제 및 디바이스 유형과 같은 요소를 기반으로 사용자에게 배포되며, 현재 버전과 함께 자주 실행되어 새 버전으로 확장의 가치를 입증합니다.