การจัดลำดับการ Rollout ของ GKE ด้วย Stage แบบกำหนดเอง

ตอนนี้ GKE ของ Google Cloud ช่วยให้คุณกำหนดลำดับที่แน่นอนในการอัปเกรดคลัสเตอร์ได้ โดยใช้การจัดลำดับการ Rollout แบบแบ่ง Stage ตามต้องการ (custom-stage rollout sequencing) ซึ่งเป็นไปตามตรรกะทางธุรกิจของคุณเอง แทนที่จะเป็นไปตามตารางเวลาตามภูมิภาค (regional schedule) แบบเริ่มต้น

การอัปเกรด Kubernetes clusters ในสภาพแวดล้อมจำนวนหลายสิบหรือหลายร้อยแห่งนั้นเป็นเรื่องที่จัดการได้ยาก การอัปเดตแพตช์ความปลอดภัยเกิดขึ้นอย่างสม่ำเสมอ แต่คุณก็ต้องรักษาบริการในส่วน Production ให้ทำงานได้อย่างต่อเนื่องด้วย โมเดลการอัปเกรดตามภูมิภาคแบบเดิมอาจส่งเวอร์ชัน Control-plane ใหม่ไปยังคลัสเตอร์ใน Production ก่อนที่สภาพแวดล้อม Staging จะทำการตรวจสอบ (validation) เสร็จสิ้น ซึ่งทำให้คลัสเตอร์ทั้งหมดในระบบ (fleet) ต้องเผชิญกับการเปลี่ยนแปลงที่ยังไม่ผ่านการทดสอบ

ทำไมโมเดลแบบเดิมถึงยังไม่ตอบโจทย์

การ Rollout ตามภูมิภาคจะมองคลัสเตอร์ทุกตัวในภูมิภาคนั้นเป็นกลุ่มเดียวกัน เมื่อช่วงเวลาอัปเกรด (upgrade window) เริ่มขึ้น ทั้ง Control plane และ Node จะถูกอัปเกรดไปพร้อมๆ กัน โดยไม่สนใจว่าคลัสเตอร์นั้นจะอยู่ในขั้นตอนใดของ Release pipeline ทีมที่ใช้กระบวนการแบบ Canary ก่อนแล้วค่อย Production อย่างเคร่งครัด มักจะประสบปัญหาการอัปเกรดแบบ "ผิดลำดับ" (out-of-order) ซึ่งอาจทำให้เกิดปัญหาถดถอย (regressions) ที่ยากต่อการสืบหาต้นตอจากการเปลี่ยนแปลงที่เฉพาะเจาะจง ต้นทุนที่เกิดขึ้นไม่ใช่แค่เรื่องของ Downtime เท่านั้น แต่ยังรวมถึงเวลาของวิศวกรที่ต้องเสียไปกับการแก้ปัญหา (debugging) ที่จริงๆ แล้วควรจะตรวจพบได้ตั้งแต่เนิ่นๆ

สิ่งที่การจัดลำดับการ Rollout ของ GKE เพิ่มเข้ามา

ฟีเจอร์ใหม่นี้มาพร้อมกับออบเจกต์ RolloutSequence ที่ใช้กำหนดชุดของ Stage ต่างๆ โดยแต่ละ Stage คือส่วนแบ่งเชิงตรรกะของ Fleet ของคุณ ซึ่งระบุด้วย Label selectors ระบบจะทำงานตามเส้นทางที่กำหนดไว้แน่นอน (deterministic path) ดังนี้:

  • อัปเกรด Control-plane ก่อน: GKE จะย้ายส่วนประกอบการจัดการส่วนกลางไปยังเวอร์ชันเป้าหมายก่อนที่จะเริ่มแตะต้อง Node ใดๆ
  • เริ่ม Soak timer: หลังจาก Control plane ถึงเวอร์ชันเป้าหมายแล้ว จะมีการหน่วงเวลาที่ตั้งค่าได้ เพื่อให้คุณมีช่วงเวลาในการรัน Health checks
  • อัปเกรด Node ไปพร้อมๆ กัน: ในขณะที่ Soak timer กำลังนับถอยหลัง GKE จะอัปเกรด Node ต่างๆ เพื่อให้คลัสเตอร์เปลี่ยนผ่านไปยังเวอร์ชันใหม่ได้อย่างรวดเร็ว
  • Stage ถัดไปจะเริ่มขึ้นเมื่อ Stage ปัจจุบันเสร็จสิ้นเท่านั้น: เมื่อ Node และ Control plane ทุกตัวใน Stage ปัจจุบันทำงานเสร็จสิ้นและ Soak timer หมดเวลาลง GKE จึงจะดำเนินการต่อไปยัง Stage ถัดไป

