Kubernetes Helm Charts 2026: คู่มือการ Packaging, Deployment และคำถามสัมภาษณ์งาน

Kubernetes Helm Charts ช่วยลดความซับซ้อนในการ deploy แอปพลิเคชันโดยการรวม Kubernetes resources ทั้งหมดเป็น artifact เดียวที่มี version กำกับ Helm 3 ซึ่งเป็นเวอร์ชันเสถียรปัจจุบัน ไม่ต้องการ Tiller อีกต่อไปและเพิ่มการรองรับ OCI registry ทำให้การกระจาย chart มีความปลอดภัยและเป็นมาตรฐานมากขึ้น บทความนี้ครอบคลุมการสร้าง chart, templating, กลยุทธ์ deployment และคำถามสัมภาษณ์ที่ทีมรับสมัครถามบ่อยที่สุด

ทำความเข้าใจโครงสร้างและส่วนประกอบของ Helm Chart

Helm chart คือไดเรกทอรีที่มีโครงสร้างที่กำหนดไว้ล่วงหน้า ชื่อ chart จะกลายเป็นชื่อไดเรกทอรี และแต่ละไฟล์มีจุดประสงค์เฉพาะในกระบวนการ packaging และ deployment

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

apiVersion: v2 ระบุว่าเข้ากันได้กับ Helm 3 field version ติดตามการเปลี่ยนแปลงของ chart ในขณะที่ appVersion แสดงเวอร์ชันของแอปพลิเคชันที่ deploy Dependencies ประกาศ charts อื่นที่ chart นี้ต้องการ พร้อมเงื่อนไขเสริมเพื่อเปิดหรือปิดการใช้งาน

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

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

postgresql:
  enabled: true
  auth:
    database: appdb

Values กำหนดการตั้งค่า default ที่ผู้ใช้สามารถ override ได้ระหว่างการติดตั้ง การจัดกลุ่ม values ภายใต้ keys ที่มีความหมายช่วยให้การตั้งค่าเป็นระเบียบและอธิบายตัวเองได้

สร้าง Kubernetes Deployments ด้วย Helm Templates

Helm templates ใช้ Go templating ร่วมกับฟังก์ชัน Sprig เพื่อสร้าง Kubernetes manifests แบบไดนามิก object {{ .Values }} ให้การเข้าถึงเนื้อหา values.yaml ในขณะที่ {{ .Release }} มี metadata ของ deployment

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

ฟังก์ชัน nindent เพิ่ม newline และ indentation ซึ่งสำคัญมากสำหรับการสร้าง YAML ที่ถูกต้อง การใช้ include กับ named templates (กำหนดใน _helpers.tpl) ช่วยให้ templates เป็นไปตามหลัก DRY และดูแลรักษาง่าย

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Helper templates ทำให้ naming conventions และ labels เป็นมาตรฐานในทุก resources ช่วยให้สอดคล้องกับ labels ที่ Kubernetes แนะนำ

Helm Chart Dependencies และ Subcharts

แอปพลิเคชันที่ซับซ้อนมักต้องพึ่งพา databases, caches, หรือ message queues Helm dependencies อนุญาตให้ฝังสิ่งเหล่านี้เป็น subcharts ซึ่งจัดการโดยอัตโนมัติระหว่างการติดตั้ง

# อัปเดต dependencies ก่อน packaging
helm dependency update ./my-application

# Build dependencies (สร้างไดเรกทอรี charts/)
helm dependency build ./my-application

คำสั่ง helm dependency update ดาวน์โหลด dependencies ไปยังไดเรกทอรี charts/ Conditional dependencies ใช้ values เพื่อเปิด/ปิด:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

รูปแบบนี้เปิดใช้งานการตั้งค่าเฉพาะสภาพแวดล้อมที่ production ใช้ managed services ในขณะที่ development ใช้ databases ภายใน cluster

Deploy Helm Charts ด้วย Release Management

Helm ติดตาม deployments เป็น releases ทำให้สามารถ rollback และ upgrade แบบมี version ได้ แต่ละ release เก็บ history สำหรับการตรวจสอบและกู้คืน

# ติดตั้ง chart ด้วย custom values
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Upgrade release ที่มีอยู่
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

flag --atomic ช่วยให้ upgrade ที่ล้มเหลว rollback โดยอัตโนมัติ flag --timeout กำหนดเวลาที่ Helm รอให้ resources พร้อมก่อนประกาศว่าล้มเหลว

# ดู release history
helm history my-release -n production

# Rollback ไปยัง revision ก่อนหน้า
helm rollback my-release 2 -n production

# ถอนการติดตั้ง release
helm uninstall my-release -n production --keep-history

flag --keep-history เก็บรักษาบันทึก release แม้หลังจากถอนการติดตั้งแล้ว ซึ่งมีประโยชน์สำหรับ compliance และ debugging

กลยุทธ์การ Testing และ Validation Helm Chart

