Kubernetes #1의 카나리아 배포: Gitlab CI

Gitlab CI와 수동 GitOps를 사용하여 Kubernetes에서 Canary 배포를 구현하고 사용합니다.

이 시리즈의 기사:

• (이 기사)
• ArgoCI를 사용한 카나리아 배포
• Istio를 사용한 카나리아 배포
• Jenkins-X Istio Flagger를 사용한 카나리아 배포

GitOps를 통해 Canary 배포를 수동으로 수행하고 기본 Kubernetes 리소스를 생성/수정하겠습니다. 이 기사는 주로 소개용으로 작성되었습니다. 다음 기사에서 고려할 보다 효과적인 자동화 방법이 있기 때문에 Kubernetes Canary에서 배포가 작동하는 방식에 대해 설명합니다.

https://www.norberteder.com/canary-deployment/

카나리아 배포

카나리아 전략을 사용하면 먼저 일부 사용자에게만 업데이트가 적용됩니다. 모니터링, 로그 데이터, 수동 테스트 또는 기타 피드백 채널을 통해 릴리스는 모든 사용자에게 릴리스되기 전에 테스트됩니다.

Kubernetes 배포(롤링 업데이트)

Kubernetes 배포의 기본 전략은 롤링 업데이트이며, 여기서 특정 수의 Pod가 새 버전의 이미지로 시작됩니다. 문제 없이 생성된 경우 이전 버전의 이미지가 포함된 포드가 종료되고 새 포드가 병렬로 생성됩니다.

GitOps

이 예에서는 다음과 같은 이유로 GitOps를 사용합니다.

• Git을 단일 정보 소스로 사용
• 빌드 및 배포에 Git Operations를 사용합니다(git tag/merge 이외의 명령은 필요하지 않습니다).

예

모범 사례를 살펴보겠습니다. 애플리케이션 코드용 리포지토리 하나와 인프라용 리포지토리 하나를 갖는 것입니다.

애플리케이션 저장소

이는 응답을 JSON으로 반환하는 매우 간단한 Python+Flask API입니다. GitlabCI를 통해 패키지를 빌드하고 결과를 Gitlab 레지스트리에 푸시하겠습니다. 레지스트리에는 두 가지 릴리스 버전이 있습니다.

• wuestkamp/k8s-deployment-example-app:v1
• wuestkamp/k8s-deployment-example-app:v2

이들 사이의 유일한 차이점은 반환된 JSON 파일의 변경 사항입니다. 우리는 어떤 버전과 통신하고 있는지 가능한 한 쉽게 시각화하기 위해 이 애플리케이션을 사용합니다.

인프라 저장소

이 순무에서는 GitlabCI를 통해 Kubernetes에 배포합니다. .gitlab-ci.yml 다음과 같습니다 :

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

직접 실행하려면 클러스터가 필요하며 Gcloud를 사용할 수 있습니다.

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

포크해야 해 https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure 변수를 만들고 KUBECONFIG 액세스를 위한 구성이 포함된 GitlabCI에서 kubectl 클러스터에.

클러스터(Gcloud)에 대한 사용자 인증 정보를 얻는 방법을 읽어보세요. 여기에.

인프라 Yaml

인프라 저장소에는 다음과 같은 서비스가 있습니다.

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

그리고 배포 deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

그리고 또 다른 배포 deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

app-deploy에는 아직 복제본이 정의되어 있지 않습니다.

초기 배포 수행

초기 배포를 시작하려면 마스터 분기에서 GitlabCI 파이프라인을 수동으로 시작할 수 있습니다. 이후 kubectl 다음을 출력해야 합니다:

우리가 본다. app 10개의 복제본으로 배포하고 0으로 app-canary를 사용합니다. 다음을 통해 액세스할 수 있는 LoadBalancer도 있습니다. curl 외부 IP를 통해:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

테스트 애플리케이션이 "v1"만 반환하는 것을 볼 수 있습니다.

카나리아 배포 실행

1단계: 일부 사용자를 위한 새 버전 출시

배포-canary.yaml 파일과 새 버전 이미지에서 복제본 수를 1로 설정했습니다.

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

파일에서 deploy.yaml 복제본 수를 9로 변경했습니다.

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

GitlabCI를 통해 배포가 시작될 저장소에 이러한 변경 사항을 푸시하고 결과를 확인합니다.

두 배포 모두에 앱 선택기가 있으므로 우리 서비스는 두 배포를 모두 가리킵니다. Kubernetes의 기본 무작위화로 인해 요청의 ~10%에 대해 서로 다른 응답이 표시됩니다.

우리 애플리케이션(Git에서 Single Source Of Truth로 가져온 GitOps)의 현재 상태는 각 버전마다 하나씩 활성 복제본이 있는 두 개의 배포가 있다는 것입니다.

약 10%의 사용자가 새 버전에 익숙해지고 의도치 않게 테스트합니다. 이제 문제를 찾기 위해 로그와 모니터링 데이터의 오류를 확인해야 할 때입니다.

2단계: 모든 사용자에게 새 버전 출시

우리는 모든 것이 잘 진행되었다고 판단했으며 이제 모든 사용자에게 새 버전을 출시해야 합니다. 이를 위해 간단히 업데이트합니다. deploy.yaml 새 버전의 이미지를 설치하고 복제본 수는 10입니다. deploy-canary.yaml 복제본 수를 다시 0으로 설정했습니다. 배포 후 결과는 다음과 같습니다.

최대 합계

나에게는 이런 방식으로 배포를 수동으로 실행하면 k8s를 사용하여 얼마나 쉽게 구성할 수 있는지 이해하는 데 도움이 됩니다. Kubernetes를 사용하면 API를 통해 모든 것을 업데이트할 수 있으므로 이러한 단계는 스크립트를 통해 자동화될 수 있습니다.

구현해야 할 또 다른 사항은 새 버전에만 액세스할 수 있는 테스터 진입점(LoadBalancer 또는 Ingress를 통해)입니다. 수동 검색에 사용할 수 있습니다.

향후 기사에서는 우리가 수행한 대부분의 작업을 구현하는 다른 자동화 솔루션을 확인해 보겠습니다.

블로그에서 다른 기사도 읽어보세요.

• 승인이 없는 ClickHouse에서 승인이 있는 ClickHouse로 마이그레이션한 결과는 무엇입니까?
• Nginx용 동적 모듈 빌드
• nxs-build-tools 업데이트 - deb 및 rpm 패키지 구축 보조자
• Hashicorp Consul의 Kubernetes 인증 소개
• Csync2 유틸리티를 사용할 때 직면해야 했던 문제
• Redmine용 텔레그램 봇. 자신과 다른 사람의 삶을 단순화하는 방법

출처 : habr.com