Kubernetes Network Plugin (CNI) बेन्चमार्क परिणामहरू 10 Gbps नेटवर्कमा (अपडेट गरिएको: अप्रिल 2019)

यो मेरो अपडेट हो अघिल्लो बेन्चमार्क, जुन अब अप्रिल 1.14 सम्मको नवीनतम CNI संस्करणको साथ Kubernetes 2019 मा चल्छ।

सबैभन्दा पहिले, म Cilium टोलीलाई धन्यवाद दिन चाहन्छु: केटाहरूले मलाई मेट्रिक्स निगरानी स्क्रिप्टहरू जाँच गर्न र सुधार गर्न मद्दत गरे।

नोभेम्बर 2018 देखि के परिवर्तन भएको छ

त्यसबेलादेखि के परिवर्तन भएको छ (यदि तपाइँ इच्छुक हुनुहुन्छ भने):

Flannel सबैभन्दा छिटो र सरल CNI इन्टरफेस रहन्छ, तर अझै पनि नेटवर्क नीतिहरू र इन्क्रिप्सन समर्थन गर्दैन।

Romana अब समर्थित छैन, त्यसैले हामीले यसलाई बेन्चमार्कबाट हटाएका छौं।

WeaveNet ले अब Ingress र Egress को लागि नेटवर्क नीतिहरूलाई समर्थन गर्दछ! तर उत्पादकत्व भने घटेको छ ।

क्यालिकोमा, तपाईले अझै पनि उत्कृष्ट प्रदर्शनको लागि अधिकतम प्याकेट साइज (MTU) कन्फिगर गर्न आवश्यक छ। क्यालिकोले CNI स्थापना गर्नका लागि दुई विकल्पहरू प्रदान गर्दछ, त्यसैले तपाईं छुट्टै ETCD भण्डार बिना गर्न सक्नुहुन्छ:

• Kubernetes API मा डाटा स्टोरको रूपमा भण्डारण गर्ने अवस्था (क्लस्टर साइज <50 नोडहरू);
• K8S API (क्लस्टर साइज > ५० नोडहरू) मा भार कम गर्न Typha प्रोक्सीको साथ डाटा स्टोरको रूपमा Kubernetes API मा भण्डारण गर्ने अवस्था।

क्यालिकोले समर्थनको घोषणा गरेको छ आवेदन स्तर नीतिहरू अनुप्रयोग-स्तर सुरक्षाको लागि Istio को शीर्षमा।

Cilium अब एन्क्रिप्शन समर्थन गर्दछ! Cilium ले IPSec टनेलहरूसँग इन्क्रिप्शन प्रदान गर्दछ र गुप्तिकरण गरिएको WeaveNet नेटवर्कको विकल्प प्रदान गर्दछ। तर WeaveNet एन्क्रिप्शन सक्षम भएको Cilium भन्दा छिटो छ।

Cilium अब बिल्ट-इन ETCD अपरेटरको लागि प्रयोग गर्न सजिलो छ।

Cilium टोलीले मेमोरी खपत र CPU लागत घटाएर आफ्नो CNI बाट केही वजन ट्रिम गर्ने प्रयास गरेको छ, तर यसका प्रतिस्पर्धीहरू अझै हल्का छन्।

बेन्चमार्क सन्दर्भ

बेन्चमार्क 10 Gb सुपरमाइक्रो स्विचको साथ तीन गैर-भर्चुअलाइज्ड सुपरमाइक्रो सर्भरहरूमा चलाइएको छ। सर्भरहरू निष्क्रिय DAC SFP+ केबलहरू मार्फत सिधै स्विचमा जडान भएका छन् र जम्बो फ्रेमहरू (MTU 9000) सँग उही VLAN मा कन्फिगर गरिएका छन्।

Kubernetes 1.14.0 Ubuntu 18.04 LTS मा Docker 18.09.2 (यस रिलीजमा पूर्वनिर्धारित डकर संस्करण) को साथ स्थापना गरियो।

