ระบบแบบกระจายอาจเป็นเรื่องยากในการจัดการเนื่องจากมีองค์ประกอบที่เคลื่อนไหวและเปลี่ยนแปลงจำนวนมาก ซึ่งทั้งหมดจำเป็นต้องทำงานอย่างถูกต้องเพื่อให้ระบบทำงานได้ หากองค์ประกอบใดองค์ประกอบหนึ่งล้มเหลว ระบบจะต้องตรวจจับ หลีกเลี่ยงและแก้ไข และทั้งหมดนี้จะต้องดำเนินการโดยอัตโนมัติ ในซีรีส์ Kubernetes Best Practices นี้ เราจะได้เรียนรู้วิธีตั้งค่าการทดสอบความพร้อมและความพร้อมใช้งานเพื่อทดสอบความสมบูรณ์ของคลัสเตอร์ Kubernetes
การตรวจสอบสภาพเป็นวิธีง่ายๆ ในการแจ้งให้ระบบทราบว่าอินสแตนซ์แอปพลิเคชันของคุณกำลังทำงานอยู่หรือไม่ หากอินสแตนซ์แอปพลิเคชันของคุณล่ม บริการอื่นๆ ไม่ควรเข้าถึงหรือส่งคำขอไปยังอินสแตนซ์ดังกล่าว แต่จะต้องส่งคำขอไปยังอินสแตนซ์อื่นของแอปพลิเคชันที่ทำงานอยู่แล้วหรือจะเปิดตัวในภายหลัง นอกจากนี้ ระบบควรคืนค่าฟังก์ชันการทำงานที่สูญเสียไปของแอปพลิเคชันของคุณ
ตามค่าเริ่มต้น Kubernetes จะเริ่มส่งการรับส่งข้อมูลไปยังพ็อดเมื่อคอนเทนเนอร์ทั้งหมดภายในพ็อดกำลังทำงาน และรีบูตคอนเทนเนอร์เมื่อคอนเทนเนอร์เสียหาย ลักษณะการทำงานของระบบเริ่มต้นนี้อาจดีพอที่จะเริ่มต้น แต่คุณสามารถปรับปรุงความน่าเชื่อถือของการปรับใช้ผลิตภัณฑ์ของคุณได้โดยใช้การตรวจสอบความเหมาะสมแบบกำหนดเอง
โชคดีที่ Kubernetes ทำให้การดำเนินการนี้ค่อนข้างง่าย ดังนั้นจึงไม่มีข้อแก้ตัวที่จะเพิกเฉยต่อการตรวจสอบเหล่านี้ Kubernetes มีการตรวจสุขภาพ XNUMX ประเภท และสิ่งสำคัญคือต้องเข้าใจความแตกต่างในการใช้งานแต่ละประเภท
การทดสอบความพร้อมออกแบบมาเพื่อบอก Kubernetes ว่าแอปพลิเคชันของคุณพร้อมที่จะรองรับการรับส่งข้อมูลแล้ว ก่อนที่จะอนุญาตให้บริการส่งการรับส่งข้อมูลไปยังพ็อด Kubernetes จะต้องตรวจสอบว่าการตรวจสอบความพร้อมสำเร็จหรือไม่ หากการทดสอบความพร้อมล้มเหลว Kubernetes จะหยุดส่งการรับส่งข้อมูลไปยังพ็อดจนกว่าการทดสอบจะผ่าน
การทดสอบความมีชีวิตชีวาจะบอก Kubernetes ว่าแอปพลิเคชันของคุณยังมีชีวิตอยู่หรือตายไปแล้ว ในกรณีแรก Kubernetes จะปล่อยมันไว้ตามลำพัง ในกรณีที่สองมันจะลบพ็อดที่ตายแล้วและแทนที่ด้วยอันใหม่
ลองจินตนาการถึงสถานการณ์ที่แอปพลิเคชันของคุณใช้เวลา 1 นาทีในการอุ่นเครื่องและเปิดใช้งาน บริการของคุณจะไม่เริ่มทำงานจนกว่าแอปพลิเคชันจะโหลดและทำงานอย่างสมบูรณ์ แม้ว่าเวิร์กโฟลว์จะเริ่มต้นแล้วก็ตาม นอกจากนี้ คุณจะประสบปัญหาหากคุณต้องการขยายการปรับใช้นี้เป็นหลายสำเนา เนื่องจากสำเนาเหล่านั้นไม่ควรรับการรับส่งข้อมูลจนกว่าจะพร้อมอย่างสมบูรณ์ อย่างไรก็ตาม ตามค่าเริ่มต้น Kubernetes จะเริ่มส่งการรับส่งข้อมูลทันทีที่กระบวนการภายในคอนเทนเนอร์เริ่มต้นขึ้น
เมื่อใช้การทดสอบความพร้อม Kubernetes จะรอจนกว่าแอปพลิเคชันจะทำงานโดยสมบูรณ์ก่อนจะอนุญาตให้บริการส่งการรับส่งข้อมูลไปยังสำเนาใหม่
ลองจินตนาการถึงสถานการณ์อื่นที่แอปพลิเคชันค้างเป็นเวลานานโดยหยุดการร้องขอการบริการ ในขณะที่กระบวนการยังคงทำงานต่อไป ตามค่าเริ่มต้น Kubernetes จะถือว่าทุกอย่างเรียบร้อยดี และส่งคำขอไปยังพ็อดที่ไม่ทำงานต่อไป แต่เมื่อใช้ Liveness Kubernetes จะตรวจพบว่าแอปพลิเคชันไม่ให้บริการคำขออีกต่อไป และจะรีสตาร์ทพ็อดที่ไม่ทำงานตามค่าเริ่มต้น
มาดูกันว่ามีการทดสอบความพร้อมและความมีชีวิตอย่างไร มีวิธีการทดสอบสามวิธี ได้แก่ HTTP, Command และ TCP คุณสามารถใช้รายการใดก็ได้เพื่อตรวจสอบ วิธีทดสอบผู้ใช้ที่พบบ่อยที่สุดคือโพรบ HTTP
แม้ว่าแอปพลิเคชันของคุณไม่ใช่เซิร์ฟเวอร์ HTTP คุณยังคงสามารถสร้างเซิร์ฟเวอร์ HTTP แบบน้ำหนักเบาภายในแอปพลิเคชันของคุณเพื่อโต้ตอบกับการทดสอบ Liveness หลังจากนี้ Kubernetes จะเริ่มส่ง Ping ไปที่พ็อด และหากการตอบสนองของ HTTP อยู่ในช่วง 200 หรือ 300 ms ก็จะบ่งบอกว่าพ็อดนั้นแข็งแรงดี มิฉะนั้น โมดูลจะถูกทำเครื่องหมายว่า "ไม่แข็งแรง"
สำหรับการทดสอบคำสั่ง Kubernetes จะรันคำสั่งภายในคอนเทนเนอร์ของคุณ หากคำสั่งส่งคืนด้วยรหัสทางออกเป็นศูนย์ คอนเทนเนอร์จะถูกทำเครื่องหมายว่าแข็งแรง มิฉะนั้น เมื่อได้รับหมายเลขสถานะทางออกตั้งแต่ 1 ถึง 255 คอนเทนเนอร์จะถูกทำเครื่องหมายว่า "ป่วย" วิธีการทดสอบนี้มีประโยชน์หากคุณไม่สามารถหรือไม่ต้องการเรียกใช้เซิร์ฟเวอร์ HTTP แต่สามารถเรียกใช้คำสั่งที่จะตรวจสอบความสมบูรณ์ของแอปพลิเคชันของคุณได้
กลไกการตรวจสอบขั้นสุดท้ายคือการทดสอบ TCP Kubernetes จะพยายามสร้างการเชื่อมต่อ TCP บนพอร์ตที่ระบุ หากสามารถทำได้ก็ถือว่าภาชนะนั้นแข็งแรง ถ้าไม่เช่นนั้นก็ถือว่าใช้งานไม่ได้ วิธีนี้อาจมีประโยชน์หากคุณใช้สถานการณ์ที่การทดสอบด้วยการร้องขอ HTTP หรือการดำเนินการคำสั่งทำงานได้ไม่ดีนัก ตัวอย่างเช่น บริการหลักสำหรับการตรวจสอบโดยใช้ TCP จะเป็น gRPC หรือ FTP
การทดสอบสามารถกำหนดค่าได้หลายวิธีโดยใช้พารามิเตอร์ที่แตกต่างกัน คุณสามารถระบุความถี่ที่ควรดำเนินการ เกณฑ์ความสำเร็จและความล้มเหลว และระยะเวลาในการรอการตอบสนอง สำหรับข้อมูลเพิ่มเติม โปรดดูเอกสารประกอบการทดสอบความพร้อมและความพร้อมใช้งาน อย่างไรก็ตาม มีจุดหนึ่งที่สำคัญมากในการตั้งค่าการทดสอบ Liveness นั่นคือการตั้งค่าเริ่มต้นของความล่าช้าในการทดสอบ InitialDelaySeconds ดังที่ได้กล่าวไปแล้ว ความล้มเหลวของการทดสอบนี้จะส่งผลให้มีการรีสตาร์ทโมดูล ดังนั้นคุณต้องตรวจสอบให้แน่ใจว่าการทดสอบไม่เริ่มต้นจนกว่าแอปพลิเคชันจะพร้อมใช้งาน มิฉะนั้นจะเริ่มวนซ้ำผ่านการรีสตาร์ท ฉันขอแนะนำให้ใช้เวลาเริ่มต้น P99 หรือเวลาเริ่มต้นแอปพลิเคชันโดยเฉลี่ยจากบัฟเฟอร์ อย่าลืมปรับค่านี้เมื่อเวลาเริ่มต้นของแอปพลิเคชันของคุณเร็วขึ้นหรือช้าลง
ผู้เชี่ยวชาญส่วนใหญ่จะยืนยันว่าการตรวจสุขภาพเป็นการตรวจสอบภาคบังคับสำหรับระบบแบบกระจายใดๆ และ 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