Helm Chart คืออะไร Deploy K8s App ง่ายๆ

Helm Chart คืออะไร? Deploy Kubernetes Application อย่างง่ายดาย

พื้นฐานความรู้เกี่ยวกับ Helm และ Kubernetes

Kubernetes คืออะไร? ทำไมต้องใช้?

Helm คืออะไร? ทำไมถึงเรียกว่า Package Manager?

Chart คืออะไร? โครงสร้าง Chart เป็นอย่างไร?

my-chart/
  ├── Chart.yaml          # ข้อมูลเกี่ยวกับ Chart
  ├── values.yaml         # ค่า Default สำหรับ Template
  └── templates/          # Template ของ Kubernetes Manifest
      ├── deployment.yaml
      ├── service.yaml
      └── ...

🎬 YouTube @icafefx

วิธีการติดตั้งและใช้งาน Helm Chart

การติดตั้ง Helm

    brew install helm
    

    # Debian/Ubuntu
    sudo apt update
    sudo apt install helm

    # CentOS/RHEL
    sudo yum install helm
    

    # Chocolatey
    choco install kubernetes-helm

    # Scoop
    scoop install helm
    

helm version

    helm repo add bitnami https://charts.bitnami.com/bitnami
    helm repo update
    

    helm search repo mysql
    

    helm install my-mysql bitnami/mysql
    

    helm list
    

    helm uninstall my-mysql
    

"Helm Chart เป็นเครื่องมือที่ช่วยให้การ Deploy Application บน Kubernetes ง่ายขึ้นมากๆ ลองใช้ดูแล้วชีวิตจะง่ายขึ้นเยอะเลยครับ!"

เทคนิคขั้นสูง / Configuration

การใช้ Template Functions

resources:
  requests:
    cpu: "{{ if eq .Values.environment "production" }}1{{ else }}0.5{{ end }}"
    memory: "{{ if eq .Values.environment "production" }}2Gi{{ else }}1Gi{{ end }}"
  limits:
    cpu: "{{ if eq .Values.environment "production" }}2{{ else }}1{{ end }}"
    memory: "{{ if eq .Values.environment "production" }}4Gi{{ else }}2Gi{{ end }}"

การใช้ Subchart และ Dependencies

dependencies:
  - name: postgresql
    version: "12.0.0"
    repository: "https://charts.bitnami.com/bitnami"

การใช้ Hooks สำหรับ Lifecycle Management

apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ .Release.Name }}-migration"
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      containers:
        - name: migration
          image: your-migration-image:latest
          command: ["./migrate"]
      restartPolicy: Never

ตัวอย่าง Configuration จริง: Ingress Controller

controller:
  replicaCount: 2
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:YOUR_ACCOUNT_ID:certificate/YOUR_CERTIFICATE_ID
  config:
    worker-processes: "2"

เปรียบเทียบ

Helm vs. Kustomize

Helm vs. Operator

ข้อควรระวัง Troubleshooting

"การ Deploy แอปพลิเคชันด้วย Helm ไม่ได้หมายความว่าจะไม่มีปัญหาเสมอไป การทำความเข้าใจข้อผิดพลาดที่อาจเกิดขึ้น และรู้วิธีแก้ไข จะช่วยให้เราใช้งาน Helm ได้อย่างมีประสิทธิภาพมากยิ่งขึ้น"

ตัวอย่างจากประสบการณ์ 20 ปี

เครื่องมือแนะนำ

Lens

# ตัวอย่างการใช้งาน Lens เพื่อดู Release ที่ Deploy ผ่าน Helm
# (ใน Lens GUI จะแสดงข้อมูล Release, Chart, Version, Status อย่างละเอียด)

ChartMuseum

# ตัวอย่างการเพิ่ม ChartMuseum Repository ลงใน Helm
helm repo add chartmuseum http://chartmuseum.example.com:8080

# ตัวอย่างการ Upload Chart ขึ้นไปเก็บไว้ใน ChartMuseum
helm push my-chart-0.1.0 chartmuseum

Argo CD