प्रजनन क्षमता सुधार गर्न, हामीले सधैं मास्टरलाई पहिलो नोडमा कन्फिगर गर्ने, दोस्रो सर्भरमा बेन्चमार्कको सर्भर भाग र तेस्रोमा ग्राहक भाग राख्ने निर्णय गर्यौं। यो गर्नको लागि, हामी Kubernetes डिप्लोयमेन्टहरूमा NodeSelector प्रयोग गर्छौं।

हामी निम्न स्केलमा बेन्चमार्क परिणामहरू वर्णन गर्नेछौं:

बेन्चमार्कको लागि CNI चयन गर्दै

यो खण्डको सूचीबाट CNI को लागि मात्र बेन्चमार्क हो kubeadm सँग एउटा मास्टर क्लस्टर सिर्जना गर्ने बारे आधिकारिक Kubernetes दस्तावेज हेर्नुहोस्। 9 CNIs मध्ये, हामी केवल 6 लिनेछौं: हामी तीहरूलाई बहिष्कार गर्नेछौं जुन स्थापना गर्न गाह्रो छ र/वा कागजात (Romana, Contiv-VPP र JuniperContrail/TungstenFabric) अनुसार कन्फिगरेसन बिना काम गर्दैन।

हामी निम्न CNI हरू तुलना गर्नेछौं:

• क्यालिको v3.6
• नहर v3.6 (सञ्जालका लागि अनिवार्य रूपमा फ्ल्यानल + क्यालिको फायरवालको रूपमा)
• सिलियम १.८.२
• फ्ल्यानेल ०.१२.०
• कुबे-राउटर ०.२.५
• WeaveNet 2.5.1

सेटिङ

CNI स्थापना गर्न जति सजिलो छ, हाम्रो पहिलो प्रभाव त्यति नै राम्रो हुनेछ। बेन्चमार्कबाट सबै सीएनआईहरू स्थापना गर्न धेरै सजिलो छन् (एक वा दुई आदेशहरूसँग)।

हामीले भनेझैं, सर्भरहरू र स्विचहरू जम्बो फ्रेमहरू सक्षम गरी कन्फिगर गरिएका छन् (हामीले MTU लाई 9000 मा सेट गर्छौं)। यदि CNI ले एडेप्टरको कन्फिगरेसनमा आधारित MTU स्वचालित रूपमा निर्धारण गर्यो भने हामी खुसी हुनेछौं। यद्यपि, केवल Cilium र Flannel ले यसलाई व्यवस्थित गर्यो। बाँकी CNIs सँग GitHub मा स्वचालित MTU खोज थप्न अनुरोध छ, तर हामी यसलाई क्यालिको, नहर र कुबे-राउटरको लागि कन्फिगम्याप परिवर्तन गरेर, वा WeaveNet को लागि वातावरणीय चर पास गरेर म्यानुअल रूपमा कन्फिगर गर्नेछौं।

गलत MTU को समस्या के हो? यो रेखाचित्रले पूर्वनिर्धारित MTU र जम्बो फ्रेम सक्षम भएको WeaveNet बीचको भिन्नता देखाउँछ:

MTU ले थ्रुपुटलाई कसरी असर गर्छ?

हामीले MTU कार्यसम्पादनको लागि कत्तिको महत्त्वपूर्ण छ भनेर देख्यौं, अब हेरौं कि हाम्रा CNI ले यसलाई स्वचालित रूपमा कसरी निर्धारण गर्छन्:

CNI स्वतः MTU पत्ता लगाउँछ

ग्राफले देखाउँछ कि इष्टतम कार्यसम्पादनको लागि तपाईंले क्यालिको, नहर, कुबे-राउटर र WeaveNet को लागि MTU कन्फिगर गर्न आवश्यक छ। Cilium र Flannel कुनै पनि सेटिङ बिना MTU आफैलाई सही रूपमा निर्धारण गर्न सक्षम थिए।

सुरक्षा

