🥇การอัปเดตคลัสเตอร์ Kubernetes โดยไม่มีการหยุดทำงาน

กระบวนการอัปเกรดสำหรับคลัสเตอร์ Kubernetes ของคุณ

ในบางจุด เมื่อใช้คลัสเตอร์ Kubernetes จำเป็นต้องอัปเดตโหนดที่ทำงานอยู่ ซึ่งอาจรวมถึงการอัปเดตแพ็คเกจ การอัปเดตเคอร์เนล หรือการปรับใช้อิมเมจเครื่องเสมือนใหม่ ในคำศัพท์ของ Kubernetes สิ่งนี้เรียกว่า “การรบกวนโดยสมัครใจ”.

โพสต์นี้เป็นส่วนหนึ่งของซีรี่ส์ 4 โพสต์:

โพสต์นี้.
แก้ไขการปิดพ็อดในคลัสเตอร์ Kubernetes อย่างถูกต้อง
การล่าช้าของพ็อดเมื่อถูกลบ
วิธีหลีกเลี่ยงการหยุดทำงานของคลัสเตอร์ Kubernetes โดยใช้ PodDisruptionBudgets

(โดยประมาณคาดว่าจะมีการแปลบทความที่เหลือในชุดได้ในอนาคตอันใกล้นี้)

ในบทความนี้ เราจะอธิบายเครื่องมือทั้งหมดที่ Kubernetes มอบให้เพื่อลดเวลาหยุดทำงานเป็นศูนย์สำหรับโหนดที่ทำงานในคลัสเตอร์ของคุณ

นิยามปัญหา

ในตอนแรกเราจะใช้แนวทางที่ไร้เดียงสา ระบุปัญหาและประเมินความเสี่ยงที่อาจเกิดขึ้นของแนวทางนี้ และสร้างองค์ความรู้เพื่อแก้ไขปัญหาแต่ละปัญหาที่เราเผชิญตลอดวงจร ผลลัพธ์คือการกำหนดค่าที่ใช้ hook วงจรการใช้งาน การตรวจสอบความพร้อม และงบประมาณการหยุดชะงักของ Pod เพื่อให้บรรลุเป้าหมายการหยุดทำงานเป็นศูนย์

เพื่อเริ่มต้นการเดินทางของเรา เรามายกตัวอย่างที่เป็นรูปธรรมกัน สมมติว่าเรามีคลัสเตอร์ Kubernetes ที่มีสองโหนด ซึ่งแอปพลิเคชันกำลังทำงานโดยมีพ็อดสองอันอยู่ด้านหลัง Service:

เริ่มต้นด้วยสองพ็อดที่มี Nginx และบริการที่ทำงานบนโหนดคลัสเตอร์ Kubernetes สองโหนดของเรา

เราต้องการอัปเดตเวอร์ชันเคอร์เนลของโหนดผู้ปฏิบัติงานสองคนในคลัสเตอร์ของเรา เราจะทำเช่นนี้ได้อย่างไร? วิธีแก้ไขง่ายๆ คือการบูตโหนดใหม่ด้วยการกำหนดค่าที่อัปเดต แล้วปิดโหนดเก่าในขณะที่เริ่มต้นโหนดใหม่ แม้ว่าวิธีนี้จะได้ผล แต่แนวทางนี้จะมีปัญหาบางประการ:

เมื่อคุณปิดโหนดเก่า พ็อดที่ทำงานบนโหนดเหล่านั้นจะถูกปิดด้วย จะเกิดอะไรขึ้นหากจำเป็นต้องเคลียร์พ็อดเพื่อการปิดระบบอย่างค่อยเป็นค่อยไป? ระบบการจำลองเสมือนที่คุณใช้อาจไม่รอให้กระบวนการล้างข้อมูลเสร็จสิ้น
จะเกิดอะไรขึ้นถ้าคุณปิดโหนดทั้งหมดพร้อมกัน? คุณจะได้รับเวลาหยุดทำงานที่เหมาะสมในขณะที่พ็อดย้ายไปยังโหนดใหม่

เราต้องการวิธีในการโยกย้ายพ็อดจากโหนดเก่าอย่างสวยงาม ในขณะเดียวกันก็ทำให้มั่นใจได้ว่าไม่มีกระบวนการของผู้ปฏิบัติงานใดทำงานอยู่ในขณะที่เราทำการเปลี่ยนแปลงกับโหนด หรือเมื่อเราทำการแทนที่คลัสเตอร์โดยสมบูรณ์ ดังตัวอย่าง (นั่นคือ เราแทนที่อิมเมจ VM) เราต้องการถ่ายโอนแอปพลิเคชันที่ทำงานอยู่จากโหนดเก่าไปยังโหนดใหม่ ในทั้งสองกรณี เราต้องการป้องกันไม่ให้กำหนดเวลาพ็อดใหม่บนโหนดเก่า จากนั้นจึงนำพ็อดที่ทำงานอยู่ทั้งหมดออกจากโหนดเหล่านั้น เพื่อให้บรรลุเป้าหมายเหล่านี้เราสามารถใช้คำสั่งได้ kubectl drain.

