เคล็ดลับและคำแนะนำของ Kubernetes: คุณลักษณะของการปิดระบบอย่างสง่างามใน NGINX และ PHP-FPM

เงื่อนไขทั่วไปเมื่อใช้ CI/CD ใน Kubernetes: แอปพลิเคชันจะต้องไม่สามารถยอมรับคำขอใหม่ของไคลเอ็นต์ก่อนที่จะหยุดโดยสิ้นเชิง และที่สำคัญที่สุดคือต้องดำเนินการคำขอที่มีอยู่ให้เสร็จสมบูรณ์

การปฏิบัติตามเงื่อนไขนี้ช่วยให้คุณมีเวลาหยุดทำงานเป็นศูนย์ในระหว่างการปรับใช้ อย่างไรก็ตาม แม้ว่าจะใช้บันเดิลยอดนิยม (เช่น NGINX และ PHP-FPM) คุณก็อาจประสบปัญหาที่จะนำไปสู่ข้อผิดพลาดมากมายในการปรับใช้แต่ละครั้ง...

ทฤษฎี. พ็อดมีชีวิตอยู่อย่างไร

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

คุณควรจำไว้ว่าระยะเวลาผ่อนผันเริ่มต้นคือ 30 วินาที: หลังจากนี้พ็อดจะถูกยกเลิกและแอปพลิเคชันจะต้องมีเวลาในการดำเนินการตามคำขอทั้งหมดก่อนช่วงเวลานี้ หมายเหตุ: แม้ว่าคำขอใดๆ ที่ใช้เวลานานกว่า 5-10 วินาทีก็เป็นปัญหาอยู่แล้ว และการปิดระบบอย่างค่อยเป็นค่อยไปจะไม่ช่วยอีกต่อไป...

เพื่อให้เข้าใจได้ดีขึ้นว่าเกิดอะไรขึ้นเมื่อพ็อดสิ้นสุดลง เพียงดูแผนภาพต่อไปนี้:

A1, B1 - รับการเปลี่ยนแปลงเกี่ยวกับสถานะของเตาไฟ
A2 - ออกเดินทาง SIGTERM
B2 - การลบพ็อดออกจากจุดสิ้นสุด
B3 - การรับการเปลี่ยนแปลง (รายการปลายทางมีการเปลี่ยนแปลง)
B4 - อัปเดตกฎ iptables

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

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

ทฤษฎี. NGINX และ PHP-FPM ยุติกระบวนการอย่างไร

NGINX

เริ่มจาก NGINX กันก่อนเพราะทุกอย่างชัดเจนไม่มากก็น้อย เมื่อเจาะลึกถึงทฤษฎีแล้ว เราได้เรียนรู้ว่า NGINX มีกระบวนการหลักหนึ่งกระบวนการและมี “ผู้ปฏิบัติงาน” หลายคน ซึ่งเป็นกระบวนการย่อยที่ประมวลผลคำขอของลูกค้า มีตัวเลือกที่สะดวก: การใช้คำสั่ง nginx -s <SIGNAL> ยุติกระบวนการทั้งในโหมดปิดระบบอย่างรวดเร็วหรือโหมดปิดระบบอย่างนุ่มนวล แน่นอนว่านี่เป็นตัวเลือกหลังที่เราสนใจ

จากนั้นทุกอย่างก็ง่าย: คุณต้องเพิ่ม preStop-ตะขอ คำสั่งที่จะส่งสัญญาณการปิดเครื่องอย่างสง่างาม ซึ่งสามารถทำได้ในการปรับใช้ในบล็อกคอนเทนเนอร์:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

ตอนนี้ เมื่อพ็อดปิดตัวลง เราจะเห็นสิ่งต่อไปนี้ในบันทึกคอนเทนเนอร์ NGINX:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

