ผลลัพธ์การเปรียบเทียบมาตรฐานปลั๊กอินเครือข่าย Kubernetes (CNI) บนเครือข่าย 10 Gbps (อัปเดต: เมษายน 2019)

นี่คือการอัปเดตของฉัน เกณฑ์มาตรฐานก่อนหน้าซึ่งขณะนี้ทำงานบน Kubernetes 1.14 พร้อมด้วย CNI เวอร์ชันล่าสุด ณ เดือนเมษายน 2019

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

สิ่งที่เปลี่ยนแปลงไปตั้งแต่เดือนพฤศจิกายน 2018

ต่อไปนี้คือสิ่งที่เปลี่ยนแปลงไปตั้งแต่นั้นมา (หากคุณสนใจ):

Flannel ยังคงเป็นอินเทอร์เฟซ CNI ที่เร็วและง่ายที่สุด แต่ก็ยังไม่รองรับนโยบายเครือข่ายและการเข้ารหัส

Romana ไม่ได้รับการสนับสนุนอีกต่อไป ดังนั้นเราจึงลบมันออกจากเกณฑ์มาตรฐาน

ขณะนี้ WeaveNet รองรับนโยบายเครือข่ายสำหรับ Ingress และ Egress! แต่ผลผลิตลดลง

ใน Calico คุณยังต้องกำหนดค่าขนาดแพ็คเก็ตสูงสุด (MTU) ด้วยตนเองเพื่อประสิทธิภาพที่ดีที่สุด Calico เสนอสองตัวเลือกสำหรับการติดตั้ง CNI ดังนั้นคุณสามารถทำได้โดยไม่ต้องมีที่เก็บ ETCD แยกต่างหาก:

• การจัดเก็บสถานะใน Kubernetes API เป็นที่เก็บข้อมูล (ขนาดคลัสเตอร์ <50 โหนด)
• การจัดเก็บสถานะใน Kubernetes API เป็นที่เก็บข้อมูลด้วยพร็อกซี Typha เพื่อลดภาระบน K8S API (ขนาดคลัสเตอร์ > 50 โหนด)

Calico ประกาศสนับสนุน นโยบายระดับแอปพลิเคชัน เหนือ Istio เพื่อความปลอดภัยระดับแอปพลิเคชัน

ตอนนี้ Cilium รองรับการเข้ารหัสแล้ว! Cilium ให้การเข้ารหัสด้วยอุโมงค์ IPSec และเสนอทางเลือกแทนเครือข่าย WeaveNet ที่เข้ารหัส แต่ WeaveNet นั้นเร็วกว่า Cilium เมื่อเปิดใช้งานการเข้ารหัส

ตอนนี้ Cilium ปรับใช้ได้ง่ายขึ้นด้วยตัวดำเนินการ ETCD ในตัว

ทีม Cilium พยายามลดน้ำหนัก CNI ของตนด้วยการลดการใช้หน่วยความจำและต้นทุน CPU แต่คู่แข่งก็ยังเบากว่า

บริบทเกณฑ์มาตรฐาน

การวัดประสิทธิภาพทำงานบนเซิร์ฟเวอร์ Supermicro ที่ไม่ใช่การจำลองเสมือน 10 ตัวพร้อมสวิตช์ Supermicro ขนาด 9000 Gb เซิร์ฟเวอร์เชื่อมต่อโดยตรงกับสวิตช์ผ่านสายเคเบิล DAC SFP+ แบบพาสซีฟ และได้รับการกำหนดค่าบน VLAN เดียวกันกับเฟรมขนาดจัมโบ้ (MTU XNUMX)

Kubernetes 1.14.0 ติดตั้งบน Ubuntu 18.04 LTS พร้อม Docker 18.09.2 (เวอร์ชัน Docker เริ่มต้นในรุ่นนี้)

เพื่อปรับปรุงความสามารถในการทำซ้ำ เราตัดสินใจกำหนดค่าต้นแบบบนโหนดแรกเสมอ วางส่วนเซิร์ฟเวอร์ของเกณฑ์มาตรฐานบนเซิร์ฟเวอร์ตัวที่สอง และส่วนไคลเอ็นต์บนโหนดที่สาม ในการดำเนินการนี้ เราใช้ NodeSelector ในการปรับใช้ Kubernetes

เราจะอธิบายผลลัพธ์การวัดประสิทธิภาพในระดับต่อไปนี้:

การเลือก CNI เพื่อเป็นเกณฑ์มาตรฐาน

นี่เป็นเกณฑ์มาตรฐานสำหรับ CNI เท่านั้นจากรายการในส่วนนี้ เกี่ยวกับการสร้างคลัสเตอร์หลักหนึ่งคลัสเตอร์ด้วย kubeadm ดูเอกสารอย่างเป็นทางการของ Kubernetes จาก CNI 9 รายการ เราจะรับเพียง 6 รายการ: เราจะยกเว้นรายการที่ติดตั้งยากและ/หรือใช้งานไม่ได้หากไม่มีการกำหนดค่าตามเอกสารประกอบ (Romana, Contiv-VPP และ JuniperContrail/TungstenFabric)

