บาดแผลของ kubectl apply-and-forget

จากที่ผมได้ไปงาน Kube Day ครั้งแรกที่ Singapore 2023 ได้มีโอกาสเข้าฟังใน Keynote เรื่อง Flux & an Intro to GitOps โดย Kwong Tung Nan (DevOps & Backend Software Engineer @ Infin8)

จากการ Deploy infratrusture หรือ application แบบดั้งเดิมโดยปกติแล้ว เราก็จะสร้าง file yaml ต่อมาก็ kubectl apply แล้วภาวนาว่ามันจะ work สุดท้ายแล้วเราก็โยนไฟล์ไว้ที่ไหนสักที่และคาดหวังว่ามันจะอยู่ใน version control

จนเวลาผ่านไปอะไรๆ ก็มีเปลี่ยนแปลง ระบบโตขึ้น คนเก่าออก คนใหม่มา จนเริ่มถามตัวเองหรือเพื่อนร่วมทีมละว่า

อันนี้ apply ไปยังนะ ??

apply ไปแล้วเมื่อไหร่ ??

apply แล้วที่ environment ไหน ??

ทำไม current state ไม่เท่ากับ desired state ??

และก็มีมีคำถามบลาๆๆๆ

จึงทำให้เราต้องเสียเวลาเพื่อ kubectl get/describe เพื่อตรวจสอบมัน

ซึ่งจากข้างต้นที่กล่าวมาทำให้รู้ว่าปัญหาจริงๆ นั้นคือการ Trust on people มากเกินไป เช่น เราอาจพูดว่าคุณควร commit code หลังจากทำ change หรือ ขอ apply หรือ fix prod ก่อนแล้วค่อย commit นะ แต่ไม่ได้มีอะไรเป็นสิ่งที่ยืนยันว่าจะทำแบบนั้นกันทุกๆ ครั้ง

GitOps Principal มีอยู่ 4 ข้อ

Declarative: สถานะที่คาดหวัง (Desired state) ไม่ว่าจะเป็น yaml, source code จะต้องอยู่ในรูปแบบ declarative

Versioned and Immutable: สถานะที่คาดหวังจะต้องมีการเก็บ version และประวัติ

Pulled Automatically: มีการ apply desired state แบบอัตโนมัติเมื่อ declarative มี change ที่ถูก approved

Continuously Reconciled: มี agent คอยสังเกต current state และปรับให้ตรงกับ Desired State ที่ต้องการตลอด

เพราะฉะนั้น Flux (จริงๆ ก็มีตัวอื่นแต่ใน session ใช้ Flux) & GitOps โดย declarations และวิธีการจากข้างต้นที่เราคุ้นเคยอยู่แล้ว จึงใช้ git เป็น Source of Truth สำหรับ current status ไม่ว่าจะ change อะไรก็ตาม จะต้องผ่าน git สิ่งนี้ทำให้สามารถตรวจสอบและเปิดให้บุคคลที่ที่ไม่มีสิทธิ์ที่จะเข้าถึงคลัสเตอร์สามารถมีส่วนร่วมได้

บทความนี้เป็นการฟังและสรุปจากตัวผมเองผิดพลาดประการใดขออภัยด้วยครับ

อ้างอิง
Keynote: Flux & an Intro to GitOps @ KubeDay Singapore 2023