🥇Giới thiệu về Mũ 3

Ghi chú. bản dịch.: Ngày 16 tháng 3.0 năm nay đánh dấu một cột mốc quan trọng trong quá trình phát triển trình quản lý gói cho Kubernetes - Helm. Vào ngày này, bản phát hành alpha đầu tiên của phiên bản chính trong tương lai của dự án - XNUMX - đã được trình làng. Việc phát hành nó sẽ mang lại những thay đổi đáng kể và được chờ đợi từ lâu cho Helm, điều mà nhiều người trong cộng đồng Kubernetes đặt nhiều hy vọng vào đó. Bản thân chúng tôi là một trong số đó, vì chúng tôi tích cực sử dụng Helm để triển khai ứng dụng: chúng tôi đã tích hợp nó vào công cụ của mình để triển khai CI/CD người sói và thỉnh thoảng chúng tôi đóng góp vào sự phát triển của thượng nguồn. Bản dịch này kết hợp 7 ghi chú từ blog chính thức của Helm, dành riêng cho bản phát hành alpha đầu tiên của Helm 3 và nói về lịch sử của dự án cũng như các tính năng chính của Helm 3. Tác giả của chúng là Matt “bacongobbler” Fisher, một nhân viên của Microsoft và là một trong những người bảo trì chính của Helm.

Vào ngày 15 tháng 2015 năm 2, dự án hiện được gọi là Helm đã ra đời. Chỉ một năm sau khi thành lập, cộng đồng Helm đã gia nhập Kubernetes, đồng thời tích cực làm việc trên Helm 2018. Vào tháng XNUMX năm XNUMX, Helm đã gia nhập CNCF như một dự án đang phát triển (ươm tạo). Chuyển nhanh đến hiện tại và bản phát hành alpha đầu tiên của Helm 3 mới sắp ra mắt. (bản phát hành này đã diễn ra rồi vào giữa tháng XNUMX - khoảng. dịch.).

Trong phần này, tôi sẽ nói về nơi mọi chuyện bắt đầu, cách chúng tôi đạt được vị trí ngày hôm nay, giới thiệu một số tính năng độc đáo có trong bản phát hành alpha đầu tiên của Helm 3 và giải thích cách chúng tôi dự định phát triển.

Tóm tắt:

lịch sử hình thành Helm;
lời chia tay dịu dàng với Tiller;
kho biểu đồ;
quản lý phát hành;
thay đổi về sự phụ thuộc của biểu đồ;
biểu đồ thư viện;
cái gì tiếp theo?

Lịch sử của Helm

Sinh

Helm 1 khởi đầu là một dự án Nguồn mở do Deis tạo ra. Chúng tôi là một công ty khởi nghiệp nhỏ hấp thụ Microsoft vào mùa xuân năm 2017 Dự án Nguồn mở khác của chúng tôi, cũng có tên là Deis, có một công cụ deisctl, được sử dụng (trong số những thứ khác) để cài đặt và vận hành nền tảng Deis trong Cụm hạm đội. Vào thời điểm đó, Hạm đội là một trong những nền tảng điều phối container đầu tiên.

Vào giữa năm 2015, chúng tôi quyết định thay đổi hướng đi và chuyển Deis (lúc đó đã đổi tên thành Deis Workflow) từ Fleet sang Kubernetes. Một trong những thứ đầu tiên được thiết kế lại là công cụ cài đặt. deisctl. Chúng tôi đã sử dụng nó để cài đặt và quản lý Deis Workflow trong cụm Hạm đội.

Helm 1 được tạo ra theo hình ảnh của những nhà quản lý gói nổi tiếng như Homebrew, apt và yum. Mục tiêu chính của nó là đơn giản hóa các tác vụ như đóng gói và cài đặt ứng dụng trên Kubernetes. Helm được giới thiệu chính thức vào năm 2015 tại hội nghị KubeCon ở San Francisco.

Nỗ lực đầu tiên của chúng tôi với Helm đã thành công nhưng không phải không có một số hạn chế nghiêm trọng. Anh ấy lấy một tập hợp các bảng kê khai Kubernetes, có thêm các trình tạo làm khối YAML giới thiệu (vấn đề phía trước)* và tải kết quả vào Kubernetes.

* Ghi chú. bản dịch.: Từ phiên bản đầu tiên của Helm, cú pháp YAML đã được chọn để mô tả tài nguyên Kubernetes, đồng thời hỗ trợ các mẫu Jinja và tập lệnh Python khi viết cấu hình. Chúng tôi đã viết thêm về điều này và cấu trúc của phiên bản đầu tiên của Helm nói chung trong chương “Lịch sử tóm tắt về Helm” vật liệu này.

