Nhiều môi trường (Staging, QA, production, v.v.) với Kubernetes

Điều gì được coi là một phương pháp hay với K8S để quản lý nhiều môi trường (QA, Staging, Production, Dev, v.v.)?

Ví dụ: giả sử một nhóm đang làm việc trên một sản phẩm yêu cầu triển khai một vài API, cùng với một ứng dụng giao diện người dùng. Thông thường, điều này sẽ yêu cầu ít nhất 2 môi trường:

• Giai đoạn: Để lặp lại / thử nghiệm và xác thực trước khi phát hành cho khách hàng
• Sản xuất: Đây là môi trường mà khách hàng có quyền truy cập. Nên chứa các tính năng ổn định và đã được thử nghiệm tốt.

Vì vậy, giả sử nhóm đang sử dụng Kubernetes, cách thực hành tốt để lưu trữ những môi trường này là gì? Cho đến nay, chúng tôi đã xem xét hai lựa chọn:

1. Sử dụng một cụm K8s cho mỗi môi trường
2. Chỉ sử dụng một cụm K8s và giữ chúng trong các không gian tên khác nhau.

(1) Có vẻ như các lựa chọn an toàn nhất vì nó giảm thiểu rủi ro có thể xảy ra lỗi do con người và hỏng hóc máy móc, có thể gây nguy hiểm cho môi trường sản xuất. Tuy nhiên, điều này đi kèm với chi phí của nhiều máy chủ hơn và chi phí quản lý cơ sở hạ tầng nhiều hơn.

(2) Có vẻ như nó đơn giản hóa cơ sở hạ tầng và quản lý triển khai vì chỉ có một cụm duy nhất nhưng nó đặt ra một số câu hỏi như:

• Làm thế nào để đảm bảo rằng một sai lầm của con người có thể ảnh hưởng đến môi trường sản xuất?
• Làm thế nào để đảm bảo rằng tải cao trong môi trường dàn dựng sẽ không làm giảm hiệu suất trong môi trường sản xuất?

Có thể có một số mối quan tâm khác, vì vậy tôi liên hệ với cộng đồng K8s trên StackOverflow để hiểu rõ hơn về cách mọi người đang đối phó với những loại thách thức này.

Xem xét nhiều cụm

Hãy xem bài đăng trên blog này của Vadim Eisenberg ( IBM / Istio ): Danh sách kiểm tra: ưu và nhược điểm của việc sử dụng nhiều cụm Kubernetes và cách phân phối khối lượng công việc giữa chúng .

Tôi muốn làm nổi bật một số ưu / nhược điểm:

Lý do có nhiều cụm

• Tách sản xuất / phát triển / thử nghiệm: đặc biệt để thử nghiệm phiên bản mới của Kubernetes, của lưới dịch vụ, của phần mềm cụm khác
• Tuân thủ: theo một số quy định, một số ứng dụng phải chạy trong các cụm riêng biệt / VPN riêng biệt
• Cách ly tốt hơn để bảo mật
• Đám mây / tại chỗ: để phân chia tải giữa các dịch vụ tại chỗ

Những lý do để có một cụm duy nhất

• Giảm chi phí thiết lập, bảo trì và quản trị
• Cải thiện việc sử dụng
• Giảm chi phí

Xem xét một môi trường không quá tốn kém, với mức bảo trì trung bình nhưng vẫn đảm bảo cách ly bảo mật cho các ứng dụng sản xuất, tôi khuyên bạn nên:

• 1 cụm cho DEV và STAGING (được phân tách bằng không gian tên, thậm chí có thể bị cô lập, sử dụng Chính sách mạng, như ở Calico )
• 1 cụm cho PROD

Môi trường chẵn lẻ

Đó là một hành động tốt để giữ cho quá trình phát triển, dàn dựng và sản xuất giống nhau nhất có thể:

Sự khác biệt giữa các dịch vụ hỗ trợ có nghĩa là các điểm không tương thích nhỏ xuất hiện, khiến mã hoạt động và vượt qua các bài kiểm tra trong quá trình phát triển hoặc dàn dựng bị lỗi trong quá trình sản xuất. Những loại lỗi này tạo ra xung đột làm mất tác dụng của việc triển khai liên tục.

Kết hợp một công cụ CI / CD mạnh mẽ với trình điều khiển . Bạn có thể sử dụng tính linh hoạt của các giá trị helm để đặt cấu hình mặc định, chỉ cần ghi đè các cấu hình khác nhau giữa một môi trường.

