โหลดบาลานซ์และปรับขนาดการเชื่อมต่อที่มีอายุการใช้งานยาวนานใน Kubernetes

บทความนี้จะช่วยให้คุณเข้าใจวิธีการทำงานของการปรับสมดุลโหลดใน Kubernetes จะเกิดอะไรขึ้นเมื่อปรับขนาดการเชื่อมต่อที่มีอายุการใช้งานยาวนาน และเหตุใดคุณจึงควรพิจารณาการปรับสมดุลฝั่งไคลเอ็นต์หากคุณใช้ HTTP/2, gRPC, RSockets, AMQP หรือโปรโตคอลที่มีอายุการใช้งานยาวนานอื่นๆ . 

เล็กน้อยเกี่ยวกับวิธีการกระจายการรับส่งข้อมูลใน Kubernetes 

Kubernetes นำเสนอแนวคิดที่สะดวกสองประการสำหรับการปรับใช้แอปพลิเคชัน: บริการและการปรับใช้

การปรับใช้จะอธิบายว่าแอปพลิเคชันของคุณควรทำงานอย่างไรและจำนวนเท่าใดในเวลาที่กำหนด แต่ละแอปพลิเคชันใช้งานเป็นพ็อดและได้รับการกำหนดที่อยู่ IP

บริการต่างๆ มีฟังก์ชันคล้ายกับโหลดบาลานเซอร์ ได้รับการออกแบบมาเพื่อกระจายการรับส่งข้อมูลไปยังหลายพ็อด

มาดูกันว่ามีลักษณะอย่างไร.

1. ในแผนภาพด้านล่าง คุณจะเห็นสามอินสแตนซ์ของแอปพลิเคชันเดียวกันและตัวจัดสรรภาระงาน:

   

2. โหลดบาลานเซอร์เรียกว่าบริการและได้รับการกำหนดที่อยู่ IP คำขอที่เข้ามาใด ๆ จะถูกเปลี่ยนเส้นทางไปยังหนึ่งในพ็อด:

   

3. สถานการณ์จำลองการปรับใช้กำหนดจำนวนอินสแตนซ์ของแอปพลิเคชัน คุณแทบจะไม่ต้องขยายโดยตรงภายใต้:

   

4. แต่ละพ็อดได้รับการกำหนดที่อยู่ IP ของตัวเอง:

   

การคิดว่าบริการต่างๆ เป็นการรวบรวมที่อยู่ IP นั้นมีประโยชน์ แต่ละครั้งที่คุณเข้าถึงบริการ ที่อยู่ IP หนึ่งรายการจะถูกเลือกจากรายการและใช้เป็นที่อยู่ปลายทาง

มีลักษณะเช่นนี้.

1. ได้รับคำขอ curl 10.96.45.152 สำหรับบริการ:

   

2. บริการเลือกหนึ่งในสามที่อยู่พ็อดเป็นปลายทาง:

   

3. การรับส่งข้อมูลถูกเปลี่ยนเส้นทางไปยังพ็อดเฉพาะ:

   

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

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

นอกจากนี้ ส่วนหน้าไม่ทราบอะไรเกี่ยวกับที่อยู่ของพ็อดที่ให้บริการแบ็กเอนด์

เมื่อส่วนหน้าส่งคำขอไปยังส่วนหลัง จะใช้ที่อยู่ IP ของบริการส่วนหลังซึ่งไม่มีการเปลี่ยนแปลง

นี่คือวิธีที่มันดู.

1. ภายใต้ 1 ร้องขอองค์ประกอบแบ็กเอนด์ภายใน แทนที่จะเลือกอันใดอันหนึ่งสำหรับแบ็กเอนด์ มันจะส่งคำขอไปยังบริการ:

   

2. บริการจะเลือกหนึ่งในพ็อดแบ็กเอนด์เป็นที่อยู่ปลายทาง:

   

3. การรับส่งข้อมูลเปลี่ยนจาก Pod 1 ถึง Pod 5 ที่เลือกโดยบริการ:

   

