Giới thiệu ngắn gọn về Kustomize

Ghi chú. bản dịch.: Bài viết được viết bởi Scott Lowe, một kỹ sư có nhiều kinh nghiệm trong lĩnh vực CNTT, là tác giả/đồng tác giả của bảy cuốn sách in (chủ yếu về VMware vSphere). Hiện anh làm việc cho công ty con Heptio của VMware (được mua lại vào năm 2016), chuyên về điện toán đám mây và Kubernetes. Bản thân văn bản này đóng vai trò là phần giới thiệu ngắn gọn và dễ hiểu về quản lý cấu hình cho Kubernetes bằng công nghệ Tùy chỉnh, gần đây đã trở thành một phần của K8.

Kustomize là một công cụ cho phép người dùng “tùy chỉnh các tệp YAML đơn giản, không có mẫu cho các mục đích khác nhau, giữ nguyên YAML gốc và có thể sử dụng được” (mô tả được mượn trực tiếp từ tùy chỉnh kho lưu trữ trên GitHub). Kustomize có thể được chạy trực tiếp hoặc, kể từ Kubernetes 1.14, được sử dụng kubectl -k để truy cập chức năng của nó (mặc dù kể từ Kubernetes 1.15, tệp nhị phân riêng biệt mới hơn các khả năng được tích hợp trong kubectl). (Ghi chú. bản dịch.: Và với bản phát hành gần đây Kubernetes 1.16 tùy chỉnh được hỗ trợ bởi cũng có trong tiện ích kubeadm.) Trong bài đăng này, tôi muốn giới thiệu với độc giả những kiến ​​thức cơ bản về tùy chỉnh.

Ở dạng/ứng dụng đơn giản nhất, kustomize chỉ đơn giản là một tập hợp các tài nguyên (tệp YAML xác định đối tượng Kubernetes: Triển khai, Dịch vụ, v.v.) cùng với danh sách hướng dẫn về những thay đổi cần thực hiện đối với các tài nguyên đó. Cũng giống như make sử dụng tập lệnh có trong Makefilevà Docker xây dựng vùng chứa dựa trên hướng dẫn từ Dockerfile, tùy chỉnh sử dụng kustomization.yaml để lưu trữ hướng dẫn về những thay đổi mà người dùng muốn thực hiện đối với một tập hợp tài nguyên.

Đây là một tập tin ví dụ kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Tôi sẽ không cố gắng nói về tất cả các trường có thể có trong tệp. kustomization.yaml (điều này được viết rất hay về đây), nhưng tôi sẽ giải thích ngắn gọn về một ví dụ cụ thể:

• Lĩnh vực resources cho biết những gì (tài nguyên nào) tùy chỉnh sẽ thay đổi. Trong trường hợp này, nó sẽ tìm kiếm tài nguyên trong các tập tin deployment.yaml и service.yaml trong thư mục của bạn (bạn có thể chỉ định đường dẫn đầy đủ hoặc tương đối nếu cần).
• Lĩnh vực namePrefix hướng dẫn kustomize thêm một tiền tố nhất định (trong trường hợp này - dev-) để thuộc tính name tất cả các tài nguyên được xác định trong trường resources. Vì vậy, nếu triển khai có name với ý nghĩa nginx-deployment, tùy chỉnh sẽ làm được dev-nginx-deployment.
• Lĩnh vực namespace hướng dẫn kustomize thêm không gian tên đã cho vào tất cả các tài nguyên. Trong trường hợp này, Triển khai và Dịch vụ sẽ rơi vào không gian tên development.
• Cuối cùng là lĩnh vực commonLabels chứa một tập hợp các nhãn sẽ được thêm vào tất cả các tài nguyên. Trong ví dụ của chúng tôi, kustomize sẽ gán nhãn cho các tài nguyên có tên environment và ý nghĩa development.

Nếu người dùng làm kustomize build . trong thư mục chứa tập tin kustomization.yaml và các tài nguyên cần thiết (tức là các tập tin deployment.yaml и service.yaml), thì ở đầu ra nó sẽ nhận được một văn bản với những thay đổi được chỉ định trong kustomization.yaml.

Ghi chú. bản dịch.: Minh họa từ tài liệu dự án về cách sử dụng tùy chỉnh “đơn giản”

Đầu ra có thể được chuyển hướng nếu cần phải thực hiện các thay đổi:

kustomize build . > custom-config.yaml

Dữ liệu đầu ra mang tính xác định (cùng một dữ liệu đầu vào sẽ tạo ra cùng một kết quả đầu ra), do đó bạn không phải lưu kết quả vào một tệp. Thay vào đó, nó có thể được chuyển trực tiếp sang lệnh khác:

kustomize build . | kubectl apply -f -

Các tính năng tùy chỉnh cũng có thể được truy cập thông qua kubectl -k (kể từ phiên bản Kubernetes 1.14). Tuy nhiên, hãy nhớ rằng gói kustomize độc ​​lập được cập nhật nhanh hơn gói kubectl tích hợp (ít nhất là trường hợp này xảy ra với bản phát hành Kubernetes 1.15).

