#Deploy ระบบบน Kubernetes ด้วย Helm

เมื่อระบบเริ่มมี Kubernetes Manifest หลายไฟล์ เช่น Deployment, Service, ConfigMap, Secret, Ingress และทรัพยากรอื่น ๆ การจัดการไฟล์ YAML แบบแยกไฟล์สำหรับ Development, Staging และ Production จะเริ่มซับซ้อนอย่างรวดเร็ว

Helm ช่วยแก้ปัญหานี้โดยทำหน้าที่เป็น Package Manager สำหรับ Kubernetes เราสามารถรวม Kubernetes Manifest ที่เกี่ยวข้องเข้าด้วยกันเป็นแพ็กเกจที่เรียกว่า Chart จากนั้นใช้ values.yaml เพื่อกำหนดค่าที่แตกต่างกันในแต่ละ Environment และจัดการวงจรชีวิตของระบบด้วยคำสั่ง เช่น install, upgrade, rollback และ uninstall

บทความนี้อ้างอิงแนวทางของ Helm 4 โดยตัวอย่างหลักยังใช้ Chart API v2 ซึ่งใช้งานได้ทั่วไปและเหมาะสำหรับ Production ในปัจจุบัน

#1. Helm คืออะไร

ถ้า Kubernetes เปรียบเสมือนระบบปฏิบัติการสำหรับ Container แล้ว Helm ก็มีบทบาทใกล้เคียงกับ apt, dnf, Homebrew หรือ package manager ของระบบปฏิบัติการ

Helm ช่วยให้เราสามารถ:

  • Package Kubernetes resources เป็น Chart
  • Deploy แอปด้วยคำสั่งเดียว
  • ใช้ Chart เดียวกันกับหลาย Environment
  • Override configuration ผ่าน Values
  • Upgrade ระบบโดยไม่ต้องแก้ Manifest ทีละไฟล์
  • เก็บประวัติแต่ละ Release
  • Rollback กลับไปยัง Revision ก่อนหน้า
  • จัดการ Dependency ของระบบ
  • ใช้ร่วมกับ CI/CD และ GitOps

แนวคิดหลักคือ

Kubernetes YAML
      │
      ▼
Helm Templates
      │
      +── values.yaml
      +── values-dev.yaml
      +── values-prod.yaml
      │
      ▼
Helm Release
      │
      ▼
Kubernetes Cluster

#2. คำศัพท์สำคัญของ Helm

#Chart

แพ็กเกจที่รวม Template และ Configuration สำหรับสร้าง Kubernetes resources

ตัวอย่าง:

webapp/
├── Chart.yaml
├── values.yaml
├── values-dev.yaml
├── values-prod.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

#Release

Instance ของ Chart ที่ถูกติดตั้งลงใน Kubernetes

ตัวอย่าง:

helm install webapp-dev ./webapp

webapp-dev คือชื่อ Release

Chart เดียวสามารถติดตั้งได้หลาย Release เช่น

webapp-dev
webapp-staging
webapp-prod

#Values

ค่าที่ส่งเข้าไปใน Template

ตัวอย่าง:

replicaCount: 2

image:
  repository: ghcr.io/example/webapp
  tag: "1.0.0"

แล้วนำไปใช้ใน Template:

replicas: {{ .Values.replicaCount }}

#Repository / OCI Registry

สถานที่จัดเก็บ Helm Chart

ปัจจุบันสามารถเก็บ Chart ใน OCI Registry ได้ เช่น

ghcr.io
Azure Container Registry
Amazon ECR
Google Artifact Registry
Harbor

#3. สิ่งที่ต้องเตรียม

ก่อนใช้งาน Helm ควรมี

  1. Kubernetes Cluster
  2. kubectl
  3. Helm CLI
  4. Container Image ของ Application
  5. สิทธิ์ในการ Deploy resource ลง Cluster

ตรวจสอบ Kubernetes:

kubectl cluster-info

ตรวจสอบ Helm:

helm version

#4. ติดตั้ง Helm

#macOS

brew install helm

#Windows ด้วย Chocolatey