4. อายุต่ำกว่า 1 ปีไม่ทราบแน่ชัดว่ามีพ็อดที่อายุต่ำกว่า 5 จำนวนเท่าใดที่ซ่อนอยู่หลังบริการ:

   

แต่บริการจะกระจายคำขออย่างไรกันแน่? ดูเหมือนว่าจะใช้การสมดุลแบบ Round-Robin หรือไม่? ลองคิดดูสิ 

การปรับสมดุลในบริการ Kubernetes

ไม่มีบริการ Kubernetes ไม่มีกระบวนการสำหรับบริการที่กำหนดที่อยู่ IP และพอร์ต

คุณสามารถตรวจสอบสิ่งนี้ได้โดยการล็อกอินเข้าสู่โหนดใดๆ ในคลัสเตอร์ และรันคำสั่ง netstat -ntlp

คุณจะไม่สามารถค้นหาที่อยู่ IP ที่จัดสรรให้กับบริการได้

ที่อยู่ IP ของบริการอยู่ในชั้นควบคุม ในตัวควบคุม และบันทึกไว้ในฐานข้อมูล - ฯลฯ ส่วนประกอบอื่นใช้ที่อยู่เดียวกัน - kube-proxy
Kube-proxy รับรายการที่อยู่ IP สำหรับบริการทั้งหมดและสร้างชุดกฎ iptables ในแต่ละโหนดในคลัสเตอร์

กฎเหล่านี้กล่าวว่า: “หากเราเห็นที่อยู่ IP ของบริการ เราจำเป็นต้องแก้ไขที่อยู่ปลายทางของคำขอและส่งไปยังหนึ่งในพ็อด”

ที่อยู่ IP ของบริการจะใช้เป็นจุดเริ่มต้นเท่านั้น และไม่ได้ให้บริการโดยกระบวนการใด ๆ ที่รับฟังที่อยู่ IP และพอร์ตนั้น

ลองดูที่นี้. 

1. พิจารณาคลัสเตอร์ของสามโหนด แต่ละโหนดมีพ็อด:

   

2. ฝักผูกทาสีเบจเป็นส่วนหนึ่งของบริการ เนื่องจากบริการไม่มีอยู่เป็นกระบวนการ จึงแสดงเป็นสีเทา:

   

3. พ็อดแรกร้องขอบริการและต้องไปที่หนึ่งในพ็อดที่เกี่ยวข้อง:

   

4. แต่ไม่มีบริการ กระบวนการไม่มีอยู่ มันทำงานอย่างไร?

   

5. ก่อนที่คำขอจะออกจากโหนด จะต้องผ่านกฎ iptables:

   

6. กฎ iptables รู้ว่าไม่มีบริการดังกล่าว และแทนที่ที่อยู่ IP ด้วยหนึ่งในที่อยู่ IP ของพ็อดที่เชื่อมโยงกับบริการนั้น:

   

7. คำขอได้รับที่อยู่ IP ที่ถูกต้องเป็นที่อยู่ปลายทางและได้รับการประมวลผลตามปกติ:

   

8. ขึ้นอยู่กับโทโพโลยีเครือข่าย ในที่สุดคำขอก็ไปถึงพ็อด:

   

iptables โหลดบาลานซ์ได้ไหม?

ไม่ iptables ใช้สำหรับการกรองและไม่ได้ออกแบบมาเพื่อการปรับสมดุล

อย่างไรก็ตาม เป็นไปได้ที่จะเขียนชุดกฎที่ใช้การได้ หลอกสมดุล.

และนี่คือสิ่งที่นำมาใช้ใน Kubernetes

หากคุณมีสามพ็อด kube-proxy จะเขียนกฎต่อไปนี้:

1. เลือกหมวดย่อยแรกที่มีความน่าจะเป็น 33% มิฉะนั้นไปที่กฎถัดไป
2. เลือกอันที่สองที่มีความน่าจะเป็น 50% มิฉะนั้นไปที่กฎถัดไป
3. เลือกอันที่สามใต้

