Helm trong 11 ngày

Ngày 1: Giới thiệu Helm và Kubernetes

• Giới thiệu về Kubernetes: Cấu trúc, thành phần, lợi ích và các khái niệm quan trọng (Pods, Services, Deployments, StatefulSets).

• Giới thiệu về Helm: Tại sao cần Helm? Helm là gì? Các thành phần của Helm (Charts, Repos, Releases).

• Cài đặt Helm: Hướng dẫn chi tiết cách cài đặt Helm trên các môi trường khác nhau (macOS, Windows, Linux).

• Khám phá Helm Chart: Cấu trúc thư mục của Helm Chart, các file quan trọng (Chart.yaml, values.yaml, templates).

• Tìm hiểu về Repos: Các Helm Repos phổ biến (ArtifactHub, Bitnami), cách thêm và quản lý Repos.

• Thực hành: Tạo và cài đặt Helm Chart đơn giản đầu tiên.

Bài tập thực hành:

1. Tạo một Helm Chart đơn giản để triển khai một Pod NGINX.

2. Tìm và cài đặt một Helm Chart từ ArtifactHub hoặc Bitnami (ví dụ: MySQL, WordPress).

3. Tạo một Helm Repo cục bộ và một Helm OCI repo cục bộ (dùng registry zot hoặc docker run registry:2 chạy local), thêm chart vào cả hai để thấy sự khác biệt.

• Đào sâu: Helm 3 không còn cần Tiller (server-side component của Helm 2) - mọi thứ chạy client-side, release state được lưu dưới dạng Secret (mặc định) trong namespace của release, mỗi lần install/upgrade tạo 1 Secret mới đánh version (sh.helm.release.v1.<name>.v<N>). Đây là lý do helm rollback hoạt động được: nó chỉ là "diff lại" với bản Secret cũ.

• Production 2026: Với Bitnami - lưu ý catalog Bitnami đã thay đổi cách phân phối free chart trong 2025, một số chart/image chuyển sang mô hình khác; luôn kiểm tra chart còn được publish ở nguồn bạn dùng trước khi build pipeline phụ thuộc vào nó, tránh CI đột nhiên fail vì repo biến mất.

Ngày 2: Làm việc với Helm Charts và Repos

• Tìm hiểu chuyên sâu về values.yaml: Các kiểu dữ liệu, cấu trúc phân cấp, cách ghi đè giá trị.

• Cài đặt Helm Chart từ Repos: Tìm kiếm và cài đặt Helm Chart từ các Repos công cộng.

• Quản lý vòng đời Helm Chart: Nâng cấp, rollback, gỡ bỏ Helm Chart.

• Tìm hiểu về Helm Hooks: Sử dụng Helm Hooks để thực hiện các tác vụ trước và sau khi cài đặt, nâng cấp, gỡ bỏ.

Bài tập thực hành:

1. Tùy chỉnh Helm Chart NGINX đã tạo ở ngày 1 bằng cách thay đổi các giá trị trong values.yaml (ví dụ: số lượng replicas, image tag).

2. Nâng cấp Helm Chart NGINX lên phiên bản mới hơn.

3. Sử dụng Helm Hook để tạo một ConfigMap trước khi cài đặt Helm Chart NGINX.

• Đào sâu: Thứ tự ghi đè giá trị thực tế (từ thấp lên cao ưu tiên): values.yaml mặc định trong chart → values.yaml của parent chart cho subchart → file -f/--values theo thứ tự truyền vào → --set/--set-string/--set-json. Hiểu đúng thứ tự này tránh bug kinh điển "tại sao --set của tôi không có tác dụng" (do file -f truyền sau đè lên).

• Hook execution order thực tế: hook có helm.sh/hook-weight để sắp thứ tự trong cùng loại hook (pre-install, post-install...); hook resource không nằm trong Helm release state như resource thường - chúng bị xoá theo helm.sh/hook-delete-policy (mặc định giữ lại), dễ gây rác nếu không set rõ.

• Production 2026: Luôn set helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded cho Job hook (migration DB, seed data) để tránh tồn đọng hàng trăm Job cũ sau nhiều lần upgrade - một lỗi vận hành rất phổ biến.

Ngày 3: Helm Templates và Templating Nâng cao

• Giới thiệu về Helm Templating: Tại sao cần templating? Các công cụ templating của Helm (Go template).

