Development

Crossplane คืออะไร? คู่มือ Kubernetes Universal Control Plane สำหรับ SME ไทย 2026

Crossplane คือ Open Source Framework ที่เปลี่ยน Kubernetes ให้เป็น Universal Control Plane สำหรับจัดการ Cloud Infrastructure ข้าม Provider ด้วย YAML + GitOps — ทางเลือกแทน Terraform สำหรับทีม DevOps ยุคใหม่

AF
ADS FIT Team
·8 นาที
Share:

# Crossplane คืออะไร? คู่มือ Kubernetes Universal Control Plane สำหรับ SME ไทย 2026

ทีม DevOps ที่ดูแลโครงสร้างพื้นฐานหลายคลาวด์พร้อมกัน มักพบปัญหาเดียวกัน คือเครื่องมือ IaC แบบเดิมอย่าง Terraform ต้องใช้ State File แยก, CI/CD Pipeline ซับซ้อน และยากที่จะบังคับ Policy ให้สม่ำเสมอ เมื่อทีมเติบโตขึ้น การจัดการ Resource ข้าม AWS, GCP, Azure ก็กลายเป็นคอขวด

Crossplane คือคำตอบของปัญหานี้ มันเปลี่ยน Kubernetes ให้กลายเป็น Universal Control Plane สำหรับจัดการทุกอย่าง — ตั้งแต่ VM, Database, Bucket, ไปจนถึง SaaS API — โดยใช้ YAML, GitOps และ Kubernetes Reconciliation Loop เดิมที่ทีมคุ้นเคยอยู่แล้ว

ในคู่มือนี้ คุณจะได้เรียนรู้ว่า Crossplane ทำงานอย่างไร, เมื่อไหร่ควรเลือกใช้แทน Terraform, โครงสร้าง Composition v2 ล่าสุด, และขั้นตอน Hands-on ติดตั้งใช้งานจริงสำหรับทีม SME ไทยในปี 2026

Crossplane คืออะไร และทำไมถึงต่างจาก Terraform

Crossplane เป็น CNCF Graduated Project ที่ขยาย Kubernetes API ด้วย Custom Resource Definition (CRD) ให้สามารถสร้างและจัดการทรัพยากรภายนอก Cluster ได้ เช่น RDS Instance, S3 Bucket, GKE Cluster, Cloudflare DNS โดย Operator จะทำหน้าที่ Reconcile สถานะปลายทางให้ตรงกับ Desired State ใน Git ตลอดเวลา

แตกต่างจาก Terraform ที่ต้องรัน `terraform apply` แล้วจบไป Crossplane ทำงานแบบ Continuous Reconciliation — ถ้ามีใครไปแก้ Resource ผ่านหน้าเว็บ Cloud Console, Controller จะดึงกลับให้ตรงกับ Manifest ใน Cluster อัตโนมัติ ทำให้เกิด Configuration Drift ได้ยาก

| ประเด็น | Crossplane | Terraform |

|---------|-----------|-----------|

| โมเดลการทำงาน | Continuous Reconciliation | Imperative Apply |

| State Storage | etcd ใน Kubernetes | State File (S3 / Cloud) |

| Drift Detection | อัตโนมัติทุก Sync Loop | ต้องรัน `plan` เอง |

| GitOps Native | รองรับ ArgoCD / Flux ทันที | ต้องใช้ Atlantis / TACO |

| Composition | XRD + Composition v2 | Module |

| Team Self-Service | สูง (API-first) | ปานกลาง |

สถาปัตยกรรมหลัก — Provider, XR, Composition