ระบบนี้ส่งผลให้แต่ละพ็อดถูกเลือกด้วยความน่าจะเป็น 33%

และไม่มีการรับประกันว่า Pod 2 จะถูกเลือกเป็นรายถัดไปหลังจาก Pod 1

หมายเหตุ: iptables ใช้โมดูลทางสถิติที่มีการแจกแจงแบบสุ่ม ดังนั้นอัลกอริธึมการปรับสมดุลจึงขึ้นอยู่กับการเลือกแบบสุ่ม

เมื่อคุณเข้าใจวิธีการทำงานของบริการแล้ว มาดูสถานการณ์บริการที่น่าสนใจเพิ่มเติมกัน

การเชื่อมต่อที่มีอายุการใช้งานยาวนานใน Kubernetes จะไม่ปรับขนาดตามค่าเริ่มต้น

คำขอ HTTP แต่ละรายการจากส่วนหน้าถึงส่วนหลังจะให้บริการโดยการเชื่อมต่อ TCP ที่แยกจากกัน ซึ่งเปิดและปิด

หากส่วนหน้าส่งคำขอ 100 รายการต่อวินาทีไปยังส่วนหลัง การเชื่อมต่อ TCP ที่แตกต่างกัน 100 รายการจะถูกเปิดและปิด

คุณสามารถลดเวลาการประมวลผลคำขอและโหลดได้โดยเปิดการเชื่อมต่อ TCP เดียวและใช้สำหรับคำขอ HTTP ที่ตามมาทั้งหมด

โปรโตคอล HTTP มีคุณลักษณะที่เรียกว่า HTTP Keep-alive หรือการใช้การเชื่อมต่อซ้ำ ในกรณีนี้ การเชื่อมต่อ TCP เดียวใช้ในการส่งและรับคำขอและการตอบกลับ HTTP หลายรายการ:

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

การตั้งค่านั้นง่ายและสามารถเข้าถึงได้สำหรับภาษาและสภาพแวดล้อมการเขียนโปรแกรมส่วนใหญ่

ต่อไปนี้เป็นลิงก์ไปยังตัวอย่างในภาษาต่างๆ:

• รักษาชีวิตใน Node.js
• Keep-alive ใน Spring boot
• Keep-alive ใน Python
• มีชีวิตอยู่ต่อไปใน .NET

จะเกิดอะไรขึ้นหากเราใช้ Keep-alive ในบริการ Kubernetes
สมมติว่าทั้งส่วนหน้าและส่วนหลังสนับสนุนยังคงอยู่

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

ต่างจากสถานการณ์ปกติที่การเชื่อมต่อ TCP ถูกปิดหลังจากได้รับการตอบสนอง ตอนนี้การเชื่อมต่อ TCP จะถูกปิดไว้สำหรับคำขอ HTTP เพิ่มเติม

จะเกิดอะไรขึ้นหากส่วนหน้าส่งคำขอเพิ่มเติมไปยังส่วนหลัง

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

iptables ไม่ควรกระจายการรับส่งข้อมูลซ้ำหรือไม่

ไม่ใช่ในกรณีนี้

เมื่อสร้างการเชื่อมต่อ TCP จะต้องผ่านกฎ iptables ซึ่งเลือกแบ็กเอนด์เฉพาะที่การรับส่งข้อมูลจะไป

เนื่องจากคำขอที่ตามมาทั้งหมดอยู่ในการเชื่อมต่อ TCP ที่เปิดอยู่แล้ว กฎ iptables จะไม่ถูกเรียกอีกต่อไป

มาดูกันว่ามีลักษณะอย่างไร.

1. พ็อดแรกส่งคำขอไปยังบริการ:

   

2. คุณรู้อยู่แล้วว่าจะเกิดอะไรขึ้นต่อไป ไม่มีบริการ แต่มีกฎ iptables ที่จะประมวลผลคำขอ:

   

3. ระบบจะเลือกหนึ่งในพ็อดแบ็กเอนด์เป็นที่อยู่ปลายทาง:

   

