ลำดับความสำคัญของพ็อดใน Kubernetes ทำให้เกิดการหยุดทำงานที่ Grafana Labs ได้อย่างไร

บันทึก. แปล: เราขอนำเสนอรายละเอียดทางเทคนิคแก่คุณเกี่ยวกับสาเหตุของการหยุดทำงานล่าสุดในบริการคลาวด์ที่ดูแลโดยผู้สร้าง Grafana นี่เป็นตัวอย่างคลาสสิกว่าฟีเจอร์ใหม่และดูเหมือนมีประโยชน์อย่างมากที่ออกแบบมาเพื่อปรับปรุงคุณภาพของโครงสร้างพื้นฐาน... อาจก่อให้เกิดอันตรายได้อย่างไร หากคุณไม่ได้ระบุถึงความแตกต่างมากมายของแอปพลิเคชันในความเป็นจริงของการผลิต เป็นเรื่องดีเมื่อมีสื่อประเภทนี้ปรากฏขึ้นที่ช่วยให้คุณเรียนรู้ไม่เพียงแต่จากความผิดพลาดของคุณเท่านั้น รายละเอียดอยู่ในการแปลข้อความนี้จากรองประธานฝ่ายผลิตภัณฑ์จาก Grafana Labs

ในวันศุกร์ที่ 19 กรกฎาคม บริการ Hosted Prometheus ใน Grafana Cloud หยุดทำงานประมาณ 30 นาที ขออภัยลูกค้าที่ได้รับผลกระทบจากไฟฟ้าดับทุกท่าน งานของเราคือการจัดหาเครื่องมือตรวจสอบที่คุณต้องการ และเราเข้าใจดีว่าการไม่มีเครื่องมือเหล่านี้อาจทำให้ชีวิตของคุณยากขึ้นได้ เราให้ความสำคัญกับเหตุการณ์นี้เป็นอย่างมาก หมายเหตุนี้จะอธิบายถึงสิ่งที่เกิดขึ้น วิธีที่เราตอบสนอง และสิ่งที่เรากำลังทำเพื่อให้แน่ใจว่าจะไม่เกิดขึ้นอีก

ประวัติศาสตร์

บริการ Grafana Cloud Hosted Prometheus ขึ้นอยู่กับ เยื่อหุ้มสมอง — โครงการ CNCF เพื่อสร้างบริการ Prometheus ที่ปรับขนาดได้ในแนวนอน พร้อมใช้งานสูง และมีผู้เช่าหลายราย สถาปัตยกรรม Cortex ประกอบด้วยชุดไมโครเซอร์วิสแต่ละชุด ซึ่งแต่ละไมโครเซอร์วิสทำหน้าที่ของตัวเอง เช่น การจำลองแบบ การจัดเก็บ การสืบค้น ฯลฯ Cortex อยู่ระหว่างการพัฒนาและกำลังเพิ่มคุณสมบัติใหม่และปรับปรุงประสิทธิภาพอย่างต่อเนื่อง เราปรับใช้ Cortex รุ่นใหม่กับคลัสเตอร์เป็นประจำ เพื่อให้ลูกค้าสามารถใช้ประโยชน์จากคุณสมบัติเหล่านี้ได้ โชคดีที่ Cortex สามารถอัปเดตได้โดยไม่ต้องหยุดทำงาน

เพื่อการอัพเดตที่ราบรื่น บริการ Ingester Cortex จำเป็นต้องมีแบบจำลอง Ingester เพิ่มเติมในระหว่างกระบวนการอัพเดต (บันทึก. แปล: นำเข้า - องค์ประกอบพื้นฐานของ Cortex หน้าที่ของบริษัทคือรวบรวมตัวอย่างอย่างต่อเนื่อง จัดกลุ่มเป็นกลุ่ม Prometheus และจัดเก็บไว้ในฐานข้อมูล เช่น DynamoDB, BigTable หรือ Cassandra) ซึ่งช่วยให้ Ingesters เก่าสามารถส่งต่อข้อมูลปัจจุบันไปยัง Ingesters ใหม่ได้ เป็นที่น่าสังเกตว่า Ingesters นั้นมีความต้องการทรัพยากรมาก เพื่อให้ทำงานได้คุณต้องมี 4 คอร์และหน่วยความจำ 15 GB ต่อพ็อด เช่น 25% ของพลังการประมวลผลและหน่วยความจำของเครื่องฐานในกรณีของคลัสเตอร์ Kubernetes ของเรา โดยทั่วไปแล้ว เรามักจะมีทรัพยากรที่ไม่ได้ใช้ในคลัสเตอร์มากกว่า 4 คอร์และหน่วยความจำ 15 GB ดังนั้นเราจึงสามารถหมุนเวียนการนำเข้าเพิ่มเติมเหล่านี้ระหว่างการอัพเกรดได้อย่างง่ายดาย

อย่างไรก็ตาม มักเกิดขึ้นว่าในระหว่างการทำงานปกติ ไม่มีเครื่องจักรใดที่มีทรัพยากรที่ไม่ได้ใช้ถึง 25% นี้ ใช่ เราไม่ได้มุ่งมั่นด้วยซ้ำ: CPU และหน่วยความจำจะมีประโยชน์สำหรับกระบวนการอื่นเสมอ เพื่อแก้ไขปัญหานี้ เราจึงตัดสินใจใช้ ลำดับความสำคัญของพ็อด Kubernetes. แนวคิดคือการให้ความสำคัญกับ Ingesters มากกว่าไมโครเซอร์วิสอื่นๆ (ไร้สัญชาติ) เมื่อเราต้องการเรียกใช้ Ingester เพิ่มเติม (N+1) เราจะแทนที่พ็อดอื่นที่เล็กกว่าชั่วคราว พ็อดเหล่านี้จะถูกถ่ายโอนไปยังทรัพยากรฟรีบนเครื่องอื่น โดยเหลือ "รู" ที่ใหญ่พอที่จะเรียกใช้ Ingester เพิ่มเติม

ในวันพฤหัสบดีที่ 18 กรกฎาคม เราได้เปิดตัวระดับความสำคัญใหม่สี่ระดับให้กับคลัสเตอร์ของเรา: วิกฤต, สูง, เฉลี่ย и ต่ำ. พวกเขาได้รับการทดสอบบนคลัสเตอร์ภายในที่ไม่มีการรับส่งข้อมูลไคลเอ็นต์เป็นเวลาประมาณหนึ่งสัปดาห์ ตามค่าเริ่มต้น พ็อดที่ไม่มีลำดับความสำคัญที่ระบุจะได้รับ เฉลี่ย ลำดับความสำคัญ คลาสถูกกำหนดไว้สำหรับ Ingesters ด้วย สูง ลำดับความสำคัญ. วิกฤต ถูกสงวนไว้สำหรับการตรวจสอบ (Prometheus, Alertmanager, node-exporter, kube-state-metrics ฯลฯ ) การกำหนดค่าของเราเปิดอยู่ และคุณสามารถดู PR ได้ ที่นี่.

อุบัติเหตุ

เมื่อวันศุกร์ที่ 19 กรกฎาคม วิศวกรคนหนึ่งได้เปิดตัวคลัสเตอร์ Cortex เฉพาะใหม่สำหรับลูกค้ารายใหญ่ การกำหนดค่าสำหรับคลัสเตอร์นี้ไม่รวมลำดับความสำคัญของพ็อดใหม่ ดังนั้นพ็อดใหม่ทั้งหมดจึงได้รับการกำหนดลำดับความสำคัญเริ่มต้น - เฉลี่ย.

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

ReplicaSet สำหรับ Ingester ที่ถูกขับไล่ในคลัสเตอร์การผลิตตรวจพบพ็อดที่ถูกขับไล่และสร้างพ็อดใหม่เพื่อรักษาจำนวนสำเนาที่ระบุ พ็อดใหม่ถูกกำหนดตามค่าเริ่มต้น เฉลี่ย ลำดับความสำคัญ และ Ingester "เก่า" อีกตัวในการผลิตสูญเสียทรัพยากร ผลลัพธ์ก็คือ กระบวนการหิมะถล่มซึ่งนำไปสู่การแทนที่พ็อดทั้งหมดจากคลัสเตอร์การผลิต Ingester สำหรับ Cortex

ผู้นำเข้าจะมีสถานะและจัดเก็บข้อมูลไว้ 12 ชั่วโมงก่อนหน้า สิ่งนี้ช่วยให้เราสามารถบีบอัดพวกมันได้อย่างมีประสิทธิภาพมากขึ้นก่อนที่จะเขียนลงในพื้นที่จัดเก็บข้อมูลระยะยาว เพื่อให้บรรลุเป้าหมายนี้ Cortex จะแบ่งข้อมูลข้ามชุดโดยใช้ Distributed Hash Table (DHT) และจำลองแต่ละชุดโดยใช้ Ingesters XNUMX ตัวโดยใช้ความสอดคล้องขององค์ประชุมสไตล์ Dynamo Cortex ไม่ได้เขียนข้อมูลไปยัง Ingesters ที่ถูกปิดใช้งาน ดังนั้น เมื่อมี Ingester จำนวนมากออกจาก DHT Cortex จะไม่สามารถจำลองรายการได้เพียงพอ และเกิดการขัดข้อง

การตรวจจับและการแก้ไข

การแจ้งเตือน Prometheus ใหม่ตาม "ข้อผิดพลาดที่ถือว่ารับได้" (ตามข้อผิดพลาดตามงบประมาณ — รายละเอียดจะปรากฏในบทความหน้า) เริ่มส่งเสียงเตือน 4 นาทีหลังจากเริ่มปิดระบบ ในอีกห้านาทีหรือประมาณนั้น เราได้ทำการวินิจฉัยและขยายขนาดคลัสเตอร์ Kubernetes พื้นฐานเพื่อโฮสต์ทั้งคลัสเตอร์ที่ใช้งานจริงใหม่และที่มีอยู่

หลังจากนั้นอีกห้านาที Ingesters รุ่นเก่าก็เขียนข้อมูลได้สำเร็จ ข้อมูลใหม่ก็เริ่มต้นขึ้น และคลัสเตอร์ Cortex ก็กลับมาใช้งานได้อีกครั้ง

ใช้เวลาอีก 10 นาทีในการวินิจฉัยและแก้ไขข้อผิดพลาดหน่วยความจำไม่เพียงพอ (OOM) จากพร็อกซีย้อนกลับการรับรองความถูกต้องที่อยู่ด้านหน้า Cortex ข้อผิดพลาด OOM เกิดจากการเพิ่มขึ้นสิบเท่าใน QPS (เราเชื่อว่าเกิดจากการร้องขอที่ก้าวร้าวมากเกินไปจากเซิร์ฟเวอร์ Prometheus ของลูกค้า)

ผลพวง

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

การดำเนินการเขียนคลัสเตอร์การผลิต

ผลการวิจัย

สิ่งสำคัญคือต้องเรียนรู้จากเหตุการณ์นี้และดำเนินการตามขั้นตอนที่จำเป็นเพื่อหลีกเลี่ยงไม่ให้เกิดซ้ำ

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

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

สุดท้ายนี้ เราจะปรับขนาดของพร็อกซีย้อนกลับการรับรองความถูกต้องโดยอัตโนมัติเพื่อป้องกัน OOM โอเวอร์โหลดที่เราพบเห็น และจะตรวจสอบการตั้งค่าเริ่มต้นของ Prometheus ที่เกี่ยวข้องกับทางเลือกสำรองและการปรับขนาดเพื่อป้องกันปัญหาที่คล้ายกันในอนาคต

ความล้มเหลวยังส่งผลเชิงบวกบางประการเช่นกัน เมื่อได้รับทรัพยากรที่จำเป็น Cortex จะกู้คืนโดยอัตโนมัติโดยไม่มีการแทรกแซงเพิ่มเติม เรายังได้รับประสบการณ์อันมีค่าในการทำงานด้วย กราฟาน่า โลกิ - ระบบการรวมบันทึกใหม่ของเรา - ซึ่งช่วยให้มั่นใจว่าผู้นำเข้าทั้งหมดมีพฤติกรรมอย่างเหมาะสมในระหว่างและหลังความล้มเหลว

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

• «การปรับขนาดอัตโนมัติและการจัดการทรัพยากรใน Kubernetes (ภาพรวมและรายงานวิดีโอ)";
• «การผจญภัยของ Kubernetes Dailymotion: การสร้างโครงสร้างพื้นฐานในระบบคลาวด์ + ภายในองค์กร";
• «Tinder เปลี่ยนไปใช้ Kubernetes";
• «เรื่องราวความสำเร็จของ Kubernetes ในการผลิต ตอนที่ 10: เรดดิท'

ที่มา: will.com