Người đọc có thể hỏi: “Tại sao lại phức tạp như vậy nếu bạn có thể chỉnh sửa trực tiếp các tệp?” Câu hỏi tuyệt vời. Trong ví dụ của chúng tôi, thực sự ai có thể sửa đổi tập tin deployment.yaml и service.yaml trực tiếp, nhưng nếu chúng là một nhánh của dự án của người khác thì sao? Việc thay đổi tệp trực tiếp gây khó khăn (nếu không nói là không thể) khởi động lại một nhánh khi các thay đổi được thực hiện đối với nguồn/nguồn. Việc sử dụng kustomize cho phép bạn tập trung những thay đổi này vào một tệp kustomization.yaml, giữ nguyên các tệp gốc và do đó giúp việc khởi động lại các tệp gốc dễ dàng hơn nếu cần thiết.

Lợi ích của tùy chỉnh trở nên rõ ràng trong các trường hợp sử dụng phức tạp hơn. Trong ví dụ trên kustomization.yaml và các tài nguyên nằm trong cùng một thư mục. Tuy nhiên, kustomize hỗ trợ các trường hợp sử dụng có cấu hình cơ bản và nhiều biến thể của cấu hình đó, còn được gọi là Overlays. Ví dụ: một người dùng muốn lấy Triển khai và Dịch vụ cho nginx, mà tôi đã sử dụng làm ví dụ và tạo các phiên bản phát triển, dàn dựng và sản xuất (hoặc các biến thể) của các tệp đó. Để làm được điều này, anh ta sẽ cần các lớp phủ nêu trên và trên thực tế, chính các tài nguyên cơ bản.

Để minh họa ý tưởng về lớp phủ và tài nguyên cơ bản (tài nguyên cơ sở), giả sử rằng các thư mục có cấu trúc sau:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Trong tập tin base/kustomization.yaml người dùng sử dụng trường resources chỉ cần khai báo các tài nguyên mà tùy chỉnh nên bao gồm.

Trong mỗi tập tin overlays/{dev,staging,prod}/kustomization.yaml người dùng tham khảo cấu hình cơ sở tại hiện trường resources, sau đó chỉ ra những thay đổi cụ thể cho môi trường nhất định. Ví dụ: tập tin overlays/dev/kustomization.yaml có thể trông giống như ví dụ được đưa ra trước đó:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Trong trường hợp này tập tin overlays/prod/kustomization.yaml có thể hoàn toàn khác:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Khi người dùng chạy kustomize build . trong danh mục overlays/dev, tùy chỉnh sẽ tạo ra tùy chọn phát triển. Nếu bạn chạy kustomize build . trong danh mục overlays/prod - bạn có được tùy chọn sản xuất. Và tất cả điều này - mà không thực hiện bất kỳ thay đổi nào đối với bản gốc (cơ sở) các tập tin, tất cả theo cách khai báo và xác định. Bạn có thể chuyển trực tiếp cấu hình cơ sở và các thư mục lớp phủ sang kiểm soát phiên bản, biết rằng dựa trên các tệp này, bạn có thể tạo lại cấu hình mong muốn bất kỳ lúc nào.

Ghi chú. bản dịch.: Minh họa từ tài liệu dự án về cách sử dụng lớp phủ trong tùy chỉnh

Tùy chỉnh có thể nhiều nhiều hơn những gì được đề cập trong bài viết này. Tuy nhiên, tôi hy vọng nó phục vụ như một lời giới thiệu tốt.

Tôi là người nước ngoài

Có rất nhiều bài báo và ấn phẩm hay về tùy chỉnh. Dưới đây là một số điều tôi thấy đặc biệt hữu ích:

• Thay đổi cấu hình YAML cơ sở cho các sản phẩm/kiểm tra môi trường khác nhau bằng Kustomize;
• Kustomize - Cách đúng đắn để tạo khuôn mẫu trong Kubernetes;
• Quản lý khai báo đối tượng Kubernetes bằng cách sử dụng Tùy chỉnh;
• Tùy chỉnh biểu đồ Helm ngược dòng với Tùy chỉnh.

Ghi chú. bản dịch.: Bạn cũng có thể đề xuất một khối liên kết được xuất bản dưới dạng Thông tin trên trang web của tiện ích, sau đó là tuyển tập các video có báo cáo mới nhất về tùy chỉnh.

Nếu bạn có câu hỏi hoặc gợi ý để cải thiện tài liệu này, tôi luôn sẵn sàng đón nhận phản hồi. Bạn có thể liên hệ với tôi tại Twitter hoặc Kênh Slack Kubernetes. Chúc bạn vui vẻ khi sửa đổi bảng kê khai của mình với tùy chỉnh!

Tái bút từ người dịch

Đọc thêm trên blog của chúng tôi:

• «Công cụ dành cho nhà phát triển ứng dụng chạy trên Kubernetes»;
• «Kubernetes 1.14: tổng quan về những cải tiến chính»;
• «Năm kết quả chính của Helm Summit 2019 tại Amsterdam»;
• «Giới thiệu thực tế về trình quản lý gói cho Kubernetes - Helm'.

Nguồn: www.habr.com