4. คำขอไปถึงพ็อด ณ จุดนี้ การเชื่อมต่อ TCP แบบถาวรระหว่างพ็อดทั้งสองจะถูกสร้างขึ้น:

   

5. คำขอใด ๆ ที่ตามมาจากพ็อดแรกจะต้องผ่านการเชื่อมต่อที่สร้างไว้แล้ว:

   

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

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

สามารถแก้ไขได้หรือไม่

เนื่องจาก Kubernetes ไม่ทราบวิธีสร้างสมดุลการเชื่อมต่อแบบถาวร งานนี้จึงตกเป็นหน้าที่ของคุณ

บริการคือชุดของที่อยู่ IP และพอร์ตที่เรียกว่าอุปกรณ์ปลายทาง

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

หรือสมัครเพิ่มเติม อัลกอริธึมการปรับสมดุลที่ซับซ้อน.

รหัสฝั่งไคลเอ็นต์ที่รับผิดชอบในการปรับสมดุลควรเป็นไปตามตรรกะนี้:

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

หน้าตาก็จะประมาณนี้.

1. แทนที่จะให้พ็อดแรกที่ส่งคำขอไปยังบริการ คุณสามารถปรับสมดุลคำขอในฝั่งไคลเอ็นต์ได้:

   

2. คุณต้องเขียนโค้ดเพื่อถามว่าพ็อดใดเป็นส่วนหนึ่งของบริการ:

   

3. เมื่อคุณมีรายการแล้ว ให้บันทึกไว้ในฝั่งไคลเอ็นต์และใช้เพื่อเชื่อมต่อกับพ็อด:

   

4. คุณมีหน้าที่รับผิดชอบอัลกอริธึมการปรับสมดุลโหลด:

   

ตอนนี้คำถามเกิดขึ้น: ปัญหานี้ใช้ได้กับ HTTP Keep-alive เท่านั้นหรือไม่

การทำโหลดบาลานซ์ฝั่งไคลเอ็นต์

HTTP ไม่ใช่โปรโตคอลเดียวที่สามารถใช้การเชื่อมต่อ TCP แบบถาวรได้

หากแอปพลิเคชันของคุณใช้ฐานข้อมูล การเชื่อมต่อ TCP จะไม่เปิดขึ้นทุกครั้งที่คุณต้องการส่งคำขอหรือดึงเอกสารจากฐานข้อมูล 

แต่จะมีการเปิดและใช้การเชื่อมต่อ TCP แบบถาวรกับฐานข้อมูลแทน

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

แบบจำลองฐานข้อมูลหนึ่งจะถูกโหลดมากกว่าแบบจำลองฐานข้อมูลอื่น Kube-proxy และ Kubernetes จะไม่ช่วยสร้างสมดุลการเชื่อมต่อ คุณต้องดูแลสมดุลการสืบค้นกับฐานข้อมูลของคุณ

ขึ้นอยู่กับไลบรารีที่คุณใช้เชื่อมต่อกับฐานข้อมูล คุณอาจมีตัวเลือกที่แตกต่างกันสำหรับการแก้ไขปัญหานี้

ด้านล่างนี้คือตัวอย่างการเข้าถึงคลัสเตอร์ฐานข้อมูล MySQL จาก Node.js:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

มีโปรโตคอลอื่นๆ อีกมากมายที่ใช้การเชื่อมต่อ TCP แบบถาวร:

• WebSockets และ WebSockets ที่ปลอดภัย
• HTTP / 2
• ก.ร.ป
• อาร์ซ็อกเก็ต
• แอมคิวพี

คุณควรจะคุ้นเคยกับโปรโตคอลเหล่านี้ส่วนใหญ่แล้ว

แต่หากโปรโตคอลเหล่านี้ได้รับความนิยมมาก เหตุใดจึงไม่มีโซลูชันการปรับสมดุลที่เป็นมาตรฐาน เหตุใดตรรกะของไคลเอ็นต์จึงต้องเปลี่ยนแปลง มีโซลูชัน Kubernetes ดั้งเดิมหรือไม่

