🥇Gộp 3 chiều vào werf: triển khai vào Kubernetes với Helm “trên steroid”

Điều mà chúng tôi (và không chỉ chúng tôi) chờ đợi bấy lâu nay đã xảy ra: người sói, tiện ích Nguồn mở của chúng tôi để xây dựng ứng dụng và phân phối chúng tới Kubernetes, hiện hỗ trợ áp dụng các thay đổi bằng cách sử dụng các bản vá hợp nhất 3 chiều! Ngoài ra, có thể áp dụng các tài nguyên K8 hiện có vào các bản phát hành Helm mà không cần xây dựng lại các tài nguyên này.

Nếu nó rất ngắn thì chúng ta đặt WERF_THREE_WAY_MERGE=enabled — chúng tôi nhận được triển khai “như trong kubectl apply", tương thích với các bản cài đặt Helm 2 hiện có và thậm chí nhiều hơn một chút.

Nhưng hãy bắt đầu với lý thuyết: chính xác thì bản vá hợp nhất 3 chiều là gì, mọi người nghĩ ra cách tiếp cận để tạo ra chúng như thế nào và tại sao chúng lại quan trọng trong quy trình CI/CD với cơ sở hạ tầng dựa trên Kubernetes? Và sau đó, hãy cùng xem tính năng hợp nhất 3 chiều trong werf là gì, mặc định sử dụng những chế độ nào và cách quản lý.

Bản vá hợp nhất 3 chiều là gì?

Vì vậy, hãy bắt đầu với nhiệm vụ triển khai các tài nguyên được mô tả trong tệp kê khai YAML vào Kubernetes.

Để làm việc với các tài nguyên, API Kubernetes cung cấp các thao tác cơ bản sau: tạo, vá, thay thế và xóa. Người ta cho rằng với sự trợ giúp của họ, cần phải xây dựng một quá trình triển khai tài nguyên liên tục thuận tiện cho cụm. Làm sao?

lệnh bắt buộc kubectl

Cách tiếp cận đầu tiên để quản lý các đối tượng trong Kubernetes là sử dụng các lệnh mệnh lệnh kubectl để tạo, sửa đổi và xóa các đối tượng đó. Chỉ cần đặt:

đội kubectl run bạn có thể chạy Triển khai hoặc Công việc:
```
kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
```
đội kubectl scale - thay đổi số lượng bản sao:
```
kubectl scale --replicas=3 deployment/mysql
```
vv

Cách tiếp cận này thoạt nhìn có vẻ thuận tiện. Tuy nhiên có vấn đề:

Nó khó tự động hóa.
làm sao phản ánh cấu hình trong Git? Làm cách nào để xem lại những thay đổi xảy ra với cụm?
Làm thế nào để cung cấp Khả năng tái lập cấu hình khi khởi động lại?
...

Rõ ràng là cách tiếp cận này không phù hợp với việc lưu trữ ứng dụng và cơ sở hạ tầng dưới dạng mã (IaC; hoặc thậm chí GitOps như một lựa chọn hiện đại hơn, ngày càng phổ biến trong hệ sinh thái Kubernetes). Do đó, các lệnh này không được phát triển thêm trong kubectl.

Các thao tác tạo, nhận, thay thế và xóa

Với chính sự sáng tạo thật đơn giản: gửi bảng kê khai tới hoạt động create kube api và tài nguyên đã được tạo. Biểu diễn YAML của tệp kê khai có thể được lưu trữ trong Git và được tạo bằng lệnh kubectl create -f manifest.yaml.

С gỡ bỏ cũng đơn giản: thay thế tương tự manifest.yaml từ Git đến nhóm kubectl delete -f manifest.yaml.

Hoạt động replace cho phép bạn thay thế hoàn toàn cấu hình tài nguyên bằng cấu hình mới mà không cần tạo lại tài nguyên. Điều này có nghĩa là trước khi thực hiện thay đổi đối với tài nguyên, việc truy vấn phiên bản hiện tại bằng thao tác là điều hợp lý get, thay đổi và cập nhật nó bằng thao tác replace. apiserver kube được tích hợp sẵn khóa lạc quan và nếu sau phẫu thuật get đối tượng đã thay đổi thì thao tác replace nó sẽ không hoạt động.