Ví dụ: để thay thế một trường trong tệp YAML, bạn phải thêm cấu trúc sau vào tệp kê khai:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Thật tuyệt vời khi có công cụ tạo mẫu ngày nay phải không?

Vì nhiều lý do, trình cài đặt Kubernetes đời đầu này yêu cầu một danh sách các tệp kê khai được mã hóa cứng và chỉ thực thi một chuỗi sự kiện nhỏ, cố định. Nó khó sử dụng đến mức nhóm R&D của Deis Workflow gặp khó khăn khi cố gắng chuyển sản phẩm của mình sang nền tảng này - tuy nhiên, hạt giống của ý tưởng đã được gieo. Nỗ lực đầu tiên của chúng tôi là một cơ hội học hỏi tuyệt vời: chúng tôi nhận ra rằng mình thực sự đam mê việc tạo ra các công cụ thực dụng để giải quyết các vấn đề hàng ngày cho người dùng.

Dựa trên kinh nghiệm từ những sai lầm trong quá khứ, chúng tôi bắt đầu phát triển Helm 2.

Làm mũ bảo hiểm 2

Vào cuối năm 2015, nhóm Google đã liên hệ với chúng tôi. Họ đang nghiên cứu một công cụ tương tự cho Kubernetes. Trình quản lý triển khai cho Kubernetes là một cổng của một công cụ hiện có được sử dụng cho Google Cloud Platform. Họ hỏi: “Chúng ta có muốn dành vài ngày để thảo luận về những điểm tương đồng và khác biệt không?”

Vào tháng 2016 năm 2, nhóm Giám đốc Chỉ đạo và Giám đốc Triển khai đã gặp nhau tại Seattle để trao đổi ý tưởng. Cuộc đàm phán kết thúc với một kế hoạch đầy tham vọng: kết hợp cả hai dự án để tạo ra Helm XNUMX. Cùng với Deis và Google, những người đến từ SkippBox (hiện là một phần của Bitnami - xấp xỉ bản dịch.)và chúng tôi bắt đầu làm việc trên Helm 2.

Chúng tôi muốn duy trì tính dễ sử dụng của Helm nhưng thêm vào những điều sau:

mẫu biểu đồ để tùy chỉnh;
quản lý nội bộ cụm cho các nhóm;
kho lưu trữ biểu đồ đẳng cấp thế giới;
định dạng gói ổn định với tùy chọn chữ ký;
cam kết mạnh mẽ về phiên bản ngữ nghĩa và duy trì khả năng tương thích ngược giữa các phiên bản.

Để đạt được những mục tiêu này, yếu tố thứ hai đã được thêm vào hệ sinh thái Helm. Thành phần nội bộ cụm này được gọi là Tiller và chịu trách nhiệm cài đặt và quản lý biểu đồ Helm.

Kể từ khi phát hành Helm 2 vào năm 2016, Kubernetes đã bổ sung một số cải tiến lớn. Đã thêm kiểm soát truy cập dựa trên vai trò (RBAC), cuối cùng đã thay thế Kiểm soát truy cập dựa trên thuộc tính (ABAC). Các loại tài nguyên mới đã được giới thiệu (Triển khai vẫn đang trong giai đoạn thử nghiệm vào thời điểm đó). Định nghĩa tài nguyên tùy chỉnh (ban đầu được gọi là Tài nguyên của bên thứ ba hoặc TPR) đã được phát minh. Và quan trọng nhất, một tập hợp các phương pháp hay nhất đã xuất hiện.

Giữa tất cả những thay đổi này, Helm vẫn tiếp tục phục vụ người dùng Kubernetes một cách trung thực. Sau ba năm và nhiều bổ sung mới, rõ ràng đã đến lúc phải thực hiện những thay đổi đáng kể đối với cơ sở mã để đảm bảo Helm có thể tiếp tục đáp ứng nhu cầu ngày càng tăng của một hệ sinh thái đang phát triển.

Lời chia tay dịu dàng với Tiller

Trong quá trình phát triển Helm 2, chúng tôi đã giới thiệu Tiller như một phần trong quá trình tích hợp với Trình quản lý triển khai của Google. Tiller đóng một vai trò quan trọng đối với các nhóm làm việc trong một cụm chung: nó cho phép các chuyên gia khác nhau vận hành cơ sở hạ tầng tương tác với cùng một bộ bản phát hành.

