Ghi chú dịch: Phần tổng quan này của Weaworks giới thiệu các chiến lược triển khai ứng dụng phổ biến nhất và cho thấy cách triển khai những chiến lược tiên tiến nhất bằng cách sử dụng toán tử Kubernetes Flagger. Nó được viết bằng ngôn ngữ đơn giản và chứa các sơ đồ trực quan cho phép ngay cả những kỹ sư mới vào nghề cũng có thể hiểu được vấn đề.
Sơ đồ được lấy từ chiến lược triển khai được thực hiện trong Giải pháp Container
Một trong những thách thức lớn nhất trong việc phát triển các ứng dụng gốc trên nền tảng đám mây hiện nay là tăng tốc độ triển khai. Theo cách tiếp cận microservice, các nhà phát triển đã làm việc và thiết kế các ứng dụng mô-đun hoàn toàn, cho phép các nhóm khác nhau viết mã và thực hiện các thay đổi đối với ứng dụng một cách đồng thời.
Việc triển khai ngắn hơn và thường xuyên hơn có những lợi ích sau:
- Thời gian đưa ra thị trường giảm.
- Các tính năng mới tiếp cận người dùng nhanh hơn.
- Phản hồi của người dùng đến với nhóm phát triển nhanh hơn. Điều này có nghĩa là nhóm có thể thêm các tính năng và khắc phục sự cố nhanh hơn.
- Tinh thần của nhà phát triển tăng lên: nhiều tính năng hơn trong quá trình phát triển sẽ thú vị hơn khi làm việc cùng.
Nhưng khi tần suất phát hành tăng lên, khả năng tác động tiêu cực đến độ tin cậy của ứng dụng hoặc trải nghiệm người dùng cũng tăng lên. Đó là lý do tại sao điều quan trọng đối với các hoạt động và nhóm DevOps là xây dựng các quy trình và quản lý chiến lược triển khai theo cách giảm thiểu rủi ro cho sản phẩm và người dùng. (Bạn có thể tìm hiểu thêm về tự động hóa đường ống CI/CD .)
Trong bài đăng này, chúng ta sẽ thảo luận về các chiến lược triển khai khác nhau trong Kubernetes, bao gồm triển khai luân phiên và các phương pháp nâng cao hơn như triển khai canary và các biến thể của chúng.
Chiến lược triển khai
Có một số loại chiến lược triển khai khác nhau mà bạn có thể sử dụng tùy thuộc vào mục tiêu của mình. Ví dụ: bạn có thể cần thực hiện các thay đổi đối với một môi trường nhất định để thử nghiệm thêm hoặc đối với một nhóm nhỏ người dùng/khách hàng hoặc bạn có thể cần thực hiện thử nghiệm người dùng có giới hạn trước khi tạo một tính năng công cộng.
Cán (dần dần, triển khai "lăn")
Đây là chiến lược triển khai tiêu chuẩn trong Kubernetes. Nó dần dần, từng cái một, thay thế các nhóm bằng phiên bản cũ của ứng dụng bằng các nhóm có phiên bản mới - không có thời gian ngừng hoạt động của cụm.
Kubernetes đợi cho đến khi các nhóm mới sẵn sàng hoạt động (kiểm tra chúng bằng cách sử dụng ), trước khi bạn bắt đầu cuộn những cái cũ. Nếu xảy ra sự cố, bản cập nhật luân phiên này có thể bị hủy bỏ mà không dừng toàn bộ cụm. Trong tệp YAML mô tả loại triển khai, hình ảnh mới thay thế hình ảnh cũ:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Các tham số cập nhật chuyển qua có thể được chỉ định trong tệp kê khai:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Tạo lại
Trong kiểu triển khai đơn giản nhất này, các nhóm cũ sẽ bị loại bỏ cùng một lúc và được thay thế bằng các nhóm mới:
Tệp kê khai tương ứng trông giống như thế này:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Xanh lam/Xanh lục (triển khai xanh lam)
Chiến lược triển khai xanh lam (đôi khi còn được gọi là đỏ/đen) liên quan đến việc triển khai đồng thời các phiên bản cũ (xanh lục) và mới (xanh lam) của ứng dụng. Sau khi đăng cả hai phiên bản, người dùng thông thường có quyền truy cập vào phiên bản màu xanh lá cây, trong khi phiên bản màu xanh lam có sẵn để nhóm QA tự động kiểm tra thông qua một dịch vụ riêng biệt hoặc chuyển tiếp cổng trực tiếp:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Sau khi phiên bản màu xanh lam (mới) được thử nghiệm và được phê duyệt phát hành, dịch vụ sẽ chuyển sang phiên bản màu xanh lam (cũ) và được gấp lại:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (triển khai canary)
Triển khai Canary tương tự như triển khai xanh lam nhưng có khả năng kiểm soát và sử dụng tốt hơn cách tiếp cận từng bước. Loại này bao gồm một số chiến lược khác nhau, bao gồm cả việc ra mắt “tàng hình” và thử nghiệm A/B.
Chiến lược này được sử dụng khi có nhu cầu thử nghiệm một số chức năng mới, thường là ở phần phụ trợ của ứng dụng. Bản chất của phương pháp này là tạo ra hai máy chủ gần như giống hệt nhau: một máy chủ phục vụ hầu hết tất cả người dùng và máy chủ kia, với các chức năng mới, chỉ phục vụ một nhóm nhỏ người dùng, sau đó kết quả công việc của họ sẽ được so sánh. Nếu mọi thứ không có lỗi, phiên bản mới sẽ dần dần được triển khai trên toàn bộ cơ sở hạ tầng.
Mặc dù chiến lược này có thể được triển khai độc quyền bằng Kubernetes, thay thế các nhóm cũ bằng các nhóm mới, nhưng việc sử dụng lưới dịch vụ như Istio sẽ thuận tiện và đơn giản hơn nhiều.
Ví dụ: bạn có thể có hai tệp kê khai khác nhau trong Git: tệp kê khai thông thường có thẻ 0.1.0 và tệp kê khai canary có thẻ 0.2.0. Bằng cách thay đổi trọng số trong bảng kê khai cổng ảo Istio, bạn có thể kiểm soát việc phân phối lưu lượng truy cập giữa hai lần triển khai này:
Để biết hướng dẫn từng bước về cách triển khai canary bằng Istio, hãy xem . (Ghi chú. bản dịch.: Chúng tôi cũng đã dịch tài liệu về việc triển khai chim hoàng yến sang Istio .)
Triển khai Canary với Trình gắn cờ Weaworks
cho phép bạn quản lý việc triển khai canary một cách dễ dàng và hiệu quả.
Người gắn cờ tự động làm việc với họ. Nó sử dụng Istio hoặc AWS App Mesh để định tuyến và chuyển đổi lưu lượng cũng như số liệu Prometheus để phân tích kết quả. Ngoài ra, việc phân tích triển khai canary có thể được bổ sung bằng webhook để tiến hành kiểm tra chấp nhận, kiểm tra tải và bất kỳ loại kiểm tra nào khác.
Dựa trên việc triển khai Kubernetes và, nếu cần, mở rộng theo chiều ngang của nhóm (HPA), Flagger tạo các bộ đối tượng (triển khai Kubernetes, dịch vụ ClusterIP và dịch vụ ảo Istio hoặc App Mesh) để phân tích và triển khai triển khai canary:
Thực hiện vòng điều khiển (vòng điều khiển),Người gắn cờ dần dần chuyển lưu lượng truy cập sang máy chủ canary, đồng thời đo lường các số liệu hiệu suất chính như phần trăm yêu cầu HTTP thành công, thời lượng yêu cầu trung bình và tình trạng nhóm. Dựa trên phân tích KPI (Chỉ số hiệu suất chính), chim hoàng yến sẽ phát triển hoặc sụp đổ và kết quả phân tích được xuất bản trên Slack. Một mô tả và minh họa của quá trình này có thể được tìm thấy trong tài liệu .
Triển khai tối (ẩn) hoặc A/B
Triển khai lén lút là một biến thể khác của chiến lược chim hoàng yến (nhân tiện, Người gắn cờ cũng có thể sử dụng chiến lược này). Sự khác biệt giữa triển khai lén lút và triển khai canary là việc triển khai lén lút xử lý giao diện người dùng thay vì phụ trợ như triển khai canary.
Một tên khác cho những triển khai này là thử nghiệm A/B. Thay vì cung cấp tính năng mới cho tất cả người dùng, tính năng này chỉ được cung cấp cho một phần giới hạn trong số họ. Thông thường, những người dùng này không biết rằng họ là những người thử nghiệm tiên phong (do đó có thuật ngữ "triển khai lén lút").
Sử dụng công tắc chức năng (chuyển đổi tính năng) và các công cụ khác, bạn có thể theo dõi cách người dùng tương tác với tính năng mới, liệu họ có bị thu hút bởi tính năng đó hay không hoặc liệu họ có thấy giao diện người dùng mới khó hiểu và các loại số liệu khác hay không.
Người gắn cờ và triển khai A/B
Ngoài định tuyến dựa trên trọng lượng, Người gắn cờ còn có thể định tuyến lưu lượng truy cập đến máy chủ canary dựa trên các tham số HTTP. Trong thử nghiệm A/B, bạn có thể sử dụng tiêu đề HTTP hoặc cookie để nhắm mục tiêu đến một phân khúc người dùng cụ thể. Điều này đặc biệt hiệu quả trong trường hợp ứng dụng giao diện người dùng yêu cầu liên kết phiên với máy chủ (mối quan hệ phiên). Bạn có thể tìm thêm thông tin trong tài liệu về Người gắn cờ.
Tác giả xin chân thành cảm ơn , kỹ sư của Weaworks (và người tạo ra Flagger), về tất cả các mô hình triển khai tuyệt vời này.
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com