🥇Kubernetes의 배포 전략: 롤링, 재생성, 블루/그린, 카나리아, 다크(A/B 테스트)

메모 번역: Weaveworks의 이 개요에서는 가장 널리 사용되는 애플리케이션 출시 전략을 소개하고 Kubernetes Flagger 연산자를 사용하여 가장 진보된 전략을 구현하는 방법을 보여줍니다. 간단한 언어로 작성되었으며 초보 엔지니어라도 문제를 이해할 수 있는 시각적 다이어그램이 포함되어 있습니다.

다이어그램은 다음에서 가져온 것입니다. 또 다른 리뷰 컨테이너 솔루션의 출시 전략

오늘날 클라우드 네이티브 애플리케이션을 개발할 때 가장 큰 과제 중 하나는 배포 속도를 높이는 것입니다. 마이크로서비스 접근 방식에서 개발자는 이미 완전히 모듈식 애플리케이션을 사용하고 설계하므로 여러 팀이 동시에 코드를 작성하고 애플리케이션을 변경할 수 있습니다.

더 짧고 더 자주 배포하면 다음과 같은 이점이 있습니다.

출시 시간이 단축됩니다.
새로운 기능은 사용자에게 더 빠르게 도달합니다.
사용자 피드백은 개발팀에 더 빨리 전달됩니다. 이는 팀이 더 신속하게 기능을 추가하고 문제를 해결할 수 있음을 의미합니다.
개발자의 사기가 높아집니다. 개발 시 더 많은 기능을 사용하면 작업이 더 재미있어집니다.

그러나 릴리스 빈도가 높아질수록 애플리케이션의 안정성이나 사용자 경험에 부정적인 영향을 미칠 가능성도 높아집니다. 그렇기 때문에 운영 및 DevOps 팀은 제품과 사용자에 대한 위험을 최소화하는 방식으로 프로세스를 구축하고 배포 전략을 관리하는 것이 중요합니다. (CI/CD 파이프라인 자동화에 대해 자세히 알아볼 수 있습니다. 여기에.)

이 게시물에서는 롤링 배포와 카나리아 롤아웃 및 그 변형과 같은 고급 방법을 포함하여 Kubernetes의 다양한 배포 전략에 대해 논의합니다.

배포 전략

목표에 따라 사용할 수 있는 배포 전략에는 여러 가지 유형이 있습니다. 예를 들어 추가 테스트를 위해 특정 환경이나 사용자/클라이언트 하위 집합을 변경해야 하거나 기능을 만들기 전에 제한된 사용자 테스트를 수행해야 할 수도 있습니다. 공개적으로 이용 가능한.

롤링(점진적, "롤링" 배포)

이는 Kubernetes의 표준 배포 전략입니다. 클러스터 가동 중지 시간 없이 점진적으로 하나씩 이전 버전의 애플리케이션이 있는 포드를 새 버전의 포드로 교체합니다.

Kubernetes는 새 포드가 작동할 준비가 될 때까지 기다립니다(다음을 사용하여 확인). 준비 테스트), 오래된 것을 롤업하기 전에. 문제가 발생하면 전체 클러스터를 중지하지 않고 이 롤링 업데이트를 중단할 수 있습니다. 배포 유형을 설명하는 YAML 파일에서 새 이미지가 이전 이미지를 대체합니다.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

롤오버 업데이트 매개변수는 매니페스트 파일에서 지정할 수 있습니다.

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

재창조

이 가장 간단한 배포 유형에서는 이전 포드가 한꺼번에 종료되고 새 포드로 교체됩니다.

해당 매니페스트는 다음과 같습니다.

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

블루/그린(블루-그린 배포)

블루-그린 배포 전략(때때로 레드/블랙이라고도 함)에는 애플리케이션의 이전(그린) 버전과 새(블루) 버전을 동시에 배포하는 것이 포함됩니다. 두 버전을 모두 게시한 후 일반 사용자는 녹색 버전에 액세스할 수 있고 파란색 버전은 QA 팀이 별도의 서비스 또는 직접 포트 전달을 통해 테스트를 자동화할 수 있습니다.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

파란색(새) 버전이 테스트되고 릴리스가 승인되면 서비스가 해당 버전으로 전환되고 녹색(이전) 버전이 접혀집니다.

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

카나리아(카나리아 배포)

카나리아 롤아웃은 청록색 롤아웃과 유사하지만 제어 및 사용이 더 좋습니다. 진보적인 단계별 접근 방식. 이 유형에는 "스텔스" 출시 및 A/B 테스트를 포함한 여러 가지 전략이 포함됩니다.