Do kiểm soát truy cập dựa trên vai trò (RBAC) được bật theo mặc định trong Kubernetes 1.6 nên việc làm việc với Tiller trong sản xuất trở nên khó khăn hơn. Do có rất nhiều chính sách bảo mật khả thi, quan điểm của chúng tôi là cung cấp cấu hình cho phép theo mặc định. Điều này cho phép người mới thử nghiệm Helm và Kubernetes mà không cần phải đi sâu vào cài đặt bảo mật trước. Thật không may, cấu hình quyền này có thể cung cấp cho người dùng phạm vi quyền quá rộng mà họ không cần. Các kỹ sư DevOps và SRE phải tìm hiểu các bước vận hành bổ sung khi cài đặt Tiller trong cụm nhiều người thuê.

Sau khi tìm hiểu cách cộng đồng sử dụng Helm trong các tình huống cụ thể, chúng tôi nhận ra rằng hệ thống quản lý phát hành của Tiller không cần phải dựa vào thành phần nội bộ cụm để duy trì trạng thái hoặc chức năng như một trung tâm trung tâm cung cấp thông tin phát hành. Thay vào đó, chúng ta có thể chỉ cần nhận thông tin từ máy chủ API Kubernetes, tạo biểu đồ ở phía máy khách và lưu trữ bản ghi cài đặt trong Kubernetes.

Mục tiêu chính của Tiller có thể đạt được nếu không có Tiller, vì vậy một trong những quyết định đầu tiên của chúng tôi về Helm 3 là từ bỏ hoàn toàn Tiller.

Khi Tiller ra đi, mô hình bảo mật của Helm đã được đơn giản hóa hoàn toàn. Helm 3 hiện hỗ trợ tất cả các phương thức bảo mật, nhận dạng và ủy quyền hiện đại của Kubernetes hiện tại. Quyền của Helm được xác định bằng cách sử dụng tập tin kubeconfig. Quản trị viên cụm có thể hạn chế quyền của người dùng ở bất kỳ mức độ chi tiết nào. Các bản phát hành vẫn được lưu trong cụm và phần còn lại của chức năng của Helm vẫn còn nguyên.

Kho biểu đồ

Ở cấp độ cao, kho lưu trữ biểu đồ là nơi có thể lưu trữ và chia sẻ biểu đồ. Máy khách Helm đóng gói và gửi biểu đồ đến kho lưu trữ. Nói một cách đơn giản, kho lưu trữ biểu đồ là một máy chủ HTTP nguyên thủy có tệp index.yaml và một số biểu đồ được đóng gói.

Mặc dù API Kho lưu trữ biểu đồ có một số ưu điểm đáp ứng hầu hết các yêu cầu lưu trữ cơ bản nhưng cũng có một số nhược điểm:

Kho lưu trữ biểu đồ không tương thích với hầu hết các triển khai bảo mật cần thiết trong môi trường sản xuất. Việc có API tiêu chuẩn để xác thực và ủy quyền là cực kỳ quan trọng trong các tình huống sản xuất.
Các công cụ xuất xứ biểu đồ của Helm, được sử dụng để ký, xác minh tính toàn vẹn và nguồn gốc của biểu đồ, là một phần tùy chọn của quy trình xuất bản Biểu đồ.
Trong trường hợp nhiều người dùng, người dùng khác có thể tải lên cùng một biểu đồ, tăng gấp đôi dung lượng cần thiết để lưu trữ cùng một nội dung. Các kho lưu trữ thông minh hơn đã được phát triển để giải quyết vấn đề này, nhưng chúng không phải là một phần của đặc tả chính thức.
Việc sử dụng một tệp chỉ mục duy nhất để tìm kiếm, lưu trữ siêu dữ liệu và truy xuất biểu đồ đã gây khó khăn cho việc phát triển triển khai an toàn cho nhiều người dùng.

Dự án Phân phối Docker (còn được gọi là Docker Đăng ký v2) là sự kế thừa của Docker Đăng ký và về cơ bản hoạt động như một bộ công cụ để đóng gói, vận chuyển, lưu trữ và phân phối hình ảnh Docker. Nhiều dịch vụ đám mây lớn cung cấp các sản phẩm dựa trên phân phối. Nhờ sự chú ý ngày càng tăng này, dự án Phân phối đã được hưởng lợi từ nhiều năm cải tiến, các biện pháp thực hành bảo mật tốt nhất và thử nghiệm thực địa đã khiến nó trở thành một trong những anh hùng thầm lặng thành công nhất của thế giới Nguồn mở.

Nhưng bạn có biết rằng Dự án phân phối được thiết kế để phân phối bất kỳ dạng nội dung nào, không chỉ hình ảnh vùng chứa?