# ตัวอย่างการสร้าง Application ใน Argo CD ที่ Deploy Helm Chart จาก Git Repository
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  destination:
    namespace: my-namespace
    server: https://kubernetes.default.svc
  source:
    path: helm/my-chart
    repoURL: https://github.com/my-org/my-repo.git
    targetRevision: HEAD
    helm:
      valueFiles:
        - values.yaml
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Case Study ประสบการณ์จริง

FAQ คำถามที่พบบ่อย

Helm Chart เหมาะกับโปรเจกต์ขนาดไหน?

จำเป็นต้องมีความรู้เรื่อง Kubernetes มากแค่ไหนถึงจะใช้ Helm Chart ได้?

Helm Chart ปลอดภัยหรือไม่? มีความเสี่ยงด้าน Security อะไรบ้าง?

Helm Chart กับ Kustomize ต่างกันอย่างไร? ควรเลือกใช้แบบไหนดี?

จะ Update Helm Chart ที่ Deploy ไปแล้วได้อย่างไร?

# ตัวอย่างการ Upgrade Release โดยเปลี่ยน Chart Version
helm upgrade my-release my-chart --version 0.2.0

# ตัวอย่างการ Upgrade Release โดยเปลี่ยนค่า Config
helm upgrade my-release my-chart --set image.tag=latest

มี Best Practices อะไรบ้างในการสร้าง Helm Chart?

สรุป

Tips จากประสบการณ์ 20 ปี

Tip 1: เข้าใจ Lifecycle ของ Helm Chart อย่างลึกซึ้ง

หลายคนมักมองข้ามเรื่อง lifecycle ของ Helm chart ซึ่งเป็นเรื่องสำคัญมากครับ! การเข้าใจว่า chart ของเราจะถูกสร้าง, ติดตั้ง, อัปเกรด, และลบออกอย่างไร จะช่วยให้เราออกแบบ chart ได้อย่างมีประสิทธิภาพมากขึ้นเยอะเลย ลองคิดดูว่าถ้าเราเขียน chart แบบไม่คิดถึงตอน uninstall จะเกิดอะไรขึ้น? อาจจะมี resource ค้างเติ่งอยู่ใน cluster เต็มไปหมดก็ได้นะ

ผมเคยเจอปัญหาตอนปี 2020 ที่บริษัทเก่า คือเรา deploy application ด้วย Helm chart ที่ไม่ได้ออกแบบมาให้ handle การอัปเกรดได้ดี พอเราอัปเกรด chart ปุ๊บ กลายเป็นว่า database connection string ใน application config ไม่ update ตาม ทำให้ application ใช้งานไม่ได้ ต้องมานั่งแก้ config เองทีละ pod วุ่นวายไปหมด ตอนนั้นเข็ดเลยครับ หลังจากนั้นมา ผมจะเน้นย้ำทีมเสมอว่า ต้องออกแบบ chart ให้รองรับการอัปเกรดและการ rollback ได้อย่างราบรื่น

ดังนั้น สิ่งที่ควรทำคือการใส่ใจในเรื่องของ hooks ครับ Helm hooks ช่วยให้เราสามารถรัน commands ต่างๆ ในช่วงเวลาที่กำหนด เช่น ก่อนการติดตั้ง, หลังการติดตั้ง, ก่อนการอัปเกรด, หรือก่อนการลบออก ซึ่ง hooks เหล่านี้แหละที่จะช่วยให้เราจัดการ lifecycle ของ application ได้อย่างละเอียดและปลอดภัยมากขึ้น

# Example: pre-install hook
apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ .Release.Name }}-pre-install-job"
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "5"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: pre-install
        image: busybox:latest
        command: ["/bin/sh", "-c", "echo 'Running pre-install job...'"]

Tip 2: ใช้ Dependencies อย่างชาญฉลาด

Helm chart dependencies คือ chart ที่ถูกเรียกใช้จาก chart หลักของเรา พูดง่ายๆ คือ chart ย่อยๆ ที่ช่วยให้เราไม่ต้องเขียนทุกอย่างเองตั้งแต่ต้น การใช้ dependencies เป็นเรื่องที่ดี แต่ต้องใช้อย่างระมัดระวังนะครับ ไม่งั้นอาจจะเจอปัญหา dependencies hell ได้

