Mở rộng Kubernetes: Helm đã cứu chúng tôi khỏi "địa ngục" quản lý YAML như thế nào

Table of Contents

Giới hạn của việc quản lý YAML thủ công

Quản lý một deployment đơn lẻ trên Kubernetes có vẻ khá dễ dàng. Bạn viết một manifest Deployment, một Service và một Ingress, sau đó chạy kubectl apply -f. Thế nhưng, phương pháp này sẽ vấp phải rào cản ngay khi hệ thống lớn dần. Sáu tháng trước, đội ngũ của tôi đã chạm ngưỡng đó. Chúng tôi phải xoay xở với 18 microservices trên ba môi trường: dev, staging và production. Chúng tôi bị nhấn chìm trong hơn 2.000 dòng YAML gần như giống hệt nhau, nơi khác biệt duy nhất chỉ là vài giới hạn CPU hoặc số lượng replica.

Việc copy-paste cấu hình đã dẫn đến tình trạng “sai lệch cấu hình” (configuration drift) không thể tránh khỏi. Một lập trình viên có thể tinh chỉnh liveness probe trong manifest của staging nhưng lại quên đồng bộ nó lên production. Những thao tác thủ công này không chỉ gây mệt mỏi mà còn là một “quả bom hẹn giờ”. Chúng tôi cần coi các ứng dụng Kubernetes như các gói phần mềm có phiên bản, chứ không phải là một tập hợp các script rời rạc. Đó là lúc chúng tôi chuyển toàn bộ sang Helm.

Kiến trúc Helm: Charts, Values và Releases

Helm đóng vai trò là trình quản lý gói (package manager) cho Kubernetes. Nó cho phép bạn định nghĩa, cài đặt và nâng cấp ngay cả những ứng dụng phức tạp nhất chỉ với một câu lệnh duy nhất. Để làm chủ Helm, bạn cần hiểu rõ ba trụ cột cốt lõi.

The Chart: Đây là bản thiết kế của bạn. Nó chứa các template YAML cho Deployment, Service và ConfigMaps.
Values: Đây là các thông số tùy chỉnh. Thay vì ghi cứng (hardcode) một image tag, bạn sử dụng một biến giữ chỗ để lấy dữ liệu từ file values.yaml.
The Release: Đây là một phiên bản đang chạy thực tế của chart. Bạn có thể chạy “api-gateway-dev” và “api-gateway-prod” trong cùng một cluster bằng cách sử dụng cùng một chart nhưng với các giá trị (values) khác nhau.

Việc tách biệt logic khỏi dữ liệu này đã thay đổi mọi thứ. Bằng cách cô lập các template hạ tầng khỏi các con số cụ thể của từng môi trường, chúng tôi đã cắt giảm được khoảng 85% lỗi cấu hình.

Quy trình thực tế: Xây dựng Chart đầu tiên của bạn

Bắt đầu rất nhanh chóng. Nếu kubectl đã được cấu hình trỏ tới cluster của bạn, bạn có thể cài đặt Helm binary trong chưa đầy 60 giây.

# Trên macOS
brew install helm

# Trên Linux
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Khởi tạo cấu trúc ứng dụng

Hãy bỏ qua việc tạo file thủ công. Sử dụng công cụ tạo khung (scaffolding) có sẵn để tạo cấu trúc thư mục tiêu chuẩn theo các thực hành tốt nhất trong ngành.

helm create my-python-app

Câu lệnh này sẽ tạo ra thư mục my-python-app/. Bên trong, thư mục templates/ là nơi công việc thực sự diễn ra. Bạn sẽ thấy các file như deployment.yaml và service.yaml đã được thiết lập sẵn with cú pháp Go template.

Hệ thống Template linh hoạt

Sức mạnh thực sự của Helm nằm ở hệ thống biến. Hãy xem cách một manifest tĩnh trở nên linh hoạt nhờ các template:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deploy
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app-container
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Sau đó, file values.yaml sẽ trở thành nguồn dữ liệu tin cậy duy nhất (single source of truth) cho cấu hình của bạn:

# values.yaml
replicaCount: 3
image:
  repository: my-registry/my-python-app
  tag: "1.2.5"

Kiểm soát vòng đời Release

Việc triển khai giờ đây là một thao tác nguyên tử (atomic operation) duy nhất. Không còn cảnh phải chạy năm câu lệnh kubectl khác nhau theo một trình tự nhất định và hy vọng không có lệnh nào bị lỗi giữa chừng.

# Cài đặt chart
helm install my-app-prod ./my-python-app --values prod-values.yaml

Nâng cấp an toàn và Rollback tức thì

Khi cần triển khai phiên bản mới, bạn không cần chạm vào các đối tượng đang chạy. Bạn chỉ cần cập nhật file values.yaml và thực hiện nâng cấp (upgrade). Helm theo dõi mọi thay đổi dưới dạng các phiên bản (revision). Nếu một image mới gây ra tình trạng tràn bộ nhớ, bạn có thể hoàn tác toàn bộ hệ thống trong chưa đầy năm giây. Điều này đã cứu chúng tôi trong một lần triển khai lỗi vào chiều thứ Sáu quý trước.

# Xem lịch sử phiên bản
helm history my-app-prod

# Rollback về revision 2 ngay lập tức
helm rollback my-app-prod 2

Những bài học xương máu từ môi trường thực tế

Chuyển sang Helm là một sự thay đổi tư duy hướng tới “Hạ tầng dưới dạng mã” (Infrastructure as Code). Thành quả lớn nhất đạt được là gì? Đó chính là các tiêu chuẩn nội bộ. Thay vì mỗi đội ngũ phải tự mày mò cách triển khai Redis, chúng tôi đã xây dựng một chart Redis nội bộ dùng chung cho tất cả mọi người. Tính nhất quán tăng lên, và thời gian xử lý sự cố giảm xuống đáng kể.

Một lời khuyên nhỏ: đừng quá phức tạp hóa (over-engineer) các template của bạn. Việc thêm logic if-else phức tạp cho mọi trường hợp biên (edge case) rất dễ gây cám dỗ, nhưng điều này sẽ khiến các chart của bạn trở nên cực kỳ khó đọc. Nếu logic trong template của bạn còn dài hơn cả file YAML kết quả, nghĩa là bạn đã đi quá xa rồi. Hãy giữ nó đơn giản.

Đối với bất kỳ đội ngũ nào vận hành từ hai hoặc ba dịch vụ trở lên, Helm là một yêu cầu bắt buộc. Nó cung cấp các “rào chắn bảo vệ” cần thiết để mở rộng quy mô mà không làm bạn mất kiểm soát. Sự ổn định của cluster chúng tôi trong nửa năm qua là kết quả trực tiếp của việc quản lý các lần triển khai dưới dạng các release có kiểm soát thay vì các bản vá thủ công.

Tổng kết

Chuyển sang dùng Helm đòi hỏi một chút nỗ lực ban đầu để tái cấu trúc lại các manifest. Nhưng thành quả mang lại là vô cùng xứng đáng. Hãy bắt đầu với một ứng dụng đơn giản, làm chủ lệnh helm install và đưa các cấu hình của bạn vào các file values. Đội ngũ SRE sẽ cảm ơn bạn khi lần rollback khẩn cấp tiếp theo chỉ mất 3 giây thay vì 30 phút.