हामी CNI सुरक्षालाई दुई पक्षहरूमा तुलना गर्नेछौं: ट्रान्समिटेड डाटा इन्क्रिप्ट गर्ने क्षमता र Kubernetes नेटवर्क नीतिहरूको कार्यान्वयन (वास्तविक परीक्षणहरूमा आधारित, कागजातमा होइन)।

केवल दुई CNI हरूले डेटा इन्क्रिप्ट गर्दछ: Cilium र WeaveNet। इन्क्रिप्सन WeaveNet CNI वातावरण चरको रूपमा इन्क्रिप्शन पासवर्ड सेट गरेर सक्षम पारियो। IN कागजात WeaveNet ले यसलाई जटिल तरिकामा वर्णन गर्दछ, तर सबै कुरा सरल रूपमा गरिन्छ। इन्क्रिप्सन सिलियम आदेशहरूद्वारा कन्फिगर गरिएको, Kubernetes रहस्यहरू सिर्जना गरेर, र deemonSet को परिमार्जन मार्फत (WeaveNet मा भन्दा अलि बढी जटिल, तर Cilium सँग चरण-दर-चरण छ। निर्देशनहरू).

सञ्जाल नीतिको कार्यान्वयनमा उनीहरू सफल भएका छन् क्यालिको, नहर, Cilium र WeaveNet, जसमा तपाइँ प्रवेश र निकासी नियमहरू कन्फिगर गर्न सक्नुहुन्छ। को लागी कुबे-राउटर त्यहाँ प्रवेशका लागि मात्र नियमहरू छन्, र फ्ल्यानल त्यहाँ कुनै पनि नेटवर्क नीतिहरू छैनन्।

यहाँ समग्र परिणामहरू छन्:

सुरक्षा प्रदर्शन बेन्चमार्क परिणामहरू

उत्पादकता

यो बेन्चमार्कले प्रत्येक परीक्षणको कम्तिमा तीन रनको औसत थ्रुपुट देखाउँछ। हामी TCP र UDP (iperf3 प्रयोग गरेर), वास्तविक अनुप्रयोगहरू जस्तै HTTP (Nginx र curl सँग) वा FTP (vsftpd र curl सँग) र अन्तमा SCP- आधारित इन्क्रिप्शन प्रयोग गरेर (क्लाइन्ट र सर्भर OpenSSH प्रयोग गरेर) को प्रदर्शन परीक्षण गर्छौं।

सबै परीक्षणहरूको लागि, हामीले नेटिभ नेटवर्क कार्यसम्पादनसँग CNI कार्यसम्पादन तुलना गर्न बेयर मेटल बेन्चमार्क (ग्रीन लाइन) प्रदर्शन गर्यौं। यहाँ हामी समान स्केल प्रयोग गर्दछौं, तर रंगमा:

• पहेंलो = धेरै राम्रो
• सुन्तला = राम्रो
• नीलो = यति
• रातो = खराब

हामीले गलत तरिकाले कन्फिगर गरिएका CNI हरू लिने छैनौं र सही MTU भएका CNI हरूका लागि मात्र परिणामहरू देखाउनेछौं। (नोट: यदि तपाईंले एन्क्रिप्शन सक्षम गर्नुभयो भने Cilium ले MTU लाई सही रूपमा गणना गर्दैन, त्यसैले तपाईंले संस्करण 8900 मा MTU लाई म्यानुअल रूपमा 1.4 मा घटाउनु पर्नेछ। अर्को संस्करण, 1.5 ले स्वचालित रूपमा गर्छ।)

यहाँ परिणामहरू छन्:

TCP प्रदर्शन

सबै सीएनआईहरूले TCP बेन्चमार्कमा राम्रो प्रदर्शन गरे। एन्क्रिप्शन भएको CNI धेरै पछाडि छ किनभने इन्क्रिप्सन महँगो छ।

UDP प्रदर्शन

