ArgoCD และ GitOps สำหรับ Kubernetes: คู่มือฉบับสมบูรณ์และคำถามสัมภาษณ์งาน 2026

ในยุคที่การพัฒนาซอฟต์แวร์มุ่งเน้นความเร็วและความน่าเชื่อถือ การนำ GitOps มาใช้ในการจัดการ Kubernetes กลายเป็นมาตรฐานที่องค์กรชั้นนำทั่วโลกให้ความสำคัญ ArgoCD เป็นเครื่องมือ Continuous Deployment แบบ declarative ที่ได้รับความนิยมสูงสุดในระบบนิเวศ Kubernetes โดยช่วยให้ทีม DevOps สามารถจัดการการ deploy แอปพลิเคชันได้อย่างมีประสิทธิภาพ ตรวจสอบได้ และย้อนกลับได้ง่ายเมื่อเกิดปัญหา บทความนี้จะอธิบายหลักการทำงานของ ArgoCD และ GitOps อย่างละเอียด พร้อมตัวอย่างการใช้งานจริงและคำถามสัมภาษณ์งานที่พบบ่อยในปี 2026

หลักการทำงานของ ArgoCD

ArgoCD ทำงานโดยการเปรียบเทียบสถานะที่กำหนดไว้ใน Git repository กับสถานะปัจจุบันของ Kubernetes cluster อย่างต่อเนื่อง เมื่อพบความแตกต่าง ArgoCD จะแจ้งเตือนหรือทำการ sync โดยอัตโนมัติตามการตั้งค่าที่กำหนด กระบวนการนี้เรียกว่า reconciliation loop ซึ่งทำงานทุก 3 นาทีโดยค่าเริ่มต้น

การตั้งค่า Application ใน ArgoCD ทำได้โดยการสร้าง Custom Resource ดังตัวอย่างต่อไปนี้:

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true

จากตัวอย่างข้างต้น การตั้งค่า automated พร้อมกับ prune: true และ selfHeal: true จะทำให้ ArgoCD ดำเนินการต่อไปนี้โดยอัตโนมัติ: ลบ resource ที่ถูกลบออกจาก Git และแก้ไขการเปลี่ยนแปลงที่ทำด้วยมือใน cluster ให้กลับไปตรงกับ Git

การจัดโครงสร้าง Repository สำหรับ GitOps

การจัดโครงสร้าง repository อย่างเหมาะสมเป็นปัจจัยสำคัญต่อความสำเร็จของการนำ GitOps มาใช้ การแยก configuration repository ออกจาก application source code เป็นแนวปฏิบัติที่แนะนำ เนื่องจากช่วยให้สามารถจัดการ permissions และ review process ได้อย่างเหมาะสม

# Recommended repository structure
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml

โครงสร้างแบบนี้ใช้ประโยชน์จาก Kustomize ในการจัดการความแตกต่างระหว่าง environment โดย base directory จะเก็บ configuration หลักที่ใช้ร่วมกัน ส่วน overlays จะเก็บการปรับแต่งเฉพาะแต่ละ environment

Sync Waves และ Hooks

ในการ deploy แอปพลิเคชันที่ซับซ้อน มักจะต้องการควบคุมลำดับการ deploy ของ resource ต่างๆ ArgoCD รองรับ Sync Waves ซึ่งช่วยให้สามารถกำหนดลำดับการ deploy ได้อย่างยืดหยุ่น resource ที่มีค่า wave ต่ำกว่าจะถูก deploy ก่อน

ตัวอย่างการใช้ Sync Wave สำหรับ database migration:

# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

การใช้ sync-wave: "-1" ร่วมกับ hook: PreSync จะทำให้ migration job รันก่อน resource อื่นๆ ที่มี wave เป็น 0 หรือสูงกว่า และ hook-delete-policy: HookSucceeded จะลบ Job หลังจากทำงานสำเร็จ

ApplicationSet สำหรับ Multi-Cluster Deployment

สำหรับองค์กรที่มีหลาย Kubernetes cluster ApplicationSet เป็นทางออกที่ช่วยลดความซ้ำซ้อนในการจัดการ Applications จำนวนมาก โดยสามารถสร้าง Application หลายตัวจาก template เดียว

# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ApplicationSet ในตัวอย่างนี้จะสร้าง Application สำหรับทุก cluster ที่มี label env: production โดยอัตโนมัติ และใช้ path ที่แตกต่างกันตาม region ของแต่ละ cluster

เปรียบเทียบ ArgoCD กับ Flux

ในตลาด GitOps tools มี 2 ตัวเลือกหลักที่ได้รับความนิยม คือ ArgoCD และ Flux การเลือกใช้ขึ้นอยู่กับความต้องการขององค์กร ตารางต่อไปนี้แสดงการเปรียบเทียบคุณสมบัติหลัก:

| Feature | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architecture | Centralized server with UI | Distributed controllers per cluster | | Web UI | Built-in, polished dashboard | No built-in UI (third-party options) | | Helm support | Renders templates server-side | Native Helm SDK integration | | Multi-cluster | Hub-and-spoke from single instance | Independent installation per cluster | | RBAC | Application-level with SSO | Kubernetes-native RBAC only | | Image automation | Separate Image Updater component | Built-in image reflector/automation | | Progressive delivery | Argo Rollouts integration | Flagger integration | | Resource footprint | Higher (API server, repo server, Redis) | Lower (only needed controllers) |

ArgoCD เหมาะสำหรับทีมที่ต้องการ UI ที่ใช้งานง่ายและการจัดการ multi-cluster แบบรวมศูนย์ ในขณะที่ Flux เหมาะสำหรับทีมที่ต้องการ lightweight solution และใช้ Kubernetes-native approach

ฟีเจอร์ใหม่ใน ArgoCD 3.4

