จะเกิดอะไรขึ้นเมื่อ kubernetes รีสตาร์ทคอนเทนเนอร์หรือคลัสเตอร์ถูกปรับขนาดขึ้น
เรากำลังใช้Helm Chartสำหรับการปรับใช้แอปพลิเคชันในคลัสเตอร์Kubernetes
เรามีบริการ statefulsets และ headless ในการเริ่มต้น mTLS เราได้สร้างชนิด 'job' และใน 'command' เรากำลังส่งสคริปต์ shell & python เป็นอาร์กิวเมนต์ และสร้างชนิด 'cronjob' เพื่ออัปเดตใบรับรอง
เราได้เขียน 'docker-entrypoint.sh' ไว้ใน 'docker image' สำหรับงานเริ่มต้นและสร้างใบรับรอง TLS
คำถามที่ถาม:
- ใคร (Helm Chart / Kubernetes) ดูแลการปรับขนาด / ตรวจสอบ / รีสตาร์ทคอนเทนเนอร์?
- มันปรับใช้อิมเมจนักเทียบท่าใหม่หรือไม่หากพ็อดล้มเหลว / รีสตาร์ท?
- นักเทียบท่าENTRYPOINT จะดำเนินการหลังจากที่คอนเทนเนอร์ล้มเหลว / รีสตาร์ทหรือไม่
- 'job' & 'cronjob' ทำงานหากคอนเทนเนอร์รีสตาร์ทหรือไม่
Kubernetes ทำตามขั้นตอนอื่น ๆ อย่างไร คุณจะแบ่งปันข้อมูลเชิงลึกของคอนเทนเนอร์ด้วยหรือไม่
คำตอบ
Kubernetes และไม่ใช่ helm จะรีสตาร์ทคอนเทนเนอร์ที่ล้มเหลวตามค่าเริ่มต้นเว้นแต่คุณจะตั้งค่าrestartPolicy: Neverใน pod spec
การรีสตาร์ทคอนเทนเนอร์จะเหมือนกับการเริ่มใช้งานในครั้งแรก ดังนั้นในการรีสตาร์ทคุณสามารถคาดหวังว่าสิ่งต่างๆจะเกิดขึ้นในลักษณะเดียวกับที่เกิดขึ้นเมื่อเริ่มต้นคอนเทนเนอร์ในครั้งแรก
เอเจนต์ kubelet ภายในที่รันในแต่ละโหนด kubernetes มอบหมายงานในการเริ่มต้นคอนเทนเนอร์ไปยังรันไทม์คอนเทนเนอร์ร้องเรียนของOCIเช่น docker, containerd เป็นต้นซึ่งจะหมุนอิมเมจนักเทียบท่าเป็นคอนเทนเนอร์บนโหนด
ฉันคาดหวังว่าสคริปต์จุดเข้าใช้งานจะถูกเรียกใช้ทั้งในการเริ่มการรีสตาร์ทคอนเทนเนอร์
มันปรับใช้อิมเมจนักเทียบท่าใหม่หรือไม่หากพ็อดล้มเหลว / รีสตาร์ท?
สร้างคอนเทนเนอร์ใหม่ที่มีอิมเมจเดียวกับที่ระบุในข้อมูลจำเพาะของพ็อด
'job' & 'cronjob' ทำงานหากคอนเทนเนอร์รีสตาร์ทหรือไม่
หากคอนเทนเนอร์ซึ่งเป็นส่วนหนึ่งของ cronjob ล้มเหลว kubernetes จะทำการรีสตาร์ทต่อไป (เว้นแต่restartPolicy: Neverในข้อมูลจำเพาะของพ็อด) คอนเทนเนอร์จนกว่างานจะไม่ถือว่าล้มเหลวตรวจสอบสิ่งนี้สำหรับวิธีทำให้ cronjob ไม่รีสตาร์ทคอนเทนเนอร์เมื่อเกิดความล้มเหลว คุณสามารถระบุbackoffLimitเพื่อควบคุมจำนวนครั้งที่จะลองใหม่ก่อนที่งานจะล้มเหลว
การขยายจะเทียบเท่ากับการตั้งเวลาและการเริ่มต้นอินสแตนซ์อื่นของคอนเทนเนอร์เดียวกันบนโหนด Kubernetes เดียวกันหรือทั้งหมด
ในฐานะที่เป็นหมายเหตุด้านข้างคุณควรใช้ Abstraction ในระดับที่สูงกว่าเช่นการปรับใช้แทนพ็อดเนื่องจากเมื่อพ็อดล้มเหลว Kubernetes จะพยายามรีสตาร์ทบนโหนดเดียวกัน แต่เมื่อการปรับใช้ล้มเหลว Kubernetes จะพยายามรีสตาร์ทในโหนดอื่นเช่นกันหากไม่สามารถทำได้ เริ่มพ็อดบนโหนดที่กำหนดเวลาไว้ปัจจุบัน