이 전략은 일반적으로 애플리케이션의 백엔드에서 몇 가지 새로운 기능을 시험해 보아야 할 때 사용됩니다. 이 접근 방식의 핵심은 거의 동일한 두 개의 서버를 만드는 것입니다. 하나는 거의 모든 사용자에게 서비스를 제공하고 다른 하나는 새로운 기능을 사용하여 소수의 사용자 하위 그룹에만 서비스를 제공한 후 작업 결과를 비교합니다. 모든 것이 오류 없이 진행되면 새 버전이 점차적으로 전체 인프라에 출시됩니다.

이 전략은 Kubernetes를 사용하여 독점적으로 구현하여 기존 포드를 새 포드로 교체할 수 있지만 Istio와 같은 서비스 메시를 사용하는 것이 훨씬 더 편리하고 간단합니다.

예를 들어 Git에는 0.1.0 태그가 있는 일반 매니페스트와 0.2.0 태그가 있는 카나리아 매니페스트라는 두 가지 매니페스트가 있을 수 있습니다. Istio 가상 게이트웨이 매니페스트에서 가중치를 변경하면 다음 두 배포 간의 트래픽 배포를 제어할 수 있습니다.

Istio를 사용하여 Canary 배포를 구현하는 방법에 대한 단계별 가이드는 다음을 참조하세요. Istio를 사용한 GitOps 워크플로. (메모. 번역: Canary 출시에 관한 자료도 Istio로 번역했습니다. 여기에.)

Weaveworks Flagger를 사용한 카나리아 배포

위브웍스 플래거 카나리아 출시를 쉽고 효과적으로 관리할 수 있습니다.

Flagger는 이들과의 작업을 자동화합니다. Istio 또는 AWS App Mesh를 사용하여 트래픽을 라우팅 및 전환하고 Prometheus 지표를 사용하여 결과를 분석합니다. 또한 웹후크를 통해 카나리아 배포 분석을 보완하여 승인 테스트, 로드 테스트 및 기타 유형의 검사를 수행할 수 있습니다.

Kubernetes 배포 및 필요한 경우 수평적 Pod 확장(HPA)을 기반으로 Flagger는 객체 세트(Kubernetes 배포, ClusterIP 서비스 및 Istio 또는 App Mesh 가상 서비스)를 생성하여 Canary 배포를 분석하고 구현합니다.

제어 루프 구현 (제어 루프),Flager는 성공적인 HTTP 요청 비율, 평균 요청 기간, Pod 상태와 같은 핵심 성능 지표를 동시에 측정하면서 점차적으로 트래픽을 카나리아 서버로 전환합니다. KPI(핵심성과지표) 분석을 기반으로 카나리아는 성장하거나 붕괴하며, 분석 결과는 Slack에 게시됩니다. 이 프로세스에 대한 설명과 시연은 자료에서 찾을 수 있습니다. App Mesh를 위한 점진적 전달.

다크(숨겨짐) 또는 A/B 배포

스텔스 배포는 카나리아 전략의 또 다른 변형입니다(그런데 Flagger도 사용할 수 있습니다). 스텔스 배포와 카나리아 배포의 차이점은 스텔스 배포는 카나리아 배포와 같은 백엔드가 아닌 프런트엔드를 처리한다는 것입니다.

이러한 배포의 또 다른 이름은 A/B 테스트입니다. 새로운 기능을 모든 사용자에게 제공하는 대신 제한된 일부 사용자에게만 제공합니다. 일반적으로 이러한 사용자는 자신이 선구적인 테스터라는 사실을 인식하지 못합니다(따라서 "스텔스 배포"라는 용어가 사용됨).

기능 스위치 사용 (기능 토글) 및 기타 도구를 사용하면 사용자가 새 기능과 상호 작용하는 방식, 사용자의 참여 여부, 새 사용자 인터페이스가 혼란스럽다고 생각하는지 여부 및 기타 유형의 측정항목을 모니터링할 수 있습니다.

신고자 및 A/B 배포

가중치 기반 라우팅 외에도 Flagger는 HTTP 매개변수를 기반으로 카나리아 서버로 트래픽을 라우팅할 수도 있습니다. A/B 테스트에서는 HTTP 헤더나 쿠키를 사용하여 특정 사용자 세그먼트를 타겟팅할 수 있습니다. 이는 서버에 대한 세션 바인딩이 필요한 프런트엔드 애플리케이션의 경우 특히 효과적입니다. (세션 어피니티). 자세한 내용은 Flagger 문서에서 확인할 수 있습니다.

저자는 감사합니다. 스테판 프로단, Weaveworks 엔지니어(그리고 Flagger의 창시자)는 이 모든 놀라운 배포 패턴에 대해 감사드립니다.

번역가의 추신

블로그에서도 읽어보세요.

출처 : habr.com

Kubernetes의 배포 전략: 롤링, 재생성, 블루/그린, 카나리아, 다크(A/B 테스트)