Lab 7 — Reusable Chart
🎯 Mục tiêu
Sau Lab này, bạn sẽ:
- Hiểu Reusable Helm Chart là gì và tại sao cần nó.
- Biết phân biệt một Chart "chỉ chạy được" với một Chart có thể tái sử dụng.
- Biết thiết kế một Chart để nhiều application có thể sử dụng chung.
- Hiểu cách dùng
values.yamlđể biến Chart thành một "interface". - Biết cách review một Reusable Chart do AI tạo.
- Hiểu một số nguyên tắc production khi thiết kế Chart dùng chung.
Mục tiêu của Lab này không phải viết một Helm framework phức tạp.
Chỉ cần hiểu:
Application-specific Chart ↓ Reusable Chart ↓ Nhiều application dùng chung logicĐây là kỹ năng quan trọng hơn việc thuộc syntax Helm.
1. 🤔 Vấn đề thực tế
Giả sử công ty có:
todo-api
user-api
payment-api
order-api
notification-api
Tất cả đều chạy trên Kubernetes.
Nhìn vào Deployment của chúng:
Deployment
├── replicas
├── image
├── resources
├── probes
├── environment
└── securityContext
Gần như giống nhau.
Nhưng nếu mỗi team tự tạo Helm Chart:
todo-api/
user-api/
payment-api/
order-api/
notification-api/
thì rất nhanh sẽ xuất hiện:
todo-api → có readinessProbe
user-api → có readinessProbe
payment-api → quên readinessProbe
order-api → cấu hình khác
notification → copy từ Chart cũ
Sau một thời gian:
5 applications
↓
5 Charts
↓
5 cách deploy
↓
5 cách cấu hình
Đây là vấn đề mà Reusable Chart muốn giải quyết.
2. 🧠 Reusable Chart là gì?
Một Reusable Chart là Chart được thiết kế để:
Một Chart có thể deploy nhiều application khác nhau bằng cách thay đổi Values.
Ví dụ:
application-chart
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
todo-api user-api payment-api
│ │ │
values values values
Thay vì:
todo-api Chart
user-api Chart
payment-api Chart
chúng ta có:
Reusable Chart
│
┌───────────┼───────────┐
▼ ▼ ▼
Todo API User API Payment API
3. 🏗️ Architecture
Có thể hình dung Reusable Chart như một template application factory:
Reusable Chart
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
values-todo values-user values-payment
│ │ │
▼ ▼ ▼
Todo API User API Payment API
│ │ │
└────────────────┼────────────────┘
▼
Kubernetes
Chart cung cấp:
Deployment
Service
ConfigMap
Ingress
Probes
Resources
Security
Application chỉ cần cung cấp:
Image
Port
Replicas
Environment
Domain
4. 🧠 Một ví dụ đời thường
Hãy tưởng tượng bạn có một khuôn bánh.
Nếu mỗi lần làm bánh bạn tạo một khuôn mới:
Bánh A → khuôn A
Bánh B → khuôn B
Bánh C → khuôn C
rất lãng phí.
Reusable Chart giống như:
Khuôn chung
│
┌────────┼────────┐
▼ ▼ ▼
Bánh A Bánh B Bánh C
Khuôn giữ:
hình dạng
quy trình
structure
Nguyên liệu thay đổi:
chocolate
vanilla
strawberry
Trong Helm:
Chart
↓
Structure + Deployment logic
Values
↓
Application-specific configuration
5. 🧠 Một Reusable Chart nên customize gì?
Không có danh sách bắt buộc.
Nhưng một application chart thường cần:
image:
repository:
tag:
replicaCount:
service:
port:
resources:
env:
probes:
ingress:
enabled:
host:
Mental model:
Reusable Chart
│
├── Image
├── Replica
├── Service
├── Resources
├── Environment
├── Probes
└── Ingress
Không phải mọi application đều cần tất cả.
6. 🚀 Chuẩn bị Lab
Tạo Chart:
helm create reusable-app
cd reusable-app
Structure:
reusable-app/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
├── service.yaml
├── configmap.yaml
└── ingress.yaml
Trong Lab này, chúng ta sẽ biến Chart mặc định thành một Chart có thể deploy:
todo-api
user-api
mà không cần copy Chart.
7. 🧪 Thiết kế Values như một Interface
Đây là phần quan trọng nhất.
Hãy coi:
values.yaml
là API của Chart.
Developer không cần biết:
deployment.yaml
service.yaml
Họ chỉ cần biết:
image:
repository: todo-api
tag: "1.0.0"
replicaCount: 3
service:
port: 8080
Giống như gọi một function:
deployApplication(
image,
replicas,
port
)
Bạn không cần biết function bên trong hoạt động thế nào.
8. 🧠 Chart Interface
Có thể hình dung:
values.yaml
│
│ Interface
▼
┌─────────────┐
│ Reusable │
│ Chart │
└──────┬──────┘
│
▼
Kubernetes
Đây là tư duy rất quan trọng:
Một Reusable Chart tốt không bắt người dùng phải hiểu implementation bên trong.
9. 🧪 Thiết kế Values
Thay values.yaml bằng cấu hình đơn giản:
nameOverride: ""
replicaCount: 1
image:
repository: nginx
tag: "1.27"
service:
port: 80
env: {}
resources: {}
ingress:
enabled: false
host: ""
probes:
enabled: false
Chúng ta có một interface tương đối đơn giản.
10. 🔧 Deployment Template
Deployment sẽ lấy configuration từ Values.
Concept:
Values
│
├── replicaCount
├── image
├── env
├── resources
└── probes
│
▼
Deployment
Ví dụ:
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
Điểm quan trọng:
Template không biết đây là Todo API hay User API.
Nó chỉ biết:
image
replica
configuration
11. 🧪 Deploy Todo API
Tạo:
values-todo.yaml
nameOverride: todo-api
replicaCount: 2
image:
repository: todo-api
tag: "1.0.0"
service:
port: 8080
env:
APP_ENV: production
Render:
helm template todo-api . \
-f values-todo.yaml
Kết quả:
Deployment
│
├── todo-api
├── replicas: 2
└── image: todo-api:1.0.0
Service
│
└── port: 8080
12. 🧪 Deploy User API
Tạo:
values-user.yaml
nameOverride: user-api
replicaCount: 3
image:
repository: user-api
tag: "2.1.0"
service:
port: 8080
env:
APP_ENV: production
Render:
helm template user-api . \
-f values-user.yaml
Kết quả:
Deployment
│
├── user-api
├── replicas: 3
└── image: user-api:2.1.0
Service
│
└── port: 8080
Bạn vừa deploy hai application khác nhau bằng cùng một Chart.
13. 🧠 Điều gì vừa xảy ra?
Chúng ta có:
reusable-app
│
┌─────────┴─────────┐
│ │
values-todo.yaml values-user.yaml
│ │
▼ ▼
Todo API User API
Không cần:
❌ todo-chart
❌ user-chart
Chỉ cần:
✅ reusable-app
14. 🔥 Tại sao điều này quan trọng?
Giả sử công ty có:
20 microservices
và muốn tất cả có:
readinessProbe
livenessProbe
resource limits
securityContext
standard labels
Nếu mỗi service có Chart riêng:
20 Charts
↓
20 nơi cần maintain
Nếu dùng Reusable Chart:
1 Chart
↓
20 applications
Bạn thay đổi:
securityContext
một lần.
Sau đó các application sử dụng Chart mới có thể nhận behavior đó.
15. ⚠️ Nhưng Reusable không có nghĩa là "mọi thứ đều configurable"
Đây là một lỗi thiết kế phổ biến.
Bạn có thể tạo:
deployment:
metadata:
spec:
containers:
securityContext:
lifecycle:
...
và expose gần như toàn bộ Kubernetes API.
Technically rất flexible.
Nhưng:
Reusable Chart
↓
values.yaml
↓
500 options
thì Chart trở nên:
khó hiểu
khó review
khó maintain
Đừng biến:
Reusable Chart
thành:
Kubernetes YAML generator
16. 🧠 Abstraction vừa đủ
Một Chart tốt nên expose:
Business-relevant configuration
Ví dụ:
image:
replicaCount:
resources:
service:
ingress:
env:
thay vì expose mọi chi tiết:
Kubernetes field A
Kubernetes field B
Kubernetes field C
...
Mental model:
Application Developer
│
│ Simple Values
▼
┌──────────────────────┐
│ Reusable Chart │
│ │
│ Complex Kubernetes │
│ logic hidden here │
└──────────┬───────────┘
│
▼
Kubernetes
17. 🧩 Standardization
Một Reusable Chart không chỉ giúp giảm code.
Nó còn giúp standardize deployment.
Ví dụ tất cả application đều có:
Standard labels
Standard probes
Standard resources
Standard security context
Standard Service
Standard monitoring annotations
Architecture:
Platform Team
│
▼
Reusable Chart
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Team A Team B Team C
│ │ │
Service A Service B Service C
Platform team quản lý:
How application should run
Application team quản lý:
Which application
Which image
Which configuration
Đây là một pattern rất phổ biến trong platform engineering.
18. 🏢 Production Example
Một công ty có:
20 backend services
Platform team tạo:
company-application-chart
Chart mặc định:
- SecurityContext
- Resource requests
- Resource limits
- Probes
- Service
- PodDisruptionBudget
- Standard labels
- Monitoring
Application team chỉ cần:
image:
repository: payment-api
tag: "2.4.1"
replicaCount: 3
service:
port: 8080
Kết quả:
Payment API
│
▼
Company Chart
│
├── Security
├── Monitoring
├── Health check
├── Resources
└── Networking
Application team không cần tự implement tất cả.
19. 🔍 Review một Reusable Chart
Khi AI tạo cho bạn một Reusable Chart, hãy hỏi:
1. Chart có thực sự reusable không?
Nếu template có:
todo-api
payment-api
user-api
hard-code ở nhiều nơi:
❌ Không reusable
2. Values có rõ ràng không?
Ví dụ:
image:
replicaCount:
service:
resources:
rất dễ hiểu.
3. Có quá nhiều options không?
Nếu:
values.yaml
có:
300+ lines
hãy xem xét.
Không phải lúc nào cũng sai, nhưng cần hỏi:
Có thực sự cần từng option không?
4. Template có business logic không?
Ví dụ:
if application == payment
...
else if application == todo
...
🚨 Đây là dấu hiệu Chart đang trở nên quá application-specific.
Reusable Chart tốt hơn khi:
Values
↓
Generic Template
thay vì:
Values
↓
if app == A
if app == B
if app == C
20. ⚠️ Khi nào KHÔNG nên dùng Reusable Chart?
Không phải application nào cũng phải dùng một Chart chung.
Ví dụ:
Kafka
PostgreSQL
Elasticsearch
có architecture rất khác:
Stateful
Storage
Cluster
Persistence
Operators
Trong khi:
Todo API
User API
Payment API
có architecture khá giống nhau.
Vì vậy:
Similar applications
↓
Reusable Chart
Nhưng:
Completely different architecture
↓
Separate Chart
21. 🧠 Reusable Chart vs Library Chart
Bạn có thể nghe tới:
Library Chart
Library Chart thường chứa helper/template dùng chung, thay vì trực tiếp deploy application.
Ví dụ:
company-library
│
├── labels
├── naming
├── security helpers
└── common templates
Application Chart:
todo-api
│
└── sử dụng library
Mental model:
Reusable Application Chart
↓
Deploy application
Library Chart
↓
Share template/helper logic
Ở giai đoạn hiện tại, bạn chỉ cần nhận biết sự khác nhau, chưa cần đi sâu.
22. 🧪 Exercise 1 — Hai Application
Dùng cùng một Chart để render:
todo-api
user-api
Todo:
nameOverride: todo-api
image:
repository: todo-api
tag: "1.0.0"
replicaCount: 2
User:
nameOverride: user-api
image:
repository: user-api
tag: "2.0.0"
replicaCount: 3
Render cả hai.
Xác nhận:
Todo Deployment
User Deployment
được tạo từ cùng một template.
23. 🧪 Exercise 2 — Standard Resources
Thêm:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
Render cả:
todo-api
user-api
Xác nhận cả hai đều có resources.
Bạn vừa tạo một standardization rule.
24. 🧪 Exercise 3 — Standard Probes
Thêm:
probes:
enabled: true
path: /health
Template tạo:
livenessProbe
readinessProbe
Render:
helm template todo-api . -f values-todo.yaml
và:
helm template user-api . -f values-user.yaml
Xác nhận cả hai application đều có health checks.
25. 🧪 Exercise 4 — Thử thêm Application thứ ba
Tạo:
values-payment.yaml
nameOverride: payment-api
image:
repository: payment-api
tag: "3.2.1"
replicaCount: 4
service:
port: 8080
Không được sửa:
templates/deployment.yaml
Render:
helm template payment-api . \
-f values-payment.yaml
Nếu thành công:
Todo API
User API
Payment API
đều sử dụng cùng một Chart.
Đó chính là bài kiểm tra đơn giản nhất cho:
"Chart này có thực sự reusable không?"
26. 🧪 Exercise 5 — Review Chart do AI tạo
Hãy yêu cầu AI tạo một:
Reusable Helm Chart for microservices
Sau đó review:
□ Template có hard-code tên application không?
□ Image có configurable không?
□ Replica có configurable không?
□ Service có configurable không?
□ Resources có configurable không?
□ Probes có configurable không?
□ Ingress có configurable không?
□ Có quá nhiều configuration không?
□ Có business logic của từng application trong Chart không?
□ Có thể deploy application thứ 3 mà không sửa template không?
Nếu câu cuối cùng là Có:
Chart
↓
Application A
Application B
Application C
thì bạn đang đi đúng hướng.
27. 🚨 Một lỗi production quan trọng
Reusable Chart có thể tạo ra một vấn đề mới:
Chart v1
↓
20 applications
Bạn sửa Chart:
Chart v2
Nếu update không cẩn thận:
20 applications
↓
Behavior thay đổi cùng lúc
Ví dụ Chart mới thay:
readinessProbe
và tất cả application đều bị ảnh hưởng.
Vì vậy Reusable Chart cần:
Versioning
Testing
Changelog
Controlled upgrade
Đây là lý do:
Reusable Chart là một platform component, không đơn giản chỉ là một folder chứa YAML.
28. 📦 Versioning
Ví dụ:
apiVersion: v2
name: company-app
version: 1.3.0
Khi thay đổi Chart:
1.3.0
↓
1.4.0
Application có thể upgrade có kiểm soát.
Mental model:
Application
│
▼
company-app:1.3.0
sau đó:
Application
│
▼
company-app:1.4.0
Không nên:
Application
│
▼
latest
và không biết mình đang sử dụng behavior nào.
29. 🧠 Reusable Chart trong CI/CD
Một architecture thực tế:
Git
│
▼
CI Pipeline
│
┌────────┴────────┐
│ │
Validate Test
│ │
└────────┬────────┘
▼
Helm Chart
│
▼
Chart Registry
│
┌──────────┼──────────┐
▼ ▼ ▼
Dev Staging Prod
Reusable Chart có thể được publish thành:
company-app-chart:1.4.0
Các team consume Chart đó.
30. 🎯 Tổng kết
Sau Lab này, bạn cần nhớ 6 điều.
1. Reusable Chart
Một Chart
↓
Nhiều Application
2. Values là Interface
Application Team
│
▼
Values
│
▼
Reusable Chart
Không cần biết implementation bên trong.
3. Template chứa logic chung
Deployment
Service
Probes
Resources
Security
có thể được standardize.
4. Đừng over-engineer
Reusable
≠
Configurable mọi thứ
Một Chart có 500 options chưa chắc là một Chart tốt.
5. Reusable Chart giúp standardize
20 Services
↓
1 Deployment Standard
thay vì:
20 Services
↓
20 cách deploy
6. Reusable Chart cần versioning
Chart v1
Chart v2
Chart v3
để application có thể upgrade có kiểm soát.
🧠 Mental Model cuối Lab
Nếu sau này bạn được giao:
"Create and maintain reusable Helm charts for internal applications."
Hãy nghĩ:
Company
│
▼
Reusable Helm Chart
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Todo API User API Payment API
│ │ │
└──────────────┼──────────────┘
│
▼
Kubernetes
Chart chịu trách nhiệm:
How application runs
Values chịu trách nhiệm:
What application is being deployed
Và mục tiêu cuối cùng là:
Viết một lần, chuẩn hóa một lần, nhiều application có thể sử dụng — nhưng vẫn đủ linh hoạt để mỗi application có configuration riêng.
Đây chính là phần kiến thức Helm có giá trị thực tế cao hơn việc học thuộc syntax template.
All rights reserved
