Helpex - Trao đổi & giúp đỡ Đăng nhập

Phần 1: Cách triển khai Canary hoạt động trong Kubernetes, Istio và Linkerd

Lý An Tâm
· 17:00 27/06/2019
2 ngày trước

Đây là phần đầu tiên của loạt bài gồm hai phần về triển khai chim hoàng yến. Trong bài đăng này, chúng tôi đề cập đến mô hình nhà phát triển và cách nó được hỗ trợ trong Kubernetes, Linkerd và Istio. Trong phần hai, chúng ta sẽ khám phá mô hình hoạt động, cách nó được hỗ trợ trong Glasnostic, so sánh các cách triển khai khác nhau và cuối cùng là ưu và nhược điểm của việc triển khai canary.

Một triển khai chim hoàng yến (hoặc phát hành canary) là một mô hình microservices mà nên là một phần của tất cả các chiến lược giao hàng liên tục. Mẫu này giúp các tổ chức triển khai dần dần các bản phát hành mới cho sản xuất, cho một nhóm nhỏ người dùng lúc đầu, trước khi thực hiện các thay đổi có sẵn cho tất cả người dùng. Trong trường hợp không may là mọi thứ đi ngang trong quá trình thúc đẩy, triển khai canary giúp giảm thiểu thời gian ngừng hoạt động, ngăn chặn các tác động tiêu cực đến một số lượng nhỏ người dùng và giúp dễ dàng bắt đầu khôi phục nếu cần. Tóm lại, hãy nghĩ về việc triển khai canary như một đợt triển khai theo giai đoạn hoặc tăng dần.

Triển khai Canary là gì?

Mô hình triển khai chim hoàng yến lấy tên từ một hoạt động hiện nay đã không còn tồn tại của những người thợ khai thác than mang theo những con chim hoàng yến vào mỏ để cảnh báo chúng khi khí độc đạt đến mức nguy hiểm. Như bạn có thể tưởng tượng, miễn là chim hoàng yến cất tiếng hót, không khí vẫn an toàn để thở. Nếu chim hoàng yến chết, có nghĩa là đã đến lúc phải sơ tán! Điều này có liên quan gì đến việc phát triển phần mềm? Hãy nghĩ về chim hoàng yến như một tập hợp nhỏ người dùng cuối được tiếp xúc với các dịch vụ mới hoặc các khả năng mới trước khi có phần lớn người dùng. Ưu điểm của kiểu phát hành này là nếu việc triển khai bị phá vỡ theo những cách không thể chấp nhận được, bản phát hành có thể được khôi phục lại và các tác động bất lợi có thể chỉ xảy ra đối với một nhóm nhỏ người dùng.

Phần 1: Cách triển khai Canary hoạt động trong Kubernetes, Istio và Linkerd

Hình 1 (ở trên): Sơ đồ triển khai canary điển hình. Ban đầu, lưu lượng khách hàng đến một dịch vụ được chuyển đến cụm sản xuất hiện có (màu xanh lam). Để kiểm tra phiên bản mới của dịch vụ, một cụm canary được triển khai và cổng quản lý hoặc bộ cân bằng tải được hướng dẫn để chuyển hướng một lượng nhỏ lưu lượng truy cập đến nó (màu xanh lá cây). Thông thường, lưu lượng truy cập này chỉ đơn giản là một tỷ lệ phần trăm nhỏ của tất cả các yêu cầu đối với dịch vụ được đề cập. Tuy nhiên, đôi khi, các nhà khai thác có thể chỉ muốn định tuyến một đoạn lưu lượng cụ thể đến cụm canary, chẳng hạn như yêu cầu từ một nhóm người dùng cụ thể hoặc yêu cầu từ một khu vực địa lý cụ thể. Nếu cụm canary hoạt động như dự định, việc triển khai sẽ được triển khai đầy đủ và cụm sản xuất cũ sẽ bị xóa. Đôi khi, một cụm riêng biệt đóng vai trò là đường cơ sở trong phân tích chim hoàng yến (màu xanh lam nở).

