vi
new
0
Avatar
Thống PM @Juu-dev
1.3K 75 160
Đã đăng vào Thứ Bảy, 6:41 SA 8 phút đọc
12

Lab 5 — Helm Debugging

🎯 Mục tiêu

Sau Lab này, bạn sẽ:

  • Biết cách debug một Helm Chart trước khi deploy.
  • Biết phân biệt lỗi của Helm và lỗi của Kubernetes.
  • Biết sử dụng helm lint, helm template, helm install --dry-run và helm get.
  • Biết cách tìm nguyên nhân khi helm install hoặc helm upgrade thất bại.
  • Hình thành workflow debugging có thể áp dụng khi review Chart do AI tạo.

Mục tiêu của Lab này không phải học thuộc hàng chục command.

Chỉ cần nhớ:

Helm có render đúng không?
         ↓
Kubernetes có nhận YAML không?
         ↓
Resource có chạy đúng không?

Đây là 3 tầng debugging quan trọng nhất.

1. 🤔 Vấn đề thực tế

Bạn nhận được một Helm Chart từ đồng nghiệp hoặc AI.

Chạy:

helm upgrade --install todo-app ./todo-app

và nhận:

Error: UPGRADE FAILED

Hoặc Helm báo thành công:

STATUS: deployed

nhưng application lại:

Pod: CrashLoopBackOff

😵

Vậy lỗi nằm ở đâu?

Helm?
   ↓
Template?
   ↓
Kubernetes?
   ↓
Deployment?
   ↓
Container?
   ↓
Application?

Nếu không có workflow rõ ràng, bạn rất dễ:

Sửa YAML
   ↓
Deploy
   ↓
Lỗi
   ↓
Sửa tiếp
   ↓
Deploy
   ↓
Lỗi

Đây là cách debug rất tốn thời gian.

2. 🧠 Hiểu nhanh

Khi Helm deploy application, có thể hình dung:

values.yaml
     │
     ▼
Helm Template
     │
     ▼
Rendered YAML
     │
     ▼
Kubernetes API
     │
     ▼
Kubernetes Resources
     │
     ▼
Pod
     │
     ▼
Application

Mỗi tầng có một loại lỗi khác nhau.

Tầng 1 — Helm

Template syntax
Values
Missing value
Invalid template

Tầng 2 — Kubernetes

Invalid YAML
Invalid resource
Invalid field

Tầng 3 — Application

Image lỗi
Config sai
Port sai
Application crash

3. 🏗️ Debugging Architecture

                 Helm Chart
                     │
                     ▼
              ┌─────────────┐
              │ helm lint   │
              └──────┬──────┘
                     │
                     ▼
              ┌─────────────┐
              │ helm        │
              │ template    │
              └──────┬──────┘
                     │
                     ▼
             Rendered YAML
                     │
                     ▼
              Kubernetes API
                     │
                     ▼
              ┌─────────────┐
              │ Deployment  │
              │ Service     │
              │ ConfigMap   │
              │ Ingress     │
              └──────┬──────┘
                     │
                     ▼
                   Pods
                     │
                     ▼
                Application

Debug từ trên xuống dưới.

Đừng nhảy thẳng vào Pod nếu chưa biết Helm đã render đúng chưa.

4. 🧪 Chuẩn bị Lab

Tạo Chart:

helm create debug-lab
cd debug-lab

Kiểm tra:

helm lint .

Nếu thành công:

1 chart(s) linted, 0 chart(s) failed

5. 🔍 Bước 1 — helm lint

Tại sao cần?

Trước khi deploy, chúng ta muốn phát hiện những lỗi cơ bản trong Chart.

helm lint .

Helm sẽ kiểm tra một số vấn đề liên quan đến Chart và template.

Mental model:

Chart
  │
  ▼
helm lint
  │
  ├── OK
  │
  └── Problem

Khi nào dùng?

Luôn chạy trước khi commit hoặc deploy.

Đây là một trong những command nên trở thành habit.

6. 🧪 Bước 2 — helm template

Đây là command quan trọng nhất trong Lab này.

helm template debug-lab .

Nó render Helm Template thành Kubernetes YAML nhưng không deploy.

values.yaml
     │
     ▼
templates/
     │
     ▼
helm template
     │
     ▼
Kubernetes YAML

Tại sao cực kỳ hữu ích?

Giả sử Template có:

replicas: {{ .Values.replicaCount }}

và Values:

replicaCount: 3

Bạn có thể xác nhận:

replicas: 3

trước khi Kubernetes nhìn thấy nó.

7. 🧪 Thực hành — Tìm lỗi bằng Render

Trong values.yaml, thử thay:

replicaCount: 3

thành:

replicaCount: 5

Chạy:

helm template debug-lab .

Tìm:

replicas: 5

Understand

Nếu output không đúng:

Helm Template / Values
        ↑
      Lỗi ở đây

Chưa cần debug Kubernetes.

8. 🧪 Bước 3 — Render với Environment

Giả sử có:

values-dev.yaml
values-prod.yaml

Chạy:

helm template debug-lab . \
  -f values-prod.yaml

Đây là cách rất tốt để kiểm tra:

"Production values thực sự tạo ra YAML như thế nào?"

Ví dụ:

replicaCount: 5

Bạn cần nhìn output:

spec:
  replicas: 5

chứ không chỉ nhìn file values-prod.yaml.

9. 🔥 Một kỹ năng cực kỳ quan trọng: --debug

Khi template có vấn đề:

helm template debug-lab . \
  --debug

--debug cung cấp thêm thông tin để xác định Helm đang xử lý Chart như thế nào.

Mental model:

helm template
      ↓
Rendered output

helm template --debug
      ↓
Rendered output
+
Debug information

Không cần nhớ chi tiết output.

Chỉ cần biết:

Có vấn đề → thêm --debug.

10. 🧪 Bước 4 — Dry Run

Sau khi render ổn:

helm install debug-lab . \
  --dry-run \
  --debug

Điểm khác:

helm template
      ↓
Render Template

helm install --dry-run
      ↓
Mô phỏng quá trình install

Bạn có thể kiểm tra:

Values
Templates
Rendered resources

mà chưa thực sự tạo Release.

11. 🧠 Helm Error vs Kubernetes Error

Đây là phần rất quan trọng.

Case 1 — Helm Template lỗi

Ví dụ:

replicas: {{ .Values.replicaCount

Thiếu }}.

Khi chạy:

helm template debug-lab .

đã lỗi.

=> Helm problem

helm template
     X

Case 2 — Helm render được nhưng Kubernetes không chấp nhận

Ví dụ YAML render thành:

apiVersion: apps/v1
kind: Deployment

spec:
  replicas: 3
  unknownField: abc

Helm có thể render được.

Nhưng Kubernetes có thể reject resource.

Flow:

Helm
  │
  │ OK
  ▼
Rendered YAML
  │
  │ X
  ▼
Kubernetes API

=> Kubernetes problem

Case 3 — Kubernetes accept nhưng Application crash

Ví dụ:

Helm
  ↓
OK

Kubernetes
  ↓
OK

Pod
  ↓
CrashLoopBackOff

=> Không còn là lỗi Helm nữa.

Đây là:

Application / Container problem

12. 🧪 Bước 5 — Deploy thật

Sau khi render ổn:

helm upgrade --install debug-lab .

Kiểm tra:

helm list

Bạn sẽ thấy:

NAME        STATUS
debug-lab   deployed

Nhưng:

STATUS: deployed không có nghĩa application chắc chắn đang hoạt động đúng.

Đây là một misconception rất hay gặp.

13. 🔍 Bước 6 — Kiểm tra Release

helm status debug-lab

Bạn có thể xem:

Release
Revision
Status
Resources
Notes

Ví dụ:

STATUS: deployed
REVISION: 1

Mental model:

helm status
     ↓
Release-level information

Nó trả lời:

Helm nghĩ Release đang ở trạng thái nào?

Nhưng chưa trả lời:

Application có thực sự chạy không?

14. 🔍 Bước 7 — Xem Values thực tế

Đây là command rất hữu ích:

helm get values debug-lab

Nếu muốn xem toàn bộ:

helm get values debug-lab --all

Tại sao cần?

Giả sử bạn nghĩ:

replicaCount = 5

nhưng production đang chạy:

replicaCount = 3

Đừng đoán.

Kiểm tra:

helm get values debug-lab --all

15. 🔍 Bước 8 — Xem Manifest thực tế

Một command cực kỳ hữu ích:

helm get manifest debug-lab

Nó cho bạn Kubernetes manifest mà Helm đã generate cho Release.

Mental model:

Chart
  ↓
Helm
  ↓
Manifest
  ↓
Kubernetes

Khi debugging production:

helm get manifest <release>

giúp trả lời:

"Helm thực sự đã deploy YAML gì?"

Điều này rất khác với việc bạn chỉ nhìn file trong Git.

16. 🔄 helm history

Helm Release có revision.

Kiểm tra:

helm history debug-lab

Ví dụ:

REVISION   STATUS
1          deployed
2          deployed
3          failed

Điều này rất hữu ích khi:

Upgrade
   ↓
Application lỗi

Bạn có thể biết:

Lỗi bắt đầu từ revision nào?

17. 🧪 Scenario — Upgrade bị lỗi

Giả sử:

helm upgrade debug-lab .

kết quả:

Error: UPGRADE FAILED

Đừng lập tức sửa random.

Hãy kiểm tra:

helm history debug-lab

Sau đó:

helm status debug-lab

và:

helm get manifest debug-lab

Bạn muốn xác định:

Upgrade
   │
   ▼
Revision mới
   │
   ▼
Resource nào thay đổi?
   │
   ▼
Resource nào lỗi?

18. 🔙 Rollback

Nếu revision trước đang chạy tốt:

helm rollback debug-lab 1

Sau đó:

helm status debug-lab

Kiểm tra:

helm history debug-lab

Production mindset

Rollback không phải:

"Tôi không biết lỗi gì nên rollback."

Mà nên là:

New version
     ↓
Production problem
     ↓
Stop impact
     ↓
Rollback
     ↓
Investigate root cause

Rollback là cách giảm thời gian application bị lỗi, không thay thế việc tìm root cause.

19. 🧩 Debug Kubernetes Resource

Nếu Helm đã deploy:

kubectl get pods

Ví dụ:

todo-api-7d8f9c   CrashLoopBackOff

Bây giờ không nên tiếp tục debug Helm syntax.

Chuyển sang Kubernetes:

kubectl describe pod <pod>

và:

kubectl logs <pod>

Nếu container restart:

kubectl logs <pod> --previous

Mental model:

Helm
 ↓
OK

Kubernetes
 ↓
Pod created

Pod
 ↓
CrashLoopBackOff
        ↓
kubectl logs
kubectl describe

20. 🔍 Debug theo Resource Chain

Một application thường có:

Ingress
   ↓
Service
   ↓
Deployment
   ↓
Pod
   ↓
Container

Khi request không hoạt động:

Bước 1

kubectl get ingress

Bước 2

kubectl get svc

Bước 3

kubectl get deployment

Bước 4

kubectl get pods

Bước 5

kubectl logs <pod>

Bạn đang đi theo request path:

User
 ↓
Ingress
 ↓
Service
 ↓
Pod
 ↓
Application

Điều này hiệu quả hơn việc chạy hàng chục command ngẫu nhiên.

21. 🚨 Scenario thực tế 1 — Pod không chạy

Bạn chạy:

helm status todo-app

Kết quả:

STATUS: deployed

Nhưng:

kubectl get pods

cho:

todo-api-xxx   CrashLoopBackOff

Workflow:

kubectl describe pod todo-api-xxx

Sau đó:

kubectl logs todo-api-xxx

Có thể thấy:

connection refused

hoặc:

Missing environment variable DATABASE_URL

Kết luận

Helm có thể hoàn toàn không có lỗi.

Chart đã được deploy.

Application configuration mới là vấn đề.

22. 🚨 Scenario thực tế 2 — Service không có traffic

Pod:

Running

Service:

Created

Nhưng request:

Connection refused

Kiểm tra:

kubectl get endpoints

Nếu Service không có endpoint:

Service
   │
   X
   │
 No Pod

Kiểm tra selector:

kubectl describe svc <service>

và label của Pod:

kubectl get pods --show-labels

Đây là lỗi rất hay gặp khi Helm template:

Service selector
        ≠
Pod labels

23. 🚨 Scenario thực tế 3 — AI tạo Chart sai

AI tạo:

service:
  port: 80
  targetPort: 3000

nhưng container thực tế:

Application listening on 8080

Helm vẫn:

deployed

Kubernetes vẫn:

Pod Running

nhưng:

Request
   ↓
Service :80
   ↓
Pod :3000
   X
App :8080

Cách debug

Không nhìn Helm trước.

Kiểm tra:

kubectl describe svc <service>

và:

kubectl describe pod <pod>

Sau đó kiểm tra application đang listen port nào.

Đây là lý do bạn cần hiểu Kubernetes behavior chứ không chỉ hiểu Helm syntax.

24. 🧠 Helm Debugging Workflow

Đây là workflow nên ghi nhớ:

              Helm Chart
                  │
                  ▼
            ┌───────────┐
            │ helm lint │
            └─────┬─────┘
                  │
                  ▼
          ┌────────────────┐
          │ helm template  │
          └───────┬────────┘
                  │
                  ▼
           Rendered YAML
                  │
             Is it correct?
                  │
          ┌───────┴───────┐
          │               │
         NO              YES
          │               │
          ▼               ▼
       Fix Chart      Dry Run
                          │
                          ▼
                     Helm Deploy
                          │
                          ▼
                   helm status
                          │
                          ▼
                    Kubernetes
                          │
                          ▼
                    kubectl get
                          │
                          ▼
                  Pod / Service
                          │
                          ▼
                 logs / describe