สิ่งที่ผมแนะนำคือ ให้พิจารณา dependencies ที่จำเป็นจริงๆ เท่านั้น อย่าใส่ dependencies ที่ไม่ได้ใช้ หรือใช้แค่บางส่วน เพราะมันจะทำให้ chart ของเราซับซ้อนและยากต่อการ maintain มากขึ้น นอกจากนี้ ควรกำหนด version ของ dependencies ให้ชัดเจน เพื่อป้องกันปัญหา compatibility ในอนาคต

อีกเรื่องที่สำคัญคือการจัดการ dependencies repository ครับ Helm สามารถดึง dependencies จากหลาย repository ได้ แต่เราต้องมั่นใจว่า repository เหล่านั้นเชื่อถือได้ และมีการ maintain อย่างสม่ำเสมอ ไม่เช่นนั้นอาจจะเจอปัญหา dependencies ไม่พร้อมใช้งาน หรือมี security vulnerability ได้

# Example: dependencies in Chart.yaml
dependencies:
- name: postgresql
  version: "10.x.x"
  repository: "https://charts.bitnami.com/bitnami"

Tip 3: Configurable Values คือหัวใจ

Values คือตัวแปรที่เราใช้ใน Helm chart เพื่อกำหนดค่าต่างๆ ให้กับ template ของเรา การออกแบบ values ที่ดี จะช่วยให้ chart ของเรามีความยืดหยุ่นและสามารถปรับแต่งได้ตามต้องการ

ผมแนะนำให้เริ่มต้นด้วยการกำหนด values ที่สำคัญและจำเป็นสำหรับการใช้งาน chart ของเราก่อน จากนั้นค่อยๆ เพิ่ม values อื่นๆ ตามความต้องการ อย่าพยายามใส่ทุกอย่างเป็น values ตั้งแต่แรก เพราะมันจะทำให้ chart ของเราซับซ้อนและยากต่อการใช้งาน

อีกเรื่องที่สำคัญคือการใส่ default values ให้กับ values ของเรา Default values จะช่วยให้ผู้ใช้งานไม่ต้องกำหนดค่าทุกอย่างเองตั้งแต่ต้น และยังช่วยป้องกันปัญหา values ที่ไม่ได้กำหนดค่า ซึ่งอาจจะทำให้ application ทำงานผิดพลาดได้

# Example: values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: latest
  pullPolicy: IfNotPresent

Tip 4: Testing, Testing, และ Testing!

การทดสอบ Helm chart เป็นเรื่องที่สำคัญมากๆ ครับ! ก่อนที่จะ deploy chart ของเราใน production environment เราควรทดสอบให้แน่ใจว่า chart ของเราทำงานได้อย่างถูกต้องและไม่มีปัญหา

ผมแนะนำให้ใช้เครื่องมือเช่น helm lint และ helm template เพื่อตรวจสอบ syntax และโครงสร้างของ chart ของเรา นอกจากนี้ เรายังสามารถใช้เครื่องมือเช่น kubeval เพื่อตรวจสอบว่า resources ที่ถูกสร้างขึ้นจาก chart ของเราถูกต้องตาม Kubernetes schema หรือไม่

นอกจากนี้ เราควรทดสอบ chart ของเราใน environment ที่ใกล้เคียงกับ production environment มากที่สุด เพื่อให้แน่ใจว่า chart ของเราทำงานได้อย่างถูกต้องในสภาพแวดล้อมจริง

# Example: helm lint
helm lint my-chart
# Example: helm template
helm template my-chart .

Tip 5: Secrets Management อย่างมืออาชีพ

การจัดการ secrets เป็นเรื่องที่ละเอียดอ่อนและสำคัญมากครับ! เราไม่ควรเก็บ secrets ไว้ใน plain text ใน chart ของเรา เพราะมันจะทำให้ secrets ของเรามีความเสี่ยงที่จะถูกเปิดเผย

ผมแนะนำให้ใช้เครื่องมือเช่น Kubernetes Secrets หรือ HashiCorp Vault เพื่อจัดการ secrets ของเราอย่างปลอดภัย เครื่องมือเหล่านี้จะช่วยให้เราเก็บ secrets ไว้ในที่ที่ปลอดภัย และสามารถดึง secrets มาใช้ใน application ของเราได้อย่างง่ายดาย

