เปรียบเทียบ Push-based vs Pull-based Deployment ทำไม Argo CD เลือกแบบ Pull

Categories

Push-based vs Pull-based Deployment คืออะไร

ในโลกของ DevOps และ Container Orchestration การ Deploy Application ไปยัง Kubernetes Cluster มีสองแบบหลักที่ต้องเข้าใจความแตกต่างกัน คือ Push-based Deployment และ Pull-based Deployment แต่ละแบบมีข้อดีและข้อเสียที่ส่งผลต่อความปลอดภัย ประสิทธิภาพ และความน่าเชื่อถือของระบบ

Argo CD เป็น GitOps Tool ที่ได้รับความนิยมในปัจจุบัน และได้เลือกใช้ Pull-based Deployment Model เป็นวิธีการหลัก ซึ่งเป็นการตัดสินใจที่มีหลักการทางสถาปัตยกรรมอย่างชัดเจน บทความนี้จะอธิบายความแตกต่างและเหตุผลในการเลือกแบบ Pull-based

Push-based Deployment คืออะไร

นิยามและแนวคิด

Push-based Deployment เป็นรูปแบบการ Deploy ที่ระบบ CI/CD เป็นผู้ Push Code หรือ Docker Image ไปยัง Kubernetes Cluster โดยตรง เมื่อมีการเปลี่ยนแปลงใน Repository

วิธีการทำงาน:

  • Developer Commit Code ไปยัง Git Repository
  • CI/CD Pipeline (เช่น Jenkins, GitLab CI, GitHub Actions) ตรวจพบการเปลี่ยนแปลง
  • Pipeline Build Docker Image และ Push ไปยัง Container Registry
  • CI/CD Pipeline ส่ง Command ไปยัง Kubernetes API Server เพื่อสั่ง Deploy
  • Kubernetes Cluster เปลี่ยนสถานะ Resource ตามคำสั่ง

ข้อดีของ Push-based Deployment

  • การ Deploy ทันที: ไม่ต้องรอให้ Argo CD Poll Repository ผลลัพธ์คือ Deployment เกิดขึ้นทันทีเมื่อ CI/CD สั่งการ
  • ความเรียบง่าย: สำหรับทีมที่คุ้นเคยกับ CI/CD แบบดั้งเดิม เข้าใจวิธีการทำงานได้ง่าย
  • การควบคุมเต็มที่: CI/CD Pipeline มีการควบคุมโดยตรงต่อการ Deploy

ข้อเสียและปัญหาของ Push-based Deployment

  • ความปลอดภัยน้อยกว่า: Cluster Credentials ต้องเก็บไว้ใน CI/CD System ซึ่งเป็นจุดอ่อนสำหรับการโจมตี
  • ไม่มี Self-healing: ถ้ามีการเปลี่ยนการตั้งค่า Cluster โดยตรง (Manual Change) ระบบจะไม่รู้และไม่แก้ไข
  • ไม่มี Single Source of Truth: Repository ไม่ได้สะท้อนสถานะจริงของ Cluster ทำให้ยากต่อการ Audit และ Troubleshooting
  • Credential Management ยุ่งยาก: ต้องจัดการ Kubernetes API Access Token ในหลาย CI/CD System
  • ปัญหาด้าน Network: Cluster ต้องเปิด API Server ให้ CI/CD เข้าถึงได้จากภายนอก

Pull-based Deployment (GitOps Model) คืออะไร

นิยามและแนวคิด

Pull-based Deployment หรือที่รู้จักกันในชื่อ GitOps Model เป็นรูปแบบการ Deploy ที่ตัว Agent ภายใน Cluster เป็นผู้ Pull Configuration จาก Git Repository อย่างต่อเนื่อง

วิธีการทำงาน:

  • Developer Commit Configuration ไปยัง Git Repository
  • Argo CD Controller ภายใน Kubernetes Poll Git Repository เป็นระยะ (Default: 3 นาที)
  • Argo CD เปรียบเทียบสถานะใน Repository กับสถานะจริงใน Cluster
  • ถ้าพบความแตกต่าง Argo CD จะ Update Cluster ให้ตรงกับ Repository
  • ไม่มีการส่ง Credentials ออกไปยัง CI/CD System ภายนอก

ข้อดีของ Pull-based Deployment

  • ความปลอดภัยสูงขึ้น: Cluster Credentials ยังคงอยู่ภายใน Cluster เท่านั้น ไม่ต้อง Expose ไปยัง CI/CD System ภายนอก
  • Single Source of Truth: Git Repository เป็นแหล่งข้อมูลเดียวที่ถูกต้อง ทุกสิ่งที่ควรมีใน Cluster ต้องอยู่ใน Repository
  • Self-healing: Argo CD ตรวจจับ Drift (ความแตกต่าง) ระหว่าง Repository กับ Cluster โดยอัตโนมัติ และแก้ไขให้สอดคล้องกัน
  • Audit Trail: ทุก Change มี Git Commit History ทำให้สามารถติดตามการเปลี่ยนแปลงได้อย่างชัดเจน
  • Permission Management ง่ายขึ้น: ไม่ต้องจัดการ Kubernetes API Credentials ในหลาย System
  • Network Flexibility: Cluster ไม่ต้องเปิด API ให้ CI/CD เข้าถึง ทำให้ปลอดภัยมากขึ้น
  • Rollback ง่าย: Rollback เป็นเพียงการ Revert Git Commit ทำได้อย่างรวดเร็วและปลอดภัย

ข้อเสียของ Pull-based Deployment

  • Deployment ไม่ทันที: Argo CD ต้อง Poll Repository ทุก 3 นาที (ตั้งค่าได้) ทำให้ Deployment อาจล่าช้าเล็กน้อย
  • ต้องตั้งค่า Webhook: เพื่อให้ Argo CD ตอบสนองทันทีเมื่อมี Commit ใหม่ ต้องตั้งค่า Webhook เพิ่มเติม
  • ต้องติดตั้ง Tool เพิ่มเติม: ต้องติดตั้ง Argo CD ในระบบ Kubernetes

ตารางเปรียบเทียบ Push-based vs Pull-based Deployment

เกณฑ์ประเมิน Push-based Pull-based (Argo CD)
ความปลอดภัย ต่ำกว่า (Credentials อยู่ใน CI/CD) สูงกว่า (Credentials อยู่ใน Cluster)
ความเร็ว Deploy ทันที ล่าช้า 3 นาที (ใช้ Webhook ได้ทันที)
Self-healing ไม่มี มี (ตรวจจับและแก้ไข Drift อัตโนมัติ)
Single Source of Truth ไม่มี มี (Git Repository)
Audit Trail ยากต่อการติดตาม ชัดเจน (Git History)
Rollback ต้องสั่ง CI/CD ใหม่ Revert Git Commit
Network Requirement ต้องเปิด Cluster API ไม่ต้องเปิด Cluster API
ความซับซ้อน ต่ำ ปานกลาง (ต้องติดตั้ง Argo CD)

ทำไม Argo CD เลือก Pull-based Model

หลักการพื้นฐานของ GitOps

Argo CD ถูกออกแบบมาตั้งแต่แรกด้วยปรัชญา GitOps ซึ่งกำหนดว่า Git Repository ควรเป็น Single Source of Truth สำหรับสถานะของระบบทั้งหมด การเลือก Pull-based Model สะท้อนหลักการนี้โดยตรง

ข้อดีด้านการออกแบบระบบ

  • Declarative Configuration: Configuration อยู่ในรูปแบบ YAML Manifest ที่อธิบายสถานะที่ต้องการ (Desired State) ได้ชัดเจน
  • Immutability: Git Commit เป็น Immutable Record ไม่สามารถเปลี่ยนแปลงได้โดยไม่มี Trace
  • Traceability: สามารถติดตามการเปลี่ยนแปลงทั้งหมดผ่าน Git Log
  • Scalability: ในสถาปัตยกรรมที่มี Cluster หลายตัว การ Pull Configuration จาก Repository เดียวทำให้จัดการได้ง่าย

ความปลอดภัยเป็นสิ่งสำคัญที่สุด

ในยุคปัจจุบันที่ Security เป็นเรื่องสำคัญขององค์กร Pull-based Model ให้ความปลอดภัยที่ดีกว่าอย่างชัดเจน:

  • Cluster Credentials ไม่ต้องเปิดเผยให้ CI/CD System หรือบุคคลภายนอก
  • Cluster สามารถทำงานใน Network แบบปิด (Private Network) ได้
  • ลด Attack Surface ด้วยการไม่ต้อง Expose API Credentials

Self-healing และ Drift Detection ของ Argo CD

Drift Detection คืออะไร

Drift Detection คือการตรวจหาความแตกต่าง (Drift) ระหว่างสถานะที่กำหนดใน Git Repository กับสถานะจริงใน Kubernetes Cluster

ตัวอย่างเหตุการณ์ที่ทำให้เกิด Drift:

  • Admin ใช้ kubectl edit เปลี่ยน Configuration โดยตรง
  • Manual Scaling จำนวน Pod Replica
  • เปลี่ยน Environment Variable ผ่าน Dashboard Tool
  • Image ในระบบถูกเปลี่ยนโดยไม่ได้บันทึกลง Git

Self-healing ทำงานอย่างไร

Argo CD ตรวจหา Drift และแก้ไขโดยอัตโนมัติตามขั้นตอนนี้:

  1. Argo CD Controller ทำการ Poll Git Repository ตามระยะเวลาที่กำหนด
  2. ดึง Configuration ล่าสุดจาก Repository
  3. เปรียบเทียบกับสถานะปัจจุบันใน Cluster
  4. ถ้าพบความแตกต่าง จะ Apply Configuration จาก Repository ให้ Cluster
  5. Cluster กลับมาสู่สถานะที่ต้องการ (Desired State)

กระบวนการนี้เรียกว่า Continuous Reconciliation ซึ่ง Argo CD ทำการประสานสถานะของระบบอย่างต่อเนื่อง

การใช้ Pull-based Deployment บน ผู้ให้บริการโฮสติ้ง Cloud VPS

สำหรับผู้ใช้งาน ผู้ให้บริการโฮสติ้ง Cloud VPS การใช้ Argo CD กับ Pull-based Model มีข้อดีที่ชัดเจน:

  • ความปลอดภัยสูง: Kubernetes Cluster บน Cloud VPS ไม่ต้อง Expose API ให้ภายนอก
  • ติดตั้งได้ง่าย: Argo CD สามารถติดตั้งได้ง่ายบน Kubernetes Cluster ที่รันบน Cloud VPS
  • Resource Efficient: Argo CD ใช้ Resource น้อยเมื่อเทียบกับการรัน CI/CD Agent ทั้งตัว
  • Compliance Ready: Git History ช่วยให้เป็นไปตามข้อกำหนด Compliance ได้

Best Practices สำหรับ Pull-based Deployment

  • ตั้งค่า Sync Policy ให้เหมาะสม: ใช้ Manual Sync สำหรับ Production และ Auto Sync สำหรับ Development
  • ใช้ Webhook: ตั้งค่า Webhook จาก Git Provider เพื่อลด Latency ในการ Deploy
  • จัดระเบียบ Repository: ใช้ Kustomize หรือ Helm เพื่อจัดการ Multiple Environments
  • ตั้งค่า RBAC: กำหนดสิทธิ์ของ Argo CD ให้เหมาะสมตามหลัก Least Privilege
  • ตั้งค่า Monitoring: ใช้ Prometheus และ Grafana ตรวจสอบสถานะ Argo CD

สรุป

Push-based Deployment เป็นรูปแบบที่ CI/CD Push Code ไปยัง Cluster โดยตรง ขณะที่ Pull-based Deployment เป็นรูปแบบที่ Cluster Pull Configuration จาก Git Repository Argo CD เลือก Pull-based Model เพราะข้อดีด้านความปลอดภัย Self-healing Drift Detection และ Audit Trail ที่ชัดเจน

สำหรับผู้ใช้งาน ผู้ให้บริการโฮสติ้ง Cloud VPS การใช้ Argo CD ร่วมกับ Pull-based Model เป็นทางเลือกที่ตอบโจทย์ทั้งด้านประสิทธิภาพและความปลอดภัย เริ่มต้นใช้งาน Argo CD บน Cloud VPS ของ ผู้ให้บริการโฮสติ้ง ได้ที่ de.co.th/cloud-vps