Google Cloud ประกาศว่าบริการ GKE ของตนพร้อมให้บริการการอัปเกรด control-plane แบบสองขั้นตอน (two-step control-plane upgrades) ในรูปแบบทั่วไป (generally-available) แล้ว ซึ่งช่วยให้ลูกค้าสามารถแยกการอัปเกรดซอฟต์แวร์ binary ออกจากการย้ายรูปแบบข้อมูล (data-format migration) และสามารถคงช่วงเวลาสำหรับการ rollback ไว้ได้ในระหว่างการเปลี่ยนเวอร์ชันย่อย (minor version changes)

ทำไม GKE จึงต้องการเส้นทางที่ปลอดภัยกว่าเดิม

การอัปเกรด Kubernetes control plane จากเวอร์ชันย่อยหนึ่งไปยังอีกเวอร์ชันหนึ่งนั้นมีความเสี่ยงเสมอ การเปลี่ยนจาก 1.33 ไปเป็น 1.34 ไม่เพียงแต่เป็นการเปลี่ยน binary เท่านั้น แต่ยังเป็นการเขียนโครงสร้างข้อมูลพื้นฐานใหม่ด้วย หากเวอร์ชันใหม่มีข้อผิดพลาด (bug) คลัสเตอร์จะไม่สามารถย้อนกลับ (revert) ได้โดยง่าย ผู้ดูแลระบบจะต้องกู้คืน snapshot ของฐานข้อมูลเก่าหรือสร้างคลัสเตอร์ใหม่ทั้งหมด ซึ่งเป็นกระบวนการที่ใช้เวลานานและเสี่ยงต่อความผิดพลาด

การอัปเกรดแบบสองขั้นตอนทำงานอย่างไร

ขั้นตอนใหม่นี้จะแบ่งการอัปเกรดออกเป็นสองระยะที่ชัดเจน:

  • ขั้นตอนที่ 1 – การอัปเกรด Binary (โหมดจำลอง/emulated mode). GKE จะสลับ control-plane binaries ไปยังเวอร์ชันเป้าหมายในขณะที่ยังคงรูปแบบข้อมูลเดิมไว้ เนื่องจากไม่มีการเขียนโครงสร้างข้อมูลใหม่ คลัสเตอร์จึงยังคงอยู่ในสถานะที่ปลอดภัยต่อการ rollback ตลอดระยะเวลานี้
  • ขั้นตอนที่ 2 – การดำเนินการขั้นสุดท้าย (Finalization). หลังจากผ่านระยะเวลารอคอยที่กำหนดค่าได้ GKE จะแปลงข้อมูลที่จัดเก็บไว้ให้อยู่ในรูปแบบใหม่ เมื่อการแปลงข้อมูลนี้เสร็จสิ้น การ rollback จะต้องใช้ความพยายามในการกู้คืน snapshot เช่นเดียวกับที่กระบวนการแบบสองขั้นตอนนี้ถูกออกแบบมาเพื่อหลีกเลี่ยง

การแยกส่วนนี้ทำให้เกิด “soak window” ซึ่งผู้ดูแลระบบสามารถสังเกตการณ์ binary ที่อัปเกรดแล้วในสภาพแวดล้อม production ได้โดยไม่ต้องผูกมัดกับการย้ายข้อมูลที่ไม่สามารถย้อนกลับได้

การใช้งาน soak window ในทางปฏิบัติ

GKE จะตรวจสอบตัวชี้วัดสุขภาพที่สำคัญโดยอัตโนมัติในระหว่างช่วง soak period เช่น API latency, อัตราข้อผิดพลาด (error rates) และสุขภาพของ pod หากบริการตรวจพบความผิดปกติ ระบบจะหยุดการ rollout ไว้ โดยทิ้งคลัสเตอร์ไว้ในสถานะที่มีเพียงการเปลี่ยน binary ซึ่งยังสามารถ rollback ได้ Google ระบุว่ามีอัตราความสำเร็จถึง 99.999% สำหรับการอัปเกรดที่ใช้รูปแบบนี้