นอกจากนี้ เราควรหมุนเวียน secrets ของเราอย่างสม่ำเสมอ เพื่อลดความเสี่ยงหาก secrets ของเราถูก compromise

# Example: Kubernetes Secret
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: $(echo -n 'admin' | base64)
  password: $(echo -n 'password123' | base64)

Tip 6: Documentation คือเพื่อนที่ดีที่สุด

การทำ documentation ที่ดีเป็นเรื่องที่สำคัญมากๆ ครับ! Documentation จะช่วยให้ผู้ใช้งานเข้าใจวิธีการใช้งาน chart ของเรา และยังช่วยให้เรา maintain chart ของเราได้ง่ายขึ้นในอนาคต

ผมแนะนำให้ใส่ documentation ที่อธิบายถึงวัตถุประสงค์ของ chart ของเรา, values ที่สำคัญ, วิธีการปรับแต่ง chart, และข้อควรระวังต่างๆ นอกจากนี้ เรายังสามารถใส่ตัวอย่างการใช้งาน chart เพื่อให้ผู้ใช้งานเข้าใจได้ง่ายขึ้น

Documentation ที่ดีควรจะถูกเก็บไว้ใน repository เดียวกับ chart ของเรา และควรจะถูก update ทุกครั้งที่มีการเปลี่ยนแปลง chart

Tip 7: Monitor และ Alert อย่างสม่ำเสมอ

การ monitor และ alert เป็นเรื่องที่สำคัญมากๆ ครับ! เราควร monitor application ที่ถูก deploy ด้วย Helm chart ของเราอย่างสม่ำเสมอ เพื่อให้แน่ใจว่า application ของเราทำงานได้อย่างถูกต้องและไม่มีปัญหา

ผมแนะนำให้ใช้เครื่องมือเช่น Prometheus และ Grafana เพื่อ monitor metrics ต่างๆ ของ application ของเรา นอกจากนี้ เรายังสามารถใช้เครื่องมือเช่น Alertmanager เพื่อตั้งค่า alerts เมื่อมีปัญหาเกิดขึ้น

การ monitor และ alert จะช่วยให้เราตรวจจับปัญหาได้ตั้งแต่เนิ่นๆ และสามารถแก้ไขปัญหาได้อย่างรวดเร็ว ก่อนที่มันจะส่งผลกระทบต่อผู้ใช้งาน

Tip 8: เรียนรู้จาก Community

Community ของ Helm นั้นแข็งแกร่งมากครับ! มีผู้ใช้งานและผู้พัฒนามากมายที่พร้อมจะแบ่งปันความรู้และประสบการณ์

ผมแนะนำให้เข้าร่วม community ของ Helm, อ่าน blogs และ articles ต่างๆ, และเข้าร่วม conferences และ meetups ที่เกี่ยวข้องกับ Helm การเรียนรู้จาก community จะช่วยให้เราพัฒนา skills ของเราและเรียนรู้เทคนิคใหม่ๆ ในการใช้งาน Helm

นอกจากนี้ เรายังสามารถ contribute กลับไปยัง community โดยการเขียน blogs, สร้าง charts, หรือช่วยตอบคำถามใน forums ต่างๆ การ contribute กลับไปยัง community จะช่วยให้เราเป็นส่วนหนึ่งของ community และยังช่วยให้เราเรียนรู้ได้มากขึ้นอีกด้วย

FAQ เพิ่มเติม

FAQ 1: Helm Chart กับ Operator ต่างกันอย่างไร?

หลายคนสับสนระหว่าง Helm Chart กับ Kubernetes Operator นะครับ ทั้งสองอย่างมีเป้าหมายเดียวกันคือช่วยให้เรา deploy และ manage application บน Kubernetes ได้ง่ายขึ้น แต่มีวิธีการทำงานที่แตกต่างกันครับ

Helm Chart เป็นเหมือน package manager สำหรับ Kubernetes ช่วยให้เรา package, distribute, และ deploy application ได้อย่างง่ายดาย โดย Helm จะใช้ template และ values เพื่อสร้าง Kubernetes resources ต่างๆ เช่น Deployments, Services, และ ConfigMaps

