0

Bài 32. Kustomize - Quản lý nhiều môi trường mà không cần copy YAML

"Chỉ khác mỗi số lượng replicas, vậy mà tôi phải copy cả file YAML?"

Đây là vấn đề mà gần như ai làm Kubernetes cũng gặp phải.

Giả sử bạn có một ứng dụng với file deployment.yaml.

Ở môi trường Development, bạn chỉ cần:

  • 1 Pod
  • Image my-app:dev

Nhưng khi lên Production, bạn lại cần:

  • 3 Pods
  • Image my-app:v1.0.0

Nếu chỉ dùng YAML thuần, cách đơn giản nhất là...

k8s/
├── dev/
│   └── deployment.yaml
└── prod/
    └── deployment.yaml

Ban đầu thì ổn.

Nhưng vài tháng sau, hai file này bắt đầu khác nhau ngày càng nhiều.

Bạn sửa một bug trong dev nhưng quên sửa prod.

Bạn thêm một label nhưng chỉ cập nhật một file.

Kết quả là có rất nhiều bản sao của cùng một cấu hình.

Đây chính là lúc Kustomize xuất hiện.


1. Kustomize là gì?

Kustomize cho phép bạn tái sử dụng một bộ YAML gốc (Base) rồi chỉ ghi đè những phần khác nhau cho từng môi trường.

Thay vì copy toàn bộ file, bạn chỉ mô tả điểm khác biệt.

Ví dụ:

k8s/
├── base/
│   └── deployment.yaml
│
└── overlays/
    ├── dev/
    └── prod/
  • Base chứa cấu hình dùng chung.
  • Overlay chỉ chứa những thay đổi của từng môi trường.

Ví dụ:

Development
replicas = 1

Production
replicas = 3

Chỉ vậy thôi.

Không cần thêm một bản deployment.yaml mới.


2. Kustomize hoạt động như thế nào?

Hãy tưởng tượng bạn có một mẫu đơn.

Mọi người đều dùng chung mẫu đó.

Riêng từng phòng ban chỉ điền thêm thông tin của mình.

Kustomize cũng hoạt động theo cách tương tự:

Base YAML
      │
      ▼
 Overlay (Dev)
      │
      ▼
 YAML hoàn chỉnh cho Dev

Base YAML
      │
      ▼
 Overlay (Prod)
      │
      ▼
 YAML hoàn chỉnh cho Production

Bạn luôn chỉ bảo trì một bản gốc.


3. Khi nào nên dùng Kustomize?

Kustomize đặc biệt phù hợp khi bạn có nhiều môi trường như:

  • Development
  • Staging
  • Production

hoặc nhiều cluster có cấu hình gần giống nhau.

Những gì giống nhau sẽ nằm trong Base.

Những gì khác nhau sẽ nằm trong Overlay.


4. Kustomize hay Helm?

Đây là câu hỏi rất phổ biến.

  • Kustomize phù hợp khi chỉ cần thay đổi một vài giá trị giữa các môi trường.
  • Helm mạnh hơn khi bạn muốn đóng gói ứng dụng thành một "chart" có thể tái sử dụng và phân phối.

Nói đơn giản:

  • Kustomize = Chỉnh sửa YAML có sẵn.
  • Helm = Sinh YAML từ Template.

Trong thực tế, nhiều đội ngũ còn sử dụng cả hai cùng nhau.


Tổng kết

Kustomize giúp bạn tránh việc sao chép hàng loạt file YAML chỉ để thay đổi vài dòng cấu hình.

Thay vì quản lý nhiều bản giống nhau, bạn chỉ cần:

  • Một Base dùng chung.
  • Nhiều Overlay cho từng môi trường.

Nhờ đó, cấu hình trở nên gọn gàng, dễ bảo trì và giảm đáng kể nguy cơ cập nhật thiếu hoặc sai lệch giữa các môi trường.


Bài tiếp theo

Khi đã biết cách quản lý cấu hình cho nhiều môi trường, câu hỏi tiếp theo là:

Làm thế nào để Kubernetes tự động đồng bộ cấu hình từ Git mỗi khi có thay đổi?

Đó chính là lúc chúng ta tìm hiểu về GitOps.


All Rights Reserved

Viblo
Let's register a Viblo Account to get more interesting posts.