• Thực hành cơ bản với Helm template: Tạo các template đơn giản để sinh ra Kubernetes manifests.

• Các hàm và toán tử trong Helm template: quote, toYaml, toJson, default, ternary, v.v.

• Helm template nâng cao:

  • Sử dụng range để lặp qua các giá trị.

  • Sử dụng with để thay đổi phạm vi.

  • Sử dụng define và template (hoặc include - xem ghi chú) để tạo các template con.

Bài tập thực hành:

1. Tạo một Helm template để sinh ra một Deployment với số lượng replicas được lấy từ values.yaml.

2. Tạo một Helm template để sinh ra một Service với các port được lấy từ values.yaml.

3. Tạo một Helm template phức tạp để sinh ra một Ingress với các rules được lấy từ values.yaml.

• Đào sâu (sửa 1 điểm dễ nhầm): Nên dùng include thay vì template trong hầu hết trường hợp - template là action gốc của Go template, in kết quả trực tiếp và không thể pipe qua hàm khác (vd indent, nindent); include là hàm do Helm bổ sung, trả về string nên pipe được: {{ include "mychart.labels" . | nindent 4 }}. Đây là pattern chuẩn cho mọi named template dùng chung labels/selectors.

• Hiểu $ trong template: bên trong range hoặc with, . đổi phạm vi (scope) - dùng $ để truy cập lại root context ($.Values.global...) khi đang ở trong vòng lặp.

• Production 2026: Luôn chạy helm template . --debug và helm lint trong CI trước khi merge - bắt lỗi cú pháp/logic template sớm thay vì phát hiện lúc helm upgrade giữa production.

Ngày 4: Quản lý phụ thuộc và cấu trúc Helm Chart phức tạp

• Quản lý phụ thuộc Helm Chart:

  • Khai báo và quản lý các phụ thuộc trong Chart.yaml (bao gồm cả dependency trỏ tới OCI registry, không chỉ HTTP repo).

  • Truyền giá trị giữa các Helm Chart.

  • Quản lý các phiên bản phụ thuộc.

• Cấu trúc Helm Chart phức tạp:

  • Chia nhỏ Helm Chart thành nhiều subchart.

  • Tạo các thư viện template dùng chung (Library Chart - type: library trong Chart.yaml).

  • Sử dụng các conditional template để tùy chỉnh Helm Chart cho các môi trường khác nhau.

Bài tập thực hành:

1. Tạo một Helm Chart để triển khai WordPress, sử dụng MySQL làm cơ sở dữ liệu (MySQL sẽ là một subchart).

2. Tạo một Library Chart (type: library) để định nghĩa cấu trúc dùng chung của Deployment/labels, và import vào chart WordPress ở bài 1.

3. Sử dụng conditional template (condition, tags trong Chart.yaml) để tùy chỉnh Helm Chart WordPress cho môi trường production và development.

• Đào sâu: Phân biệt rõ subchart thường (có thể helm install độc lập, tạo resource riêng) và library chart (type: library - không tạo resource nào cả, chỉ export named template để chart khác include). Đây là công cụ đúng để chia sẻ chuẩn labels/annotations giữa hàng chục chart trong 1 tổ chức mà không phát sinh release thừa.

• Dependency trong Chart.yaml giờ hỗ trợ repository: "oci://..." trực tiếp - không cần helm repo add trước khi helm dependency update nữa nếu registry là OCI.

• Production 2026: Tổ chức có nhiều team nên có 1 "platform library chart" version hoá riêng (semver), publish lên OCI registry nội bộ, các chart ứng dụng khai báo dependency tới nó - giống mô hình npm package cho hạ tầng Helm, giảm trùng lặp boilerplate.

Ngày 5: Xây dựng Helm Chart tùy chỉnh

• Quy trình xây dựng Helm Chart:

  • Thiết kế cấu trúc Helm Chart.

  • Viết các template Kubernetes manifests.

  • Kiểm thử và gỡ lỗi Helm Chart.

• Các công cụ hỗ trợ xây dựng Helm Chart:

  • helm lint: Kiểm tra chất lượng Helm Chart.

  • helm template: Xem trước Kubernetes manifests được sinh ra từ Helm Chart.

  • helm install --dry-run --debug: Xem manifest sau khi đã được server tham gia render (khác helm template ở chỗ có gọi tới cluster để lấy Capabilities/API version thật).