Crossplane แบ่งชั้นการทำงานเป็น 3 ส่วนที่ PM และ Developer ควรเข้าใจ

  • Provider: Plugin ที่ห่อ API ของ Cloud แต่ละเจ้า เช่น `provider-upjet-aws`, `provider-gcp`, `provider-azure`, `provider-kubernetes` ติดตั้งได้แบบ Helm หรือ `kubectl apply`
  • Managed Resource (MR): CRD ตัวเล็กที่ Map 1:1 กับทรัพยากรของคลาวด์ เช่น `Bucket`, `RDSInstance`, `Subnet` ทีมปลายทางมักไม่ได้ใช้ตรงๆ เพราะมี Field เยอะเกินไป
  • Composite Resource (XR) + Composition: ชั้นนามธรรมที่ Platform Team สร้างขึ้น เพื่อรวม MR หลายตัวเป็น API เดียว เช่น `PostgreSQLInstance` ที่ประกอบด้วย VPC + Subnet + RDS + Secret ให้ทีม Product เรียกใช้งานผ่าน Manifest สั้นๆ เพียง 10 บรรทัด
  • Composition v2 ที่ออกในปี 2025 รองรับ Function Pipelines เขียนเป็น KCL, Go Template หรือ WebAssembly ทำให้ Logic ซับซ้อนอ่านง่ายขึ้นมาก

    5 ขั้นตอนเริ่มต้นใช้ Crossplane ในองค์กร

    ขั้นตอนนี้ใช้ได้กับทั้ง Cluster ใน EKS, GKE, AKS หรือ On-Prem

    1. ติดตั้ง Crossplane Core ผ่าน Helm: `helm install crossplane crossplane-stable/crossplane -n crossplane-system --create-namespace`

    2. ติดตั้ง Provider ที่ต้องการ เช่น AWS: `kubectl apply -f provider-aws-s3.yaml` แล้วตั้งค่า `ProviderConfig` ให้ใช้ IRSA หรือ Workload Identity แทน Static Key

    3. ออกแบบ Composite Resource Definition (XRD) สำหรับ Service ที่ทีม Product ใช้บ่อย เช่น `XPostgreSQL`

    4. เขียน Composition ให้ Map XRD เป็น Managed Resource หลายตัว ใส่ Default, Patch และ Policy เช่น Tag + Backup

    5. เชื่อมกับ ArgoCD/Flux เพื่อ Sync YAML ใน Git มายัง Cluster ทำให้เกิด Platform-as-a-Product ที่ทีมอื่นเรียกผ่าน PR ได้เลย

    เมื่อไหร่ควรเลือก Crossplane และเมื่อไหร่ไม่ควร

    | สถานการณ์ | ควรใช้ Crossplane | ใช้ Terraform/Pulumi ดีกว่า |

    |-----------|------------------|---------------------------|

    | ทีมมี Kubernetes อยู่แล้ว | ✅ | ➖ |

    | ต้องการ Self-Service API ภายใน | ✅ | ❌ |

    | ต้องการ Drift Detection ตลอดเวลา | ✅ | ❌ |

    | Infrastructure ยังไม่แตะ Kubernetes | ❌ | ✅ |

    | ทีมเล็ก <3 คน | ❌ | ✅ |

    | ต้องการ Dry-Run Preview ก่อน Apply | ➖ | ✅ |

    สำหรับ SME ไทยที่มีทีม DevOps 5 คนขึ้นไปและต้องดูแลหลาย Environment, Crossplane จะช่วยลดภาระการเขียน Pipeline ซ้ำซ้อน และสร้าง Internal Developer Platform ได้รวดเร็วกว่าการเขียน Terraform Module เอง

    ข้อควรระวังและ Best Practice

  • หลีกเลี่ยง Static Credential: ใช้ IRSA, Workload Identity หรือ External Secrets Operator แทน
  • เริ่มที่ XRD ขนาดเล็ก: ทำ PostgreSQL หรือ S3 Bucket ก่อน ค่อยขยายไป Network, IAM
  • สำรอง etcd: เพราะ State ของ Infrastructure ทั้งหมดอยู่ที่นี่ ต้อง Backup ระดับ Cluster
  • ใช้ Kyverno / OPA Gatekeeper ควบคู่: เพื่อบังคับ Policy บน XR ก่อนที่จะสร้างจริง
  • ตรวจสอบ Cost: Resource ที่ Crossplane สร้างเป็นของคลาวด์จริง ต้องมี Budget + Alert แยก
  • สรุป + Call to Action

    Crossplane คือ "Infrastructure as Kubernetes" ที่เหมาะกับองค์กรซึ่งต้องการรวมศูนย์ Control Plane และเปิดให้ทีมอื่นเข้าถึง Infrastructure ผ่าน API ที่ปลอดภัย ทีมที่มี Kubernetes อยู่แล้วสามารถประยุกต์ใช้ได้ทันทีโดยไม่ต้องเรียนรู้ภาษาใหม่ และช่วยลดต้นทุนระยะยาวจากการลด Tool Sprawl

    สิ่งที่ควรจำ ได้แก่ เริ่มจาก Composite Resource ที่เล็กและชัดเจน ใช้ GitOps เป็นตัวขับเคลื่อนหลัก และวาง Policy ตั้งแต่วันแรก

    หากทีมคุณกำลังวางแผนย้าย Terraform มาเป็น Platform Engineering สมัยใหม่ [ติดต่อ ADS FIT](https://www.adsfit.co.th/contact) เพื่อประเมินความพร้อม Platform และออกแบบ Internal Developer Platform สำหรับองค์กรของคุณได้ฟรี

    Tags

    #Crossplane#Kubernetes#Infrastructure as Code#GitOps#Control Plane#Cloud Native

    สนใจโซลูชันนี้?

    ปรึกษาทีม ADS FIT ฟรี เราพร้อมออกแบบระบบที่ฟิตกับธุรกิจของคุณ

    ติดต่อเรา →

    บทความที่เกี่ยวข้อง