Để lưu trữ cấu hình trong Git và cập nhật nó bằng cách thay thế, bạn cần thực hiện thao tác get, hợp nhất cấu hình từ Git với những gì chúng tôi nhận được và thực thi replace. Mặc định kubectl chỉ cho phép bạn sử dụng lệnh kubectl replace -f manifest.yamlĐâu manifest.yaml - một bảng kê khai đã được chuẩn bị đầy đủ (trong trường hợp của chúng tôi là đã hợp nhất) cần được cài đặt. Hóa ra người dùng cần triển khai các bảng kê khai hợp nhất và đây không phải là vấn đề tầm thường...

Cũng cần lưu ý rằng mặc dù manifest.yaml và được lưu trữ trong Git, chúng ta không thể biết trước liệu có cần tạo một đối tượng hay cập nhật nó hay không - việc này phải được thực hiện bởi phần mềm người dùng.

Tổng số: chúng ta có thể triển khai liên tục không chỉ sử dụng tạo, thay thế và xóa, đảm bảo rằng cấu hình cơ sở hạ tầng được lưu trữ trong Git cùng với mã và CI/CD tiện lợi?

Về nguyên tắc, chúng ta có thể... Vì điều này bạn sẽ cần phải thực hiện thao tác hợp nhất bản tuyên ngôn và một số loại ràng buộc rằng:

kiểm tra sự hiện diện của một đối tượng trong cụm,
thực hiện việc tạo tài nguyên ban đầu,
cập nhật hoặc xóa nó.

Khi cập nhật xin lưu ý rằng tài nguyên có thể đã thay đổi kể từ lần cuối get và tự động xử lý trường hợp khóa lạc quan - thực hiện các lần cập nhật lặp lại.

Tuy nhiên, tại sao phải phát minh lại bánh xe khi kube-apiserver cung cấp một cách khác để cập nhật tài nguyên: hoạt động patch, điều này giúp người dùng giảm bớt một số vấn đề được mô tả?

Vá

Bây giờ chúng ta đến các bản vá.

Các bản vá là cách chính để áp dụng các thay đổi cho các đối tượng hiện có trong Kubernetes. Hoạt động patch nó hoạt động như thế này:

người dùng kube-apiserver cần gửi bản vá ở dạng JSON và chỉ định đối tượng,
và chính apiserver sẽ xử lý trạng thái hiện tại của đối tượng và đưa nó về dạng được yêu cầu.

Khóa lạc quan là không cần thiết trong trường hợp này. Thao tác này mang tính khai báo nhiều hơn là thay thế, mặc dù lúc đầu nó có vẻ ngược lại.

Như vậy:

sử dụng một thao tác create chúng tôi tạo một đối tượng theo bảng kê khai từ Git,
thông qua delete - xóa nếu đối tượng không còn cần thiết nữa,
thông qua patch — chúng ta thay đổi đối tượng, đưa nó về dạng được mô tả trong Git.

Tuy nhiên, để làm được điều này, bạn cần tạo bản vá chính xác!

Cách hoạt động của các bản vá trong Helm 2: hợp nhất 2 chiều

Khi bạn cài đặt một bản phát hành lần đầu tiên, Helm sẽ thực hiện thao tác create cho các tài nguyên biểu đồ.

Khi cập nhật bản phát hành Helm cho từng tài nguyên:

xem xét bản vá giữa phiên bản tài nguyên từ biểu đồ trước và phiên bản biểu đồ hiện tại,
áp dụng bản vá này.

Chúng tôi sẽ gọi bản vá này Bản vá hợp nhất 2 chiều, bởi vì có 2 bản tuyên ngôn liên quan đến việc tạo ra nó:

bảng kê khai tài nguyên từ bản phát hành trước,
bản kê khai tài nguyên từ tài nguyên hiện tại.

Khi loại bỏ hoạt động delete trong kube apiserver được gọi cho các tài nguyên đã được khai báo trong bản phát hành trước nhưng không được khai báo trong bản phát hành hiện tại.

