Operators และ CRD — ต่อขยาย K8s เอง
สอน K8s ให้รู้จัก resource ใหม่ และดูแลมันอัตโนมัติ
พื้นฐานที่ควรรู้: ตามปกติ K8s รู้จักออบเจกต์พื้นฐานเช่น Pod, Service, Deployment แต่บางครั้งเราอยากให้มันรู้จักสิ่งที่เป็นเฉพาะทางมากขึ้น เช่น "ฐานข้อมูล MySQL" หรือ "ใบเสร็จรับเงิน" เราสามารถสอนให้ K8s รู้จักคำศัพท์ใหม่ๆ เหล่านี้ได้
CRD เหมือนสอนคำศัพท์ใหม่ให้ K8s (เช่นคำว่า Database) · Operator เหมือนจ้างผู้เชี่ยวชาญประจำที่รู้วิธีดูแลของชนิดนั้น (backup, failover, upgrade ฐานข้อมูลให้เอง) — เอา know-how ของ admin มาใส่ในโค้ด
CustomResourceDefinition (CRD) ให้เรานิยาม resource ชนิดใหม่นอกเหนือจาก Pod/Deployment · Operator คือ controller ที่เฝ้า resource ชนิดนั้นแล้ว reconcile ให้เป็นไปตาม desired state — ขยายแนวคิด "desired vs current" ของ K8s ไปสู่แอปซับซ้อน
ตัวอย่างจริง: ติดตั้ง Prometheus Operator แล้วสร้าง resource ServiceMonitor · หรือ database operator ที่คุณสร้าง PostgresCluster object แล้วมันจัดการ replica/backup ให้เองทั้งหมด
สรุป Key Takeaways
- CRD = นิยาม resource ชนิดใหม่ให้ K8s รู้จัก
- Operator = controller ที่ดูแล resource นั้นตามหลัก desired vs current (know-how เป็นโค้ด)
- ระบบนิเวศ K8s ส่วนใหญ่สร้างบน CRD+Operator — เริ่มจาก "ใช้" ก่อน "เขียน"
คำถามที่พบบ่อย
CRD กับ Operator ต่างกันยังไง
CRD = การสอน K8s ให้รู้จัก resource ชนิดใหม่ (เช่น ชนิด "PostgresCluster") — แค่โครงข้อมูล ส่วน Operator = CRD + controller ที่ "ทำงานจริง" ตามนั้น (เห็น PostgresCluster ถูกสร้างก็ไปตั้ง StatefulSet, backup, failover ให้) — Operator คือการแพ็คความรู้ ops ของมนุษย์ลงเป็นโค้ด
เมื่อไหร่ควรใช้ Operator ของสำเร็จ เมื่อไหร่ควรเขียนเอง
ใช้ของสำเร็จเสมอเมื่อมี (Prometheus Operator, cert-manager, ฐานข้อมูลดังๆ มีหมดแล้ว) — เขียนเองเฉพาะเมื่อมี domain logic เฉพาะองค์กรที่ต้อง automate ซ้ำๆ จริงจัง เพราะเขียน operator ให้ถูกต้องยากกว่าที่คิดมาก