เราจะเปรียบเทียบ CNI ต่อไปนี้:

• ผ้าดิบ v3.6
• Canal v3.6 (โดยพื้นฐานแล้วคือ Flannel สำหรับเครือข่าย + Calico เป็นไฟร์วอลล์)
• ซีเลียม 1.4.2
• ผ้าสักหลาด 0.11.0
• Kube-เราเตอร์ 0.2.5
• วีฟเน็ต 2.5.1

การติดตั้ง

ยิ่งติดตั้ง CNI ได้ง่ายเท่าไร ความประทับใจแรกของเราก็จะยิ่งดีขึ้นเท่านั้น CNI ทั้งหมดจากเกณฑ์มาตรฐานนั้นติดตั้งได้ง่ายมาก (ด้วยคำสั่งหนึ่งหรือสองคำสั่ง)

ดังที่เราได้กล่าวไว้ เซิร์ฟเวอร์และสวิตช์ได้รับการกำหนดค่าโดยเปิดใช้งานจัมโบ้เฟรม (เราตั้งค่า MTU เป็น 9000) เรายินดีเป็นอย่างยิ่งหาก CNI กำหนด MTU โดยอัตโนมัติตามการกำหนดค่าของอแด็ปเตอร์ อย่างไรก็ตาม มีเพียง Cilium และ Flannel เท่านั้นที่จัดการเรื่องนี้ได้ CNI ที่เหลือมีการร้องขอบน GitHub เพื่อเพิ่มการค้นพบ MTU อัตโนมัติ แต่เราจะกำหนดค่าด้วยตนเองโดยการเปลี่ยน ConfigMap สำหรับ Calico, Canal และ Kube-เราเตอร์ หรือส่งตัวแปรสภาพแวดล้อมสำหรับ WeaveNet

ปัญหาของ MTU ที่ไม่ถูกต้องคืออะไร แผนภาพนี้แสดงความแตกต่างระหว่าง WeaveNet ที่เปิดใช้งาน MTU และเฟรมจัมโบ้เริ่มต้น:

MTU ส่งผลต่อปริมาณงานอย่างไร

เราได้เห็นแล้วว่า MTU มีความสำคัญต่อประสิทธิภาพเพียงใด ตอนนี้เรามาดูกันว่า CNI ของเราจะพิจารณาโดยอัตโนมัติอย่างไร:

CNI ตรวจจับ MTU โดยอัตโนมัติ

กราฟแสดงให้เห็นว่าคุณต้องกำหนดค่า MTU สำหรับ Calico, Canal, Kube-router และ WeaveNet เพื่อประสิทธิภาพสูงสุด Cilium และ Flannel สามารถระบุ MTU ได้อย่างถูกต้องโดยไม่ต้องตั้งค่าใดๆ

ความปลอดภัย

เราจะเปรียบเทียบความปลอดภัยของ CNI ในสองด้าน: ความสามารถในการเข้ารหัสข้อมูลที่ส่งและการใช้งานนโยบายเครือข่าย Kubernetes (อิงจากการทดสอบจริง ไม่ใช่เอกสารประกอบ)

CNI เพียงสองตัวเท่านั้นที่เข้ารหัสข้อมูล: Cilium และ WeaveNet การเข้ารหัส วีฟเน็ต เปิดใช้งานโดยการตั้งรหัสผ่านการเข้ารหัสเป็นตัวแปรสภาพแวดล้อม CNI ใน เอกสาร WeaveNet อธิบายมันด้วยวิธีที่ซับซ้อน แต่ทุกอย่างก็ทำได้ง่ายๆ การเข้ารหัส ซีเลีย กำหนดค่าโดยคำสั่ง โดยการสร้างความลับของ Kubernetes และผ่านการแก้ไข daemonSet (ซับซ้อนกว่าใน WeaveNet เล็กน้อย แต่ Cilium มีทีละขั้นตอน) คำแนะนำ).

ส่วนการดำเนินนโยบายเครือข่ายก็ประสบผลสำเร็จ ผ้าดิบ คลอง ซีเลียม และวีฟเน็ตซึ่งคุณสามารถกำหนดค่ากฎขาเข้าและขาออกได้ สำหรับ Kube-เราเตอร์ มีกฎเฉพาะสำหรับ Ingress และ สักหลาด ไม่มีนโยบายเครือข่ายเลย

นี่คือผลลัพธ์โดยรวม:

ผลลัพธ์เกณฑ์มาตรฐานประสิทธิภาพด้านความปลอดภัย