• Thực hành: Xây dựng Helm Chart tùy chỉnh cho một ứng dụng cụ thể (ví dụ: NGINX, WordPress, MySQL).

• Tích hợp Helm Chart với CI/CD pipeline.

Bài tập thực hành:

1. Xây dựng Helm Chart cho một ứng dụng web đơn giản (ví dụ: ứng dụng Node.js hoặc Python).

2. Viết các unit test cho Helm Chart của bạn (xem công cụ ở Ngày 8).

3. Tích hợp Helm Chart của bạn vào một CI/CD pipeline (ví dụ: GitHub Actions, GitLab CI).

• Đào sâu: helm template render hoàn toàn offline, không cần cluster, dùng giá trị Capabilities mặc định giả định - nên nó không phát hiện được lỗi phụ thuộc API version thật của cluster đích (vd CRD chưa cài). helm install --dry-run thì có kết nối cluster nên chính xác hơn nhưng chậm hơn - biết khi nào dùng cái nào là kỹ năng debug quan trọng.

• Production 2026: Pipeline CI/CD chuẩn hiện nay: helm lint → helm template (kiểm tra offline nhanh) → kubeconform/kube-score (validate schema K8s thật + best-practice) → ct install trên cluster kind/k3d tạm (xem Ngày 8) → package + push OCI + sign bằng cosign (xem Ngày 11) - tất cả trước khi merge, không chỉ lint suông.

Ngày 6: Helm Plugin

• Giới thiệu về Helm Plugin: Khái niệm, lợi ích, cách thức hoạt động.

