การประเมินประสิทธิภาพ CNI สำหรับ Kubernetes บนเครือข่าย 10G (สิงหาคม 2020)

TL; DR: CNI ทั้งหมดทำงานตามที่ควรจะเป็น ยกเว้น Kube-Router และ Kube-OVN, Calico ดีที่สุด ยกเว้นการตรวจจับ MTU อัตโนมัติ

บทความ - อัพเดทการตรวจสอบที่ผ่านมาของฉัน (2018 и 2019) ในขณะที่ทดสอบฉันใช้ Kubernetes 1.19 บน Ubuntu 18.04 พร้อม CNI ที่อัปเดต ณ เดือนสิงหาคม 2020

ก่อนที่เราจะเจาะลึกเรื่องเมตริก...

มีอะไรใหม่ตั้งแต่เดือนเมษายน 2019?

• สามารถทดสอบบนคลัสเตอร์ของคุณเอง: คุณสามารถทำการทดสอบบนคลัสเตอร์ของคุณเองโดยใช้เครื่องมือของเรา เกณฑ์มาตรฐานเครือข่าย Kubernetes: ลูกบิด
• มีสมาชิกใหม่ปรากฏตัวแล้ว
  • รายการ จาก VMware Tanzu
  • คิวบ์-OVN จาก alauda.io
• สถานการณ์ใหม่: การตรวจสอบปัจจุบันเรียกใช้การทดสอบประสิทธิภาพเครือข่าย "Pod-to-Pod" และมีการเพิ่มสคริปต์ "Pod-to-Service" ใหม่ที่ทำการทดสอบใกล้กับสภาวะโลกแห่งความเป็นจริงมากขึ้น ในทางปฏิบัติ Pod ของคุณที่มี API จะทำงานร่วมกับฐานเป็นบริการ ไม่ใช่ผ่านที่อยู่ IP ของ Pod (แน่นอนว่าเราจะตรวจสอบทั้ง TCP และ UDP สำหรับทั้งสองสถานการณ์)
• การใช้ทรัพยากร: ขณะนี้การทดสอบแต่ละครั้งมีการเปรียบเทียบทรัพยากรของตัวเอง
• การลบการทดสอบแอปพลิเคชันออก: เราไม่ทำการทดสอบ HTTP, FTP และ SCP อีกต่อไป เนื่องจากความร่วมมือที่ประสบความสำเร็จของเรากับชุมชนและผู้ดูแล CNI ได้ค้นพบช่องว่างระหว่างผลลัพธ์ iperf บน TCP และผลลัพธ์ของ curl เนื่องจากความล่าช้าในการเริ่มต้น CNI (สองสามวินาทีแรกของ Pod ซึ่งไม่ปกติในสภาวะจริง)
• โอเพ่นซอร์ส: แหล่งทดสอบทั้งหมด (สคริปต์ การตั้งค่า yml และข้อมูล "ดิบ") ดั้งเดิมมีให้ใช้งาน ที่นี่

โปรโตคอลการทดสอบอ้างอิง

โปรโตคอลมีการอธิบายโดยละเอียด ที่นี่โปรดทราบว่าบทความนี้เกี่ยวกับ Ubuntu 18.04 พร้อมเคอร์เนลเริ่มต้น

การเลือก CNI เพื่อการประเมิน

การทดสอบนี้มีวัตถุประสงค์เพื่อเปรียบเทียบ CNI ที่กำหนดค่าด้วยไฟล์ yaml ไฟล์เดียว (ดังนั้นจึงไม่รวมไฟล์ที่ติดตั้งโดยสคริปต์ทั้งหมด เช่น VPP และอื่นๆ)

CNI ที่เราเลือกไว้เพื่อการเปรียบเทียบ:

• แอนเทรีย v.0.9.1
• ผ้าดิบ v3.16
• Canal v3.16 (เครือข่ายผ้าสักหลาด + นโยบายเครือข่ายผ้าดิบ)
• ซีเลียม 1.8.2
• ผ้าสักหลาด 0.12.0
• เราเตอร์ Kube ล่าสุด (2020–08–25)
• วีฟเน็ต 2.7.0

การกำหนดค่า MTU สำหรับ CNI

ก่อนอื่น เราตรวจสอบผลกระทบของการตรวจจับ MTU อัตโนมัติต่อประสิทธิภาพ TCP:

ผลกระทบของ MTU ต่อประสิทธิภาพ TCP

พบช่องว่างที่ใหญ่กว่าเมื่อใช้ UDP:

ผลกระทบของ MTU ต่อประสิทธิภาพของ UDP

เมื่อพิจารณาถึงผลกระทบด้านประสิทธิภาพอย่างมากที่เปิดเผยในการทดสอบ เราต้องการส่งจดหมายแห่งความหวังไปยังผู้ดูแล CNI ทุกคน: โปรดเพิ่มการตรวจจับ MTU อัตโนมัติให้กับ CNI คุณจะช่วยลูกแมว ยูนิคอร์น และแม้แต่ตัวที่น่ารักที่สุด: Devop ตัวน้อย