ด้วยการแบ่ง Fleet ออกเป็นกลุ่มย่อยๆ ตาม Label คุณสามารถอัปเกรดคลัสเตอร์กลุ่ม Canary เพียงไม่กี่แห่งก่อน เพื่อตรวจสอบว่ากฎการ Monitoring และการจัดการ Traffic (traffic-routing) ทำงานได้ตามที่คาดหวัง จากนั้นจึงค่อย Rollout เวอร์ชันเดียวกันไปยังส่วนที่เหลือของ Production

กฎที่ช่วยให้การจัดลำดับเป็นไปอย่างราบรื่น

  • Catch-all stage: Stage สุดท้ายจะไม่มีการระบุ Label selector เพื่อรับประกันว่าคลัสเตอร์ใดก็ตามที่ไม่ตรงกับเงื่อนไขก่อนหน้านี้ จะยังคงได้รับการอัปเกรด
  • Conflict resolution: หาก Label ของคลัสเตอร์ตรงกับเงื่อนไขมากกว่าหนึ่ง Stage ทาง GKE จะจัดให้คลัสเตอร์นั้นอยู่ใน Stage แรกที่ตรงเงื่อนไข เพื่อป้องกันการอัปเกรดซ้ำซ้อนโดยไม่ตั้งใจ

ปุ่มควบคุมแบบ Real-time

ในระหว่างการ Rollout ที่กำลังดำเนินอยู่ คุณยังคงเป็นผู้ควบคุม:

  • Pause หยุดการอัปเกรดที่เหลือทั้งหมด เพื่อให้คุณสามารถตรวจสอบความล้มเหลวใน Stage ของ Canary ได้โดยไม่ทำให้ปัญหาลุกลามไปยังส่วนอื่น
  • Force-complete ยกเลิกเวลา Soak time ที่เหลืออยู่ เมื่อสคริปต์การตรวจสอบ (validation scripts) ของคุณรายงานผลสำเร็จก่อนกำหนด เพื่อช่วยให้การ Rollout รวดเร็วยิ่งขึ้น
  • Cancel ยกเลิกลำดับการทำงานทั้งหมด หากเวอร์ชันที่เพิ่งปล่อยออกมาพบ Bug ร้ายแรง เพื่อให้คุณสามารถย้อนกลับ (revert) หรือรอการแก้ไขแบบเร่งด่วน (hotfix) ได้

ใครได้รับประโยชน์ และมีข้อแลกเปลี่ยนอย่างไรบ้าง

สิ่งที่ควรติดตามต่อไป

บทสรุป

การจัดลำดับการ Rollout แบบแบ่ง Stage ตามต้องการ ช่วยให้ผู้ดูแล GKE สามารถอัปเกรดคลัสเตอร์ตามลำดับที่ธุรกิจต้องการ ไม่ใช่ตามลำดับที่แพลตฟอร์มกำหนด ด้วยการแยกการอัปเกรด Control-plane และ Node ออกจากกัน การเพิ่มช่วงเวลา Soak period ที่ตั้งค่าได้ และการมีคำสั่ง Pause/Force-complete/Cancel ฟีเจอร์นี้จึงช่วยลดความเสี่ยงในการอัปเกรด ในขณะที่ยังคงรักษาความเร็วที่ทีม Cloud-native ต้องการ สำหรับใครก็ตามที่กำลังรับมือกับความวุ่นวายของการอัปเกรด Kubernetes ทั่วทั้ง Fleet โมเดลการจัดลำดับแบบใหม่นี้ถือเป็นก้าวสำคัญสู่ระบบอัตโนมัติที่ปลอดภัยและสอดคล้องกับความต้องการทางธุรกิจ