• Các Helm Plugin phổ biến:

  • helm diff: So sánh sự khác biệt giữa các phiên bản Helm Chart trước khi upgrade thật (rất hay dùng trong CI để review "sẽ đổi gì").

  • helm secrets: Quản lý bí mật trong Helm Chart (dựa trên SOPS) - hiện có xu hướng thay bằng External Secrets Operator hoặc Sealed Secrets để tách hẳn secret khỏi Git, xem thêm Ngày 10.

  • helm push - đã lỗi thời như một plugin riêng. Từ Helm 3.8.0, helm push là lệnh built-in để đẩy chart lên OCI registry (helm push mychart-1.0.0.tgz oci://registry.example.com/charts), không cần cài plugin nữa.

• Xây dựng Helm Plugin tùy chỉnh:

  • Cấu trúc của một Helm Plugin (plugin.yaml + binary/script).

  • Cách viết code cho Helm Plugin bằng Go (dùng Helm SDK) hoặc đơn giản là shell script.

  • Cách đóng gói và phân phối Helm Plugin.

Bài tập thực hành:

1. Cài helm diff và dùng nó để xem trước thay đổi trước khi helm upgrade chart NGINX ở Ngày 1-2.

2. Package chart và đẩy lên 1 OCI registry local bằng lệnh helm push built-in (không cài plugin).

3. Viết 1 Helm plugin đơn giản dạng shell script (vd: plugin liệt kê tất cả release kèm chart version đang chạy trên toàn cluster).

• Đào sâu: Plugin Helm chạy hoàn toàn client-side, không có sandbox - plugin có toàn quyền như binary bất kỳ trên máy bạn (đọc kubeconfig, gọi API cluster). Đây là điều cần cân nhắc về bảo mật chuỗi cung ứng khi cài plugin từ nguồn không tin cậy.

• Production 2026: helm diff upgrade là bước bắt buộc trong quy trình review trước khi merge PR thay đổi Helm values cho production - biến "tôi nghĩ thay đổi này chỉ đổi image tag" thành bằng chứng cụ thể trong PR comment.

Ngày 7: Quản lý Helm Release theo kiểu GitOps (đã thay thế "Helm Operator")

Sửa quan trọng: Nội dung gốc "Helm Operator" nói về fluxcd/helm-operator - dự án này đã deprecated, README chính thức ghi rõ successor là helm-controller. Ngày này được viết lại để dạy đúng công cụ đang dùng thật ở production hiện nay.

• Giới thiệu về quản lý Helm Release theo GitOps: tại sao "áp helm upgrade thủ công từ laptop" không phù hợp production.

• Hai lựa chọn chính hiện nay:

  • Flux v2 - helm-controller: một controller trong GitOps Toolkit, dùng CRD HelmRelease (API group helm.toolkit.fluxcd.io, bản mới nhất) trỏ tới HelmRepository/OCIRepository làm nguồn chart.

  • Argo CD - Helm source type: Argo CD Application trỏ trực tiếp tới Helm chart (Git, HTTP repo, hoặc OCI) và tự helm template + apply, không cần Helm CLI cài trong cluster.

• Cài đặt và cấu hình helm-controller (Flux):

  • Bootstrap Flux vào cluster.

  • Tạo HelmRepository hoặc OCIRepository trỏ tới nguồn chart.

  • Tạo HelmRelease để triển khai chart, với spec.chart.spec và spec.values.

• Sử dụng helm-controller:

  • Quản lý vòng đời Helm Chart bằng HelmRelease (reconcile tự động khi Git thay đổi).

  • Tích hợp với các công cụ khác (Prometheus, Grafana) để giám sát trạng thái reconcile.

Bài tập thực hành:

1. Bootstrap Flux v2 vào 1 cluster kind/k3d, tạo HelmRepository trỏ tới 1 chart repo công khai.

2. Tạo HelmRelease để triển khai chart NGINX bạn xây từ Ngày 1, quan sát Flux tự động cài đặt.

3. Sửa values trong HelmRelease qua Git commit, quan sát Flux tự động reconcile (upgrade) mà không cần chạy helm upgrade thủ công.

4. (Nâng cao) Làm lại bài 2-3 bằng Argo CD Application thay vì Flux, so sánh trải nghiệm.

• Đào sâu: helm-controller không gọi helm CLI - nó dùng trực tiếp Helm SDK (Go library) bên trong chính controller để render và apply, nghĩa là hành vi bám sát Helm thật (không phải "một cách bắt chước Helm"). Từ Flux 2.8, phần dùng Helm bên trong đã cập nhật lên nhánh Helm v4, hỗ trợ server-side apply.

• Khác biệt hành vi quan trọng: HelmRelease (v2) mặc định merge cả values.yaml gốc của chart theo thứ tự bạn khai báo trong valuesFiles, khác với Helm Operator (v1 cũ) - nếu bạn từng đọc tài liệu Helm Operator cũ, hành vi merge giá trị đã đổi khi chuyển sang helm-controller.

• Production 2026: Một pattern rất phổ biến hiện nay: ArgoCD cho production plane trung tâm + Flux cho các cluster edge/remote, cùng trỏ vào 1 Git repo, phân biệt bằng label cluster - không cần chọn tuyệt đối 1 trong 2. Dù chọn công cụ nào, tuyệt đối không để bất kỳ ai chạy helm upgrade --install thủ công trực tiếp vào production nữa - mọi thay đổi phải qua Git.

Ngày 8: Helm Chart Testing

• Giới thiệu về Helm Chart Testing: Tại sao cần kiểm thử Helm Chart? Các loại kiểm thử Helm Chart (lint-level, render-level, install-level).

• Công cụ kiểm thử Helm Chart:

  • helm unittest (plugin helm-unittest): viết unit test dạng YAML, assert trực tiếp trên output render của template - không cần cluster thật, chạy rất nhanh trong CI.

  • ct (chart-testing): công cụ chuẩn của cộng đồng Helm (dùng cả trong CI chính thức của helm/charts cũ và Artifact Hub) - chạy ct lint và ct install (cài thật lên cluster kind tạm) để phát hiện lỗi mà lint tĩnh không thấy được.

  • kubeconform: validate output render đúng schema Kubernetes API (bắt lỗi field sai/thiếu mà helm lint không kiểm tra).

  • Terratest: dùng khi hạ tầng chart đi kèm với provisioning bằng Terraform, ít dùng riêng cho Helm thuần.

• Thực hành: Viết và thực thi các bài kiểm tra cho Helm Chart.

Bài tập thực hành:

1. Cài helm-unittest và viết 3 test case cho chart ở Ngày 5 (vd: đúng số replicas khi values thay đổi, đúng image tag, container port đúng).

2. Cài ct và chạy ct lint --charts ./mychart, sau đó ct install trên cluster kind tạm để xác nhận chart thực sự cài được thành công.

3. Chạy helm template . | kubeconform -strict để bắt lỗi schema Kubernetes.

• Đào sâu: helm-unittest test output tĩnh (bạn assert đúng YAML sinh ra) - nhanh nhưng không phát hiện được lỗi runtime (vd Service không match được Pod do label sai giữa 2 template khác nhau). ct install test hành vi thật trên cluster - chậm hơn nhưng bắt được lớp lỗi hoàn toàn khác. Một bộ test chart trưởng thành cần cả 2 lớp, không thay thế nhau được.

• Production 2026: ct là công cụ mà Artifact Hub và phần lớn official Helm chart repo dùng để CI-gate PR - nếu bạn maintain chart công khai hoặc chart nội bộ dùng chung nhiều team, đây gần như là lựa chọn mặc định thay vì tự viết pipeline test riêng.

Ngày 9: Helm Chart Best Practices

• Thiết kế cấu trúc Helm Chart:

  • Chia nhỏ Helm Chart thành nhiều subchart khi thực sự cần (không lạm dụng - mỗi subchart thêm là thêm 1 lớp phức tạp khi debug).

  • Sử dụng Library Chart cho phần dùng chung (xem Ngày 4) thay vì copy-paste template giữa các chart.

  • Sử dụng các conditional template để tùy chỉnh Helm Chart cho các môi trường khác nhau.

• Viết template Helm Chart:

  • Sử dụng các hàm và toán tử Helm template hiệu quả (include thay template, xem Ngày 3).

  • Tránh các lỗi thường gặp: thiếu nindent, quên default cho giá trị optional gây nil pointer khi render, hard-code namespace thay vì dùng .Release.Namespace.

  • Tối ưu hóa template Helm Chart để tăng hiệu suất (hạn chế logic phức tạp trong template - nếu chart cần quá nhiều if/else lồng nhau, có thể dấu hiệu cần tách chart).

• Quản lý phụ thuộc Helm Chart:

  • Sử dụng các phiên bản phụ thuộc cụ thể (pin version, tránh dùng range mở quá rộng như >=1.0.0).

  • Kiểm tra tính tương thích giữa các phụ thuộc.

  • Cập nhật phụ thuộc thường xuyên, có kiểm soát (qua PR + ct install, không auto-merge mù).

Bài tập thực hành:

1. Refactor chart ở Ngày 5 để dùng include/Library Chart thay vì lặp lại đoạn labels ở nhiều nơi.

2. Rà soát chart tìm ít nhất 2 lỗi "best practice" phổ biến kể trên và sửa.

3. Pin version chính xác cho tất cả dependency trong Chart.yaml, thử helm dependency update và xác nhận không có version trôi ngoài ý muốn.

• Production 2026: Dùng helm show values <chart> và helm show readme <chart> khi review chart bên thứ 3 trước khi đưa vào production - đọc kỹ giá trị mặc định (đặc biệt resources, securityContext, replicaCount) vì rất nhiều chart cộng đồng để mặc định không phù hợp production (không giới hạn resource, chạy root...).

Ngày 10: Helm Chart Security

• Các vấn đề bảo mật Helm Chart:

  • Lỗ hổng trong template Helm Chart (vd giá trị người dùng truyền vào không được escape đúng, gây injection vào manifest).

  • Lỗ hổng trong các phụ thuộc Helm Chart (image CVE, chart phụ thuộc cấu hình không an toàn mặc định).

  • Quản lý bí mật không an toàn (secret nằm thẳng trong values.yaml commit lên Git).

• Các công cụ và kỹ thuật bảo mật Helm Chart:

  • Trivy: quét cả image trong chart lẫn cấu hình Kubernetes manifest sinh ra từ chart (misconfiguration scanning), hiện là công cụ phổ biến nhất trong nhóm này.

  • Checkov / Kubescape / Polaris: quét policy/best-practice trên manifest render ra từ chart (privileged container, thiếu resource limit, thiếu readOnlyRootFilesystem...).

  • Chữ ký & toàn vẹn chart (chuẩn 2026):

    • Helm provenance file (.prov) - ký bằng GPG, kiểm tra bằng helm verify hoặc helm install --verify. Đây là cơ chế ký "kiểu cũ" nhưng vẫn hỗ trợ.

    • Cosign/Sigstore - ký chart đã push lên OCI registry giống hệt cách ký container image (cosign sign, cosign verify), hỗ trợ cả ký bằng key lẫn keyless signing qua OIDC (GitHub Actions identity...). Đây là hướng khuyến nghị cho workflow OCI hiện đại, và Flux/Argo CD đều có thể enforce verify Cosign trước khi reconcile.

  • Quản lý secret: External Secrets Operator hoặc SOPS + helm secrets plugin để không bao giờ commit secret plaintext vào Git, thay vì chỉ dựa vào Kubernetes Secret (vốn chỉ base64, không mã hoá).

• Thực hành: Áp dụng các biện pháp bảo mật cho Helm Chart.

Bài tập thực hành:

1. Chạy Trivy quét cấu hình (trivy config .) trên thư mục chart và trên output helm template để so sánh 2 loại kết quả.

2. Push chart lên 1 OCI registry local, ký bằng cosign sign (dùng key pair tự tạo), sau đó cosign verify để xác nhận.

3. Thiết lập SOPS + helm secrets để mã hoá 1 giá trị nhạy cảm (vd DB password) trong values.yaml, xác nhận không có plaintext nào trong Git.

• Đào sâu: Provenance file (.prov) và Cosign giải quyết 2 lớp khác nhau: .prov ký nội dung file .tgz (toàn vẹn gói chart), còn Cosign ký digest của OCI artifact trong registry (toàn vẹn bản đã publish, gắn liền với Rekor transparency log để audit công khai ai đã ký khi nào). Production nghiêm ngặt nên dùng cả hai lớp thay vì chọn một.

• Production 2026: Xu hướng hiện nay là enforce verify tại tầng GitOps controller (Flux OCIRepository.spec.verify.provider: cosign hoặc Argo CD tương đương) - nghĩa là cluster từ chối reconcile nếu chart không có chữ ký hợp lệ khớp danh tính CI/CD định trước, biến việc ký chart từ "nên làm" thành "không ký thì không deploy được".

Ngày 11: OCI-native Helm & GitOps end-to-end

• Sáng - OCI-native workflow:

  • So sánh mô hình cũ (index.yaml HTTP repo) và mô hình mới (OCI registry) - hiểu vì sao OCI thắng: dùng chung hạ tầng registry với container image (auth, quota, replication, quét bảo mật đều tái dùng được), và các nhà cung cấp lớn (ACR...) đang loại bỏ dần endpoint repo kiểu cũ.

  • Thực hành đầy đủ chu trình: helm package → helm push oci://... → helm pull oci://... → helm install trực tiếp từ OCI reference.

• Chiều - Ghép pipeline hoàn chỉnh:

  • CI: lint (helm lint, kubeconform) → test (ct install trên kind) → quét bảo mật (Trivy config) → package → push OCI → sign (Cosign, keyless qua OIDC của CI) → tạo provenance.

  • CD: HelmRelease/Argo CD Application trỏ tới OCIRepository có bật verify.provider: cosign - mọi thay đổi values đi qua Git PR, review bằng helm diff, merge xong tự reconcile.

Bài tập thực hành:

1. Dựng toàn bộ pipeline trên bằng GitHub Actions (hoặc GitLab CI) cho chart bạn đã xây dựng suốt 10 ngày trước - từ commit tới chart chạy trên cluster kind, có ký và verify.

2. Thử cố tình push 1 chart không ký lên cùng registry, xác nhận Flux/Argo CD từ chối reconcile nó (nếu bật verify).

3. Viết 1 tài liệu runbook ngắn: "Làm sao để thêm 1 chart mới vào hệ thống GitOps này, từ code tới production" - đây chính là artifact giá trị nhất bạn mang được vào công việc thực tế.

• Production 2026: Toàn bộ chuỗi này (OCI + Cosign keyless + Flux/Argo CD verify) là mô hình supply-chain security cho Helm được khuyến nghị rộng rãi hiện nay - nắm được nó là điểm khác biệt rõ nhất giữa "biết dùng Helm" và "biết vận hành Helm an toàn ở production".

Tài liệu tham khảo nên bookmark

• Helm Docs - chủ đề OCI Registries: https://helm.sh/docs/topics/registries/

• Flux - Migrate from Helm Operator to Helm Controller: https://fluxcd.io/flux/migration/helm-operator-migration/

• chart-testing (ct): https://github.com/helm/chart-testing

• Sigstore Cosign: https://github.com/sigstore/cosign

• Artifact Hub (tìm & đánh giá chất lượng chart công khai): https://artifacthub.io