Cách tiếp cận bản vá hợp nhất 2 chiều có một vấn đề: nó dẫn đến không đồng bộ với trạng thái thực của tài nguyên trong cụm và bảng kê khai trong Git.

Minh họa vấn đề bằng một ví dụ

Trong Git, biểu đồ lưu trữ một bảng kê khai trong đó trường image Vấn đề triển khai ubuntu:18.04.
Người dùng thông qua kubectl edit đã thay đổi giá trị của trường này thành ubuntu:19.04.
Khi triển khai lại biểu đồ Helm không tạo ra một bản vá, bởi vì trường image trong phiên bản trước của bản phát hành và trong biểu đồ hiện tại đều giống nhau.
Sau khi triển khai lại image còn lại ubuntu:19.04, mặc dù biểu đồ cho biết ubuntu:18.04.

Chúng tôi đã không đồng bộ hóa và mất khả năng khai báo.

Tài nguyên được đồng bộ hóa là gì?

Nói chung, đầy đủ Không thể có được sự trùng khớp giữa bảng kê khai tài nguyên trong cụm đang chạy và bảng kê khai từ Git. Bởi vì trong một bảng kê khai thực tế có thể có các chú thích/nhãn dịch vụ, các vùng chứa bổ sung và dữ liệu khác được một số bộ điều khiển thêm vào và xóa khỏi tài nguyên một cách linh hoạt. Chúng tôi không thể và không muốn giữ dữ liệu này trong Git. Tuy nhiên, chúng tôi muốn các trường mà chúng tôi đã chỉ định rõ ràng trong Git sẽ nhận các giá trị phù hợp khi triển khai.

Hoá ra chung chung thế quy tắc tài nguyên được đồng bộ hóa: khi triển khai tài nguyên, bạn chỉ có thể thay đổi hoặc xóa những trường được chỉ định rõ ràng trong tệp kê khai từ Git (hoặc đã được chỉ định trong phiên bản trước và hiện đã bị xóa).

Bản vá hợp nhất 3 chiều

ý tưởng trung tâm Bản vá hợp nhất 3 chiều: chúng tôi tạo một bản vá giữa phiên bản được áp dụng cuối cùng của tệp kê khai từ Git và phiên bản đích của tệp kê khai từ Git, có tính đến phiên bản hiện tại của tệp kê khai từ cụm đang chạy. Bản vá kết quả phải tuân thủ quy tắc tài nguyên được đồng bộ hóa:

các trường mới được thêm vào phiên bản đích được thêm vào bằng bản vá;
các trường hiện có trước đó trong phiên bản được áp dụng gần đây nhất và không tồn tại trong phiên bản đích được đặt lại bằng bản vá;
các trường trong phiên bản hiện tại của đối tượng khác với phiên bản đích của tệp kê khai sẽ được cập nhật bằng bản vá.

Theo nguyên tắc này, nó tạo ra các bản vá kubectl apply:

phiên bản áp dụng cuối cùng của tệp kê khai được lưu trữ trong chú thích của chính đối tượng đó,
mục tiêu - được lấy từ tệp YAML được chỉ định,
cái hiện tại là từ một cụm đang chạy.

Bây giờ chúng ta đã sắp xếp xong lý thuyết, đã đến lúc kể cho bạn nghe những gì chúng ta đã làm trong werf.

Áp dụng các thay đổi cho werf

Trước đây, werf, giống như Helm 2, đã sử dụng các bản vá hợp nhất 2 chiều.

Sửa chữa vá

Để chuyển sang một loại bản vá mới - hợp nhất 3 chiều - bước đầu tiên chúng tôi đã giới thiệu cái gọi là sửa chữa các bản vá lỗi.

Khi triển khai, bản vá hợp nhất 2 chiều tiêu chuẩn sẽ được sử dụng, nhưng werf còn tạo thêm một bản vá có thể đồng bộ hóa trạng thái thực của tài nguyên với những gì được viết trong Git (bản vá như vậy được tạo bằng cách sử dụng cùng một quy tắc tài nguyên được đồng bộ hóa được mô tả ở trên) .

