Kustomize Overlay Best Practices ที่ต้องรู้
Kustomize Overlay Best Practices ที่ต้องรู้
Kustomize เป็น Kubernetes native configuration management tool ที่ใช้ overlay pattern แก้ไข YAML manifests โดยไม่ต้องใช้ templates เหมือน Helm ถูก built-in ใน kubectl ตั้งแต่ v1.14 ทำให้ไม่ต้องติดตั้งเพิ่ม Overlay คือการซ้อน configuration patches บน base manifests เพื่อสร้าง environment-specific configs (dev, staging, production) โดยไม่ duplicate YAML บทความนี้อธิบาย best practices สำหรับ Kustomize overlays พร้อมตัวอย่าง Python automation tools
FAQ - คำถามที่พบบ่อย
Q: Kustomize กับ Helm อันไหนดีกว่า?
A: Kustomize: ง่ายกว่า, built-in kubectl, ไม่ต้อง template language — ดีสำหรับ simple overlays Helm: powerful กว่า, charts ecosystem ใหญ่, template logic — ดีสำหรับ complex apps + reusable packages ใช้ Kustomize: internal apps ที่ต้องการ env-specific configs ใช้ Helm: third-party apps (nginx, prometheus), complex templating รวมกัน: Helm render → Kustomize post-process (ดีที่สุด)
Q: Strategic Merge Patch กับ JSON Patch ต่างกันอย่างไร?
A: Strategic Merge Patch: YAML format เหมือน resource เดิม — ง่าย อ่านง่าย เหมาะ patch ส่วนใหญ่ JSON Patch: array ของ operations (add, remove, replace) — ละเอียดกว่า เหมาะ arrays ใช้ Strategic Merge Patch: 90% ของกรณี — เขียนง่าย อ่านง่าย ใช้ JSON Patch: เมื่อต้อง manipulate arrays (เช่น เพิ่ม container, volume)
Q: Components ใน Kustomize คืออะไร?
A: Components = reusable Kustomize configs ที่ overlay ไหนัก็ include ได้ ต่างจาก base: base เป็น required dependency, component เป็น optional feature ตัวอย่าง: component/monitoring (ServiceMonitor), component/ingress (Ingress), component/autoscaling (HPA) ใช้: components: [../../components/monitoring] ใน kustomization.yaml
Q: CI/CD กับ Kustomize ทำยังไง?
A: GitOps (แนะนำ): ArgoCD/Flux watch Git repo → auto-sync เมื่อ kustomization.yaml เปลี่ยน Pipeline: CI build image → kustomize edit set image → commit → ArgoCD sync Validation: kustomize build | kubeconform → validate ก่อน merge PR Diff: kustomize build | kubectl diff → review changes ก่อน apply