และนี่จะหมายถึงสิ่งที่เราต้องการ: NGINX รอให้คำขอเสร็จสิ้น แล้วจึงปิดกระบวนการ อย่างไรก็ตามด้านล่างเราจะพิจารณาปัญหาทั่วไปด้วยซึ่งแม้จะมีคำสั่งก็ตาม nginx -s quit กระบวนการยุติอย่างไม่ถูกต้อง

และในขั้นตอนนี้ เราได้เสร็จสิ้นการใช้ NGINX แล้ว อย่างน้อยจากบันทึก คุณจะเข้าใจได้ว่าทุกอย่างทำงานได้ตามปกติ

การจัดการกับ PHP-FPM คืออะไร? มันจะจัดการกับการปิดระบบอย่างค่อยเป็นค่อยไปได้อย่างไร? ลองคิดดูสิ

PHP-FPM

ในกรณีของ PHP-FPM มีข้อมูลน้อยนิด หากคุณมุ่งเน้นที่ คู่มืออย่างเป็นทางการ ตาม PHP-FPM จะบอกว่ายอมรับสัญญาณ POSIX ต่อไปนี้:

1. SIGINT, SIGTERM — ปิดเครื่องอย่างรวดเร็ว
2. SIGQUIT — การปิดระบบอย่างสง่างาม (สิ่งที่เราต้องการ)

งานนี้ไม่จำเป็นต้องใช้สัญญาณที่เหลือ ดังนั้นเราจะละเว้นการวิเคราะห์ หากต้องการยุติกระบวนการอย่างถูกต้อง คุณจะต้องเขียน preStop hook ต่อไปนี้:

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

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

ฝึกฝน. ปัญหาที่อาจเกิดขึ้นกับการปิดระบบอย่างสง่างาม

NGINX

ประการแรก ควรจำ: นอกเหนือจากการดำเนินการคำสั่งแล้ว nginx -s quit มีอีกขั้นตอนหนึ่งที่ควรค่าแก่การใส่ใจ เราพบปัญหาที่ NGINX ยังคงส่ง SIGTERM แทนสัญญาณ SIGQUIT ส่งผลให้คำขอดำเนินการไม่ถูกต้อง กรณีที่คล้ายกันก็สามารถพบได้ เช่น ที่นี่. ขออภัย เราไม่สามารถระบุสาเหตุเฉพาะสำหรับลักษณะการทำงานนี้ได้ เนื่องจากมีข้อสงสัยเกี่ยวกับเวอร์ชัน NGINX แต่ไม่ได้รับการยืนยัน อาการคือพบข้อความในบันทึกคอนเทนเนอร์ NGINX: "เปิดซ็อกเก็ต #10 เหลือการเชื่อมต่อ 5"หลังจากนั้นพ็อดก็หยุด

เราสามารถสังเกตปัญหาดังกล่าวได้ เช่น จากการตอบสนองของ Ingress ที่เราต้องการ:

ตัวบ่งชี้รหัสสถานะ ณ เวลาที่ปรับใช้

ในกรณีนี้ เราได้รับรหัสข้อผิดพลาด 503 จาก Ingress เอง: ไม่สามารถเข้าถึงคอนเทนเนอร์ NGINX ได้ เนื่องจากไม่สามารถเข้าถึงได้อีกต่อไป หากคุณดูบันทึกของคอนเทนเนอร์ด้วย NGINX จะมีดังต่อไปนี้:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

หลังจากเปลี่ยนสัญญาณหยุด คอนเทนเนอร์จะเริ่มหยุดอย่างถูกต้อง: สิ่งนี้ได้รับการยืนยันจากข้อเท็จจริงที่ว่าไม่พบข้อผิดพลาด 503 อีกต่อไป

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

PHP-FPM... และอื่นๆ อีกมากมาย