choco install kubernetes-helm

#Windows ด้วย Scoop

scoop install helm

#Linux

บน Distribution ที่รองรับ package manager สามารถติดตั้งผ่าน package manager ได้ หรือดาวน์โหลด binary จาก Helm Release โดยตรง

ตรวจสอบหลังติดตั้ง:

helm version

#5. สร้าง Helm Chart

สร้าง Chart ใหม่:

helm create webapp

Helm จะสร้างโครงสร้างเริ่มต้นให้

webapp/
├── Chart.yaml
├── charts/
├── templates/
├── values.yaml
└── ...

สำหรับการเรียนรู้ เราสามารถลด Chart ให้เหลือไฟล์สำคัญดังนี้

webapp/
├── Chart.yaml
├── values.yaml
├── values-dev.yaml
├── values-prod.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

#6. สร้าง Chart.yaml

ไฟล์ Chart.yaml

apiVersion: v2
name: webapp
description: Helm chart for web application
type: application

version: 0.1.0
appVersion: "1.0.0"

ความหมาย:

Field ความหมาย
apiVersion API ของ Helm Chart
name ชื่อ Chart
description รายละเอียด
type ประเภท Chart
version Version ของ Chart
appVersion Version ของ Application

ควรแยกความหมายของ version กับ appVersion

Chart version = Version ของ deployment package
App version   = Version ของ application

#7. สร้าง values.yaml

ไฟล์ values.yaml ทำหน้าที่เป็นค่า Default ของ Chart

replicaCount: 2

image:
  repository: nginx
  tag: "1.27-alpine"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

containerPort: 80

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

ingress:
  enabled: false
  className: nginx
  host: app.example.com

ข้อดีคือ Kubernetes Manifest ไม่ต้อง hard-code ค่าที่เปลี่ยนแปลงบ่อย

#8. สร้าง Deployment Template

สร้างไฟล์

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app.kubernetes.io/name: {{ .Chart.Name | quote }}
    app.kubernetes.io/instance: {{ .Release.Name | quote }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Chart.Name | quote }}
      app.kubernetes.io/instance: {{ .Release.Name | quote }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .Chart.Name | quote }}
        app.kubernetes.io/instance: {{ .Release.Name | quote }}
    spec:
      containers:
        - name: {{ .Chart.Name | quote }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: {{ .Values.containerPort }}
              protocol: TCP
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

ตัวแปรสำคัญ:

.Values
.Chart
.Release

ตัวอย่าง:

{{ .Values.replicaCount }}
{{ .Chart.Name }}
{{ .Release.Name }}

#9. สร้าง Service Template

สร้าง

templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  labels:
    app.kubernetes.io/name: {{ .Chart.Name | quote }}
    app.kubernetes.io/instance: {{ .Release.Name | quote }}
spec:
  type: {{ .Values.service.type }}
  selector:
    app.kubernetes.io/name: {{ .Chart.Name | quote }}
    app.kubernetes.io/instance: {{ .Release.Name | quote }}
  ports:
    - name: http
      port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP

#10. เพิ่ม Ingress แบบ Optional

สร้าง

templates/ingress.yaml

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Release.Name }}
spec:
  ingressClassName: {{ .Values.ingress.className | quote }}
  rules:
    - host: {{ .Values.ingress.host | quote }}
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: {{ .Release.Name }}
                port:
                  number: {{ .Values.service.port }}
{{- end }}

เปิดใช้งานผ่าน Values:

ingress:
  enabled: true
  className: nginx
  host: app.example.com

Kubernetes ระบุว่า Ingress API ยังคงใช้งานได้ แต่ API ถูก freeze แล้ว และแนะนำให้พิจารณา Gateway API สำหรับระบบใหม่ หาก Infrastructure ของ Cluster รองรับ

#11. แยก Configuration ตาม Environment

จุดแข็งของ Helm คือใช้ Template ชุดเดียว แต่ใช้ Values ต่างกัน

#Development

values-dev.yaml

replicaCount: 1

image:
  repository: ghcr.io/example/webapp
  tag: "dev"