Nhờ những nỗ lực Sáng kiến vùng chứa mở (hoặc OCI), biểu đồ Helm có thể được đặt trên bất kỳ phiên bản Phân phối nào. Hiện tại, quá trình này là thử nghiệm. Hỗ trợ đăng nhập và các tính năng khác cần thiết cho Helm 3 đầy đủ đang được tiến hành nhưng chúng tôi rất vui được học hỏi từ những khám phá mà nhóm OCI và Phân phối đã thực hiện trong nhiều năm qua. Và thông qua sự cố vấn và hướng dẫn của họ, chúng tôi tìm hiểu được việc vận hành một dịch vụ có tính sẵn sàng cao trên quy mô lớn là như thế nào.

Đã có mô tả chi tiết hơn về một số thay đổi sắp tới đối với kho biểu đồ Helm по ссылке.

Quản lý phát hành

Trong Helm 3, trạng thái ứng dụng được theo dõi trong cụm bởi một cặp đối tượng:

đối tượng phát hành - đại diện cho một phiên bản ứng dụng;
bí mật phiên bản phát hành - thể hiện trạng thái mong muốn của ứng dụng tại một thời điểm cụ thể (ví dụ: phát hành phiên bản mới).

Gọi helm install tạo một đối tượng phát hành và bí mật phiên bản phát hành. Gọi helm upgrade yêu cầu một đối tượng phát hành (có thể thay đổi) và tạo một bí mật phiên bản phát hành mới chứa các giá trị mới và một bảng kê khai đã chuẩn bị sẵn.

Đối tượng phát hành chứa thông tin về bản phát hành, trong đó bản phát hành là bản cài đặt cụ thể của biểu đồ và giá trị được đặt tên. Đối tượng này mô tả siêu dữ liệu cấp cao nhất về bản phát hành. Đối tượng phát hành tồn tại trong suốt vòng đời của ứng dụng và là chủ sở hữu của tất cả các bí mật của phiên bản phát hành cũng như tất cả các đối tượng được biểu đồ Helm trực tiếp tạo ra.

Bí mật phiên bản phát hành liên kết một bản phát hành với một loạt các bản sửa đổi (cài đặt, cập nhật, khôi phục, xóa).

Trong Helm 2, các bản sửa đổi cực kỳ nhất quán. Gọi helm install đã tạo v1, bản cập nhật tiếp theo (nâng cấp) - v2, v.v. Bí mật phát hành và phiên bản phát hành đã được thu gọn thành một đối tượng duy nhất được gọi là bản sửa đổi. Các bản sửa đổi được lưu trữ trong cùng một không gian tên với Tiller, điều đó có nghĩa là mỗi bản phát hành đều mang tính "toàn cầu" về mặt không gian tên; kết quả là chỉ có thể sử dụng một phiên bản của tên.

Trong Helm 3, mỗi bản phát hành được liên kết với một hoặc nhiều bí mật của phiên bản phát hành. Đối tượng phát hành luôn mô tả bản phát hành hiện tại được triển khai cho Kubernetes. Mỗi bí mật phiên bản phát hành chỉ mô tả một phiên bản của bản phát hành đó. Ví dụ: một bản nâng cấp sẽ tạo bí mật phiên bản phát hành mới và sau đó thay đổi đối tượng phát hành để trỏ đến phiên bản mới đó. Trong trường hợp khôi phục, bạn có thể sử dụng bí mật của phiên bản phát hành trước đó để khôi phục bản phát hành về trạng thái trước đó.

Sau khi Tiller bị bỏ rơi, Helm 3 lưu trữ dữ liệu phát hành trong cùng không gian tên với bản phát hành. Thay đổi này cho phép bạn cài đặt biểu đồ có cùng tên phát hành trong một không gian tên khác và dữ liệu được lưu giữa các lần cập nhật/khởi động lại cụm trong etcd. Ví dụ: bạn có thể cài đặt WordPress trong không gian tên "foo" và sau đó trong không gian tên "bar" và cả hai bản phát hành đều có thể được đặt tên là "wordpress".

Thay đổi đối với phần phụ thuộc của biểu đồ

Biểu đồ được đóng gói (sử dụng helm package) để sử dụng với Helm 2 có thể được cài đặt với Helm 3, tuy nhiên quy trình phát triển biểu đồ đã được đại tu hoàn toàn nên phải thực hiện một số thay đổi để tiếp tục phát triển biểu đồ với Helm 3. Đặc biệt, hệ thống quản lý phụ thuộc biểu đồ đã thay đổi.