यहाँ पनि, सबै सीएनआईहरू राम्रो गर्दैछन्। एन्क्रिप्शनको साथ CNI ले लगभग उस्तै परिणाम देखायो। Cilium प्रतिस्पर्धामा अलि पछाडि छ, तर यो नंगे धातुको मात्र 2,3% हो, त्यसैले यो खराब नतिजा होइन। नबिर्सनुहोस् कि केवल Cilium र Flannel ले MTU आफैंलाई सही रूपमा निर्धारण गर्यो, र यी कुनै अतिरिक्त कन्फिगरेसन बिना तिनीहरूको परिणामहरू हुन्।

वास्तविक अनुप्रयोगको बारेमा के हो? तपाईले देख्न सक्नुहुन्छ, HTTP को लागि समग्र प्रदर्शन TCP को तुलनामा थोरै कम छ। यदि तपाइँ TCP सँग HTTP प्रयोग गर्नुहुन्छ भने, हामीले HTTP बेन्चमार्कलाई असर गर्ने ढिलो सुरुबाट बच्न TCP बेन्चमार्कमा iperf3 कन्फिगर गर्यौं। यहाँ सबैले राम्रो काम गरेका छन् । कुबे-राउटरको स्पष्ट फाइदा छ, तर WeaveNet ले राम्रो प्रदर्शन गर्न सकेन: लगभग 20% नंगे धातु भन्दा खराब। Cilium र WeaveNet एन्क्रिप्शन संग साँच्चै दुखी देखिन्छ।

FTP को साथ, अर्को TCP-आधारित प्रोटोकल, परिणामहरू भिन्न हुन्छन्। Flannel र Kube-router ले काम गर्छ, तर Calico, Canal र Cilium थोरै पछाडि छन् र बेयर मेटल भन्दा लगभग 10% ढिलो छन्। WeaveNet 17% पछि छ, तर इन्क्रिप्टेड WeaveNet इन्क्रिप्टेड Cilium भन्दा 40% अगाडि छ।

SCP को साथ हामी तुरुन्तै देख्न सक्छौं कि SSH एन्क्रिप्शनले हामीलाई कति खर्च गर्छ। लगभग सबै CNI हरू राम्रो गर्दैछन्, तर WeaveNet फेरि पछि परेको छ। Cilium र WeaveNet एन्क्रिप्शनको साथ दोहोरो इन्क्रिप्शन (SSH + CNI) को कारणले सबैभन्दा खराब हुने अपेक्षा गरिएको छ।

यहाँ नतिजाहरु संग एक सारांश तालिका छ:

स्रोत उपभोग

अब तुलना गरौं कि CNI कसरी भारी भार (TCP स्थानान्तरणको समयमा, 10 Gbps) अन्तर्गत स्रोतहरू खपत गर्छ। प्रदर्शन परीक्षणहरूमा हामी CNI लाई बेयर मेटल (हरियो रेखा) सँग तुलना गर्छौं। स्रोत उपभोगको लागि, CNI बिना नै शुद्ध Kubernetes (बैजनी रेखा) देखाउनुहोस् र CNI ले कति अतिरिक्त स्रोतहरू खपत गर्छ हेर्नुहोस्।

सम्झना संग सुरु गरौं। यहाँ स्थानान्तरणको समयमा MB मा नोडहरूको RAM (बफर र क्यास बाहेक) को लागि औसत मान छ।

मेमोरी खपत

फ्ल्यानेल र कुबे-राउटरले उत्कृष्ट नतिजाहरू देखाए - केवल 50 एमबी। क्यालिको र नहरमा प्रत्येकमा ७० छन्। WeaveNet ले स्पष्ट रूपमा अरू भन्दा बढी खपत गर्छ - 70 MB, र Cilium 130 जति प्रयोग गर्दछ।
अब CPU समय खपत जाँच गरौं। उल्लेखनीय: रेखाचित्रले प्रतिशत देखाउँदैन, तर पीपीएम, अर्थात्, "बेयर आइरन" को लागि 38 पीपीएम 3,8% हो। यहाँ परिणामहरू छन्:

CPU खपत

क्यालिको, नहर, फ्ल्यानेल र कुबे-राउटर धेरै CPU कुशल छन् - CNI बिना Kubernetes भन्दा मात्र 2% बढी। WeaveNet अतिरिक्त 5% संग धेरै पछि छ, Cilium 7% मा पछि।

यहाँ संसाधन खपत को एक सारांश छ:

परिणामहरू

सबै परिणामहरूको साथ तालिका:

सामान्य बेन्चमार्क परिणामहरू

निष्कर्षमा

अन्तिम भागमा म नतिजामा मेरो व्यक्तिपरक राय व्यक्त गर्नेछु। याद गर्नुहोस् कि यो बेन्चमार्कले धेरै सानो क्लस्टर (3 नोडहरू) मा एकल जडानको थ्रुपुट मात्र परीक्षण गर्दछ। यो ठूला क्लस्टरहरू (<50 नोडहरू) वा समानान्तर जडानहरूमा लागू हुँदैन।

म परिदृश्यको आधारमा निम्न CNIs प्रयोग गर्न सिफारिस गर्दछु:

• के तपाइँ तपाइँको क्लस्टर मा छ थोरै स्रोतहरूसँग नोडहरू (धेरै GB RAM, धेरै कोरहरू) र तपाईंलाई सुरक्षा सुविधाहरू आवश्यक पर्दैन - छनौट गर्नुहोस् फ्ल्यानल। यो सबैभन्दा लागत-प्रभावी CNIs मध्ये एक हो। र यो आर्किटेक्चरको एक विस्तृत विविधता (amd64, arm, arm64, आदि) संग उपयुक्त छ। थप रूपमा, यो दुई मध्ये एक हो (अर्को Cilium हो) CNI जसले स्वचालित रूपमा MTU निर्धारण गर्न सक्छ, त्यसैले तपाईंले केहि पनि कन्फिगर गर्नुपर्दैन। कुबे-राउटर पनि उपयुक्त छ, तर यो मानक जस्तो छैन र तपाईंले MTU म्यानुअल रूपमा कन्फिगर गर्न आवश्यक छ।
• यदि आवश्यक छ नेटवर्क इन्क्रिप्ट गर्नुहोस् सुरक्षाको लागि, लिनुहोस् WeaveNet। यदि तपाइँ जम्बो फ्रेमहरू प्रयोग गर्दै हुनुहुन्छ भने MTU साइज निर्दिष्ट गर्न नबिर्सनुहोस्, र वातावरण चर मार्फत पासवर्ड निर्दिष्ट गरेर इन्क्रिप्सन सक्षम गर्नुहोस्। तर प्रदर्शनको बारेमा बिर्सनु राम्रो छ - त्यो ईन्क्रिप्शनको लागत हो।
• गर्न सामान्य प्रयोग советую Calico। यो CNI व्यापक रूपमा विभिन्न Kubernetes तैनाती उपकरण (Kops, Kubespray, Rancher, आदि) मा प्रयोग गरिन्छ। WeaveNet को रूपमा, जम्बो फ्रेमहरू प्रयोग गर्दा कन्फिगम्यापमा MTU कन्फिगर गर्न निश्चित हुनुहोस्। यो एक बहु-कार्यात्मक उपकरण हो जुन संसाधन खपत, प्रदर्शन र सुरक्षा को मामला मा कुशल छ।

र अन्तमा, म तपाईंलाई विकासको अनुसरण गर्न सल्लाह दिन्छु सिलियम। यो CNI सँग धेरै सक्रिय टोली छ जसले तिनीहरूको उत्पादनमा धेरै काम गर्दछ (विशेषताहरू, स्रोत बचत, प्रदर्शन, सुरक्षा, क्लस्टरिङ...) र तिनीहरूसँग धेरै रोचक योजनाहरू छन्।

CNI चयनको लागि भिजुअल रेखाचित्र

स्रोत: www.habr.com