อย่างไรก็ตาม หากคุณต้องการใช้ CNI โดยไม่รองรับการตรวจจับ MTU อัตโนมัติ คุณสามารถกำหนดค่าด้วยตนเองเพื่อให้ได้ประสิทธิภาพ โปรดทราบว่าสิ่งนี้ใช้ได้กับ Calico, Canal และ WeaveNet

คำขอเล็กๆ น้อยๆ ของฉันถึง CNI ที่แนบมาด้วย...

การทดสอบ CNI: ข้อมูลดิบ

ในส่วนนี้ เราจะเปรียบเทียบ CNI กับ MTU ที่ถูกต้อง (กำหนดโดยอัตโนมัติหรือตั้งค่าด้วยตนเอง) เป้าหมายหลักที่นี่คือการแสดงข้อมูลดิบในรูปแบบกราฟ

ตำนานสี:

• สีเทา - ตัวอย่าง (เช่น เหล็กเปลือย)
• สีเขียว - แบนด์วิธสูงกว่า 9500 Mbps
• สีเหลือง - แบนด์วิดธ์สูงกว่า 9000 Mbps
• สีส้ม - แบนด์วิดธ์สูงกว่า 8000 Mbps
• สีแดง - แบนด์วิดท์ต่ำกว่า 8000 Mbps
• สีน้ำเงิน - เป็นกลาง (ไม่เกี่ยวข้องกับแบนด์วิธ)

ปริมาณการใช้ทรัพยากรที่ไม่มีการโหลด

ก่อนอื่น ให้ตรวจสอบปริมาณการใช้ทรัพยากรเมื่อคลัสเตอร์ “อยู่ในโหมดสลีป”

ปริมาณการใช้ทรัพยากรที่ไม่มีการโหลด

พ็อดต่อพ็อด

สถานการณ์นี้สันนิษฐานว่า Pod ไคลเอนต์เชื่อมต่อโดยตรงกับเซิร์ฟเวอร์ Pod โดยใช้ที่อยู่ IP

สถานการณ์แบบพ็อดทูพ็อด

TCP

ผลลัพธ์ TCP ของ Pod-to-Pod และการใช้ทรัพยากรที่เกี่ยวข้อง:

UDP

ผลลัพธ์ UDP แบบ Pod-to-Pod และการใช้ทรัพยากรที่เกี่ยวข้อง:

พ็อดทูเซอร์วิส

ส่วนนี้เกี่ยวข้องกับกรณีการใช้งานจริง พ็อดไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์พ็อดผ่านบริการ ClusterIP

สคริปต์ Pod-to-Service

TCP

ผลลัพธ์ TCP ของ Pod-to-Service และการใช้ทรัพยากรที่เกี่ยวข้อง:

UDP

ผลลัพธ์ UDP ของ Pod-to-Service และการใช้ทรัพยากรที่เกี่ยวข้อง:

การสนับสนุนนโยบายเครือข่าย

สิ่งเดียวที่ไม่สนับสนุนการเมืองคือผ้าสักหลาด อื่นๆ ทั้งหมดใช้นโยบายเครือข่ายอย่างถูกต้อง รวมถึงขาเข้าและขาออก เยี่ยมมาก!

การเข้ารหัส CNI

ในบรรดา CNI ที่ได้รับการตรวจสอบ มี CNI ที่สามารถเข้ารหัสการแลกเปลี่ยนเครือข่ายระหว่าง Pod ได้:

• Antrea ใช้ IPsec
• ผ้าดิบใช้ wireguard
• ซีเลียมใช้ IPsec
• WeaveNet โดยใช้ IPsec

แบนด์วิดท์

เนื่องจาก CNI เหลือน้อยลง เราจะรวมสถานการณ์ทั้งหมดไว้ในกราฟเดียว:

การใช้ทรัพยากร

ในส่วนนี้ เราจะประเมินทรัพยากรที่ใช้เมื่อประมวลผลการสื่อสาร Pod-to-Pod ใน TCP และ UDP ไม่มีประโยชน์ในการวาดกราฟ Pod-to-Service เนื่องจากไม่ได้ให้ข้อมูลเพิ่มเติม

วางมันทั้งหมดเข้าด้วยกัน

ลองทำซ้ำกราฟทั้งหมด เราแนะนำความเป็นส่วนตัวเล็กน้อยที่นี่ โดยแทนที่ค่าจริงด้วยคำว่า "vwry fast", "low" ฯลฯ

บทสรุปและข้อสรุปของฉัน

นี่เป็นเรื่องส่วนตัวเล็กน้อยเนื่องจากฉันกำลังถ่ายทอดการตีความผลลัพธ์ของตัวเอง

ฉันดีใจที่ CNI ใหม่ปรากฏขึ้น Antrea ทำงานได้ดี มีการใช้งานฟังก์ชั่นมากมายแม้ในเวอร์ชันแรกๆ: การตรวจจับ MTU อัตโนมัติ การเข้ารหัส และการติดตั้งง่าย