แจกจ่ายพ็อดทั้งหมดจากโหนดอีกครั้ง

การดำเนินการเดรนทำให้คุณสามารถแจกจ่ายพ็อดทั้งหมดจากโหนดอีกครั้ง ในระหว่างการดำเนินการระบาย โหนดจะถูกทำเครื่องหมายว่าไม่สามารถจัดกำหนดการได้ (flag NoSchedule). วิธีนี้จะป้องกันไม่ให้พ็อดใหม่ปรากฏขึ้น จากนั้นเดรนจะเริ่มไล่พ็อดออกจากโหนด ปิดคอนเทนเนอร์ที่กำลังทำงานบนโหนดในปัจจุบันโดยการส่งสัญญาณ TERM ภาชนะในฝัก

แม้ว่า kubectl drain จะกำจัดฝักออกได้ดีมาก มีปัจจัยอีกสองประการที่อาจทำให้การดำเนินการระบายน้ำล้มเหลว:

ใบสมัครของคุณจะต้องสามารถยุติลงได้อย่างสวยงามเมื่อส่ง TERM สัญญาณ. เมื่อพ็อดถูกไล่ออก Kubernetes จะส่งสัญญาณ TERM และรอให้ตู้หยุดตามระยะเวลาที่กำหนด หลังจากนั้นหากยังไม่หยุดก็จะบังคับปิดตู้คอนเทนเนอร์ ไม่ว่าในกรณีใด หากคอนเทนเนอร์ของคุณรับรู้สัญญาณไม่ถูกต้อง คุณยังคงสามารถดับพ็อดได้อย่างไม่ถูกต้องหากพ็อดเหล่านั้นกำลังทำงานอยู่ (เช่น ธุรกรรมฐานข้อมูลอยู่ระหว่างดำเนินการ)
คุณจะสูญเสียพ็อดทั้งหมดที่มีแอปพลิเคชันของคุณ อาจไม่พร้อมใช้งานเมื่อมีการเปิดตัวคอนเทนเนอร์ใหม่บนโหนดใหม่ หรือหากพ็อดของคุณใช้งานโดยไม่มีตัวควบคุม พ็อดเหล่านั้นอาจไม่รีสตาร์ทเลย

หลีกเลี่ยงการหยุดทำงาน

เพื่อลดเวลาหยุดทำงานจากการหยุดชะงักโดยสมัครใจ เช่น จากการดำเนินการเดรนบนโหนด Kubernetes มีตัวเลือกการจัดการความล้มเหลวดังต่อไปนี้:

ในส่วนที่เหลือของซีรีส์นี้ เราจะใช้ฟีเจอร์ Kubernetes เหล่านี้เพื่อลดผลกระทบของการย้ายพ็อด เพื่อให้ง่ายต่อการปฏิบัติตามแนวคิดหลัก เราจะใช้ตัวอย่างด้านบนกับการกำหนดค่าทรัพยากรต่อไปนี้:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

การกำหนดค่านี้เป็นตัวอย่างขั้นต่ำ Deploymentซึ่งจัดการพ็อด nginx ในคลัสเตอร์ นอกจากนี้ การกำหนดค่ายังอธิบายถึงทรัพยากรอีกด้วย Serviceซึ่งสามารถใช้เพื่อเข้าถึงพ็อด nginx ในคลัสเตอร์ได้

ตลอดวงจรนี้ เราจะขยายการกำหนดค่านี้ซ้ำๆ เพื่อรวมความสามารถทั้งหมดที่ Kubernetes มอบให้เพื่อลดเวลาหยุดทำงานในที่สุด

หากต้องการดูการอัปเดตคลัสเตอร์ Kubernetes เวอร์ชันที่มีการใช้งานและทดสอบแล้วอย่างสมบูรณ์ เพื่อการหยุดทำงานเป็นศูนย์บน AWS และอื่นๆ โปรดไปที่ Gruntwork.io.

อ่านบทความอื่น ๆ ในบล็อกของเราด้วย:

ที่มา: will.com

การอัปเกรดคลัสเตอร์ Kubernetes โดยไม่ต้องหยุดทำงาน

นิยามปัญหา

แจกจ่ายพ็อดทั้งหมดจากโหนดอีกครั้ง

หลีกเลี่ยงการหยุดทำงาน

อ่านบทความอื่น ๆ ในบล็อกของเราด้วย:

เพิ่มความคิดเห็น ยกเลิกการตอบ