Hầu hết các tổ chức ngày nay Deployment các thay đổi phần mềm của họ vào production một cách nhanh chóng. Tuy nhiên, các tổ chức muốn sử dụng các cơ chế phân phối tiến bộ như canary để Deployment các thay đổi và tính năng của mình, đồng thời chấp nhận rủi ro có tính toán. Họ muốn hiển thị phần mềm mới của mình cho một phần nhỏ lưu lượng truy cập production, Analysis xem phần mềm có hoạt động theo cách mong đợi hay không, sau đó dần dần Release phần mềm cho toàn bộ lưu lượng truy cập.
Khi phần mềm ngày càng được Deployment vào Kubernetes, Argo Rollouts đã trở thành một công cụ phổ biến rộng rãi để Deployment canary một cách nhanh chóng. Để phân chia lưu lượng truy cập theo thời gian thực, mặc dù có thể thực hiện bằng cách xâm nhập đơn giản, chúng tôi sẽ xem xét service mesh Istio cho blog của mình. Istio là một mạng service mesh được biết đến rộng rãi và đang được các doanh nghiệp áp dụng nhanh hơn.
Lưu ý : Argo Rollouts hoạt động tốt với bộ cân bằng tải và hầu hết tất cả bộ điều khiển NGINX.
Blog này sẽ trình bày cách Deployment canary tự động cho các application subset (v1 và v2) bằng cách sử dụng Argo Rollouts và Istio và OpsMx ISD cho Argo.
Trước khi chúng tôi bắt đầu
Một cách đơn giản để thực hiện chiến lược canary là xem xét 3 bước sau:
- cấu hình mạng : cấu hình Port Istio để kiểm soát lưu lượng truy cập đến và chuyển hướng đến một ứng dụng (phiên bản ổn định và canary)
- cấu hình agent Deployment : cấu hình Deployment Argo và đặt rules để Release phiên bản mới vào production bằng cách sử dụng Deployment canary.
- cấu hình phần mềm Analysis : Áp dụng AI/ML để tự động hóa việc xác minh canary trước khi tăng dần lưu lượng truy cập.
cấu hình Istio để phân chia lưu lượng giữa các application subset
Quá trình hiển thị một subset nhỏ người dùng hoặc lưu lượng truy cập sang phiên bản ứng dụng mới (được gọi là canary) trong khi cho phép lưu lượng truy cập chính đến phiên bản cũ hơn được gọi là Deployment canary. Sau khi hiệu suất và chất lượng của phiên bản mới được xác thực và xác minh, nhiều lưu lượng truy cập sẽ được phân bổ hơn và cuối cùng, phiên bản mới sẽ thay thế phiên bản cũ; đây được gọi là chiến lược Deployment canary.
Istio cung cấp khả năng phân chia lưu lượng truy cập phức tạp cho canarying và hình ảnh được đưa ra bên dưới:
Việc phân chia lưu lượng trong thời gian chạy có thể đạt được bằng Istio Gateway và Virtual Services (CRD do Istio cung cấp). Tệp yaml Template cho Port vào Istio và Virtual Services sẽ trông như bên dưới. Xin lưu ý rằng trong trường hợp này, rules Virtual Services được đặt để chia lưu lượng truy cập đến thành 90% và 10%, trong đó 90% được phép đối với baseline version của ứng dụng Template và 10% được phép đối với phiên bản mới (canary ).
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: canary-gateway
spec:
selector:
istio: ingressgateway # using Istio IngressGateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
Tệp yaml Virtual Services Template để chỉ định rules phân chia lưu lượng. (Nó sẽ được Argo Rollouts cập nhật khi nó tích hợp nguyên bản với Istio).
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: rollout-vsvc
namespace: ar-ns
spec:
gateways:
- canary-gateway
hosts:
- sample-application
http:
- name: primary
route:
- destination:
host: sample-application
subset: canary
weight: 10
- destination:
host: sample-application
subset: baseline
weight: 90
rules đích trong Istio được sử dụng để xác định các phiên bản khác nhau của cùng một ứng dụng có thể được sử dụng trong Virtual Services Istio.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: rollout-ds
namespace: ar-ns
spec:
host: sample-application # interpreted as sample-application.ar-ns.svc.cluster.local
subsets:
- name: baseline
labels:
version: baseline
- name: canary
labels:
version: canary
Istio có thể phân chia lưu lượng. Tuy nhiên, agent cần cập nhật tỷ lệ phần trăm lưu lượng truy cập dựa trên một số Analysis. Argo Rollouts đóng vai trò là agent.
Bây giờ chúng ta hãy hiểu cấu hình Deployment Argo.
cấu hình Argo Rollouts để Deployment Canary và các rules để Analysis
Argo Rollouts là bộ điều khiển K8 cung cấp một bộ CRD để Deployment Deployment canary. Argo Rollouts sẽ tích hợp với ingress controller (trong trường hợp của chúng tôi là Istio) để dần dần đạt được khả năng phân chia lưu lượng truy cập trong thời gian chạy nhằm chuyển lưu lượng truy cập sang phiên bản mới. Argo cung cấp resource workload có tên Rollouts ( đọc thông số kỹ thuật ) để Deployment các ứng dụng vào Kubernetes. Lưu ý: Deployment là phần mở rộng của resource Deployment/ReplicaSet trong Kubernetes.
Deployment Argo có thể truy vấn và giải thích các số liệu từ nhiều nhà cung cấp khác nhau để xác minh các KPI chính và thúc đẩy promotion hoặc rollback tự động trong quá trình cập nhật. Vì vậy, nó cung cấp một resource khác gọi là AnalysisTemplate để xác định cách thực hiện Analysis canary.
Bạn phải có một dịch vụ để Deployment ứng dụng Template. ( Lưu ý: chúng tôi sẽ sử dụng resource Argo Rollouts thay vì resource Deployment trong K8 để Deployment Canary). Như bạn có thể thấy, resource Dịch vụ đề cập đến sa-argo-rollout, resource Deployment.
apiVersion: v1
kind: Service
metadata:
name: sample-application
labels:
app: sa-argo-rollout
spec:
selector:
app: sa-argo-rollout
ports:
- port: 3100
targetPort: 8088
type: ClusterIP
Dưới đây là ví dụ về resource Deployment có tên sa-argo-rollout. Mục đích ở đây là tạo ra 2 nhóm Release (v1.2.5), đại diện cho phiên bản ổn định (hoặc baseline version).
resource Deployment sẽ cập nhật Virtual Services với 20% lưu lượng truy cập đến canary và sẽ chạy Analysis trong 31 giây. Và sẽ tạm dừng để Analysis xem canary có hoạt động tốt không. Nếu đúng như vậy, nó sẽ cập nhật lại Virtual Services để cho phép thêm 20% (tổng cộng 40%) lưu lượng truy cập đến canary.
Theo đặc tả chiến lược canary, chúng tôi đã đề cập rằng mỗi lần có một đợt Deployment canary mới, resource sa-argo-rollout sẽ gọi isd-analysis-job, một resource Analysis Deployment Argo.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: sa-argo-rollout
spec:
replicas: 2
revisionHistoryLimit: 2
selector:
matchLabels:
app: sa-argo-rollout
template:
metadata:
labels:
app: sa-argo-rollout
spec:
containers:
- name: rollouts-baseline
image: docker.io/opsmxdev/issuegen:1.2.5
imagePullPolicy: Always
ports:
- containerPort: 8088
strategy:
canary:
trafficRouting:
istio:
virtualService:
name: rollout-vsvc # required
routes:
- primary # optional if there is a single route in VirtualService, required otherwise
destinationRule:
name: rollout-ds # required
canarySubsetName: canary # required
stableSubsetName: baseline # required
steps:
- setWeight: 20
- pause: { duration: 31s }
- experiment:
analyses:
- name : isd-analysis-job
requiredForCompletion: true
templateName: isd-analysis-job
templates:
- name: baseline
specRef: stable
- name: canary
specRef: canary
Tất cả logic để Analysis số liệu và Logs của canary với baseline version đều được xác định trong Template Analysis.
Cấu hình Template Analysis trong Argo Rollouts để Analysis canary
resource Template Analysis Deployment Argo sẽ giống như resource bên dưới. Tốt nhất, bạn có thể đề cập đến các rules, điều kiện và logic Analysis nâng cấp giao thông. Trong trường hợp này, chúng tôi đã gọi opsmx11/verifyjob:v5 để thực hiện xác minh canary bằng AI/ML trong ISD cho Argo . Ý tưởng ở đây là chỉ tăng lưu lượng truy cập đến bản Release canary nếu điểm Analysis trên 60. Nếu không, Template Analysis sẽ không Deployment canary và xóa nhóm Deployment mới được tạo.
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: isd-analysis-job
spec:
metrics:
- name: isd-analysis-job
provider:
opsmx:
gateUrl: https://ds312.isd-dev.opsmx.net/
application: sample-application
user: admin
lifetimeHours: "0.05"
threshold:
pass: 80
marginal: 60
Tự động xác minh canary OpsMx ISD cho Argo
OpsMx ISD dành cho Argo cung cấp thông tin thông minh cho các quy trình CI/CD để cung cấp phần mềm một cách an toàn và bảo mật. OpsMx ISD cho Argo sử dụng AI/ML để Analysis Logs, số liệu và các nguồn dữ liệu khác nhằm xác định rủi ro của tất cả các thay đổi, tự động xác định độ tin cậy rằng bản cập nhật có thể được nâng cấp lên giai đoạn tiếp theo của quá trình Deployment canary. Kiểm tra các nguồn dữ liệu OpsMx ISD tích hợp sẵn. ISD cho Argo xác định điểm rủi ro riêng lẻ về chất lượng, hiệu suất, độ tin cậy và bảo mật. Tham khảo hình ảnh dưới đây.
Splunk, Sumo Logic, Appdynamics, Prometheus, New relic, Graphite, elasticsearch, Dynatrace, v.v. cho Logs và số liệu, nhưng nó cũng có thể thực hiện cả Analysis Logs và số liệu cùng một lúc và cho điểm từ 0 đến 100, đồng thời làm nổi bật nguy cơ rò rỉ trong production. Nếu có bất kỳ vấn đề nào trong ứng dụng mới trong chương trình, chẳng hạn như vấn đề về độ trễ hoặc vấn đề kết nối SQL, v.v., nó có thể nhanh chóng được khôi phục.
Phần kết luận
Sau khi Analysis một bản Release, ISD dành cho Argo sẽ gửi lại kết quả và Argo Rollouts quyết định hủy bỏ hoặc tiếp tục Release. Điều tuyệt vời nhất không phải là ISD cho Argo có thể fetch Logs và số liệu từ nhiều công cụ, chẳng hạn như Deployment canary là một tính năng thiết yếu trong phân phối phần mềm để hầu hết tất cả các nhóm DevOps trong các ngành Release sản phẩm của họ một cách nhanh chóng và không gặp rủi ro. Tuy nhiên, các ứng dụng doanh nghiệp có thể có nhiều phần phụ thuộc giữa các vi dịch vụ, các bộ cân bằng tải mạng khác nhau, cơ sở hạ tầng đám mây và các yêu cầu bảo mật. Vì vậy, chiến lược Deployment Canary cần được thực hiện với sự cân nhắc kỹ lưỡng và các phương pháp thực hành tốt nhất.
Đăng ký liền tay Nhận Ngay Bài Mới
Subscribe ngay
Cám ơn bạn đã đăng ký !
Lỗi đăng ký !
Add Comment