Hệ thống quản lý phụ thuộc của biểu đồ đã chuyển từ requirements.yaml и requirements.lock trên Chart.yaml и Chart.lock. Điều này có nghĩa là các biểu đồ sử dụng lệnh helm dependency, yêu cầu một số thiết lập để hoạt động trong Helm 3.

Hãy xem một ví dụ. Hãy thêm phần phụ thuộc vào biểu đồ trong Helm 2 và xem những gì thay đổi khi chuyển sang Helm 3.

Trong Helm 2 requirements.yaml trông như thế này:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Trong Helm 3, sự phụ thuộc tương tự sẽ được phản ánh trong Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Biểu đồ vẫn được tải xuống và đặt trong thư mục charts/, vậy biểu đồ con (biểu đồ con), nằm trong danh mục charts/, sẽ tiếp tục hoạt động mà không có thay đổi.

Giới thiệu biểu đồ thư viện

Helm 3 hỗ trợ một lớp biểu đồ được gọi là biểu đồ thư viện (sơ đồ thư viện). Biểu đồ này được các biểu đồ khác sử dụng nhưng không tự tạo ra bất kỳ thành phần phát hành nào. Mẫu biểu đồ thư viện chỉ có thể khai báo các phần tử define. Nội dung khác chỉ đơn giản là bị bỏ qua. Điều này cho phép người dùng sử dụng lại và chia sẻ các đoạn mã có thể sử dụng trên nhiều biểu đồ, từ đó tránh trùng lặp và tuân thủ nguyên tắc KHÔ.

Biểu đồ thư viện được khai báo trong phần dependencies trong tập tin Chart.yaml. Việc cài đặt và quản lý chúng cũng không khác gì những biểu đồ khác.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Chúng tôi rất vui mừng về các trường hợp sử dụng mà thành phần này sẽ mở ra cho các nhà phát triển biểu đồ cũng như các phương pháp hay nhất có thể xuất hiện từ biểu đồ thư viện.

Cái gì tiếp theo?

Helm 3.0.0-alpha.1 là nền tảng để chúng tôi bắt đầu xây dựng phiên bản Helm mới. Trong bài viết, tôi đã mô tả một số tính năng thú vị của Helm 3. Nhiều tính năng trong số đó vẫn đang trong giai đoạn phát triển ban đầu và điều này là bình thường; Mục đích của bản phát hành alpha là kiểm tra ý tưởng, thu thập phản hồi từ những người dùng đầu tiên và xác nhận các giả định của chúng tôi.

Ngay khi phiên bản alpha được phát hành (hãy nhớ rằng đây là vừa mới xảy ra - khoảng. dịch.), chúng tôi sẽ bắt đầu chấp nhận các bản vá cho Helm 3 từ cộng đồng. Bạn cần tạo một nền tảng vững chắc cho phép phát triển và áp dụng chức năng mới, đồng thời để người dùng cảm thấy được tham gia vào quá trình này bằng cách mở yêu cầu và thực hiện các bản sửa lỗi.

Tôi đã cố gắng nêu bật một số cải tiến chính sắp có trong Helm 3, nhưng danh sách này không có nghĩa là đầy đủ. Lộ trình đầy đủ cho Helm 3 bao gồm các tính năng như chiến lược cập nhật được cải thiện, tích hợp sâu hơn với các cơ quan đăng ký OCI và sử dụng lược đồ JSON để xác thực các giá trị biểu đồ. Chúng tôi cũng có kế hoạch dọn dẹp cơ sở mã và cập nhật các phần đã bị bỏ quên trong ba năm qua.

Nếu bạn cảm thấy chúng tôi đã bỏ lỡ điều gì đó, chúng tôi rất muốn nghe suy nghĩ của bạn!

Tham gia thảo luận trên của chúng tôi Kênh chùng:

#helm-users để giải đáp thắc mắc và giao tiếp đơn giản với cộng đồng;
#helm-dev để thảo luận về các yêu cầu kéo, mã và lỗi.

Bạn cũng có thể trò chuyện trong Cuộc gọi dành cho nhà phát triển công khai hàng tuần của chúng tôi vào Thứ Năm lúc 19:30 MSK. Các cuộc họp được dành riêng để thảo luận các vấn đề mà các nhà phát triển chính và cộng đồng đang giải quyết, cũng như các chủ đề thảo luận trong tuần. Bất cứ ai cũng có thể tham gia và tham gia cuộc họp. Liên kết có sẵn trong kênh Slack #helm-dev.

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

Giới thiệu Helm 3