การทดสอบ Helm charts ก่อน deployment ช่วยจับข้อผิดพลาด template และปัญหาการตั้งค่าตั้งแต่เนิ่นๆ Helm มีเครื่องมือในตัวสำหรับ linting และ dry-run testing

# Lint chart เพื่อหาข้อผิดพลาดและ best practices
helm lint ./my-application

# Render templates แบบ local โดยไม่ deploy
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run กับ cluster API
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

คำสั่ง helm template render manifests แบบ local ซึ่งมีประโยชน์สำหรับ CI pipelines ที่ตรวจสอบ YAML ที่สร้างขึ้น flag --dry-run ส่ง manifests ไปยัง Kubernetes API server เพื่อ validation โดยไม่สร้าง resources

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Helm hooks ที่มี helm.sh/hook: test จะทำงานหลัง helm test my-release เพื่อตรวจสอบว่า deployment ทำงานถูกต้องหลังการติดตั้ง

เทคนิค Helm Templating ขั้นสูง

Production charts ต้องการ conditional logic, loops, และ data transformation ฟังก์ชัน Sprig ขยาย Go templates ด้วยเครื่องมือสำหรับ string manipulation, encoding, และ flow control

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

ฟังก์ชัน range วนซ้ำผ่าน maps และ lists ฟังก์ชัน b64enc เข้ารหัส base64 ค่าสำหรับ Kubernetes secrets Pipe operators เชื่อมต่อฟังก์ชันเพื่อแปลงข้อมูล

คำถามและคำตอบสัมภาษณ์ Helm Charts

การสัมภาษณ์ทางเทคนิคมักทดสอบความรู้ Helm ผ่านคำถามแนวคิดและปฏิบัติ ส่วนต่อไปนี้ครอบคลุมหัวข้อที่ถูกถามบ่อยที่สุด

ความแตกต่างระหว่าง helm install และ helm upgrade --install คืออะไร?

helm install สร้าง release ใหม่และล้มเหลวถ้า release มีอยู่แล้ว helm upgrade --install (พร้อม flag --install) สร้าง release ใหม่ถ้าไม่มี หรือ upgrade ถ้ามีอยู่แล้ว CI/CD pipelines มักใช้ helm upgrade --install สำหรับ idempotent deployments

จะส่งข้อมูลที่ละเอียดอ่อนไปยัง Helm charts ได้อย่างไร?

มีสามวิธี: external secret managers (Vault, AWS Secrets Manager), ไฟล์ values ที่เข้ารหัส (SOPS, sealed-secrets), หรือ Kubernetes secrets ที่สร้างภายนอก Helm และอ้างอิงใน templates หลีกเลี่ยงการเก็บ secrets ในไฟล์ values.yaml แบบ plain-text ที่ commit ไปยัง version control

Helm hooks คืออะไรและควรใช้เมื่อไหร่?

Hooks ทำงานที่จุดเฉพาะใน lifecycle ของ release: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback, และ test การใช้งานทั่วไปรวมถึง database migrations ก่อน upgrades, ส่ง notifications หลัง deployments, หรือรัน integration tests

จะจัดการ chart versioning ได้อย่างไร?

field version ใน Chart.yaml ติดตามการเปลี่ยนแปลง chart โดยใช้ semantic versioning field appVersion ติดตามเวอร์ชันของแอปพลิเคชันที่ deploy เพิ่ม version สำหรับการแก้ไข chart ทุกครั้ง แม้ว่าเวอร์ชันแอปพลิเคชันจะเหมือนเดิม

จุดประสงค์ของ .helmignore คืออะไร?

คล้ายกับ .gitignore, .helmignore ยกเว้นไฟล์จากการ packaging chart รายการทั่วไปรวมถึง *.tgz (หลีกเลี่ยงการ packaging builds ก่อนหน้า), .git/, เอกสาร *.md ที่ไม่จำเป็นตอน runtime, และไฟล์การตั้งค่า CI

สำหรับการเตรียมสัมภาษณ์ Kubernetes เพิ่มเติม สำรวจโมดูลคำถาม Kubernetes Basics และ Kubernetes Advanced บน SharpSkill

สรุป

ประเด็นปฏิบัติสำหรับการทำงานกับ Helm charts:

• จัดโครงสร้าง charts ด้วยการแยกที่ชัดเจนระหว่าง metadata Chart.yaml, defaults values.yaml, และไดเรกทอรี templates ที่มี Kubernetes manifests
• ใช้ helper templates ใน _helpers.tpl เพื่อทำให้ naming และ labels เป็นมาตรฐานในทุก resources
• จัดการ dependencies ผ่าน Chart.yaml ด้วย conditional enablement สำหรับการตั้งค่าเฉพาะสภาพแวดล้อม
• ทดสอบ charts ด้วย helm lint, helm template, และ helm install --dry-run ก่อน deploy ไปยัง production
• ติดตาม releases ด้วยชื่อที่มีความหมายและใช้ flag --atomic สำหรับ automatic rollback เมื่อ upgrade ล้มเหลว
• เก็บ secrets ใน external managers แทนที่จะเป็นไฟล์ values แบบ plain-text