GitLab CI / CD với AutoDevops có tích hợp mạnh mẽ với Kubernetes, cho phép bạn quản lý nhiều cụm Kubernetes đã có hỗ trợ lãnh đạo.

Quản lý nhiều cụm ( kubectltương tác)

Khi bạn đang làm việc với nhiều cụm Kubernetes, bạn rất dễ kubectlnhầm lẫn với ngữ cảnh và chạy sai cụm. Ngoài ra, Kubernetes có các hạn chế đối với việc lập phiên bản không khớp giữa máy khách ( kubectl) và máy chủ (kubernetes chủ), vì vậy chạy lệnh trong ngữ cảnh phù hợp không có nghĩa là chạy đúng phiên bản máy khách.

Để khắc phục điều này:

• Sử dụng asdfđể quản lý nhiều kubectlphiên bản
• ĐặtKUBECONFIG env var để thay đổi giữa nhiều kubeconfigtệp
• Sử dụng kube-ps1để theo dõi ngữ cảnh / không gian tên hiện tại của bạn
• Sử dụng kubectxvàkubens thay đổi nhanh chóng giữa các cụm / không gian tên
• Sử dụng bí danh để kết hợp tất cả chúng lại với nhau

Tôi có một bài viết minh họa cách thực hiện điều này: Sử dụng các phiên bản kubectl khác nhau với nhiều cụm Kubernetes

Tôi cũng giới thiệu các bài đọc sau:

• Làm chủ tệp KUBECONFIG của Ahmet Alp Balkan ( Kỹ sư Google )
• Cách Zalando quản lý hơn 140 cụm Kubernetes của Henning Jacobs ( Zalando Tech )

Chắc chắn sử dụng một cụm riêng biệt để phát triển và tạo hình ảnh docker để các cụm dàn / sản xuất của bạn có thể được khóa bảo mật một cách khôn ngoan. Việc bạn sử dụng các cụm riêng biệt cho hay không staging + productionlà do bạn quyết định dựa trên rủi ro / chi phí - chắc chắn việc giữ chúng riêng biệt sẽ giúp tránh stagingảnh hưởng production.

Tôi cũng thực sự khuyên bạn nên sử dụng GitOps để quảng bá các phiên bản ứng dụng giữa các môi trường của bạn.

Để giảm thiểu lỗi của con người, tôi cũng khuyên bạn nên xem xét việc tự động hóa càng nhiều càng tốt cho CI / CD và quảng cáo của bạn.

Đây là bản trình diễn về cách tự động hóa CI / CD với nhiều môi trường trên Kubernetes bằng cách sử dụng GitOps để quảng cáo giữa các môi trường và Môi trường xem trước trên Yêu cầu kéo được thực hiện trực tiếp trên GKE mặc dù Jenkins X hỗ trợ hầu hết các cụm kubernetes

Nó phụ thuộc vào những gì bạn muốn kiểm tra trong mỗi tình huống. Nói chung, tôi sẽ cố gắng tránh chạy các kịch bản thử nghiệm trên cụm sản xuất để tránh các tác dụng phụ không cần thiết (tác động đến hiệu suất, v.v.).

Nếu ý định của bạn là thử nghiệm với một hệ thống dàn dựng bắt chước chính xác hệ thống sản xuất, tôi khuyên bạn nên kích hoạt một bản sao chính xác của cụm hoàn chỉnh và tắt nó sau khi bạn thử nghiệm xong và chuyển các triển khai sang sản xuất.

Nếu mục đích của bạn là kiểm tra một hệ thống dàn cho phép thử nghiệm ứng dụng để triển khai, tôi sẽ chạy một cụm dàn nhỏ hơn vĩnh viễn và cập nhật các triển khai (với cả phiên bản triển khai thu nhỏ) theo yêu cầu để kiểm tra liên tục.

Để kiểm soát các cụm khác nhau, tôi thích có một máy ci / cd riêng biệt không phải là một phần của cụm nhưng được sử dụng để kích hoạt và tắt các cụm cũng như thực hiện công việc triển khai, bắt đầu kiểm tra, v.v. Điều này cho phép thiết lập và tắt như một phần của các kịch bản thử nghiệm tự động.

Rõ ràng là bằng cách giữ cho cụm sản xuất tách khỏi cụm sản xuất, nguy cơ xảy ra các lỗi tiềm ẩn ảnh hưởng đến dịch vụ sản xuất được giảm thiểu. Tuy nhiên, điều này đi kèm với chi phí quản lý cơ sở hạ tầng / cấu hình nhiều hơn, vì nó yêu cầu ít nhất:

• ít nhất 3 master cho cụm sản xuất và ít nhất một master cho dàn
• 2 tệp cấu hình Kubectl sẽ được thêm vào hệ thống CI / CD

Cũng đừng quên rằng có thể có nhiều hơn một môi trường. Ví dụ: tôi đã làm việc tại các công ty có ít nhất 3 môi trường:

• QA: Đây là nơi chúng tôi đã triển khai hàng ngày và là nơi chúng tôi thực hiện QA nội bộ trước khi phát hành cho khách hàng)
• Khách hàng QA: Đây là nơi chúng tôi đã triển khai trước khi triển khai cho phiên bản sản xuất để khách hàng có thể xác thực môi trường trước khi phát hành sang phiên bản sản xuất)
• Sản xuất: Đây là nơi các dịch vụ sản xuất được triển khai.

Tôi nghĩ các cụm tạm thời / theo yêu cầu có ý nghĩa nhưng chỉ đối với một số trường hợp sử dụng nhất định (thử nghiệm tải / hiệu suất hoặc tích hợp / thử nghiệm end-to-end rất «lớn») nhưng đối với các môi trường liên tục / cố định hơn, tôi thấy chi phí có thể giảm bằng cách chạy chúng trong một cụm duy nhất.

Tôi đoán tôi muốn liên hệ với cộng đồng k8s để xem những mẫu nào được sử dụng cho những trường hợp như vậy giống như những trường hợp tôi đã mô tả.

Trừ khi tuân thủ hoặc các yêu cầu khác quy định khác, tôi ưu tiên một cụm duy nhất cho tất cả các môi trường. Với cách tiếp cận này, các điểm cần chú ý là:

• Đảm bảo rằng bạn cũng nhóm các nút cho mỗi môi trường bằng cách sử dụng nhãn. Sau đó, bạn có thể sử dụng các nodeSelectortài nguyên trên để đảm bảo rằng chúng đang chạy trên các nút cụ thể. Điều này sẽ làm giảm nguy cơ tiêu thụ tài nguyên (dư thừa) tràn giữa các môi trường.

• Coi không gian tên của bạn là mạng con và cấm tất cả lưu lượng truy cập ra / vào theo mặc định. Xem https://kubernetes.io/docs/concept/services-networking/network-policies/ .

• Có chiến lược quản lý tài khoản dịch vụ. ClusterRoleBindingsngụ ý điều gì đó khác nếu một cụm lưu trữ nhiều hơn một môi trường.

• Hãy xem xét kỹ lưỡng khi sử dụng các công cụ như Helm. Một số biểu đồ ngang nhiên cài đặt tài khoản dịch vụ với quyền trên toàn cụm, nhưng quyền đối với tài khoản dịch vụ phải được giới hạn trong môi trường mà chúng đang ở.

Sử dụng nhiều cụm là một tiêu chuẩn, ngay từ đầu để thực thi sự tách biệt mạnh mẽ giữa sản xuất và “phi sản xuất”.

Theo tinh thần đó, hãy lưu ý rằng GitLab 13.2 (tháng 7 năm 2020) hiện bao gồm:

Triển khai nhiều cụm Kubernetes trong Core

Việc sử dụng GitLab để triển khai nhiều cụm Kubernetes với GitLab trước đây yêu cầu giấy phép Premium.
Cộng đồng của chúng tôi đã phát biểu và chúng tôi đã lắng nghe: việc triển khai tới nhiều cụm rất hữu ích ngay cả đối với những người đóng góp riêng lẻ.
Dựa trên phản hồi của bạn, bắt đầu từ GitLab 13.2, bạn có thể triển khai cho nhiều nhóm dự án và nhóm trong Core.

Xem tài liệu và vấn đề /

Tôi nghĩ rằng việc chạy một cụm duy nhất có ý nghĩa vì nó giảm chi phí giám sát. Tuy nhiên, bạn phải đảm bảo đặt các chính sách mạng, kiểm soát truy cập đúng chỗ.

Chính sách mạng - cấm khối lượng công việc trong môi trường dev / qa tương tác với các cửa hàng sản xuất / dàn dựng.

Kiểm soát truy cập - những người có quyền truy cập vào các tài nguyên môi trường khác nhau bằng cách sử dụng ClusterRoles, Roles, v.v.