resources:
  requests:
    cpu: 50m
    memory: 64Mi
  limits:
    cpu: 200m
    memory: 128Mi

ingress:
  enabled: true
  className: nginx
  host: dev.example.com

#Production

values-prod.yaml

replicaCount: 3

image:
  repository: ghcr.io/example/webapp
  tag: "1.0.0"

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 512Mi

ingress:
  enabled: true
  className: nginx
  host: app.example.com

ดังนั้น Architecture จะเป็น

                     ┌───────────────────┐
                     │    Helm Chart     │
                     └─────────┬─────────┘
                               │
            ┌──────────────────┼──────────────────┐
            │                  │                  │
            ▼                  ▼                  ▼
     values-dev.yaml   values-staging.yaml values-prod.yaml
            │                  │                  │
            ▼                  ▼                  ▼
       DEV Cluster        STAGING Cluster      PROD Cluster

#12. ตรวจสอบ Chart ก่อน Deploy

ก่อน Deploy จริงควรตรวจสอบ Chart อย่างน้อย 2 ขั้นตอน

#Helm Lint

helm lint ./webapp

ใช้ตรวจสอบโครงสร้าง Chart และข้อผิดพลาดพื้นฐาน

#Render Manifest

helm template webapp ./webapp

หากใช้ Development Values:

helm template webapp ./webapp \
  -f ./webapp/values-dev.yaml

หรือ Render พร้อม Namespace:

helm template webapp ./webapp \
  --namespace webapp-dev \
  -f ./webapp/values-dev.yaml

ข้อดีคือเห็น Kubernetes YAML ที่ Helm สร้างขึ้นก่อนส่งไป Cluster

#13. Deploy ระบบครั้งแรก

Deploy Development:

helm install webapp-dev ./webapp \
  --namespace webapp-dev \
  --create-namespace \
  -f ./webapp/values-dev.yaml

ตรวจสอบ Release:

helm list -n webapp-dev

ตรวจสอบ Kubernetes resources:

kubectl get all -n webapp-dev

ตรวจสอบ Pod:

kubectl get pods -n webapp-dev

ตรวจสอบ Service:

kubectl get svc -n webapp-dev

#14. รูปแบบที่แนะนำ: helm upgrade --install

ในการทำ CI/CD นิยมใช้คำสั่ง

helm upgrade --install webapp-dev ./webapp \
  --namespace webapp-dev \
  --create-namespace \
  -f ./webapp/values-dev.yaml

ข้อดี:

  • ถ้ายังไม่มี Release → Install
  • ถ้ามี Release แล้ว → Upgrade

จึงเหมาะสำหรับ Pipeline เพราะใช้คำสั่งเดียวได้ทั้ง First Deployment และ Deployment รอบถัดไป

#15. รอให้ระบบ Ready และ Rollback เมื่อ Deploy ล้มเหลว

สำหรับ Helm 4 สามารถใช้

helm upgrade --install webapp-prod ./webapp \
  --namespace webapp-prod \
  --create-namespace \
  -f ./webapp/values-prod.yaml \
  --wait \
  --rollback-on-failure \
  --timeout 5m

ความหมาย:

--wait
    รอจน resource พร้อมใช้งาน

--rollback-on-failure
    rollback หาก upgrade ไม่สำเร็จ

--timeout 5m
    กำหนดเวลารอสูงสุด

ใน Helm 4 ชื่อ flag ใหม่คือ

--rollback-on-failure

แทนชื่อเดิม

--atomic

โดย flag เดิมยังมีไว้เพื่อ compatibility แต่ถูก deprecate

#16. Upgrade Application

สมมติเปลี่ยน Image จาก

1.0.0

เป็น

1.1.0

สามารถสั่ง

helm upgrade webapp-prod ./webapp \
  --namespace webapp-prod \
  -f ./webapp/values-prod.yaml \
  --set image.tag=1.1.0 \
  --wait \
  --rollback-on-failure

หรือแก้ไฟล์

image:
  tag: "1.1.0"

แล้วรัน

