🥇Triển khai Canary trong Kubernetes #1: Gitlab CI

Chúng tôi sẽ sử dụng Gitlab CI và GitOps thủ công để triển khai và sử dụng triển khai Canary trong Kubernetes

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

(Bài viết này)
Triển khai Canary bằng ArgoCI
Triển khai Canary bằng Istio
Triển khai Canary bằng cách sử dụng Jenkins-X Istio Flagger

Chúng tôi sẽ thực hiện triển khai Canary theo cách thủ công thông qua GitOps và tạo/sửa đổi các tài nguyên Kubernetes chính. Bài viết này chủ yếu nhằm mục đích giới thiệu với cách hoạt động triển khai trong Kubernetes Canary, vì có nhiều phương pháp tự động hóa hiệu quả hơn mà chúng ta sẽ xem xét trong các bài viết sau.

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

Triển khai Canary

Với chiến lược Canary, các bản cập nhật trước tiên chỉ được áp dụng cho một nhóm nhỏ người dùng. Thông qua giám sát, ghi dữ liệu, kiểm tra thủ công hoặc các kênh phản hồi khác, bản phát hành được kiểm tra trước khi phát hành cho tất cả người dùng.

Triển khai Kubernetes (cập nhật luân phiên)

Chiến lược mặc định cho Triển khai Kubernetes là cập nhật luân phiên, trong đó một số nhóm nhất định được khởi chạy cùng với các phiên bản hình ảnh mới. Nếu chúng được tạo mà không gặp sự cố, các nhóm có phiên bản hình ảnh cũ sẽ bị chấm dứt và các nhóm mới sẽ được tạo song song.

GitOps

Chúng tôi sử dụng GitOps trong ví dụ này vì chúng tôi:

sử dụng Git như một nguồn sự thật duy nhất
chúng tôi sử dụng Hoạt động Git để xây dựng và triển khai (không cần lệnh nào ngoài thẻ git/hợp nhất)

Ví dụ

Hãy thực hành tốt - có một kho lưu trữ mã ứng dụng và một kho lưu trữ cơ sở hạ tầng.

Kho ứng dụng

Đâ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 thông qua GitlabCI và đẩy kết quả vào Cơ quan đă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à sự thay đổi trong 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 củ cải này, chúng tôi sẽ triển khai thông qua GitlabCI tới Kubernetes, .gitlab-ci.yml như sau:

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

Để 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 đăng nhập cho một cụm (Gcloud) ngay tại đây.

Cơ sở hạ tầng Yaml

Trong kho cơ sở hạ tầng, chúng tôi có dịch vụ:

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

Và triển khai ở 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

Và một triển khai khác trong 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

Lưu ý rằng triển khai ứng dụng chưa có bất kỳ bản sao nào được xác định.

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

Để bắt đầu triển khai ban đầu, bạn có thể khởi động quy trình GitlabCI theo cách thủ công trên nhánh chính. Sau đó kubectl nên xuất ra như sau:

Chúng tôi thấy app triển khai với 10 bản sao và app-canary với 0. Ngoài ra còn có LoadBalancer mà từ đó chúng ta có thể truy cập thông qua curl thông qua IP bên ngoài:

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

Chúng tôi thấy rằng ứng dụng thử nghiệm của chúng tôi chỉ trả về “v1”.

Thực hiện triển khai Canary

Bước 1: phát hành phiên bản mới cho một số người dùng

Chúng tôi đặt số lượng bản sao thành 1 trong tệp triển khai-canary.yaml và hình ảnh phiên bản mới:

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

Trong tập tin deploy.yaml chúng tôi đã thay đổi số lượng bản sao thành 9:

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

Chúng tôi đẩy những thay đổi này vào kho lưu trữ nơi quá trình triển khai sẽ bắt đầu (thông qua GitlabCI) và xem kết quả là:

Dịch vụ của chúng tôi sẽ trỏ đến cả hai hoạt động triển khai vì cả hai đều có bộ chọn ứng dụng. Do tính ngẫu nhiên mặc định của Kubernetes, chúng ta sẽ thấy các phản hồi khác nhau cho ~10% yêu cầu:

Trạng thái hiện tại của ứng dụng của chúng tôi (GitOps, được lấy từ Git dưới dạng Nguồn sự thật duy nhất) là sự hiện diện của hai bản triển khai với các bản sao hoạt động, một bản cho mỗi phiên bản.

~10% người dùng làm quen với phiên bản mới và vô tình thử nghiệm nó. Bây giờ là lúc kiểm tra lỗi trong nhật ký và theo dõi dữ liệu để tìm ra vấn đề.

Bước 2: Phát hành phiên bản mới cho tất cả người dùng

Chúng tôi quyết định rằng mọi thứ đã diễn ra tốt đẹp và bây giờ chúng tôi cần tung ra phiên bản mới cho tất cả người dùng. Để làm điều này chúng tôi chỉ cần cập nhật deploy.yaml cài đặt phiên bản mới của hình ảnh và số lượng bản sao bằng 10. Trong deploy-canary.yaml chúng ta thiết lập số lượng bản sao về 0. Sau khi triển khai, kết quả sẽ như sau:

Tổng hợp

Đối với tôi, việc triển khai theo cách thủ công theo cách này giúp hiểu được việc có thể định cấu hình nó bằng k8s dễ dàng như thế nào. Vì Kubernetes cho phép bạn cập nhật mọi thứ thông qua API nên các bước này có thể được tự động hóa thông qua tập lệnh.

Một điều khác cần được triển khai là điểm vào của người thử nghiệm (LoadBalancer hoặc thông qua Ingress) mà qua đó chỉ có thể truy cập phiên bản mới. Nó có thể được sử dụng để duyệt thủ công.

Trong các bài viết sau, chúng ta sẽ tìm hiểu các giải pháp tự động hóa khác có thể triển khai hầu hết những gì chúng tôi đã thực hiện.

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 #1: Gitlab CI