Phân tích Canary thì sao?

Việc cải tiến mẫu canary được gọi là phân tích canary bao gồm một cụm đường cơ sở bổ sung chạy các dịch vụ của phiên bản sản xuất hiện tại cùng với cụm canary và với lượng lưu lượng truy cập bằng nhau. Điều này giúp loại bỏ mọi đặc thù của cụm sản xuất do tính chất hoạt động lâu dài của nó.

Triển khai mô hình triển khai Canary

Kubernetes

Hỗ trợ triển khai canary trong Kubernetes tương đối hạn chế. Phương pháp thường được thực hiện liên quan đến việc triển khai các phiên bản canary theo tỷ lệ mong muốn cùng với các phiên bản sản xuất và sau đó định cấu hình bộ cân bằng tải để phân phối tải trên tất cả các phiên bản một cách đồng đều nhất có thể. Việc triển khai chim hoàng yến có phần dễ dàng hơn nếu bộ cân bằng tải quản lý là bộ điều khiển xâm nhập. Bởi vì quy tắc nhập có thể dựa trên máy chủ lưu trữ hoặc đường dẫn của yêu cầu hoặc kết hợp cả hai, điều này cung cấp nhiều tiêu chí hơn về cách có thể phân chia lưu lượng truy cập.

Tuy nhiên, trong phần lớn các trường hợp, cách duy nhất để điều chỉnh lưu lượng truy cập tương đối giữa phiên bản canaries và phiên bản sản xuất là điều chỉnh tỷ lệ phiên bản. (Xem  bài đăng này để biết ví dụ đầy đủ về cách có thể thực hiện điều này.) Nói cách khác, nếu 10% lưu lượng truy cập phải được chuyển đến canary, nó sẽ phải được triển khai cùng với chín phiên bản của phiên bản sản xuất. Để làm cho vấn đề tồi tệ hơn, mối quan hệ tuyến tính này chỉ đúng đối với các chiến lược cân bằng tải được phân phối đều như cân bằng tổng hợp. Các chiến lược động như cân bằng ít kết nối nhất làm cho các tỷ lệ cụ thể khó duy trì.

Nhìn chung, Kubernetes không đặc biệt thích hợp với việc triển khai chim hoàng yến . Nó không hỗ trợ định tuyến canary dựa trên tiêu chí nguồn yêu cầu như địa lý hoặc nhân khẩu học. Kubernetes cũng có xu hướng lãng phí tài nguyên khi yêu cầu tỷ lệ định tuyến canary cụ thể.

Linkerd

Bởi vì Linkerd được dựa trên Twitter Finagle thư viện, ban đầu Buoyant của Linkerd , bây giờ thường được gọi là Linkerd 1.x , hỗ trợ tốt các chung chung hơn, định tuyến yêu cầu năng động , mà các nhà khai thác có thể sử dụng để thực hiện những gì Buoyant gọi là “chuyển giao thông.” Định tuyến yêu cầu động dựa trên tập hợp các quy tắc định tuyến được gọi là “bảng ủy quyền” ( viết tắt là dtabs ) được lưu trữ toàn cầu trong namerd và có thể thay đổi trong thời gian chạy mà không cần khởi động lại proxy linkerd. Là một lưới dịch vụ, Linkerd 1.x có thể áp dụng các quy tắc định tuyến cho bất kỳ lưu lượng nào, theo hướng Bắc-Nam hoặc Đông-Tây, không chỉ lưu lượng truy cập xâm nhập.

Linkerd 1.x hỗ trợ định tuyến rất rộng rãi. Khi Linkerd 1.x ban đầu chấp nhận một yêu cầu, nó sẽ được gán một “đường dẫn đích” hợp lý. Ví dụ: một yêu cầu http://users-service/lookup  có thể được chỉ định /svc/userslàm đường dẫn đích. Đường dẫn này sau đó có thể trải qua một loạt các biến đổi dựa trên quy tắc. Ví dụ, một quy tắc dtab như:

/svc => /env/prod

... sẽ viết lại đường dẫn đích trước đó /svc/userstới /env/prod/users.

Các quy tắc định tuyến có thể khá rõ ràng. Ví dụ: để triển khai một mẫu canary, các toán tử có thể chỉ định một quy tắc như:

/svc/users => 99 * /env/prod/users & 1 * /env/prod/users-v2

... để chuyển hướng 1% lưu lượng truy cập sang người dùng v2 canary. Ngoài ra, các quy tắc định tuyến có thể bị ghi đè theo yêu cầu thông qua l5d-dtabtiêu đề HTTP cụ thể của Linkerd . Điều này cho phép những con chim hoàng yến được kiểm tra bằng cách yêu cầu chúng một cách rõ ràng.

Linkerd 2.x gần đây hơn là bản viết lại của Linkerd trong Go and Rust và do đó không bao gồm các khả năng định tuyến dựa trên Finagle phong phú. Do đó, triển khai canary không được hỗ trợ ngay lập tức, khiến người dùng Linkerd 2.x phải dựa vào hỗ trợ định tuyến hạn chế của Kubernetes. Yêu cầu tính năng hỗ trợ định tuyến trong Linkerd 2.x đang được theo dõi tại đây .

Istio

Là một lưới dịch vụ, Istio hỗ trợ các quy tắc định tuyến được áp dụng cho tất cả các dịch vụ trong lưới, không chỉ để xâm nhập lưu lượng truy cập. Tương tự như Linkerd 1.x, các quy tắc định tuyến này cho phép kiểm soát mức độ hợp lý đối với cách hướng lưu lượng truy cập. Không giống như Kubernetes, triển khai canary trong Istio có thể được thực hiện mà không yêu cầu một số trường hợp cụ thể.

Triển khai Canary trong Istio được cấu hình theo hai bước. Đầu tiên, một quy tắc đích được tạo để xác định các tập con của dịch vụ đích dựa trên nhãn phiên bản ( hình 2 ). Sau đó, một quy tắc dịch vụ ảo được sử dụng để chỉ định trọng số tương đối giữa các tập hợp con này ( hình 3 ).

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: users-destinations
spec:
  host: users.prod.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Hình 2 (khối mã trên): Quy tắc đích Istio xác định tập hợp con “v1” và “v2” của dịch vụ users.prod.svc.cluster.local dựa trên nhãn phiên bản của các phiên bản dịch vụ.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: users-route
spec:
  hosts:
  - users.prod.svc.cluster.local
  http:
  - route:
    - destination:
        host: users.prod.svc.cluster.local
        subset: v1
      weight: 95
    - destination:
        host: users.prod.svc.cluster.local
        subset: v2
      weight: 5

Hình 3  (khối mã trên) : Quy tắc dịch vụ ảo Istio chỉ định rằng 95% lưu lượng truy cập tới users.prod.svc.cluster.local phải được chuyển đến tập con “v1” và 5% đến tập con “v2” của nó.

Khi các quy tắc này được áp dụng (thông qua kubectl apply), việc triển khai canary sẽ có hiệu lực ngay lập tức.

Ví dụ được đưa ra ở trên chỉ làm xước bề mặt của những gì các quy tắc định tuyến của Istio có thể làm. Ví dụ: định nghĩa dịch vụ ảo có thể bao gồm một biểu thức chính quy khớp với cookie của người dùng để triển khai các quy tắc định tuyến nguồn, trong số các quy tắc khác. 

Hãy theo dõi phần hai của loạt bài này, nơi chúng ta xem xét triển khai canary từ góc độ hoạt động, cách nó được hỗ trợ trong Glasnostic, so sánh các triển khai khác nhau và cuối cùng là ưu và nhược điểm của triển khai canary.

10 hữu ích 0 bình luận 7.0k xem chia sẻ

Có thể bạn quan tâm