helm upgrade webapp-prod ./webapp \
  -n webapp-prod \
  -f ./webapp/values-prod.yaml

#17. ตรวจสอบประวัติ Release

helm history webapp-prod -n webapp-prod

ตัวอย่างแนวคิด:

REVISION    STATUS       CHART          APP VERSION
1           superseded   webapp-0.1.0   1.0.0
2           deployed     webapp-0.2.0   1.1.0

ดูสถานะ:

helm status webapp-prod -n webapp-prod

ดู Values ที่ Release ใช้งาน:

helm get values webapp-prod -n webapp-prod

ดู Manifest ที่ถูก Deploy:

helm get manifest webapp-prod -n webapp-prod

#18. Rollback

ถ้า Version ใหม่มีปัญหา

helm rollback webapp-prod 1 \
  -n webapp-prod

ตรวจสอบ:

helm history webapp-prod -n webapp-prod

จุดสำคัญคือ Helm จะเก็บ Revision history ของ Release ทำให้การ rollback ทำได้สะดวกกว่าการแก้ Manifest ด้วยมือ

#19. ลบระบบ

helm uninstall webapp-dev \
  -n webapp-dev

ถ้าต้องการลบ Namespace:

kubectl delete namespace webapp-dev

#20. การ Override Values

Helm รองรับหลายวิธี

#ใช้ values file

helm upgrade --install webapp ./webapp \
  -f values-prod.yaml

#ใช้ --set

helm upgrade --install webapp ./webapp \
  --set replicaCount=4

#ใช้หลาย Values files

helm upgrade --install webapp ./webapp \
  -f values.yaml \
  -f values-prod.yaml \
  -f secrets-prod.yaml

ไฟล์ด้านขวาจะมี priority สูงกว่าเมื่อ key ซ้ำกัน

แนวคิด:

values.yaml
     ↓ override
values-prod.yaml
     ↓ override
--set

#21. Secret ไม่ควรเก็บใน values.yaml แบบ Plain Text

หลีกเลี่ยง

database:
  password: super-secret-password

โดยเฉพาะเมื่อไฟล์ถูก commit เข้า Git

ทางเลือกที่เหมาะกว่า เช่น

  • Kubernetes Secret
  • External Secrets Operator
  • HashiCorp Vault
  • AWS Secrets Manager
  • Azure Key Vault
  • Google Secret Manager
  • Sealed Secrets
  • SOPS

ตัวอย่างอ้าง Secret จาก Deployment:

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: database-secret
        key: password

#22. ConfigMap ด้วย Helm

Values:

config:
  APP_ENV: production
  LOG_LEVEL: info

สร้าง

templates/configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-config
data:
  APP_ENV: {{ .Values.config.APP_ENV | quote }}
  LOG_LEVEL: {{ .Values.config.LOG_LEVEL | quote }}

นำไปใช้:

envFrom:
  - configMapRef:
      name: {{ .Release.Name }}-config

#23. Health Check

Production workload ควรมี readinessProbe และ livenessProbe

Values:

health:
  path: /
  port: 80

Deployment:

readinessProbe:
  httpGet:
    path: {{ .Values.health.path | quote }}
    port: {{ .Values.health.port }}
  initialDelaySeconds: 5
  periodSeconds: 10

livenessProbe:
  httpGet:
    path: {{ .Values.health.path | quote }}
    port: {{ .Values.health.port }}
  initialDelaySeconds: 15
  periodSeconds: 20

ประโยชน์:

  • Pod ที่ยังไม่ Ready จะไม่รับ Traffic
  • Kubernetes ตรวจสอบ Process ที่ไม่ตอบสนองได้
  • helm --wait สามารถประเมิน readiness ของ resource ได้มีประสิทธิภาพขึ้น

#24. Autoscaling

สามารถสร้าง HorizontalPodAutoscaler เป็น Helm Template ได้

ตัวอย่าง Values:

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

แล้วใช้เงื่อนไข:

