การเขียน Kubernetes Controller, Part 3 — โลกด้านนอกรั้วของ Kubernetes

จาก Part ที่แล้ว คิดว่า Part นี้จะได้เข้า spec ของตัว TF-controller แต่ก็เจอว่าก่อนจะลงรายละเอียดของการเขียน Kubernetes Controller ตัวนี้ ผมมีความจำเป็นที่ต้องรื้อฟื้นความเข้าใจโลกด้านนอกขอบเขตของ Kubernetes ก่อน เพราะจักรวาลจริง ๆ ของระบบการ operator ซอฟต์แวร์ ไม่ได้มีอยู่แค่ในขอบเขตของ Kubernetes

และแน่นอนว่าเครื่องมือตัวนึงที่อยู่คู่กับเรามานานคือ Terraform

Terraform มีความสามารถในการจัดการ resource (แทบจะ) ใด ๆ ในโลกของการ operate ระบบซอฟต์แวร์ ไล่ไปตั้งแต่ on-prem hardware จนถึงโลกฝั่ง Serverless

ปัญหา classic ของ Terraform คือเราต้องจัดการดูแล state ของระบบเอง หรือไม่ก็ต้องทำเครื่องมือ เช่น Cron มาเฝ้า state ของระบบแล้วคอยเตือนว่ามีชิ้นไหนบ้างที่พัง หรือ เปลี่ยนไปจากระบบที่เราคาดหวังว่ามันควรจะเป็น

พูดง่าย ๆ ก็คือเราต้องหาวิธีตรวจหา “drift” ของระบบด้วยตัวเอง

เรารู้อยู่แล้วว่า Terraform กับ CI/CD pipeline ไม่ได้ช่วยแก้ปัญหาเรื่องการตรวจหา drift หรือการ reconcile ให้ drift หายไปอย่างอัตโนมัติ ในตอนที่เราเริ่มรู้ว่าระบบล่มบางชิ้น เราก็จะใช้วิธี commit change เข้า CI/CD pipeline ให้ตัว pipeline ทำงาน เพื่อสั่ง plan และ apply เป็นครั้ง ๆ ไป และเราก็มั่นใจว่า นี่คือ Infrastructure as Code ที่ดีแล้ว

แต่บางคนก็อาจจะใช้เทคนิคที่ advanced ขึ้นไปอีก step โดยใช้ Cron มาเฝ้า state ของ Terraform แล้วถ้าเกิด drift ก็อาจจะให้แจ้งเตือนไปยังช่องทางที่ต้องการ หรือ ถ้าในระบบที่ไม่ critical ก็อาจจะให้ Terraform ทำการ apply อัตโนมัติได้เลย ส่วน state ของแต่ละระบบที่สร้างโดย Terraform ก็หาที่เก็บดี ๆ

แล้วถ้ามันมีวิธีที่ดีประมาณเดียวกัน แต่เป็นระบบมากกว่าหล่ะ?

ผมเจอว่าปัญหาของการจัดการ Terraform ให้มีความเป็น automatic สามารถแก้ได้โดยใช้ความสามารถของ Kubernetes Controller เข้ามาช่วย

ลองดู design ของ API นี้ครับ

ตามตัวอย่าง Terraform object ด้านบนนี้ เป็นการทำงานในโหมด auto ของ controller (approvePlan: “auto”) โดยเราต่อ object นี้เข้ากับ GitRepository ตัวนึงที่เก็บไฟล์ TF ไว้ (sourceRef: …) และ object นี้จะไปทำงานในพาธ ./policies ของ repo (path: ./policies) เพื่อ detect drift, plan และ apply ทุก ๆ 10 นาที (interval: 10m) โดยการ reconcile ตัว Terraform resource บน AWS จะใช้ Secret ชื่อ aws-credentails ที่เก็บอยู่ใน Kubernetes (varsFrom: …)

เมื่อทำงานเสร็จ ได้ TFSTATE ของ Terraform มาจากระบบจริง ก็จะทำการเก็บเป็น Secret ไว้ใน Kubernetes เช่นกัน

จะเห็นได้ว่า นี่คือกลไกที่สามารถใช้แก้ปัญหาได้แบบเดียวกับระบบ Cron แต่มี interface ที่เป็น standard กว่า สามารถพลิกแพลงจัดการ Secret ได้เป็นระบบกว่า เก็บ resource ไว้ใน Git repo แล้วดึงมาใช้ได้เลยผ่านกลไกของ Flux ทำให้เกิดระบบจัดการ Terraform ที่มีความเป็น GitOps เต็มตัว ได้กลไกการ audit เพิ่มเข้ามาอีกจากการใช้ Git ไม่ว่าจะเป็นในระดับของการเก็บไฟล์ TF หรือตัว configuration ชุดอื่น ๆ

หน้าต่างนี้แสดงให้เห็นการทำงานของ Terraform object ทำงานร่วมกับ Kustomization object ของ Flux ในการแสดงสถานะหลังการตรวจ drift ในแต่ละรอบ และก็จะมีการรายงานออกมาในลักษณะตามภาพ

ตอนนี้ก็ได้เห็นตัวอย่าง design ของ Terraform object ตัว v1apha1 และความหมายของมันบางส่วนไปแล้ว คราวหน้าก็จะพาเข้าไปดูใน code โดยเริ่มจากขั้นตอนการออกแบบจาก spec ครับ