Kube-proxy และ iptables ได้รับการออกแบบมาเพื่อครอบคลุมกรณีการใช้งานทั่วไปส่วนใหญ่เมื่อปรับใช้กับ Kubernetes ทั้งนี้เพื่อความสะดวก

หากคุณกำลังใช้บริการเว็บที่เปิดเผย REST API คุณโชคดี ในกรณีนี้ การเชื่อมต่อ TCP แบบถาวรจะไม่ถูกใช้ คุณสามารถใช้บริการ Kubernetes ใดก็ได้

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

อย่างไรก็ตาม มีตัวเลือกที่สามารถช่วยได้อย่างแน่นอน

ปรับสมดุลการเชื่อมต่อระยะยาวใน Kubernetes

มีบริการสี่ประเภทใน Kubernetes:

1. คลัสเตอร์ไอพี
2. โหนดพอร์ต
3. โหลดบาลานเซอร์
4. หัวขาด

บริการสามรายการแรกทำงานตามที่อยู่ IP เสมือน ซึ่ง kube-proxy ใช้เพื่อสร้างกฎ iptables แต่พื้นฐานพื้นฐานของบริการทั้งหมดคือบริการแบบไม่มีหัว

บริการ headless ไม่มีที่อยู่ IP ใด ๆ เชื่อมโยงอยู่ และมีเพียงกลไกในการดึงรายการที่อยู่ IP และพอร์ตของพ็อด (จุดสิ้นสุด) ที่เชื่อมโยงอยู่เท่านั้น

บริการทั้งหมดจะขึ้นอยู่กับบริการที่ไม่มีหัว

บริการ ClusterIP เป็นบริการแบบไม่มีส่วนหัวที่มีการเพิ่มเติมบางอย่าง: 

1. เลเยอร์การจัดการจะกำหนดที่อยู่ IP ให้กับมัน
2. Kube-proxy สร้างกฎ iptables ที่จำเป็น

วิธีนี้ทำให้คุณสามารถเพิกเฉยต่อ kube-proxy และใช้รายการตำแหน่งข้อมูลที่ได้รับจากบริการ headless โดยตรงเพื่อปรับสมดุลการโหลดแอปพลิเคชันของคุณ

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

หากแอปพลิเคชันของคุณถูกปรับใช้แล้ว งานนี้อาจดูเหมือนเป็นไปไม่ได้ อย่างไรก็ตาม มีตัวเลือกอื่นอยู่

เซอร์วิสเมชจะช่วยคุณได้

คุณอาจสังเกตแล้วว่ากลยุทธ์การปรับสมดุลโหลดฝั่งไคลเอ็นต์ค่อนข้างเป็นมาตรฐาน

เมื่อแอปพลิเคชันเริ่มต้นขึ้น มันจะ:

1. รับรายการที่อยู่ IP จากบริการ
2. เปิดและรักษาพูลการเชื่อมต่อ
3. อัพเดตพูลเป็นระยะโดยการเพิ่มหรือลบจุดสิ้นสุด

เมื่อแอปพลิเคชันต้องการส่งคำขอ มันจะ:

1. เลือกการเชื่อมต่อที่ใช้ได้โดยใช้ตรรกะบางอย่าง (เช่น Round-robin)
2. ดำเนินการตามคำขอ

ขั้นตอนเหล่านี้ใช้ได้กับทั้งการเชื่อมต่อ WebSockets, gRPC และ AMQP

คุณสามารถแยกตรรกะนี้ออกเป็นไลบรารีแยกต่างหากและใช้ในแอปพลิเคชันของคุณได้

อย่างไรก็ตาม คุณสามารถใช้ Service Mesh เช่น Istio หรือ Linkerd แทนได้

Service Mesh เพิ่มแอปพลิเคชันของคุณด้วยกระบวนการที่:

1. ค้นหาที่อยู่ IP ของบริการโดยอัตโนมัติ
2. ทดสอบการเชื่อมต่อ เช่น WebSockets และ gRPC
3. ปรับสมดุลคำขอโดยใช้โปรโตคอลที่ถูกต้อง

