Helm cho FDE: đóng gói bản triển khai thành chart, cài cho nhiều khách mà không cần sửa template

Thử hình dung tuần sau bạn phải cài cùng một dịch vụ vào cụm Kubernetes của hai khách: một ngân hàng cần ba replica và hostname nội bộ, một công ty logistics chỉ cần một replica. Nếu bàn giao bằng một thư mục YAML rời rồi sửa tay cho từng nơi, đến khách thứ ba bạn sẽ không còn nhớ chỗ nào đã sửa.

Trang chủ Helm tự giới thiệu dự án là trình quản lý gói cho Kubernetes. Tình huống hai khách ở trên chính là loại việc mà một trình quản lý gói sinh ra để làm.

Với một FDE, Helm hữu ích ở chỗ nó thay bước “sửa YAML cho khách” bằng một gói có phiên bản. Khách có thể đọc gói đó, bạn cài lại được, và khi có sự cố thì quay về bản trước.

Chart chứa gì?

Theo tài liệu của Helm, chart là tập hợp các file mô tả một nhóm tài nguyên Kubernetes có liên quan. Ở mức tối thiểu, chart có ba phần: Chart.yaml mô tả gói, thư mục templates/ chứa manifest có chỗ trống để điền giá trị, và values.yaml chứa cấu hình mặc định.

Có hai chi tiết nên làm đúng ngay từ đầu. Chart dành cho Helm 3 trở lên phải khai báo apiVersion: v2 trong Chart.yaml. Nếu sản phẩm cần thêm một database hay ingress controller, bạn khai báo chúng trong trường dependencies của cùng file đó, thay vì bắt khách tự cài từng thứ.

Để thấy giá trị chảy vào manifest thế nào, xem một đoạn trích từ template Deployment:

# templates/deployment.yaml (trích)
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: "myrepo/app:{{ .Values.image.tag }}"

Nếu values.yaml đặt replicaCount: 1 và image.tag: "1.4.0", manifest sinh ra sẽ có replicas: 1 và image myrepo/app:1.4.0. Với ngân hàng, file values riêng chỉ cần ghi replicaCount: 3; template giữ nguyên, chỉ con số được điền vào thay đổi.

Hãy coi values.yaml là nơi đặt mặc định an toàn cho mọi khách. Mọi thứ khác nhau giữa các khách (số replica, image tag, hostname, kích thước ổ đĩa) đều phải là một khóa trong file này. Như vậy khách thứ mười không bắt bạn sửa template.

Giá trị nào thắng khi ba nơi cùng đặt một tham số?

Khi cài, bạn truyền cấu hình riêng cho khách bằng một hoặc nhiều file qua cờ -f, hoặc từng giá trị qua --set. Tài liệu Helm ghi rõ: khi dùng cả hai, giá trị của --set được gộp vào phần --values với độ ưu tiên cao hơn.

Tính thử với ví dụ ngân hàng. values.yaml đặt replicaCount: 1, file values-nganhang.yaml đặt replicaCount: 3, còn trong lúc xử lý sự cố ai đó gõ thêm --set replicaCount=5. Cụm sẽ chạy 5 replica, và con số 5 không nằm trong file nào bạn lưu trong Git.

Vì thế nên giữ --set cho việc thử nhanh. Cấu hình của khách cần nằm trong file values có version control, để lần cài sau ra đúng kết quả như lần trước.

Trước khi động vào cụm của khách, hãy chạy helm template. Lệnh này render template ngay trên máy bạn và in manifest ra, nên bạn đọc được chính xác Helm sắp tạo những gì:

helm template ./my-chart -f values-nganhang.yaml
helm install my-app ./my-chart -f values-nganhang.yaml

Khi khách có đội platform muốn duyệt thay đổi, gửi họ bản manifest đã render sẽ dễ được chấp nhận hơn là gửi một thư mục template.

Release và revision: lý do Helm đáng học

Mỗi lần cài một chart, Helm tạo ra một release. helm upgrade thao tác trên release đã có, còn helm rollback [RELEASE] [REVISION] đưa nó về một revision trước đó. Theo tài liệu, mỗi lần install, upgrade hoặc rollback, số revision tăng thêm 1.

Đếm thử một tuần ở ngân hàng: cài lần đầu là revision 1, nâng image tag là revision 2, đổi hostname là revision 3. Bản thứ ba lỗi, bạn rollback về revision 2. Kết quả là revision 4 mang nội dung của revision 2, chứ số revision không lùi về 2.

Vì số chỉ tăng, bản lỗi vẫn còn trong lịch sử dưới số 3, ngay trước bản khôi phục mang số 4. Khi khách hỏi “hôm qua các anh đã đổi gì”, bạn có số revision cụ thể để chỉ ra.

Giao chart cho khách sao cho họ tin được?

Helm khuyến nghị dùng container registry hỗ trợ OCI để lưu trữ và chia sẻ chart. Nếu khách đã có sẵn registry cho image, chart có thể đi cùng đường đó mà không cần dựng thêm hạ tầng.

Bạn cũng có thể ký chart lúc đóng gói để phía khách kiểm chứng khi nhận. Tài liệu của Helm nói thẳng: nếu kiểm chứng thất bại thì có lý do để không tin gói đó. Nếu khách có đội bảo mật, hãy chuẩn bị sẵn hướng dẫn để họ tự kiểm chứng chữ ký trước khi cài.

Helm không làm thay những gì?

Helm chỉ cài đúng những gì chart mô tả. Nếu template sai hoặc values của khách sai, Helm vẫn cài cái sai đó một cách nhất quán. helm template giúp bạn nhìn thấy lỗi, nhưng người đọc kết quả vẫn là bạn.

Các chart khai báo trong dependencies cũng là mã của người khác chạy trong cụm của khách. Bạn cần biết chúng tạo ra tài nguyên gì trước khi đưa vào gói.

Còn phiên bản thì sao? Helm là dự án đã tốt nghiệp CNCF: vào vườn ươm năm 2018, lên mức Graduated ngày 1/5/2020. Tháng 11/2025, Helm 4.0.0 ra mắt tại KubeCon, là phiên bản major đầu tiên sau 6 năm.

Chart apiVersion: v2 đòi hỏi ít nhất Helm 3, và giờ đã có Helm 4. Hãy hỏi đội platform của khách xem họ đang chạy bản nào ngay trong buổi họp kỹ thuật đầu tiên, đừng đợi đến ngày cài.

Học theo thứ tự nào?

Bắt đầu bằng cấu trúc chart và values.yaml, rồi đến thứ tự ưu tiên giữa -f và --set, sau đó là vòng install, upgrade, rollback trên một cụm thử. Đóng gói, ký và đẩy lên registry OCI là bước cuối, nhưng đừng bỏ qua.

Nếu JD của một vị trí FDE nhắc tới Kubernetes, hãy chuẩn bị cho các câu hỏi về Helm. Trong CV, đừng chỉ ghi “biết Helm”. Hãy viết rằng bạn đã đóng gói một dịch vụ thành chart, cài cho nhiều môi trường bằng các file values riêng và từng rollback trong production, tức là kể ra cả chuỗi việc thay vì chỉ nêu tên công cụ.

Một chart tốt khiến lần cài cho khách thứ năm nhàm chán y như lần cài cho khách thứ hai.