สำหรับคลัสเตอร์ที่ใช้ฟีเจอร์ auto-upgrade ของ GKE แพลตฟอร์มจะจัดการลำดับขั้นตอนทั้งสองโดยอัตโนมัติโดยไม่ต้องดำเนินการด้วยตนเอง ส่วนผู้ใช้ที่ต้องการควบคุมอย่างเต็มรูปแบบสามารถเรียกใช้กระบวนการนี้ผ่าน Cloud CLI หรือ Terraform ได้

การดำเนินการอัปเกรดแบบสองขั้นตอนด้วยตนเอง

การอัปเกรดด้วยตนเองทั่วไปที่มีช่วงเวลาความปลอดภัย 48 ชั่วโมง มีลักษณะดังนี้:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

เพื่อตรวจสอบสถานะปัจจุบัน:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

หากพบข้อบกพร่องในระหว่างช่วง soak ผู้ดูแลระบบสามารถสั่งคำสั่ง rollback เพื่อย้อนกลับไปยังเวอร์ชันก่อนหน้าได้โดยไม่สูญเสียข้อมูล เมื่อคลัสเตอร์มีความเสถียรแล้ว สามารถดำเนินการอัปเกรดให้เสร็จสิ้นก่อนกำหนดได้ด้วยคำสั่ง complete-control-plane-upgrade

ข้อจำกัดและข้อกำหนด

  • ฟีเจอร์นี้ใช้กับคลัสเตอร์ GKE ที่รันเวอร์ชัน 1.33 หรือใหม่กว่า
  • สามารถอัปเกรดได้เพียงครั้งละหนึ่งเวอร์ชันย่อยเท่านั้น ไม่รองรับการข้ามเวอร์ชัน
  • ทั้ง Autopilot และ regional clusters ยังคงใช้งานได้ตลอดกระบวนการแบบสองขั้นตอน

ข้อเสียที่อาจเกิดขึ้น

การแยกการอัปเกรด binary และข้อมูลออกจากกันเป็นการเพิ่มขั้นตอนในไทม์ไลน์การอัปเกรด ซึ่งอาจทำให้ระยะเวลาโดยรวมยาวนานขึ้นสำหรับองค์กรที่ต้องการเปลี่ยนเวอร์ชันอย่างรวดเร็ว นอกจากนี้ ช่วง soak period ยังต้องพึ่งพาการตรวจสอบสุขภาพแบบอัตโนมัติ ทีมที่รันเวิร์กโหลดที่มีการปรับแต่งสูงอาจจำเป็นต้องใช้เครื่องมือ observability ของตนเองควบคู่ไปกับการตรวจสอบของ GKE เพื่อตรวจจับความผิดปกติที่อาจเกิดขึ้นในกรณีเฉพาะ (edge-case regressions)

สิ่งที่ต้องจับตามองต่อไป

Google ยังไม่ได้เปิดเผยแผนงาน (roadmap) ในการขยายโมเดลแบบสองขั้นตอนไปยังการอัปเกรดเวอร์ชันหลัก (major version upgrades) ซึ่งในหลายกรณียังคงต้องสร้างคลัสเตอร์ใหม่ทั้งหมด ผู้สังเกตการณ์จะรอฟังประกาศเกี่ยวกับการสร้างระบบความปลอดภัยที่คล้ายกันสำหรับการอัปเกรด node-pool และการผสานรวมกับ CI/CD pipeline ของบุคคลที่สามที่สามารถตรวจสอบ soak-window ได้โดยอัตโนมัติ

สรุปประเด็นสำคัญ: ด้วยการแยกการอัปเกรด binary ออกจากการย้ายข้อมูล GKE ช่วยให้วิศวกรแพลตฟอร์มมีช่วงเวลาสำหรับการ rollback ที่ใช้งานได้จริงสำหรับการเปลี่ยนเวอร์ชันย่อย ช่วยลดต้นทุนการดำเนินงานในการดูแลรักษาคลัสเตอร์ในขณะที่รักษาเวลาดาวน์ไทม์ (downtime) ให้เหลือน้อยที่สุด