Service Mesh ช่วยจัดการการรับส่งข้อมูลภายในคลัสเตอร์ แต่ค่อนข้างใช้ทรัพยากรมาก ตัวเลือกอื่นๆ กำลังใช้ไลบรารีของบุคคลที่สาม เช่น Netflix Ribbon หรือพร็อกซีแบบตั้งโปรแกรมได้ เช่น Envoy

จะเกิดอะไรขึ้นหากคุณเพิกเฉยต่อปัญหาเรื่องความสมดุล

คุณสามารถเลือกที่จะไม่ใช้การจัดสรรภาระงานได้แต่ยังคงไม่สังเกตเห็นการเปลี่ยนแปลงใดๆ ลองดูสถานการณ์การทำงานบางประการ

หากคุณมีไคลเอนต์มากกว่าเซิร์ฟเวอร์ นี่ไม่ใช่ปัญหาใหญ่

สมมติว่ามีไคลเอนต์ห้าเครื่องที่เชื่อมต่อกับเซิร์ฟเวอร์สองเครื่อง แม้ว่าจะไม่มีการปรับสมดุล แต่เซิร์ฟเวอร์ทั้งสองจะถูกนำมาใช้:

การเชื่อมต่ออาจไม่กระจายเท่าๆ กัน: อาจมีไคลเอนต์สี่เครื่องที่เชื่อมต่อกับเซิร์ฟเวอร์เดียวกัน แต่มีโอกาสที่ดีที่จะใช้ทั้งสองเซิร์ฟเวอร์

สิ่งที่เป็นปัญหามากกว่าคือสถานการณ์ที่ตรงกันข้าม

หากคุณมีไคลเอนต์น้อยลงและมีเซิร์ฟเวอร์มากขึ้น ทรัพยากรของคุณอาจถูกใช้งานน้อยเกินไปและอาจทำให้เกิดปัญหาคอขวด

สมมติว่ามีไคลเอนต์สองเครื่องและเซิร์ฟเวอร์ห้าเครื่อง ในกรณีที่ดีที่สุด จะมีการเชื่อมต่อถาวรสองครั้งไปยังเซิร์ฟเวอร์สองเครื่องจากห้าเครื่อง

เซิร์ฟเวอร์ที่เหลือจะไม่ได้ใช้งาน:

หากเซิร์ฟเวอร์ทั้งสองนี้ไม่สามารถรองรับคำขอของไคลเอ็นต์ได้ การปรับขนาดแนวนอนจะไม่ช่วยอะไร

ข้อสรุป

บริการ Kubernetes ได้รับการออกแบบมาเพื่อทำงานในสถานการณ์แอปพลิเคชันเว็บมาตรฐานส่วนใหญ่

อย่างไรก็ตาม เมื่อคุณเริ่มทำงานกับแอปพลิเคชันโปรโตคอลที่ใช้การเชื่อมต่อ TCP แบบถาวร เช่น ฐานข้อมูล gRPC หรือ WebSockets บริการจะไม่เหมาะสมอีกต่อไป Kubernetes ไม่มีกลไกภายในสำหรับปรับสมดุลการเชื่อมต่อ TCP แบบถาวร

ซึ่งหมายความว่าคุณต้องเขียนแอปพลิเคชันโดยคำนึงถึงการปรับสมดุลฝั่งไคลเอ็นต์

แปลโดยทีมงาน Kubernetes aaS จาก Mail.ru.

มีอะไรอีกให้อ่านในหัวข้อ:

1. การปรับขนาดอัตโนมัติสามระดับใน Kubernetes และวิธีใช้งานอย่างมีประสิทธิภาพ. 
2. Kubernetes ด้วยจิตวิญญาณแห่งการละเมิดลิขสิทธิ์พร้อมเทมเพลตสำหรับการนำไปปฏิบัติ.
3. ช่องโทรเลขของเราเกี่ยวกับการเปลี่ยนแปลงทางดิจิทัล.

ที่มา: will.com