ปัญหาเกี่ยวกับ PHP-FPM มีการอธิบายไว้ในลักษณะเล็กน้อย: มันไม่ได้รอให้กระบวนการลูกเสร็จสิ้น แต่จะยุติกระบวนการเหล่านั้นซึ่งเป็นสาเหตุที่ทำให้เกิดข้อผิดพลาด 502 ในระหว่างการปรับใช้และการดำเนินการอื่น ๆ มีรายงานข้อผิดพลาดหลายฉบับใน bugs.php.net ตั้งแต่ปี 2005 (เช่น ที่นี่ и ที่นี่) ซึ่งอธิบายปัญหานี้ แต่คุณมักจะไม่เห็นสิ่งใดในบันทึก: PHP-FPM จะประกาศการเสร็จสิ้นกระบวนการโดยไม่มีข้อผิดพลาดหรือการแจ้งเตือนจากบุคคลที่สาม

เป็นเรื่องที่ควรค่าแก่การชี้แจงว่าปัญหานั้นอาจขึ้นอยู่กับขอบเขตของแอปพลิเคชันไม่มากก็น้อย และอาจไม่แสดงออกมาให้เห็น เช่น ในการตรวจสอบ หากคุณพบปัญหาดังกล่าว วิธีแก้ปัญหาง่ายๆ จะต้องคำนึงถึงเป็นอันดับแรก: เพิ่มตะขอ preStop ด้วย sleep(30). มันจะช่วยให้คุณดำเนินการตามคำขอทั้งหมดก่อนหน้านี้ได้ (และเราไม่รับคำขอใหม่ เนื่องจาก pod แล้ว สามารถ ยกเลิก) และหลังจากผ่านไป 30 วินาที พ็อดจะลงท้ายด้วยสัญญาณ SIGTERM.

แต่กลับกลายเป็นว่า lifecycle สำหรับคอนเทนเนอร์จะมีลักษณะดังนี้:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

อย่างไรก็ตามเนื่องจากเวลา 30 วินาที sleep เรา เสถียร เราจะเพิ่มเวลาในการปรับใช้ เนื่องจากแต่ละพ็อดจะถูกยกเลิก ขั้นต่ำ 30 วินาทีซึ่งแย่มาก สิ่งที่สามารถทำได้เกี่ยวกับเรื่องนี้?

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

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

ดังนั้น เบ็ดเสร็จ ด้วยคำสั่งดังกล่าวแล้ว process_control_timeout คุณสามารถใช้โครงสร้างต่อไปนี้เพื่อ lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

ในกรณีนี้เราจะชดเชยความล่าช้าด้วยคำสั่ง sleep และไม่เพิ่มเวลาในการปรับใช้อย่างมีนัยสำคัญ เพราะท้ายที่สุดแล้ว ความแตกต่างระหว่าง 30 วินาทีกับอันหนึ่งเห็นได้ชัดเจนใช่ไหม.. อันที่จริงแล้ว มันคือ process_control_timeoutและ lifecycle ใช้เป็น "ตาข่ายนิรภัย" เท่านั้นในกรณีที่เกิดความล่าช้า

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

ฝึกฝน. โหลดการทดสอบเพื่อตรวจสอบการทำงานของพ็อด

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

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

ความแตกต่างอีกอย่างหนึ่งคือการดูบันทึกของคอนเทนเนอร์ระหว่างการยกเลิก มีข้อมูลเกี่ยวกับการปิดระบบอย่างค่อยเป็นค่อยไปบันทึกไว้หรือไม่ มีข้อผิดพลาดในบันทึกเมื่อเข้าถึงทรัพยากรอื่น ๆ (เช่น ไปยังคอนเทนเนอร์ PHP-FPM ที่อยู่ใกล้เคียง) หรือไม่ เกิดข้อผิดพลาดในแอปพลิเคชัน (เช่นในกรณีของ NGINX ที่อธิบายไว้ข้างต้น)? ฉันหวังว่าข้อมูลเบื้องต้นจากบทความนี้จะช่วยให้คุณเข้าใจได้ดีขึ้นว่าเกิดอะไรขึ้นกับคอนเทนเนอร์ระหว่างการยกเลิกคอนเทนเนอร์