การปฏิบัติ

เกณฑ์มาตรฐานนี้แสดงปริมาณงานเฉลี่ยจากการทดสอบแต่ละครั้งอย่างน้อยสามครั้ง เราทดสอบประสิทธิภาพของ TCP และ UDP (โดยใช้ iperf3) แอปพลิเคชันจริง เช่น HTTP (พร้อม Nginx และ curl) หรือ FTP (พร้อม vsftpd และ curl) และสุดท้ายประสิทธิภาพของแอปพลิเคชันโดยใช้การเข้ารหัสแบบ SCP (โดยใช้ไคลเอนต์และเซิร์ฟเวอร์ OpenSSH)

สำหรับการทดสอบทั้งหมด เราทำเกณฑ์มาตรฐาน Bare Metal (เส้นสีเขียว) เพื่อเปรียบเทียบประสิทธิภาพของ CNI กับประสิทธิภาพของเครือข่ายดั้งเดิม ที่นี่เราใช้สเกลเดียวกัน แต่เป็นสี:

• สีเหลือง = ดีมาก
• ส้ม = ดี
• สีฟ้า = พอประมาณ
• สีแดง = ไม่ดี

เราจะไม่รับ CNI ที่กำหนดค่าไม่ถูกต้อง และจะแสดงเฉพาะผลลัพธ์สำหรับ CNI ที่มี MTU ที่ถูกต้องเท่านั้น (หมายเหตุ: Cilium ไม่ได้คำนวณ MTU อย่างถูกต้องหากคุณเปิดใช้งานการเข้ารหัส ดังนั้น คุณจะต้องลด MTU ด้วยตนเองเป็น 8900 ในเวอร์ชัน 1.4 เวอร์ชันถัดไป 1.5 จะดำเนินการนี้โดยอัตโนมัติ)

นี่คือผลลัพธ์:

ประสิทธิภาพของ TCP

CNI ทั้งหมดทำงานได้ดีในเกณฑ์มาตรฐาน TCP CNI ที่มีการเข้ารหัสยังล่าช้ากว่ามากเนื่องจากการเข้ารหัสมีราคาแพง

ประสิทธิภาพ UDP

CNI ทั้งหมดก็ทำได้ดีเช่นกัน CNI ที่มีการเข้ารหัสแสดงผลลัพธ์ที่เกือบจะเหมือนกัน Cilium ล้าหลังคู่แข่งเล็กน้อย แต่มีโลหะเปลือยเพียง 2,3% ดังนั้นจึงไม่ใช่ผลลัพธ์ที่แย่ อย่าลืมว่ามีเพียง Cilium และ Flannel เท่านั้นที่สามารถกำหนด MTU ได้อย่างถูกต้อง และนี่คือผลลัพธ์โดยไม่มีการกำหนดค่าเพิ่มเติม

แล้วการสมัครจริงล่ะ? อย่างที่คุณเห็น ประสิทธิภาพโดยรวมของ HTTP นั้นต่ำกว่า TCP เล็กน้อย แม้ว่าคุณจะใช้ HTTP กับ TCP เราก็กำหนดค่า iperf3 ในการวัดประสิทธิภาพ TCP เพื่อหลีกเลี่ยงการเริ่มต้นที่ช้าซึ่งจะส่งผลต่อการวัดประสิทธิภาพ HTTP ทุกคนทำงานได้ดีที่นี่ เราเตอร์ Kube มีข้อได้เปรียบที่ชัดเจน แต่ WeaveNet ทำงานได้ไม่ดี: แย่กว่าโลหะเปลือยประมาณ 20% Cilium และ WeaveNet ที่มีการเข้ารหัสดูน่าเศร้าจริงๆ

ด้วย FTP ซึ่งเป็นโปรโตคอลที่ใช้ TCP อื่น ผลลัพธ์จะแตกต่างกันไป เราเตอร์ผ้าสักหลาดและ Kube ทำงานได้ดี แต่ Calico, Canal และ Cilium ช้ากว่าเล็กน้อยและช้ากว่า Bare Metal ประมาณ 10% WeaveNet ตามหลังมากถึง 17% แต่ WeaveNet ที่เข้ารหัสนั้นเหนือกว่า Cilium ที่เข้ารหัสถึง 40%

ด้วย SCP เราจะเห็นได้ทันทีว่าการเข้ารหัส SSH มีค่าใช้จ่ายเท่าไร CNI เกือบทั้งหมดไปได้ดี แต่ WeaveNet ก็ล้าหลังอีกครั้ง Cilium และ WeaveNet พร้อมการเข้ารหัสคาดว่าจะแย่ที่สุดเนื่องจากการเข้ารหัสสองครั้ง (SSH + CNI)

นี่คือตารางสรุปพร้อมผลลัพธ์:

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