25. 🤖 Workflow khi Review Chart do AI tạo

Đây là workflow đặc biệt hữu ích với cách làm việc hiện nay.

AI đưa cho bạn:

Helm Chart

Đừng:

AI output
   ↓
helm install

Hãy:

AI output
   ↓
helm lint
   ↓
helm template
   ↓
Review rendered YAML
   ↓
helm install --dry-run --debug
   ↓
Deploy
   ↓
kubectl get pods

Bạn không cần tự viết toàn bộ Chart.

Bạn cần biết kiểm tra AI đã tạo gì.

26. 🧪 Bài tập thực hành

Exercise 1 — Render trước khi Deploy

Chạy:

helm lint .

Sau đó:

helm template debug-lab .

Xác nhận Deployment, Service được render đúng.

Exercise 2 — Production Values

Tạo:

values-prod.yaml

Ví dụ:

replicaCount: 3

image:
  tag: "1.0.0"

Render:

helm template debug-lab . \
  -f values-prod.yaml

Kiểm tra:

replicas: 3

và image đúng version.

Exercise 3 — Dry Run

Chạy:

helm install debug-lab . \
  --dry-run \
  --debug

Quan sát:

Values
Templates
Rendered resources

Exercise 4 — Release Investigation

Deploy:

helm upgrade --install debug-lab .

Sau đó:

helm status debug-lab

helm get values debug-lab --all

helm get manifest debug-lab

Exercise 5 — History & Rollback

Thay đổi:

replicaCount: 1

upgrade:

helm upgrade debug-lab .

Sau đó đổi:

replicaCount: 3

upgrade lần nữa:

helm upgrade debug-lab .

Kiểm tra:

helm history debug-lab

Thử rollback revision trước:

helm rollback debug-lab 1

Kiểm tra:

kubectl get deployment

27. 🎯 Tổng kết

Bạn không cần nhớ 20 command Helm.

Chỉ cần nhớ nhóm command này:

Validate

helm lint .

Chart có vấn đề cơ bản không?

Render

helm template <name> .

Helm thực sự generate YAML gì?

Dry Run

helm install <name> . --dry-run --debug

Nếu deploy thì chuyện gì sẽ xảy ra?

Release

helm status <release>

Release đang ở trạng thái nào?

Values

helm get values <release> --all

Release đang sử dụng configuration nào?

Manifest

helm get manifest <release>

Helm đã deploy những resource nào?

History

helm history <release>

Các revision trước đó thế nào?

Rollback

helm rollback <release> <revision>

Quay về version trước.

🧠 Mental Model cuối Lab

Khi Helm có vấn đề, đừng hỏi ngay:

"Command nào để fix?"

Hãy hỏi:

"Lỗi đang nằm ở tầng nào?"

┌─────────────────────────────┐
│         Helm Chart          │
│   values + templates        │
└──────────────┬──────────────┘
               │
          helm lint
               │
               ▼
┌─────────────────────────────┐
│       Rendered YAML         │
└──────────────┬──────────────┘
               │
         helm template
               │
               ▼
┌─────────────────────────────┐
│       Kubernetes API        │
└──────────────┬──────────────┘
               │
          kubectl
               │
               ▼
┌─────────────────────────────┐
│       Pod / Service         │
└──────────────┬──────────────┘
               │
          logs / describe
               │
               ▼
┌─────────────────────────────┐
│        Application           │
└─────────────────────────────┘

Chỉ cần nhớ một câu:

Render trước → Review → Deploy → Kiểm tra Kubernetes → Debug Application.

Đây là kỹ năng Helm thực tế quan trọng hơn việc thuộc syntax Template.

📝 Checklist

Khi nhận một Helm Chart mới, hãy tự hỏi:

□ helm lint có pass không?

□ helm template có tạo YAML đúng không?

□ values-prod.yaml có render đúng không?

□ Image đúng version chưa?

□ Replica đúng chưa?

□ Resources đã có chưa?

□ Service port / targetPort có đúng không?

□ ConfigMap / Secret có đúng không?

□ Ingress có đúng host không?

□ Pod có Running không?

□ Service có endpoint không?

□ Application có log lỗi không?

Nếu bạn có thể đi qua checklist này một cách tự nhiên, bạn đã có nền tảng debugging Helm đủ tốt để review và vận hành Chart trong thực tế, kể cả khi phần lớn Chart được AI hỗ trợ tạo ra.

Helm Debugging

All rights reserved

Mục lục


Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí