จุดสำคัญในการทำงานของระบบแบบกระจายคือการจัดการความล้มเหลว Kubernetes ช่วยในเรื่องนี้โดยใช้ตัวควบคุมที่ตรวจสอบความสมบูรณ์ของระบบของคุณ และรีสตาร์ทบริการที่หยุดทำงาน อย่างไรก็ตาม Kubernetes สามารถบังคับหยุดแอปพลิเคชันของคุณเพื่อให้แน่ใจว่าระบบโดยรวมสมบูรณ์ ในซีรีส์นี้ เราจะมาดูกันว่าคุณสามารถช่วยให้ Kubernetes ทำงานได้อย่างมีประสิทธิภาพมากขึ้นและลดเวลาหยุดทำงานของแอปพลิเคชันได้อย่างไร
ก่อนคอนเทนเนอร์ แอปพลิเคชันส่วนใหญ่จะทำงานบนเครื่องเสมือนหรือเครื่องจริง หากแอปพลิเคชันขัดข้องหรือค้าง จะใช้เวลานานในการยกเลิกงานที่กำลังดำเนินอยู่และโหลดโปรแกรมใหม่ ในกรณีที่เลวร้ายที่สุด ต้องมีผู้แก้ไขปัญหานี้ด้วยตนเองในเวลากลางคืนในเวลาที่ไม่เหมาะสมที่สุด หากมีเครื่องจักรทำงานเพียง 1-2 เครื่องที่ทำงานสำคัญ การหยุดชะงักดังกล่าวเป็นสิ่งที่ยอมรับไม่ได้โดยสิ้นเชิง
ดังนั้น แทนที่จะรีบูตด้วยตนเอง พวกเขาจึงเริ่มใช้การตรวจสอบระดับกระบวนการเพื่อรีสตาร์ทแอปพลิเคชันโดยอัตโนมัติในกรณีที่มีการยุติการทำงานที่ผิดปกติ หากโปรแกรมล้มเหลว กระบวนการตรวจสอบจะจับรหัสทางออกและรีบูตเซิร์ฟเวอร์ ด้วยการถือกำเนิดของระบบอย่าง Kubernetes การตอบสนองต่อความล้มเหลวของระบบประเภทนี้จึงถูกรวมเข้ากับโครงสร้างพื้นฐานเพียงอย่างเดียว
Kubernetes ใช้ลูปเหตุการณ์การสังเกตความแตกต่างและการดำเนินการเพื่อให้แน่ใจว่าทรัพยากรยังคงมีสุขภาพที่ดีในขณะที่เดินทางจากคอนเทนเนอร์ไปยังโหนดเอง
ซึ่งหมายความว่าคุณไม่จำเป็นต้องเรียกใช้การตรวจสอบกระบวนการด้วยตนเองอีกต่อไป หากทรัพยากรไม่ผ่านการตรวจสุขภาพ Kubernetes จะจัดเตรียมทรัพยากรทดแทนให้โดยอัตโนมัติ อย่างไรก็ตาม Kubernetes ทำมากกว่าแค่ตรวจสอบความล้มเหลวของแอปพลิเคชันของคุณ โดยสามารถสร้างสำเนาของแอปพลิเคชันเพิ่มเติมเพื่อทำงานบนเครื่องหลายเครื่อง อัปเดตแอปพลิเคชัน หรือเรียกใช้แอปพลิเคชันหลายเวอร์ชันพร้อมกันได้
ดังนั้นจึงมีสาเหตุหลายประการที่ทำให้ Kubernetes สามารถยุติคอนเทนเนอร์ที่สมบูรณ์แข็งแรงได้ ตัวอย่างเช่น หากคุณอัปเกรดการปรับใช้งาน Kubernetes จะค่อยๆ หยุดพ็อดเก่าขณะเริ่มต้นพ็อดใหม่ หากคุณปิดโหนด Kubernetes จะหยุดเรียกใช้พ็อดทั้งหมดบนโหนดนั้น สุดท้ายนี้ หากโหนดทรัพยากรหมด Kubernetes จะปิดพ็อดทั้งหมดเพื่อเพิ่มทรัพยากรเหล่านั้น
ดังนั้นจึงจำเป็นอย่างยิ่งที่แอปพลิเคชันของคุณยุติการทำงานโดยมีผลกระทบต่อผู้ใช้น้อยที่สุดและมีเวลาการกู้คืนน้อยที่สุด ซึ่งหมายความว่าก่อนที่จะปิดระบบจะต้องบันทึกข้อมูลทั้งหมดที่ต้องบันทึก ปิดการเชื่อมต่อเครือข่ายทั้งหมด ทำงานที่เหลือให้เสร็จสิ้น และจัดการงานเร่งด่วนอื่น ๆ
ในทางปฏิบัติ หมายความว่าแอปพลิเคชันของคุณต้องสามารถจัดการข้อความ SIGTERM ซึ่งเป็นสัญญาณการยุติกระบวนการที่เป็นสัญญาณเริ่มต้นสำหรับยูทิลิตี้ kill บนระบบปฏิบัติการ Unix เมื่อได้รับข้อความนี้ แอปพลิเคชันควรจะปิดตัวลง
เมื่อ Kubernetes ตัดสินใจยุติพ็อด จะมีเหตุการณ์หลายอย่างเกิดขึ้น มาดูแต่ละขั้นตอนที่ Kubernetes ดำเนินการเมื่อปิดคอนเทนเนอร์หรือพ็อด
สมมติว่าเราต้องการยุติพ็อดอันใดอันหนึ่ง ณ จุดนี้ จะหยุดรับการรับส่งข้อมูลใหม่ - คอนเทนเนอร์ที่ทำงานอยู่ในพ็อดจะไม่ได้รับผลกระทบ แต่การรับส่งข้อมูลใหม่ทั้งหมดจะถูกบล็อก
มาดูที่ตะขอ preStop ซึ่งเป็นคำสั่งพิเศษหรือคำขอ HTTP ที่ส่งไปยังคอนเทนเนอร์ในพ็อด หากแอปพลิเคชันของคุณปิดระบบไม่ถูกต้องเมื่อได้รับ SIGTERM คุณสามารถใช้ preStop เพื่อปิดระบบได้อย่างถูกต้อง
โปรแกรมส่วนใหญ่จะออกอย่างสง่างามเมื่อได้รับสัญญาณ SIGTERM แต่หากคุณใช้โค้ดของบริษัทอื่นหรือบางระบบที่คุณควบคุมไม่ได้ทั้งหมด เบ็ดแบบ preStop เป็นวิธีที่ดีในการบังคับให้ปิดระบบอย่างค่อยเป็นค่อยไปโดยไม่ต้องเปลี่ยนแอปพลิเคชัน
หลังจากดำเนินการฮุกนี้ Kubernetes จะส่งสัญญาณ SIGTERM ไปยังคอนเทนเนอร์ในพ็อด เพื่อแจ้งให้ทราบว่าจะยกเลิกการเชื่อมต่อเร็วๆ นี้ เมื่อได้รับสัญญาณนี้ รหัสของคุณจะดำเนินการเข้าสู่กระบวนการปิดระบบ กระบวนการนี้อาจรวมถึงการหยุดการเชื่อมต่อที่มีอายุการใช้งานยาวนาน เช่น การเชื่อมต่อฐานข้อมูลหรือสตรีม WebSocket บันทึกสถานะปัจจุบัน และอื่นๆ ที่คล้ายคลึงกัน
แม้ว่าคุณจะใช้ preStop hook สิ่งสำคัญมากคือต้องตรวจสอบว่าเกิดอะไรขึ้นกับแอปพลิเคชันของคุณเมื่อคุณส่งสัญญาณ SIGTERM และลักษณะการทำงานของแอปพลิเคชัน เพื่อไม่ให้เหตุการณ์หรือการเปลี่ยนแปลงในการทำงานของระบบที่เกิดจากการปิดระบบพ็อดเกิดขึ้น แปลกใจสำหรับคุณ
ณ จุดนี้ Kubernetes จะรอตามระยะเวลาที่กำหนด เรียกว่า terminationGracePeriodSecond หรือระยะเวลาที่จะปิดระบบอย่างค่อยเป็นค่อยไปเมื่อได้รับสัญญาณ SIGTERM ก่อนที่จะดำเนินการต่อไป
ตามค่าเริ่มต้นช่วงเวลานี้คือ 30 วินาที สิ่งสำคัญคือต้องทราบว่าอุปกรณ์ทำงานขนานกับตะขอ preStop และสัญญาณ SIGTERM Kubernetes จะไม่รอให้ preStop hook และ SIGTERM สิ้นสุด หากแอปพลิเคชันของคุณออกก่อนที่ TerminationGracePeriod จะสิ้นสุดลง Kubernetes จะย้ายไปยังขั้นตอนถัดไปทันที ดังนั้นตรวจสอบว่าค่าของช่วงเวลานี้เป็นวินาทีไม่น้อยกว่าเวลาที่ต้องใช้ในการปิดพ็อดอย่างถูกต้อง และหากเกิน 30 ให้เพิ่มระยะเวลาเป็นค่าที่ต้องการใน YAML ในตัวอย่างที่ให้มา มันคือ 60
และสุดท้าย ขั้นตอนสุดท้ายคือหากคอนเทนเนอร์ยังคงทำงานอยู่หลังจากการยุติ GracePeriod คอนเทนเนอร์จะส่งสัญญาณ SIGKILL และจะถูกบังคับลบ ณ จุดนี้ Kubernetes จะล้างออบเจ็กต์พ็อดอื่นๆ ทั้งหมดด้วย
Kubernetes ยุติพ็อดด้วยเหตุผลหลายประการ ดังนั้นโปรดตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณยุติอย่างสง่างามไม่ว่าในกรณีใด ๆ เพื่อให้บริการมีเสถียรภาพ
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com