Kubernetes จำกัดจำนวนการรีสตาร์ทพ็อดพร้อมกันทั่วทั้งคลัสเตอร์

เรามีคลัสเตอร์ Kubernetes 6 โหนดที่เรียกใช้เวิร์กโหลดชุดแบบจำลองขนาดใหญ่ประมาณ 20 ชุด (บริการ Java) แต่ละเวิร์กโหลดพ็อด (1 พ็อดต่อเวิร์กโหลด) ใช้เวลาประมาณ 30 วินาทีโดยเฉลี่ยในการเริ่มและใช้ CPU จำนวนมาก สิ่งนี้ทำให้การเริ่มต้นพ็อด/ปริมาณงานหลายรายการพร้อมกันกลายเป็นปัญหา จนถึงจุดที่เมื่อ 2 หรือ 3 เริ่มทำงานพร้อมกันบนโหนดเดียวกัน พวกเขาใช้เวลาไม่กี่นาทีในการเริ่มต้นและสุดท้ายจะถูกฆ่าโดยโพรบความพร้อม โพรบความพร้อมค่อนข้างผ่อนคลาย แต่การขยายเวลาผ่อนผันไปเรื่อย ๆ ดูเหมือนจะไม่ใช่แนวทางปฏิบัติที่ดี

อย่างที่ใคร ๆ ก็จินตนาการได้ สิ่งนี้ทำให้การปิดล้อมและการระบายโหนดเป็นปัญหา - หากเราระบายโหนดหนึ่ง ๆ พ็อดทั้งหมดจะเริ่มต้นใหม่พร้อมกันที่อื่นและอาจทำให้คนทำงานมากเกินไป (หรือหยุดทำงานทำให้เกิดการรีสตาร์ทหลายครั้งซึ่งนำไปสู่การล็อกฐานข้อมูลในที่สุด ).

เพื่อแก้ไขปัญหานี้ ฉันได้เขียนเชลล์สคริปต์ซึ่งใช้ kubectl เพื่อแสดงรายการพ็อด รีสตาร์ทแต่ละพ็อด (โดยการแพตช์ข้อมูลเมตา) รอให้สถานะพร้อมใช้งานและย้ายไปยังอันถัดไป

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

แนวคิดหนึ่งคือการมีคอนเทนเนอร์ init ซึ่งรับรู้ถึงปริมาณงานเริ่มต้นอื่นๆ หากไม่มีภาระงานอื่นที่กำลังเริ่มต้นบนโหนดเดียวกัน คอนเทนเนอร์เริ่มต้นจะออกจากการปล่อยให้คอนเทนเนอร์หลักเริ่มทำงาน สิ่งนี้จะต้องมีบัญชีบริการและการอนุญาต แต่อาจเป็นวิธีแก้ปัญหา แต่ฉันสงสัยว่ามีวิธีที่เป็นมาตรฐานมากกว่านี้ในการดำเนินการนี้ผ่านการกำหนดค่า (กฎความสัมพันธ์ ฯลฯ ) หรือไม่

นี่เป็นปัญหาที่เกิดขึ้นเมื่อมีการกำหนดเวลาพ็อดได้ทุกที่ คุณมาถูกทางแล้วกับกฎความสัมพันธ์

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

อย่างไรก็ตาม มีวิธีที่ดีกว่าในการบรรลุสิ่งนี้ - ผ่านข้อจำกัดการแพร่กระจายของโทโพโลยีแบบพ็อด เมื่อระบุข้อจำกัดการแพร่กระจาย ตัวกำหนดตารางเวลาจะทำให้แน่ใจว่าพ็อดมีความสมดุลระหว่างโดเมนความล้มเหลว (ไม่ว่าจะเป็น AZ หรือโหนด) และการไม่ปรับสมดุลของพ็อดจะส่งผลให้ไม่สามารถจัดกำหนดการได้

เราสามารถเขียนสิ่งนี้ในลักษณะที่รับประกันว่าพ็อดจะกระจายไปตามโหนด และความล้มเหลวของโหนดจะไม่ทำให้เกิดการ "มัดรวมกัน" ลองดูพ็อดตัวอย่างนี้:

ชนิด: ฝัก
api เวอร์ชัน: v1
ข้อมูลเมตา:
  ชื่อ: มายพอด
  ป้ายกำกับ:
    ฟู: บาร์
ข้อมูลจำเพาะ:
  โทโพโลยีการแพร่กระจายข้อจำกัด:
  - ความเอียงสูงสุด: 1
    โทโพโลยีคีย์: โซน
    เมื่อไม่พอใจ: DoNotSchedule
    ตัวเลือกป้ายกำกับ:
      ป้ายกำกับการแข่งขัน:
        ฟู: บาร์
  - ความเอียงสูงสุด: 1
    โทโพโลยีคีย์: โหนด
    เมื่อไม่พอใจ: DoNotSchedule
    ตัวเลือกป้ายกำกับ:
      ป้ายกำกับการแข่งขัน:
        ฟู: บาร์
  ตู้คอนเทนเนอร์:
  - ชื่อ: หยุดชั่วคราว
    รูปภาพ: k8s.gcr.io/pause:3.1

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