Lab 9 — Helm Testing & Validation
🎯 Mục tiêu
Sau Lab này, bạn sẽ:
- Hiểu tại sao Helm Chart cần được validate trước khi deploy.
- Biết sử dụng
helm lintđể phát hiện lỗi cơ bản. - Biết dùng
helm templateđể kiểm tra YAML mà Helm thực sự render. - Biết sử dụng
helm install --dry-runđể mô phỏng deployment. - Biết kiểm tra Kubernetes Manifest sau khi render.
- Biết xây dựng một quy trình validation đơn giản trong CI/CD.
Mục tiêu của Lab này không phải học nhiều công cụ testing của Helm.
Chỉ cần hình thành một thói quen:
Write Chart ↓ Validate ↓ Render ↓ Test ↓ DeployĐây là kỹ năng rất thực tế khi bạn phải review Helm Chart do AI tạo.
1. 🤔 Vấn đề thực tế
Giả sử bạn vừa sửa:
templates/deployment.yaml
và chạy ngay:
helm upgrade todo-api .
Kubernetes trả về:
YAML parse error
Hoặc tệ hơn:
Helm install thành công
↓
Pod không chạy
↓
CrashLoopBackOff
Hoặc:
Deployment chạy
↓
Service không connect được
Vấn đề là:
Helm Chart có thể đúng syntax Helm nhưng sai Kubernetes configuration.
Vì vậy chúng ta cần kiểm tra Chart theo nhiều tầng:
Helm Syntax
↓
Rendered YAML
↓
Kubernetes Manifest
↓
Application Behavior
2. 🧠 Hiểu nhanh
Có thể chia validation Helm thành 3 mức:
┌──────────────────────────────┐
│ 1. helm lint │
│ Chart có vấn đề cơ bản? │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ 2. helm template │
│ Render ra YAML thế nào? │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ 3. dry-run / Kubernetes │
│ Deploy có hợp lệ không? │
└──────────────────────────────┘
Mỗi bước trả lời một câu hỏi khác nhau.
3. 🏗️ Validation Flow
Architecture của Lab:
Developer
│
│ Helm Chart
▼
┌───────────────┐
│ helm lint │
└───────┬───────┘
│
▼
┌───────────────┐
│ helm template │
└───────┬───────┘
│
▼
┌──────────────────┐
│ Rendered YAML │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Dry Run / Test │
└────────┬─────────┘
│
▼
Kubernetes
4. 🚀 Chuẩn bị Lab
Sử dụng Chart đã tạo ở các Lab trước.
Ví dụ:
todo-app/
├── Chart.yaml
├── values.yaml
├── templates/
└── charts/
Kiểm tra:
helm version
và:
helm lint .
5. 🧪 Bước 1 — helm lint
Tại sao cần?
helm lint giống như một vòng code review tự động cơ bản.
Nó kiểm tra Chart có những vấn đề phổ biến hay không.
Chạy:
helm lint .
Nếu hợp lệ:
1 chart(s) linted, 0 chart(s) failed
Mental model:
Chart
│
▼
helm lint
│
├── Syntax
├── Chart structure
└── Common problems
6. 🧠 helm lint không kiểm tra tất cả
Đây là điều rất quan trọng.
Nếu:
helm lint .
pass:
✅ Chart có vẻ hợp lệ
không có nghĩa:
❌ Application chắc chắn chạy được
Ví dụ:
image:
repository: my-api
tag: "999"
Chart có thể vẫn lint được.
Nhưng image:
my-api:999
có thể không tồn tại.
Vì vậy:
helm lint
chỉ là bước đầu tiên.
7. 🧪 Exercise 1 — Cố tình tạo lỗi
Mở:
templates/deployment.yaml
Thử tạo một lỗi indentation hoặc template syntax.
Ví dụ cố tình viết sai một template expression:
name: {{ .Values.name
Chạy:
helm lint .
Quan sát lỗi.
Sau đó sửa lại.
Chạy:
helm lint .
Kết quả:
0 chart(s) failed
Điều cần hiểu
Bạn vừa thấy:
Code
↓
helm lint
↓
Feedback nhanh
Không cần deploy lên Kubernetes để phát hiện lỗi cơ bản.
8. 🧪 Bước 2 — helm template
helm lint chỉ cho biết:
Chart có vấn đề hay không?
Nhưng chúng ta còn một câu hỏi quan trọng hơn:
Helm thực sự tạo ra YAML gì?
Đó là lúc dùng:
helm template todo-api .
9. 🧠 Tại sao helm template quan trọng?
Helm Chart chứa:
Template
+
Values
Kubernetes lại cần:
Plain YAML
Quá trình:
values.yaml
│
▼
templates/
│
▼
Helm Engine
│
▼
Rendered YAML
│
▼
Kubernetes
helm template cho phép bạn nhìn thấy kết quả ở giữa.
10. 🧪 Render Chart
Chạy:
helm template todo-api .
Bạn sẽ thấy:
apiVersion: apps/v1
kind: Deployment
metadata:
name: todo-api
spec:
replicas: 2
và:
apiVersion: v1
kind: Service
...
Điều quan trọng:
Đây chính là YAML mà Helm chuẩn bị đưa cho Kubernetes.
11. 🧠 Đây là command cực kỳ quan trọng khi review AI
Giả sử AI tạo cho bạn:
200 lines Helm Template
Đừng cố đọc từng dòng template trước.
Hãy:
helm template .
Sau đó review:
Rendered YAML
Bạn sẽ dễ phát hiện:
replicas sai
image sai
port sai
env sai
namespace sai
probe sai
resources sai
Mental model:
AI-generated Chart
│
▼
helm template
│
▼
Actual Kubernetes YAML
│
▼
Human Review
Đây là một trong những kỹ năng Helm thực tế nhất.
12. 🧪 Exercise 2 — Kiểm tra Rendered YAML
Chạy:
helm template todo-api .
Sau đó tìm:
kind: Deployment
Kiểm tra:
□ replicas đúng?
□ image đúng?
□ containerPort đúng?
□ environment đúng?
□ resources đúng?
□ probes đúng?
Sau đó tìm:
kind: Service
Kiểm tra:
□ port đúng?
□ targetPort đúng?
□ selector có match Pod không?
13. ⚠️ Một lỗi rất hay gặp
Ví dụ Deployment:
metadata:
labels:
app: todo-api
Nhưng Service:
selector:
app: todo
Helm vẫn có thể render thành YAML hợp lệ.
Helm
↓
✅ Render được
Nhưng Kubernetes:
Service
│
│ selector: app=todo
▼
Không tìm thấy Pod
Kết quả:
Service
↓
No endpoints
Đây là ví dụ rất rõ:
YAML hợp lệ ≠ Configuration đúng.
14. 🧪 Bước 3 — helm install --dry-run
Bây giờ chúng ta tiến thêm một bước.
Thay vì:
helm install
chúng ta có thể mô phỏng:
helm install todo-api . \
--dry-run
Có thể thêm:
--debug
để xem thông tin chi tiết hơn:
helm install todo-api . \
--dry-run \
--debug
15. 🧠 dry-run là gì?
dry-run nghĩa là:
Thử thực hiện nhưng không thực sự deploy.
Mental model:
helm install
│
▼
Kubernetes
│
▼
Resources created
Còn:
helm install --dry-run
│
▼
Simulation
│
▼
Không tạo resources thật
Điều này rất hữu ích khi:
Production
và bạn muốn kiểm tra trước khi thực sự thay đổi cluster.
16. 🧪 Exercise 3 — Dry Run
Chạy:
helm install todo-api . \
--dry-run \
--debug
Quan sát:
Deployment
Service
ConfigMap
...
Sau đó:
kubectl get pods
Bạn sẽ thấy:
Không có Todo API Pod mới
Đây là điểm khác biệt quan trọng:
dry-run
↓
validate/simulate
install
↓
actually change cluster
17. 🧠 helm template vs dry-run
Hai command có vẻ giống nhau nhưng mục đích hơi khác.
helm template
Tập trung vào:
Helm render ra YAML gì?
Chart
↓
Rendered YAML
helm install --dry-run
Tập trung vào:
Nếu install thì Helm release sẽ trông như thế nào?
Chart
↓
Helm install simulation
Trong thực tế bạn sẽ thường dùng:
helm lint
↓
helm template
↓
helm install --dry-run
18. 🧪 Bước 4 — Validate Kubernetes Manifest
Đến đây chúng ta đã kiểm tra:
Helm
Nhưng vẫn cần kiểm tra:
Kubernetes
Một manifest có thể:
Helm render thành công
nhưng không hợp lệ với Kubernetes API.
Một cách thực tế là render ra file:
helm template todo-api . > rendered.yaml
Sau đó inspect:
cat rendered.yaml
Bạn cũng có thể sử dụng các công cụ Kubernetes/schema validation trong CI để kiểm tra manifest trước khi apply.
Điều quan trọng cần nhớ:
Helm Validation
+
Kubernetes Validation
là hai lớp khác nhau.
19. 🧠 Validation nhiều tầng
Bây giờ mental model hoàn chỉnh:
Helm Chart
│
▼
┌───────────┐
│ helm lint │
└─────┬─────┘
│
▼
┌──────────────┐
│ helm template│
└──────┬───────┘
│
▼
Rendered YAML
│
▼
Kubernetes Validation
│
▼
Dry Run / Test
│
▼
Real Deploy
Mỗi tầng bắt một loại lỗi khác nhau.
20. 🧪 Exercise 4 — Values Validation
Một Chart tốt thường có nhiều environment:
values-dev.yaml
values-staging.yaml
values-prod.yaml
Đừng chỉ test:
helm lint .
Hãy test từng configuration.
Ví dụ:
helm lint . -f values-dev.yaml
helm lint . -f values-staging.yaml
helm lint . -f values-prod.yaml
Và:
helm template todo-api . \
-f values-prod.yaml
21. 🧠 Tại sao phải test từng Values file?
Vì:
Chart
+
values-dev
có thể chạy.
Nhưng:
Chart
+
values-prod
có thể lỗi.
Ví dụ:
# values-dev.yaml
image:
tag: "dev"
và:
# values-prod.yaml
image:
tag: ""
Chart vẫn tồn tại.
Nhưng Production có thể tạo:
image: todo-api:
và Pod không chạy.
Vì vậy:
Chart + Values = một configuration cần test.
22. 🧪 Exercise 5 — Cố tình tạo lỗi Values
Sửa:
values-prod.yaml
thành:
replicaCount: "three"
Thay vì:
replicaCount: 3
Render:
helm template todo-api . \
-f values-prod.yaml
Quan sát kết quả.
Đây là lúc bạn nhận ra:
values.yaml
không chỉ là dữ liệu.
Nó là input của hệ thống template.
23. 🧠 Schema Validation
Khi Chart lớn hơn, bạn có thể thêm:
values.schema.json
Mục đích:
Giới hạn Values được phép truyền vào Chart.
Ví dụ bạn muốn:
replicaCount
phải là:
integer
thay vì:
"three"
Mental model:
values.yaml
│
▼
values.schema.json
│
▼
Validate Input
│
▼
Helm Template
24. 🧪 Exercise 6 — Schema
Tạo:
values.schema.json
Ví dụ đơn giản:
{
"$schema": "http://json-schema.org/schema#",
"type": "object",
"properties": {
"replicaCount": {
"type": "integer",
"minimum": 1
}
}
}
Bây giờ:
replicaCount: "three"
sẽ bị validation bắt lỗi.
Trong khi:
replicaCount: 3
hợp lệ.
25. 🧠 Tại sao Schema hữu ích?
Hãy tưởng tượng:
20 developers
│
▼
Reusable Chart
│
▼
20 values files
Nếu không có validation:
replicaCount: 3
replicaCount: "3"
replicaCount: three
replicaCount: null
Có thể xuất hiện nhiều configuration không nhất quán.
Schema giúp biến:
values.yaml
thành một interface có contract rõ ràng.
26. 🧪 Exercise 7 — Test Dependency
Nếu Chart có dependency:
charts/
└── postgresql
hãy kiểm tra:
helm dependency list
Sau đó:
helm template todo-app .
Xác nhận:
PostgreSQL
được render đúng.
Cuối cùng:
helm install todo-app . \
--dry-run \
--debug
27. 🧠 Helm Test
Helm còn có một khái niệm gọi là:
Helm Test
Nó khác với:
helm lint
và:
helm template
helm test dùng để kiểm tra release sau khi đã deploy.
Ví dụ:
Application
│
▼
Kubernetes
│
▼
Running Pod
│
▼
Test Pod
│
▼
Check Application
Một test có thể kiểm tra:
Application có response không?
Service có connect được không?
Database connection có hoạt động không?
28. 🧠 Khi nào cần Helm Test?
Không phải Chart nào cũng cần test phức tạp.
Với application đơn giản:
helm lint
helm template
dry-run
có thể đã đủ cho bước validation cơ bản.
Nhưng application quan trọng có thể thêm:
Helm Test
để kiểm tra behavior sau deployment.
Ví dụ:
Deployment
↓
Pod Running
↓
helm test
↓
HTTP request
↓
Expected response
29. 🧪 Exercise 8 — Helm Test
Tạo:
templates/tests/test-connection.yaml
Một Helm test thường tạo một Pod có:
annotations:
"helm.sh/hook": test
Test Pod có thể thực hiện:
curl http://todo-api
Sau khi install:
helm test todo-api
Nếu application phản hồi đúng:
TEST SUITE: ...
PASSED
Không cần nhớ cấu trúc test hook. Chỉ cần hiểu:
helm test ↓ kiểm tra behavior của release
30. 🏢 Production Workflow
Trong CI/CD, bạn có thể xây dựng flow:
Pull Request
│
▼
helm lint
│
▼
helm dependency
│
▼
helm template
│
▼
Manifest Validation
│
▼
Helm Test
│
▼
Review
│
▼
Deploy
Ví dụ CI:
helm lint .
helm dependency build .
helm template todo-api . \
-f values-prod.yaml
helm install todo-api . \
-f values-prod.yaml \
--dry-run
Sau khi mọi thứ pass:
Deploy
31. 🚨 Đừng chỉ test "Chart"
Đây là một điểm rất quan trọng.
Bạn không thực sự deploy:
Chart
Bạn deploy:
Chart
+
Values
+
Dependencies
Vì vậy test phải phản ánh configuration thực tế.
Ví dụ:
Chart
+
values-dev.yaml
là một configuration.
Chart
+
values-prod.yaml
là một configuration khác.
32. 🧠 Một cách review Helm Chart rất thực tế
Khi AI đưa cho bạn một Chart, thay vì đọc toàn bộ:
templates/
deployment.yaml
service.yaml
ingress.yaml
...
hãy làm:
Step 1
helm lint .
Step 2
helm template .
Step 3
Review rendered YAML.
Step 4
helm install --dry-run
Step 5
Nếu có cluster test:
Deploy
↓
Check Pod
↓
Check Service
↓
Check Application
Đây là cách review nhanh hơn rất nhiều.
33. 🔥 Một ví dụ Debug thực tế
Giả sử:
Pod Running
nhưng:
API không truy cập được
Đừng lập tức sửa Helm Template.
Kiểm tra theo tầng:
1. Helm render đúng?
↓
2. Deployment đúng?
↓
3. Pod labels đúng?
↓
4. Service selector đúng?
↓
5. Service port đúng?
↓
6. Ingress đúng?
Ví dụ:
Pod
labels:
app: todo-api
Service:
selector:
app: todo
Kết quả:
Pod Running
↓
Service
↓
No Endpoint
Helm có thể hoàn toàn không báo lỗi.
Đây là lý do:
Validation phải kiểm tra cả logic, không chỉ syntax.
34. 🧠 Validation Pyramid
Bạn có thể ghi nhớ bằng mô hình:
Production
▲
│
Application Test
│
Kubernetes Validation
│
Helm Dry Run
│
helm template
│
helm lint
│
Chart Syntax
Càng lên cao:
Test càng thực tế
nhưng:
Test càng tốn thời gian
Vì vậy không phải lúc nào cũng cần test mọi thứ ở mọi bước.
35. 🧪 Final Exercise — Validation Pipeline
Hãy tạo một script:
validate.sh
Concept:
#!/bin/sh
helm lint .
helm dependency build .
helm template todo-api . \
-f values-prod.yaml
helm install todo-api . \
-f values-prod.yaml \
--dry-run
Chạy:
./validate.sh
Mục tiêu:
Một command
↓
Validate toàn bộ Chart
36. 🏆 Production Checklist
Trước khi merge một Helm Chart:
□ helm lint pass
□ Dependencies được resolve
□ Chart.lock được kiểm soát
□ helm template pass
□ Rendered YAML được review
□ Production values đã được test
□ Schema validation nếu cần
□ Dry-run pass
□ Kubernetes manifest hợp lệ
□ Helm test nếu application cần
□ Không có secret hard-code
□ Image tag được xác định rõ
□ Resources được cấu hình
□ Probes được cấu hình
Không phải Chart nào cũng cần toàn bộ checklist.
Hãy chọn mức validation phù hợp với độ quan trọng của application.
37. 🎯 Tổng kết
Sau Lab này, bạn chỉ cần nhớ:
1. helm lint
Chart có vấn đề cơ bản không?
2. helm template
Helm thực sự render YAML gì?
3. --dry-run
Nếu deploy thì chuyện gì xảy ra?
4. Schema
Values có đúng format không?
5. Helm Test
Application sau khi deploy có hoạt động không?
6. Quan trọng nhất
Chart
+
Values
+
Dependencies
↓
Rendered Manifest
↓
Validation
↓
Deploy
Đừng chỉ hỏi:
"Helm Chart có syntax đúng không?"
Hãy hỏi:
"Sau khi render, Kubernetes sẽ nhận được gì và application có thực sự chạy đúng không?"
🧠 Mental Model cuối Lab
Khi review một Helm Chart do AI tạo, workflow của bạn nên gần như trở thành phản xạ:
AI tạo Chart
│
▼
helm lint
│
▼
helm template
│
▼
Review Rendered YAML
│
▼
Validate Kubernetes
│
▼
Dry Run
│
▼
Deploy Test Environment
│
▼
helm test / Application Test
│
▼
Production
Bạn không cần thuộc hàng trăm syntax Helm.
Điều quan trọng hơn là biết:
Helm làm gì?
↓
Render ra gì?
↓
Kubernetes nhận gì?
↓
Application chạy thế nào?
Đó chính là mức hiểu Helm phù hợp với mục tiêu review, customize và maintain Chart trong môi trường DevOps thực tế.
All rights reserved