ดังนั้นการทดสอบการทำงานครั้งแรกจึงเกิดขึ้นโดยไม่มี lifecycle และไม่มีคำสั่งเพิ่มเติมสำหรับแอปพลิเคชันเซิร์ฟเวอร์ (process_control_timeout ใน PHP-FPM) วัตถุประสงค์ของการทดสอบนี้คือเพื่อระบุจำนวนข้อผิดพลาดโดยประมาณ (และมีข้อผิดพลาดหรือไม่) นอกจากนี้ จากข้อมูลเพิ่มเติม คุณควรทราบว่าเวลาเฉลี่ยในการปรับใช้สำหรับแต่ละพ็อดคือประมาณ 5-10 วินาทีจนกว่าจะพร้อมใช้งานโดยสมบูรณ์ ผลลัพธ์คือ:

แผงข้อมูล Yandex.Tank แสดงข้อผิดพลาด 502 ที่เพิ่มขึ้นอย่างรวดเร็ว ซึ่งเกิดขึ้นในขณะที่ใช้งานและกินเวลาโดยเฉลี่ยสูงสุด 5 วินาที อาจเป็นเพราะคำขอที่มีอยู่ไปยังพ็อดเก่าถูกยกเลิกเมื่อถูกยกเลิก หลังจากนั้น ข้อผิดพลาด 503 ปรากฏขึ้น ซึ่งเป็นผลมาจากคอนเทนเนอร์ NGINX ที่หยุดทำงาน ซึ่งทำให้การเชื่อมต่อหลุดเนื่องจากแบ็กเอนด์ (ซึ่งทำให้ Ingress ไม่สามารถเชื่อมต่อได้)

มาดูวิธีการกัน process_control_timeout ใน PHP-FPM จะช่วยให้เรารอให้กระบวนการย่อยเสร็จสิ้น เช่น แก้ไขข้อผิดพลาดดังกล่าว ปรับใช้อีกครั้งโดยใช้คำสั่งนี้:

ไม่มีข้อผิดพลาดอีกต่อไปในระหว่างการปรับใช้ครั้งที่ 500! การปรับใช้สำเร็จ การปิดระบบเป็นไปอย่างราบรื่น

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

ข้อสรุป

หากต้องการยุติกระบวนการอย่างสวยงาม เราคาดหวังลักษณะการทำงานต่อไปนี้จากแอปพลิเคชัน:

1. รอสักครู่แล้วหยุดยอมรับการเชื่อมต่อใหม่
2. รอให้คำขอทั้งหมดเสร็จสิ้นและปิดการเชื่อมต่อ Keepalive ทั้งหมดที่ไม่ได้ดำเนินการตามคำขอ
3. สิ้นสุดกระบวนการของคุณ

อย่างไรก็ตาม ไม่ใช่ว่าทุกแอปพลิเคชันจะสามารถทำงานได้ในลักษณะนี้ วิธีแก้ไขปัญหาประการหนึ่งในความเป็นจริงของ Kubernetes คือ:

• เพิ่มตะขอก่อนหยุดที่จะรอสักครู่
• ศึกษาไฟล์การกำหนดค่าของแบ็กเอนด์ของเราเพื่อหาพารามิเตอร์ที่เหมาะสม

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

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

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

PS

อื่นๆ จากซีรี่ส์เคล็ดลับและเทคนิคของ K8s:

• «หน้าข้อผิดพลาดที่กำหนดเองใน NGINX Ingress";
• «เกี่ยวกับการจัดสรรโหนดและโหลดบนเว็บแอปพลิเคชัน";
• «เข้าถึงไซต์ dev";
• «การเร่งความเร็วบูตสแตรปสำหรับฐานข้อมูลขนาดใหญ่'

ที่มา: will.com