ตอนนี้เรามาเปรียบเทียบว่า CNI ใช้ทรัพยากรภายใต้ภาระหนักอย่างไร (ระหว่างการถ่ายโอน TCP, 10 Gbps) ในการทดสอบประสิทธิภาพ เราจะเปรียบเทียบ CNI กับโลหะเปลือย (เส้นสีเขียว) สำหรับการใช้ทรัพยากร เรามาแสดง Kubernetes ล้วนๆ (เส้นสีม่วง) โดยไม่มี CNI และดูว่า CNI ใช้ทรัพยากรเพิ่มเติมจำนวนเท่าใด

เริ่มจากความทรงจำกันก่อน นี่คือค่าเฉลี่ยสำหรับ RAM ของโหนด (ไม่รวมบัฟเฟอร์และแคช) ในหน่วย MB ระหว่างการถ่ายโอน

การใช้หน่วยความจำ

Flannel และ Kube-router แสดงผลลัพธ์ที่ยอดเยี่ยม - เพียง 50 MB Calico และ Canal ต่างก็มี 70 WeaveNet กินมากกว่าอันอื่นอย่างชัดเจน - 130 MB และ Cilium ใช้มากถึง 400
ตอนนี้เรามาตรวจสอบการสิ้นเปลืองเวลาของ CPU น่าสังเกต: แผนภาพไม่แสดงเปอร์เซ็นต์ แต่เป็น ppm นั่นคือ 38 ppm สำหรับ “เหล็กเปลือย” คือ 3,8% นี่คือผลลัพธ์:

ปริมาณการใช้ซีพียู

Calico, Canal, Flannel และ Kube-เราเตอร์มีประสิทธิภาพ CPU มาก - มากกว่า Kubernetes เพียง 2% ที่ไม่มี CNI WeaveNet ตามหลังมากโดยเพิ่มอีก 5% ตามด้วย Cilium ที่ 7%

นี่คือบทสรุปของการใช้ทรัพยากร:

ผลของการ

ตารางที่มีผลลัพธ์ทั้งหมด:

ผลลัพธ์การวัดประสิทธิภาพทั่วไป

ข้อสรุป

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

ฉันแนะนำให้ใช้ CNI ต่อไปนี้ ขึ้นอยู่กับสถานการณ์:

• คุณมีในคลัสเตอร์ของคุณหรือไม่ โหนดที่มีทรัพยากรน้อย (RAM หลาย GB, หลายคอร์) และคุณไม่จำเป็นต้องมีคุณสมบัติด้านความปลอดภัย - เลือก สักหลาด. นี่คือหนึ่งใน CNI ที่คุ้มค่าที่สุด และเข้ากันได้กับสถาปัตยกรรมที่หลากหลาย (amd64, arm, arm64 ฯลฯ) นอกจากนี้ นี่คือหนึ่งในสอง (อีกอันคือ Cilium) CNI ที่สามารถกำหนด MTU ได้โดยอัตโนมัติ ดังนั้นคุณจึงไม่ต้องกำหนดค่าอะไรเลย Kube-router ก็เหมาะเช่นกัน แต่ไม่ได้มาตรฐานและคุณจะต้องกำหนดค่า MTU ด้วยตนเอง
• หากจำเป็น เข้ารหัสเครือข่าย เพื่อความปลอดภัยให้เอา วีฟเน็ต. อย่าลืมระบุขนาด MTU หากคุณใช้เฟรมจัมโบ้ และเปิดใช้งานการเข้ารหัสโดยระบุรหัสผ่านผ่านตัวแปรสภาพแวดล้อม แต่การลืมเรื่องประสิทธิภาพจะดีกว่า - นั่นคือต้นทุนของการเข้ารหัส
• สำหรับ การใช้งานปกติ ฉันแนะนำ ผ้าดิบ. CNI นี้ใช้กันอย่างแพร่หลายในเครื่องมือการปรับใช้ Kubernetes ต่างๆ (Kops, Kubespray, Rancher ฯลฯ) เช่นเดียวกับ WeaveNet อย่าลืมกำหนดค่า MTU ใน ConfigMap หากใช้เฟรมขนาดจัมโบ้ เป็นเครื่องมืออเนกประสงค์ที่มีประสิทธิภาพทั้งในแง่ของการใช้ทรัพยากร ประสิทธิภาพ และความปลอดภัย

และสุดท้ายนี้ผมขอแนะนำให้คุณติดตามการพัฒนา ซีเลีย. CNI นี้มีทีมงานที่กระตือรือร้นและทำงานอย่างหนักกับผลิตภัณฑ์ของตน (ฟีเจอร์ การประหยัดทรัพยากร ประสิทธิภาพ ความปลอดภัย การจัดกลุ่ม...) และพวกเขามีแผนที่น่าสนใจมาก

แผนภาพภาพสำหรับการเลือก CNI

ที่มา: will.com