ArgoCD 3.4 นำเสนอฟีเจอร์ใหม่หลายอย่างที่ช่วยเพิ่มประสิทธิภาพการทำงาน หนึ่งในนั้นคือ Helm Value Globs ที่ช่วยลดความยุ่งยากในการจัดการ value files หลายไฟล์:

# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml

นอกจากนี้ยังมีความสามารถในการหยุด reconciliation ชั่วคราวสำหรับ cluster เฉพาะ ซึ่งมีประโยชน์ในการทำ maintenance หรือ troubleshooting:

# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }

แนวทางปฏิบัติที่ดีสำหรับ Production

การนำ ArgoCD ไปใช้ใน production environment ควรพิจารณาแนวทางปฏิบัติต่อไปนี้:

การแยก Configuration Repository: การแยก config repo ออกจาก application code repo ช่วยให้สามารถจัดการ access control ได้ดีขึ้น และป้องกันไม่ให้ developer ที่ไม่มีสิทธิ์สามารถแก้ไข production configuration ได้

การใช้ Sealed Secrets หรือ External Secrets: ไม่ควรเก็บ secrets ใน Git โดยตรง แม้จะเป็น private repository ก็ตาม การใช้ Sealed Secrets หรือ External Secrets Operator ช่วยให้สามารถจัดการ secrets อย่างปลอดภัย

การตั้งค่า Resource Limits: ArgoCD components ควรมีการตั้งค่า resource requests และ limits อย่างเหมาะสม โดยเฉพาะ repo-server ที่อาจใช้ memory มากเมื่อทำงานกับ repository ขนาดใหญ่

การตั้งค่า High Availability: สำหรับ production ควรติดตั้ง ArgoCD ในโหมด HA ที่มีหลาย replica และใช้ Redis cluster สำหรับ caching

คำถามสัมภาษณ์งานที่พบบ่อย

คำถาม: อธิบายความแตกต่างระหว่าง Push-based และ Pull-based deployment

Push-based deployment เป็นรูปแบบดั้งเดิมที่ CI/CD pipeline จะ push การเปลี่ยนแปลงไปยัง cluster โดยตรง ซึ่งต้องการ credentials ที่สามารถเข้าถึง cluster ได้ ในขณะที่ Pull-based deployment ที่ ArgoCD ใช้ จะมี agent อยู่ใน cluster ทำหน้าที่ดึงการเปลี่ยนแปลงจาก Git เข้ามา ซึ่งมีความปลอดภัยมากกว่าเนื่องจาก cluster credentials ไม่ต้องอยู่นอก cluster

คำถาม: Sync Wave ใช้เพื่อแก้ปัญหาอะไร

Sync Wave ใช้เพื่อควบคุมลำดับการ deploy ของ resources ที่มี dependencies ต่อกัน เช่น database migration ต้องรันก่อน application deployment หรือ ConfigMap ต้องถูกสร้างก่อน Pod ที่ใช้งาน

คำถาม: Self-heal ใน ArgoCD ทำงานอย่างไร และควรใช้เมื่อใด

Self-heal จะทำให้ ArgoCD แก้ไขการเปลี่ยนแปลงที่ทำด้วยมือใน cluster ให้กลับไปตรงกับ Git โดยอัตโนมัติ ควรใช้ใน production environment เพื่อป้องกัน configuration drift แต่อาจไม่เหมาะสำหรับ development environment ที่ต้องการความยืดหยุ่นในการทดลอง

คำถาม: อธิบายวิธีจัดการ secrets ใน GitOps workflow

มีหลายวิธีในการจัดการ secrets ได้แก่ Sealed Secrets ที่เข้ารหัส secrets ให้สามารถเก็บใน Git ได้อย่างปลอดภัย, External Secrets Operator ที่ดึง secrets จาก external provider เช่น AWS Secrets Manager หรือ HashiCorp Vault, และ ArgoCD Vault Plugin ที่ดึง secrets ตอน render manifests

คำถาม: ApplicationSet generators มีประเภทอะไรบ้าง

ApplicationSet รองรับ generators หลายประเภท ได้แก่ List generator สำหรับรายการที่กำหนดไว้ล่วงหน้า, Cluster generator สำหรับสร้าง Application ต่อ cluster, Git generator สำหรับสร้างจาก directories หรือ files ใน Git, Matrix และ Merge generators สำหรับรวม generators หลายตัว

บทสรุป

ArgoCD และ GitOps ได้เปลี่ยนแปลงวิธีการจัดการ Kubernetes deployments อย่างมีนัยสำคัญ โดยนำหลักการของ Infrastructure as Code และ declarative configuration มาใช้ในการ deploy แอปพลิเคชัน ประโยชน์หลักที่ได้รับจากการนำ ArgoCD มาใช้ ได้แก่:

• ความสามารถในการตรวจสอบ: ทุกการเปลี่ยนแปลงถูกบันทึกใน Git history
• ความสามารถในการย้อนกลับ: สามารถ rollback ได้ง่ายด้วย git revert
• ความสอดคล้อง: สถานะของ cluster จะตรงกับ Git เสมอด้วย self-heal
• ความปลอดภัย: Pull-based model ไม่ต้องเปิดเผย cluster credentials
• การทำงานร่วมกัน: การเปลี่ยนแปลงผ่าน Pull Request ช่วยให้ทีมทำ code review ได้

การเรียนรู้ ArgoCD และหลักการ GitOps เป็นทักษะที่จำเป็นสำหรับ DevOps Engineer และ Platform Engineer ในปัจจุบัน การเข้าใจแนวคิดเหล่านี้อย่างลึกซึ้งจะช่วยให้สามารถออกแบบและจัดการระบบ Kubernetes ได้อย่างมีประสิทธิภาพและปลอดภัย