{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
...
{{- end }}

ทำให้ DEV สามารถปิด Autoscaling แต่ Production เปิดได้ด้วย Chart ชุดเดียว

#25. แนวทาง Versioning

ควร Version ทั้ง Chart และ Application

ตัวอย่าง:

version: 0.4.0
appVersion: "2.1.3"

แนะนำใช้ Semantic Versioning

MAJOR.MINOR.PATCH

ตัวอย่าง:

1.0.0
1.1.0
1.1.1
2.0.0

และหลีกเลี่ยงการ Deploy Production ด้วย Image Tag เช่น

latest
dev
main

ควรใช้ immutable tag เช่น

1.4.2
git-a82d9cf
sha256 digest

#26. Package Helm Chart

สร้าง Package:

helm package ./webapp

จะได้ไฟล์ประมาณ:

webapp-0.1.0.tgz

ตรวจสอบ:

helm show chart webapp-0.1.0.tgz

#27. ใช้ OCI Registry

Login:

helm registry login ghcr.io

Push Chart:

helm push webapp-0.1.0.tgz \
  oci://ghcr.io/example/charts

ติดตั้งจาก OCI:

helm install webapp \
  oci://ghcr.io/example/charts/webapp \
  --version 0.1.0

แนวทางนี้เหมาะเมื่อองค์กรมี Container Registry อยู่แล้วและต้องการเก็บ Container Image กับ Helm Chart ใน Infrastructure เดียวกัน

#28. ใช้ Helm กับ CI/CD

Workflow ทั่วไป:

Developer
    │
    ▼
Git Push
    │
    ▼
CI
├── Unit Test
├── Build Image
├── Security Scan
└── Push Image
    │
    ▼
Helm Lint
    │
    ▼
Helm Template
    │
    ▼
Helm Upgrade --Install
    │
    ▼
Kubernetes
    │
    ▼
Health Check

ตัวอย่างขั้นตอน Deploy:

helm lint ./helm/webapp

helm template webapp ./helm/webapp \
  -f ./helm/webapp/values-prod.yaml \
  --set image.tag="${IMAGE_TAG}"

helm upgrade --install webapp ./helm/webapp \
  --namespace webapp \
  --create-namespace \
  -f ./helm/webapp/values-prod.yaml \
  --set image.tag="${IMAGE_TAG}" \
  --wait \
  --rollback-on-failure \
  --timeout 5m

#29. ตัวอย่าง GitHub Actions

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Helm
        uses: azure/setup-helm@v4

      - name: Helm lint
        run: helm lint ./helm/webapp

      - name: Render chart
        run: |
          helm template webapp ./helm/webapp \
            -f ./helm/webapp/values-prod.yaml

      - name: Deploy
        run: |
          helm upgrade --install webapp ./helm/webapp \
            --namespace webapp \
            --create-namespace \
            -f ./helm/webapp/values-prod.yaml \
            --wait \
            --rollback-on-failure \
            --timeout 5m

ในระบบจริง Kubernetes credentials ควรถูกจัดการด้วยวิธีที่ปลอดภัย เช่น

  • OIDC
  • Workload Identity
  • Cloud IAM
  • Short-lived credentials

หลีกเลี่ยงการเก็บ kubeconfig ระยะยาวเป็น Plain Text Secret หากมีวิธีที่ปลอดภัยกว่า

#30. Helm กับ GitOps

Helm สามารถใช้ร่วมกับ

  • Argo CD
  • Flux CD

Architecture:

Application Repo
      │
      ▼
Build Image
      │
      ▼
Container Registry

GitOps Repo
      │
      ├── Helm Chart
      └── Values
             │
             ▼
        Argo CD / Flux
             │
             ▼
        Kubernetes

ข้อแตกต่างหลักคือ

CI/CD แบบ Push:
Pipeline → Kubernetes

GitOps แบบ Pull:
Git → Argo CD / Flux → Kubernetes

สำหรับ Production ขนาดกลางถึงใหญ่ GitOps ช่วยให้ Desired State ของระบบตรวจสอบย้อนหลังและ Audit ได้ง่ายขึ้น

#31. Best Practices

#1. ใช้ Chart เดียว หลาย Values

ควรใช้:

Chart
├── values-dev.yaml
├── values-staging.yaml
└── values-prod.yaml

แทนการ copy Chart แยกหลายชุดโดยไม่จำเป็น

#2. Run helm lint ทุกครั้ง

helm lint ./webapp

#3. Render ก่อน Deploy

helm template ...

#4. Pin Image Version

ควรใช้:

tag: "1.4.2"

หลีกเลี่ยง:

tag: latest

#5. ใช้ Resource Requests / Limits

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

#6. ใช้ Probes

readinessProbe
livenessProbe
startupProbe

#7. แยก Secret ออกจาก Chart

Chart ควรอ้าง Secret มากกว่าฝังค่า Secret โดยตรง

#8. ใช้ --wait และ --rollback-on-failure ใน Production

--wait
--rollback-on-failure
--timeout 5m

#9. ใช้ quote / toYaml / nindent อย่างเหมาะสม

ค่าที่นำมาแทรกใน YAML ควร render อย่างปลอดภัย

ตัวอย่าง:

name: {{ .Values.name | quote }}

และ Map/List:

{{- toYaml .Values.resources | nindent 12 }}

#10. ตรวจสอบ Release History

helm history RELEASE -n NAMESPACE

#32. คำสั่ง Helm ที่ใช้บ่อย

Command ใช้งาน
helm create สร้าง Chart
helm lint ตรวจ Chart
helm template Render Manifest
helm install ติดตั้ง Release
helm upgrade Upgrade Release
helm upgrade --install Install หรือ Upgrade
helm list ดู Release
helm status ดูสถานะ
helm history ดู Revision
helm rollback Rollback
helm get values ดู Values
helm get manifest ดู Manifest
helm package Package Chart
helm push Push Chart
helm uninstall ถอน Release

#33. Workflow ที่แนะนำสำหรับ Production

1. Developer Push Code
        ↓
2. Run Tests
        ↓
3. Build Container Image
        ↓
4. Scan Image
        ↓
5. Push Image ไป Registry
        ↓
6. helm lint
        ↓
7. helm template
        ↓
8. Deploy ด้วย helm upgrade --install
        ↓
9. --wait
        ↓
10. Health Check / Smoke Test
        ↓
11. Success
        │
        └── หาก Failure → Rollback

คำสั่ง Deploy:

helm upgrade --install webapp ./helm/webapp \
  -n production \
  --create-namespace \
  -f ./helm/webapp/values-prod.yaml \
  --set image.tag="${IMAGE_TAG}" \
  --wait \
  --rollback-on-failure \
  --timeout 5m

#34. Helm Deployment Architecture

                 Git Repository
                       │
                       ▼
               Application Source
                       │
                       ▼
                  CI Pipeline
              ┌────────┴────────┐
              ▼                 ▼
         Build Image        Helm Lint
              │                 │
              ▼                 ▼
      Container Registry   Helm Template
              │                 │
              └────────┬────────┘
                       ▼
              helm upgrade --install
                       │
                       ▼
                Kubernetes API
                       │
       ┌───────────────┼──────────────┐
       ▼               ▼              ▼
   Deployment        Service     Ingress/Gateway
       │
       ▼
      Pods

#35. สรุป

Helm ช่วยยกระดับการ Deploy Kubernetes จากการจัดการ YAML แบบ Manual ไปสู่ระบบ Packaging และ Release Management ที่เป็นระบบมากขึ้น

แก่นสำคัญของ Helm คือ:

Chart
  +
Templates
  +
Values
  =
Release

ถ้าต้อง Deploy ระบบจริง แนวทางที่แนะนำคือ

helm lint

จากนั้น

helm template

และ Deploy ด้วย

helm upgrade --install

พร้อม

--wait
--rollback-on-failure

เมื่อใช้งานร่วมกับ CI/CD, OCI Registry และ GitOps เช่น Argo CD หรือ Flux จะทำให้การ Deploy ระบบ Kubernetes มีความสามารถด้าน Versioning, Reproducibility, Auditability และ Rollback ที่ดีขึ้นอย่างมาก

#References