🥇Triển khai Canary trong Kubernetes #2: Triển khai Argo

Chúng tôi sẽ sử dụng bộ điều khiển triển khai Argo Rollouts gốc k8s và GitlabCI để chạy triển khai Canary cho Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Các bài viết trong loạt bài này

Triển khai Canary trong Kubernetes #1: Gitlab CI
(Bài viết này)
Triển khai Canary bằng Istio
Triển khai Canary bằng cách sử dụng Jenkins-X Istio Flagger

Triển khai Canary

Chúng tôi hy vọng bạn đọc phần đầu tiên, trong đó chúng tôi đã giải thích ngắn gọn Triển khai Canary là gì. Chúng tôi cũng đã chỉ ra cách triển khai nó bằng tài nguyên Kubernetes tiêu chuẩn.

Triển khai Argo

Argo Rollouts là bộ điều khiển triển khai gốc Kubernetes. Nó cung cấp CRD (Định nghĩa tài nguyên tùy chỉnh) cho Kubernetes. Nhờ nó, chúng ta có thể sử dụng một thực thể mới: Rollout, quản lý việc triển khai xanh lam và hoàng yến với nhiều tùy chọn cấu hình khác nhau.

Bộ điều khiển Triển khai Argo được tài nguyên tùy chỉnh sử dụng Rollout, Cho phép các chiến lược triển khai bổ sung như xanh lam và hoàng yến cho Kubernetes. Nguồn Rollout cung cấp chức năng tương đương Deployment, chỉ với các chiến lược triển khai bổ sung.
tài nguyên Deployments có hai chiến lược để triển khai: RollingUpdate и Recreate. Mặc dù các chiến lược này phù hợp với hầu hết các trường hợp, nhưng để triển khai tới máy chủ trên quy mô rất lớn, các chiến lược bổ sung sẽ được sử dụng, chẳng hạn như xanh lam hoặc xanh canary, không có sẵn trong Bộ điều khiển triển khai. Để sử dụng các chiến lược này trong Kubernetes, người dùng phải viết các tập lệnh trên phần Triển khai của họ. Bộ điều khiển triển khai Argo hiển thị các chiến lược này dưới dạng các tham số đơn giản, có tính khai báo và có thể định cấu hình.
https://argoproj.github.io/argo-rollouts

Ngoài ra còn có Argo CI, cung cấp giao diện web thuận tiện để sử dụng với Rollouts, chúng ta sẽ xem xét điều đó trong bài viết tiếp theo.

Cài đặt triển khai Argo

Phía máy chủ

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Trong củ cải cơ sở hạ tầng của chúng tôi (xem bên dưới), chúng tôi đã thêm install.yaml dưới dạng i/k8s/argo-rollouts/install.yaml. Bằng cách này GitlabCI sẽ cài đặt nó vào cụm.