Nếu xảy ra quá trình giải đồng bộ hóa, khi kết thúc quá trình triển khai, người dùng sẽ nhận được CẢNH BÁO kèm theo thông báo tương ứng và bản vá phải được áp dụng để đưa tài nguyên về dạng được đồng bộ hóa. Bản vá này cũng được ghi lại trong một chú thích đặc biệt werf.io/repair-patch. Người ta cho rằng bàn tay của người dùng mình sẽ áp dụng bản vá này: werf sẽ không áp dụng nó.

Tạo các bản vá sửa chữa là một biện pháp tạm thời cho phép bạn thực sự kiểm tra việc tạo các bản vá dựa trên nguyên tắc hợp nhất 3 chiều, nhưng không tự động áp dụng các bản vá này. Hiện tại, chế độ vận hành này được bật theo mặc định.

Bản vá hợp nhất 3 chiều chỉ dành cho các bản phát hành mới

Bắt đầu từ ngày 1 tháng 2019 năm XNUMX, phiên bản beta và alpha của werf bắt đầu theo mặc định sử dụng các bản vá hợp nhất 3 chiều đầy đủ để chỉ áp dụng các thay đổi cho các bản phát hành Helm mới được triển khai thông qua werf. Các bản phát hành hiện tại sẽ tiếp tục sử dụng phương pháp vá lỗi hợp nhất 2 chiều + sửa chữa.

Chế độ vận hành này có thể được kích hoạt rõ ràng bằng cách cài đặt WERF_THREE_WAY_MERGE_MODE=onlyNewReleases bây giờ.

Ghi: tính năng này đã xuất hiện trong werf qua một số bản phát hành: trong kênh alpha, tính năng này đã sẵn sàng với phiên bản v1.0.5-alpha.19và trong kênh beta - với v1.0.4-beta.20.

Bản vá hợp nhất 3 chiều cho tất cả các bản phát hành

Bắt đầu từ ngày 15 tháng 2019 năm 3, phiên bản beta và alpha của werf bắt đầu sử dụng các bản vá hợp nhất XNUMX chiều đầy đủ theo mặc định để áp dụng các thay đổi cho tất cả các bản phát hành.

Chế độ vận hành này có thể được kích hoạt rõ ràng bằng cách cài đặt WERF_THREE_WAY_MERGE_MODE=enabled bây giờ.

Phải làm gì với việc tự động chia tỷ lệ tài nguyên?

Có 2 loại tự động tính toán trong Kubernetes: HPA (ngang) và VPA (dọc).

Ngang tự động chọn số lượng bản sao, dọc - số lượng tài nguyên. Cả số lượng bản sao và yêu cầu tài nguyên đều được chỉ định trong bản kê khai tài nguyên (xem Bản kê khai tài nguyên). spec.replicas hoặc spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и những người khác).

Sự cố: nếu người dùng định cấu hình tài nguyên trong biểu đồ để nó chỉ định các giá trị nhất định cho tài nguyên hoặc bản sao và bộ chia tỷ lệ tự động được bật cho tài nguyên này thì với mỗi lần triển khai, werf sẽ đặt lại các giá trị này thành giá trị được ghi trong bảng kê khai biểu đồ .

Có hai giải pháp cho vấn đề. Để bắt đầu, tốt nhất là tránh chỉ định rõ ràng các giá trị được tự động chia tỷ lệ trong bảng kê khai biểu đồ. Nếu tùy chọn này không phù hợp vì một số lý do (ví dụ: vì thuận tiện khi đặt giới hạn tài nguyên ban đầu và số lượng bản sao trong biểu đồ), thì werf sẽ cung cấp các chú thích sau:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

Nếu có chú thích như vậy, werf sẽ không đặt lại các giá trị tương ứng trên mỗi lần triển khai mà sẽ chỉ đặt chúng khi tài nguyên được tạo ban đầu.

Để biết thêm chi tiết, hãy xem tài liệu dự án để biết HPA и VPA.

Cấm sử dụng bản vá hợp nhất 3 chiều

Người dùng hiện có thể cấm sử dụng các bản vá mới trong werf bằng cách sử dụng biến môi trường WERF_THREE_WAY_MERGE_MODE=disabled. Tuy nhiên, bắt đầu Từ ngày 1/2020/XNUMX, lệnh cấm này sẽ không còn được áp dụng. và sẽ chỉ có thể sử dụng các bản vá hợp nhất 3 chiều.