หากเราเปรียบเทียบประสิทธิภาพ CNI ทั้งหมดทำงานได้ดี ยกเว้น Kube-OVN และ Kube-Router Kube-Router ไม่สามารถตรวจจับ MTU ได้ ฉันไม่พบวิธีกำหนดค่าที่ใดก็ได้ในเอกสารประกอบ (ที่นี่ คำขอในหัวข้อนี้เปิดอยู่)

ในแง่ของการใช้ทรัพยากร Cilium ยังคงใช้ RAM มากกว่ารายอื่น แต่ผู้ผลิตกำหนดเป้าหมายคลัสเตอร์ขนาดใหญ่อย่างชัดเจน ซึ่งไม่เหมือนกับการทดสอบคลัสเตอร์แบบ XNUMX โหนดอย่างชัดเจน Kube-OVN ยังใช้ทรัพยากร CPU และ RAM จำนวนมาก แต่เป็น CNI รุ่นเยาว์ที่ใช้ Open vSwitch (เช่น Antrea ทำงานได้ดีกว่าและใช้น้อยลง)

ทุกคนยกเว้น Flannel มีนโยบายเครือข่าย มีโอกาสมากที่เขาจะไม่สนับสนุนพวกเขาเนื่องจากเป้าหมายนั้นง่ายกว่าหัวผักกาดนึ่ง: ยิ่งเบาก็ยิ่งดี

นอกจากนี้ประสิทธิภาพการเข้ารหัสยังยอดเยี่ยมอีกด้วย Calico เป็นหนึ่งใน CNI ที่เก่าแก่ที่สุด แต่มีการเพิ่มการเข้ารหัสเมื่อสองสามสัปดาห์ก่อน พวกเขาเลือก wireguard แทน IPsec พูดง่ายๆ ก็คือ มันใช้งานได้ดีและน่าทึ่ง บดบัง CNI อื่นๆ โดยสิ้นเชิงในการทดสอบส่วนนี้ แน่นอนว่าการใช้ทรัพยากรเพิ่มขึ้นเนื่องจากการเข้ารหัส แต่ปริมาณงานที่ได้รับนั้นคุ้มค่า (Calico แสดงให้เห็นการปรับปรุงการทดสอบการเข้ารหัสเพิ่มขึ้นหกเท่าเมื่อเทียบกับ Cilium ซึ่งอยู่ในอันดับที่สอง) นอกจากนี้ คุณยังสามารถเปิดใช้งาน Wireguard ได้ตลอดเวลาหลังจากที่คุณปรับใช้ Calico กับคลัสเตอร์ และคุณยังสามารถปิดการใช้งานในช่วงเวลาสั้นๆ หรือถาวรได้หากต้องการ มันสะดวกอย่างเหลือเชื่อ! เราขอเตือนคุณว่าขณะนี้ Calico ไม่ได้ตรวจจับ MTU อัตโนมัติ (ฟีเจอร์นี้วางแผนไว้สำหรับเวอร์ชันในอนาคต) ดังนั้นอย่าลืมกำหนดค่า MTU หากเครือข่ายของคุณรองรับ Jumbo Frames (MTU 9000)

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

โดยสรุป ฉันขอแนะนำกรณีการใช้งานต่อไปนี้:

• ต้องการ CNI สำหรับคลัสเตอร์ขนาดเล็กมาก หรือ ฉันไม่ต้องการความปลอดภัย: ทำงานกับ สักหลาดCNI ที่เบาที่สุดและเสถียรที่สุด (เขายังเป็นหนึ่งในผู้ที่มีอายุมากที่สุดตามตำนานที่เขาคิดค้นโดย Homo Kubernautus หรือ Homo Contaitorus). คุณอาจสนใจโครงการที่แยบยลที่สุด k3s, ตรวจสอบ!
• ต้องการ CNI สำหรับคลัสเตอร์ปกติ: ผ้าดิบ - ทางเลือกของคุณ แต่อย่าลืมกำหนดค่า MTU หากจำเป็น คุณสามารถเล่นกับนโยบายเครือข่าย เปิดและปิดการเข้ารหัส ฯลฯ ได้อย่างง่ายดายและเป็นธรรมชาติ
• ต้องการ CNI สำหรับคลัสเตอร์ขนาดใหญ่ (มาก): การทดสอบไม่ได้แสดงพฤติกรรมของคลัสเตอร์ขนาดใหญ่ ฉันยินดีที่จะทำการทดสอบ แต่เราไม่มีเซิร์ฟเวอร์หลายร้อยเครื่องที่มีการเชื่อมต่อ 10Gbps ดังนั้นตัวเลือกที่ดีที่สุดคือทำการทดสอบแบบดัดแปลงบนโหนดของคุณ อย่างน้อยกับ Calico และ Cilium

ที่มา: will.com