Phía khách hàng (plugin kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Ứng dụng ví dụ

Cách tốt nhất là có các kho lưu trữ riêng cho mã ứng dụng và cơ sở hạ tầng.

Kho lưu trữ cho ứng dụng

Kim Wuestkamp/k8s-triển khai-example-app

Đây là API Python+Flask rất đơn giản trả về phản hồi dưới dạng JSON. Chúng tôi sẽ xây dựng gói bằng GitlabCI và đẩy kết quả vào Sổ đăng ký Gitlab. Trong sổ đăng ký, chúng tôi có hai phiên bản phát hành khác nhau:

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

Sự khác biệt duy nhất giữa chúng là tệp JSON được trả về. Chúng tôi sử dụng ứng dụng này để hình dung dễ dàng nhất có thể phiên bản chúng tôi đang giao tiếp.

Kho cơ sở hạ tầng

Trong kho lưu trữ này, chúng tôi sẽ sử dụng GitlabCI để triển khai cho Kubernetes, .gitlab-ci.yml trông như thế này:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Để tự chạy nó, bạn sẽ cần một cụm, bạn có thể sử dụng Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Bạn cần rẽ nhánh https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure và tạo một biến KUBECONFIG trong GitlabCI, nơi sẽ chứa cấu hình để truy cập kubectl đến cụm của bạn.

Здесь Bạn có thể đọc về cách lấy thông tin xác thực cho một cụm (Gcloud).

Cơ sở hạ tầng Yaml

Bên trong kho cơ sở hạ tầng chúng tôi có dịch vụ:

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

và rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout hoạt động tương tự như Triển khai. Nếu chúng tôi không đặt chiến lược cập nhật (như canary ở đây), chiến lược này sẽ hoạt động giống như Triển khai cập nhật luân phiên mặc định.

Chúng tôi xác định hai bước trong yaml để triển khai canary:

10% lưu lượng truy cập vào canary (đợi thủ công OK)
50% lưu lượng truy cập vào canary (đợi 2 phút rồi tiếp tục 100%)

Thực hiện triển khai ban đầu

Sau lần triển khai đầu tiên, tài nguyên của chúng ta sẽ như thế này:

Và chúng tôi chỉ nhận được phản hồi từ phiên bản đầu tiên của ứng dụng:

Thực hiện triển khai Canary

Bước 1: 10% lưu lượng truy cập

Để bắt đầu triển khai canary, chúng ta chỉ cần thay đổi phiên bản hình ảnh như chúng ta thường làm với quá trình triển khai:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

Và chúng tôi thúc đẩy các thay đổi, vì vậy Gitlab CI sẽ triển khai và chúng tôi thấy những thay đổi:

Bây giờ nếu chúng ta truy cập dịch vụ:

Tuyệt vời! Chúng tôi đang trong quá trình triển khai chim hoàng yến. Chúng ta có thể thấy sự tiến bộ bằng cách chạy:

kubectl argo rollouts get rollout rollout-canary

Bước 2: 50% lưu lượng truy cập:

Bây giờ hãy chuyển sang bước tiếp theo: chuyển hướng 50% lưu lượng truy cập. Chúng tôi đã định cấu hình bước này để chạy thủ công:

kubectl argo rollouts promote rollout-canary # continue to step 2

Và ứng dụng của chúng tôi đã trả về 50% phản hồi từ các phiên bản mới:

Và đánh giá triển khai:

Tuyệt vời.

Bước 3: 100% lưu lượng truy cập:

Chúng tôi thiết lập để sau 2 phút, bước 50% tự động kết thúc và bước 100% bắt đầu:

Và đầu ra ứng dụng:

Và đánh giá triển khai:

Quá trình triển khai Canary đã hoàn tất.

Các ví dụ khác với Argo Rollouts

Có nhiều ví dụ hơn ở đây, chẳng hạn như cách thiết lập bản xem trước và so sánh môi trường dựa trên canary:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Video về Triển khai Argo và Argo CI

Tôi thực sự khuyên bạn nên xem video này, nó cho thấy cách Argo Rollouts và Argo CI phối hợp với nhau:

Tổng

Tôi thực sự thích ý tưởng sử dụng CRD để quản lý việc tạo các loại triển khai hoặc bản sao bổ sung, chuyển hướng lưu lượng truy cập, v.v. Làm việc với họ diễn ra suôn sẻ. Tiếp theo tôi muốn thử nghiệm khả năng tích hợp với Argo CI.

Tuy nhiên, dường như sắp có sự hợp nhất lớn giữa Argo CI và Flux CI, vì vậy tôi có thể đợi cho đến khi bản phát hành mới ra mắt: Thông lượng Argo.

Bạn đã có kinh nghiệm gì với Argo Rollouts hoặc Argo CI chưa?

Cũng đọc các bài viết khác trên blog của chúng tôi:

Nguồn: www.habr.com

Triển khai Canary trong Kubernetes #2: Triển khai Argo