Thông qua các tài nguyên trong werf

Nắm vững phương pháp áp dụng các thay đổi với các bản vá hợp nhất 3 chiều cho phép chúng tôi triển khai ngay một tính năng như áp dụng các tài nguyên hiện có trong cụm vào bản phát hành Helm.

Helm 2 có một vấn đề: bạn không thể thêm tài nguyên vào các bảng kê khai biểu đồ đã tồn tại trong cụm mà không tạo lại tài nguyên này từ đầu (xem phần XNUMX). #6031, #3275). Chúng tôi đã dạy werf cách chấp nhận các tài nguyên hiện có để phát hành. Để thực hiện việc này, bạn cần cài đặt chú thích trên phiên bản hiện tại của tài nguyên từ cụm đang chạy (ví dụ: sử dụng kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

Bây giờ, tài nguyên cần được mô tả trong biểu đồ và lần tiếp theo khi werf triển khai bản phát hành có tên thích hợp, tài nguyên hiện có sẽ được chấp nhận vào bản phát hành này và vẫn nằm trong tầm kiểm soát của nó. Hơn nữa, trong quá trình chấp nhận tài nguyên để phát hành, werf sẽ đưa trạng thái hiện tại của tài nguyên từ cụm đang chạy sang trạng thái được mô tả trong biểu đồ, sử dụng cùng các bản vá hợp nhất 3 chiều và quy tắc tài nguyên được đồng bộ hóa.

Ghi: cài đặt WERF_THREE_WAY_MERGE_MODE không ảnh hưởng đến việc áp dụng tài nguyên - trong trường hợp áp dụng, bản vá hợp nhất 3 chiều luôn được sử dụng.

Chi tiết - trong tài liệu.

Kết luận và kế hoạch tương lai

Tôi hy vọng rằng sau bài viết này, mọi người sẽ hiểu rõ hơn bản vá hợp nhất 3 chiều là gì và tại sao chúng lại đến với chúng. Từ quan điểm thực tế về sự phát triển của dự án werf, việc triển khai chúng là một bước nữa nhằm cải thiện việc triển khai giống như Helm. Giờ đây, bạn có thể quên đi các vấn đề về đồng bộ hóa cấu hình thường phát sinh khi sử dụng Helm 2. Đồng thời, một tính năng hữu ích mới là sử dụng tài nguyên Kubernetes đã tải xuống đã được thêm vào bản phát hành Helm.

Vẫn còn một số vấn đề và thách thức khi triển khai giống Helm, chẳng hạn như việc sử dụng mẫu Go, mà chúng tôi sẽ tiếp tục giải quyết.

Thông tin về các phương pháp cập nhật tài nguyên và áp dụng cũng có thể được tìm thấy tại trang tài liệu này.

Mũ bảo hiểm 3

Đáng lưu ý đặc biệt phát hành mới hôm nọ, một phiên bản chính mới của Helm - v3 - cũng sử dụng các bản vá hợp nhất 3 chiều và loại bỏ Tiller. Phiên bản mới của Helm yêu cầu sự di cư cài đặt hiện có để chuyển đổi chúng sang định dạng lưu trữ phát hành mới.

Về phần mình, Werf hiện đã loại bỏ việc sử dụng Tiller, chuyển sang hợp nhất 3 chiều và thêm nhiều hơn nữa, trong khi vẫn tương thích với các bản cài đặt Helm 2 hiện có (không cần thực thi tập lệnh di chuyển). Vì vậy, cho đến khi werf chuyển sang Helm 3, người dùng werf vẫn không mất đi những ưu điểm chính của Helm 3 so với Helm 2 (werf cũng có chúng).

Tuy nhiên, việc chuyển werf sang codebase Helm 3 là điều không thể tránh khỏi và sẽ xảy ra trong thời gian tới. Có lẽ đây sẽ là werf 1.1 hoặc werf 1.2 (hiện tại, phiên bản chính của werf là 1.0; để biết thêm thông tin về thiết bị tạo phiên bản werf, hãy xem đây). Trong thời gian này, Helm 3 sẽ có thời gian ổn định.