ส่วน Kubernetes Operator เป็น controller ที่ extends Kubernetes API เพื่อจัดการ lifecycle ของ application อย่างอัตโนมัติ Operator จะ monitor application และทำการ action ต่างๆ เช่น scale up, scale down, หรือ restart เมื่อมีปัญหาเกิดขึ้น

พูดง่ายๆ คือ Helm Chart เหมาะสำหรับการ deploy application ในขณะที่ Operator เหมาะสำหรับการ manage application ในระยะยาว Operator จะมีความซับซ้อนกว่า Helm Chart แต่ก็มีความยืดหยุ่นและสามารถปรับแต่งได้มากกว่า

FAQ 2: Helm Chart เหมาะกับ Application ประเภทไหน?

Helm Chart เหมาะกับ application หลากหลายประเภทเลยครับ ตั้งแต่ application ขนาดเล็กไปจนถึง application ขนาดใหญ่และซับซ้อน แต่โดยทั่วไปแล้ว Helm Chart จะเหมาะกับ application ที่มี dependencies หลายอย่าง หรือต้องการการปรับแต่งที่ยืดหยุ่น

ตัวอย่าง application ที่เหมาะกับการใช้ Helm Chart ได้แก่: Databases (เช่น PostgreSQL, MySQL), Message queues (เช่น RabbitMQ, Kafka), Web applications (เช่น WordPress, Drupal), และ Microservices

นอกจากนี้ Helm Chart ยังเหมาะกับการ deploy application ในหลาย environment เช่น development, staging, และ production โดยเราสามารถใช้ values ที่แตกต่างกันเพื่อปรับแต่ง application ให้เหมาะสมกับแต่ละ environment

FAQ 3: จะ migrate จาก Manifests ธรรมดา มาเป็น Helm Chart ได้อย่างไร?

การ migrate จาก Kubernetes manifests ธรรมดา มาเป็น Helm Chart อาจจะดูยุ่งยากในตอนแรก แต่จริงๆ แล้วไม่ยากอย่างที่คิดครับ สิ่งที่เราต้องทำคือการแปลง manifests ของเราให้เป็น Helm templates และกำหนด values ที่เหมาะสม

ขั้นตอนการ migrate:

1. สร้าง Helm chart ใหม่โดยใช้ command helm create
2. Copy manifests ของเราไปยัง directory templates ใน chart ของเรา
3. แปลง manifests ของเราให้เป็น Helm templates โดยการใส่ variables และ functions ต่างๆ
4. กำหนด values ที่เหมาะสมในไฟล์ values.yaml
5. ทดสอบ chart ของเราโดยใช้ command helm template และ helm install

เครื่องมือเช่น kustomize สามารถช่วยให้เราจัดการ manifests ของเราได้ง่ายขึ้นก่อนที่จะ migrate มาเป็น Helm Chart

FAQ 4: มี Best Practices อะไรบ้างในการสร้าง Helm Chart?

แน่นอนครับ มี best practices หลายอย่างที่เราควรปฏิบัติตามในการสร้าง Helm Chart เพื่อให้ chart ของเรามีคุณภาพและใช้งานได้ง่าย

Best practices ที่สำคัญ:

• ใช้ meaningful names สำหรับ resources และ values
• ใส่ comments ที่อธิบายถึงวัตถุประสงค์ของ resources และ values
• ใช้ functions และ helpers อย่างชาญฉลาดเพื่อลดความซับซ้อนของ templates
• ทดสอบ chart ของเราอย่างสม่ำเสมอ
• ทำ documentation ที่ดี
• เก็บ secrets ไว้ในที่ที่ปลอดภัย
• Monitor application ที่ถูก deploy ด้วย chart ของเราอย่างสม่ำเสมอ

การปฏิบัติตาม best practices เหล่านี้จะช่วยให้เราสร้าง Helm Chart ที่มีคุณภาพและใช้งานได้ง่าย ซึ่งจะช่วยให้เรา deploy และ manage application บน Kubernetes ได้อย่างมีประสิทธิภาพ