Kubernetes में बैकस्टेज नेटवर्क

लगभग। ट्रांस। : मूल लेख के लेखक, निकोलस लीवा, एक सिस्को समाधान वास्तुकार हैं जिन्होंने अपने साथियों, नेटवर्क इंजीनियरों के साथ साझा करने का फैसला किया, कि कुबेरनेट्स नेटवर्क कैसे अंदर से काम करता है। ऐसा करने के लिए, वह क्लस्टर में अपने सरलतम विन्यास की खोज करता है, सक्रिय रूप से सामान्य ज्ञान, नेटवर्क और मानक लिनक्स / कुबेरनेट्स उपयोगिताओं के अपने ज्ञान का उपयोग करता है। यह स्वेच्छा से निकला, लेकिन बहुत स्पष्ट रूप से।



इस तथ्य के अलावा कि केल्सी हाईटॉवर के कुबेरनेट्स द हार्ड वे गाइड सिर्फ काम करता है ( यहां तक ​​कि एडब्ल्यूएस पर भी! ), मुझे पसंद आया कि नेटवर्क को साफ और सरल रखा गया था; और उदाहरण के लिए, कंटेनर नेटवर्क इंटरफ़ेस ( CNI ) की भूमिका को समझने का यह एक शानदार अवसर है। यह कहने के बाद, मैं कहता हूं कि कुबेरनेट्स नेटवर्क वास्तव में बहुत सहज नहीं है, विशेष रूप से शुरुआती लोगों के लिए ... और यह भी मत भूलना कि "कंटेनरों के लिए नेटवर्क जैसी कोई चीज नहीं है "।

हालांकि इस विषय पर पहले से ही अच्छी सामग्री है (लिंक यहां देखें), मुझे ऐसा कोई उदाहरण नहीं मिला कि मैं टीम के निष्कर्षों के साथ जरूरी हर चीज को जोड़ दूं जो कि नेटवर्क इंजीनियर प्यार और नफरत करते हैं, यह प्रदर्शित करते हुए कि वास्तव में पर्दे के पीछे क्या हो रहा है। इसलिए, मैंने कई स्रोतों से जानकारी एकत्र करने का फैसला किया - मुझे उम्मीद है कि इससे मदद मिलेगी और आप बेहतर ढंग से समझ पाएंगे कि सब कुछ एक दूसरे के साथ कैसे जुड़ा है। यह ज्ञान न केवल स्वयं का परीक्षण करने के लिए, बल्कि समस्याओं के निदान की प्रक्रिया को सरल बनाने के लिए भी महत्वपूर्ण है। आप कुबेरनेट्स द हार्ड वे से अपने क्लस्टर में उदाहरण का अनुसरण कर सकते हैं: सभी आईपी पते और सेटिंग्स वहां से ली गई हैं (मई 2018 के लिए हिट्स के अनुसार , नबला कंटेनरों का उपयोग करने से पहले)।

और हम अंत से शुरू करेंगे, जब हमारे पास तीन नियंत्रक और तीन काम करने वाले नोड होंगे:



आप देख सकते हैं कि यहाँ कम से कम तीन निजी सबनेट भी हैं! थोड़ा धैर्य, और वे सभी पर विचार किया जाएगा। याद रखें कि भले ही हम बहुत विशिष्ट आईपी उपसर्गों का उल्लेख करते हैं, वे बस कुबेरनेट्स द हार्ड वे से लिए गए हैं , इसलिए उनका केवल स्थानीय महत्व है, और आप RFC 1918 के अनुसार अपने वातावरण के लिए कोई अन्य पता ब्लॉक चुनने के लिए स्वतंत्र हैं। IPv6 के मामले के लिए, एक अलग ब्लॉग लेख होगा।

होस्ट नेटवर्क (10.240.0.0/24)

यह एक आंतरिक नेटवर्क है जिसमें सभी नोड्स एक हिस्सा हैं। कंप्यूटिंग संसाधनों को आवंटित करते समय GCP में --private-network-ip ध्वज और AWS में --private-ip-address विकल्प द्वारा परिभाषित।

जीसीपी में नियंत्रक नोड्स को प्रारंभ करना

 for i in 0 1 2; do gcloud compute instances create controller-${i} \ # ... --private-network-ip 10.240.0.1${i} \ # ... done 

( controllers_gcp.sh )

AWS में नियंत्रक नोड्स की शुरुआत

 for i in 0 1 2; do declare controller_id${i}=`aws ec2 run-instances \ # ... --private-ip-address 10.240.0.1${i} \ # ... done 

( controllers_aws.sh )



प्रत्येक उदाहरण में दो आईपी पते होंगे: होस्ट नेटवर्क से निजी (नियंत्रक - 10.240.0.1${i}/24 , कार्यकर्ता - 10.240.0.2${i}/24 ) और एक सार्वजनिक एक, जिसे क्लाउड प्रदाता द्वारा नियुक्त किया जाता है, जिसके बारे में हम बाद में बात करेंगे। NodePorts को कैसे प्राप्त करें।

जीसीपी

 $ gcloud compute instances list NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS controller-0 us-west1-c n1-standard-1 10.240.0.10 35.231.XXX.XXX RUNNING worker-1 us-west1-c n1-standard-1 10.240.0.21 35.231.XX.XXX RUNNING ... 

एडब्ल्यूएस

 $ aws ec2 describe-instances --query 'Reservations[].Instances[].[Tags[?Key==`Name`].Value[],PrivateIpAddress,PublicIpAddress]' --output text | sed '$!N;s/\n/ /' 10.240.0.10 34.228.XX.XXX controller-0 10.240.0.21 34.173.XXX.XX worker-1 ... 

यदि सुरक्षा नीतियां सही हैं (और यदि ping होस्ट पर स्थापित है) तो सभी नोड्स एक दूसरे को पिंग करने में सक्षम होंगे।

चूल्हा नेटवर्क (10.200.0.0/16)

यह वह नेटवर्क है जिसमें पॉड रहते हैं। प्रत्येक कार्य नोड इस नेटवर्क के एक सबनेट का उपयोग करता है। हमारे मामले में, POD_CIDR=10.200.${i}.0/24 worker-${i} ।



यह समझने के लिए कि सब कुछ कैसे कॉन्फ़िगर किया गया है, एक कदम पीछे ले जाएं और कुबेरनेट्स नेटवर्क मॉडल को देखें , जिसके लिए निम्नलिखित की आवश्यकता है:

• सभी कंटेनर NAT का उपयोग किए बिना किसी भी अन्य कंटेनर के साथ संवाद कर सकते हैं।
• सभी नोड्स NAT का उपयोग किए बिना सभी कंटेनरों (और इसके विपरीत) के साथ संवाद कर सकते हैं।
• आईपी ​​जो कंटेनर देखता है वह वैसा ही होना चाहिए जैसा कि अन्य लोग देखते हैं।

यह सब कई तरीकों से लागू किया जा सकता है, और कुबेरनेट्स नेटवर्क सेटअप को सीएनआई प्लगइन में पास करता है ।

"CNI प्लगइन कंटेनर के नेटवर्क नेमस्पेस (उदाहरण के लिए, वीथ पेयर का एक सिरा) के लिए एक नेटवर्क इंटरफ़ेस जोड़ने और होस्ट पर आवश्यक परिवर्तन करने के लिए जिम्मेदार है (उदाहरण के लिए, वीथ के दूसरे छोर को एक पुल से जोड़ना)। फिर उसे एक आईपी इंटरफ़ेस असाइन करना होगा और वांछित आईपीएएम प्लगइन को कॉल करके आईपी एड्रेस मैनेजमेंट सेक्शन के अनुसार मार्गों को कॉन्फ़िगर करना होगा। " ( कंटेनर नेटवर्क इंटरफ़ेस विनिर्देश से )

नेटवर्क नामस्थान

“नाम स्थान वैश्विक सिस्टम संसाधन को एक अमूर्त में लपेटता है जो इस नामस्थान में प्रक्रियाओं के लिए इस तरह से दिखाई देता है कि उनके पास वैश्विक संसाधन का अपना पृथक उदाहरण है। इस नाम स्थान में शामिल अन्य प्रक्रियाओं के लिए वैश्विक संसाधन में परिवर्तन दिखाई दे रहे हैं, लेकिन अन्य प्रक्रियाओं के लिए दृश्यमान नहीं हैं। " ( नाम स्थान पृष्ठ से )

लिनक्स सात अलग-अलग नामस्थान ( Cgroup , IPC , Network , Mount , PID , User , UTS ) प्रदान करता है। नेटवर्क नेमस्पेस ( CLONE_NEWNET ) नेटवर्क संसाधनों को परिभाषित करता है जो इस प्रक्रिया के लिए सुलभ हैं: "प्रत्येक नेटवर्क नेमस्पेस के पास अपने नेटवर्क डिवाइस, आईपी पते, आईपी रूटिंग टेबल, /proc/net डाइरेक्टरी, पोर्ट नंबर इत्यादि होते हैं" ( लेख " ऑपरेशन में नामस्थान ") से ।

वर्चुअल ईथरनेट डिवाइस (Veth)

"एक वर्चुअल नेटवर्क पेयर (वेथ) एक" पाइप "के रूप में एक अमूर्तता प्रदान करता है, जिसका उपयोग नेटवर्क नेमस्पेस के बीच सुरंग बनाने या किसी अन्य नेटवर्क स्पेस में एक भौतिक नेटवर्क डिवाइस के लिए एक पुल बनाने के लिए किया जा सकता है। जब नाम स्थान को मुक्त कर दिया जाता है, तो इसमें सभी वीथ डिवाइस नष्ट हो जाते हैं। " ( नेटवर्क नामस्थान मैन पेज से )

नीचे जमीन पर जाएं और देखें कि यह सब क्लस्टर से कैसे संबंधित है। सबसे पहले, कुबेरनेट्स में नेटवर्क प्लगइन्स विविध हैं, और सीएनआई प्लगइन्स उनमें से एक हैं ( सीएनएम क्यों नहीं )। प्रत्येक नोड पर क्यूबलेट कंटेनर रनटाइम को बताता है कि कौन सा नेटवर्क प्लग-इन का उपयोग करना है। कंटेनर नेटवर्क इंटरफ़ेस ( CNI ) कंटेनर रनटाइम और नेटवर्क कार्यान्वयन के बीच है। और पहले से ही CNI प्लगइन नेटवर्क सेट करता है।

“सीएनआई प्लगइन कमांड लाइन --network-plugin=cni to Kubelet को पास करके चुना गया है। क्यूबलेट फ़ाइल को --cni-conf-dir (डिफ़ॉल्ट /etc/cni/net.d ) से /etc/cni/net.d और प्रत्येक फ़ाइल के लिए नेटवर्क को कॉन्फ़िगर करने के लिए इस फ़ाइल से CNI कॉन्फ़िगरेशन का उपयोग करता है। " ( नेटवर्क प्लगइन आवश्यकताओं से )

CNI प्लगइन के असली बायनेरिज़ हैं -- cni-bin-dir (डिफ़ॉल्ट /opt/cni/bin )।

कृपया ध्यान दें कि kubelet.service कॉल kubelet.service में शामिल हैं - --network-plugin=cni :

 [Service] ExecStart=/usr/local/bin/kubelet \\ --config=/var/lib/kubelet/kubelet-config.yaml \\ --network-plugin=cni \\ ... 

सबसे पहले, कुबेरनेट्स किसी भी प्लगइन्स को कॉल करने से पहले ही चूल्हा के लिए एक नेटवर्क नेमस्पेस बनाता है। यह विशेष pause कंटेनर का उपयोग करके कार्यान्वित किया जाता है, जो "सभी चूल्हा कंटेनरों के लिए" मूल कंटेनर "के रूप में कार्य करता है" (लेख " सर्वशक्तिमान ठहराव कंटेनर " से) । कुबेरनेट्स तब नेटवर्क को pause कंटेनर को संलग्न करने के लिए CNI प्लगइन को निष्पादित करता है। सभी पॉड कंटेनर इस pause कंटेनर के netns उपयोग करते हैं।

 { "cniVersion": "0.3.1", "name": "bridge", "type": "bridge", "bridge": "cnio0", "isGateway": true, "ipMasq": true, "ipam": { "type": "host-local", "ranges": [ [{"subnet": "${POD_CIDR}"}] ], "routes": [{"dst": "0.0.0.0/0"}] } } 

सीएनआई कॉन्फिगरेशन का उपयोग रूट नाम स्थान में cnio0 ( डिफ़ॉल्ट नाम cni0 ) में लिनक्स (L2) सॉफ़्टवेयर ब्रिज को कॉन्फ़िगर करने के लिए bridge प्लगइन के उपयोग को इंगित करता है, जो एक प्रवेश द्वार ( "isGateway": true गेटवे "isGateway": true ) के रूप में कार्य करता है।



चूल्हा जोड़े को नवनिर्मित पुल से चूल्हा जोड़ने के लिए भी कॉन्फ़िगर किया जाएगा:



L3 जानकारी, जैसे कि IP पते, IPAM ( ipam ) प्लगइन को असाइन करने के लिए कहा जाता है। इस स्थिति में, host-local प्रकार का उपयोग किया जाता है, "जो होस्ट फ़ाइल सिस्टम पर स्थानीय रूप से राज्य को संग्रहीत करता है, जो एक होस्ट पर आईपी पते की विशिष्टता सुनिश्चित करता है" ( host-local के host-local ) । आईपीएएम प्लगइन इस जानकारी को पिछले प्लगइन ( bridge ) पर लौटाता है, ताकि कॉन्फ़िगरेशन में निर्दिष्ट सभी मार्गों को कॉन्फ़िगर किया जा सके ( "routes": [{"dst": "0.0.0.0/0"}] )। यदि gw निर्दिष्ट नहीं है, तो इसे सबनेट से लिया जाता है । डिफ़ॉल्ट मार्ग भी चूल्हा के नेटवर्क नेमस्पेस में कॉन्फ़िगर किया गया है, पुल की ओर इशारा करते हुए (जो कि चूल्हा के पहले आईपी सबनेट के रूप में कॉन्फ़िगर किया गया है)।

और अंतिम महत्वपूर्ण विवरण: हमने चूल्हा नेटवर्क से आने वाले ट्रैफ़िक के लिए "ipMasq": true ( "ipMasq": true ) का अनुरोध किया। हमें वास्तव में यहां NAT की आवश्यकता नहीं है, लेकिन कुबेरनेट्स द हार्ड वे में यह कॉन्फिगर है । इसलिए, पूर्णता के लिए, मुझे यह उल्लेख करना होगा कि bridge प्लग के iptables में प्रविष्टियां इस विशेष उदाहरण के लिए कॉन्फ़िगर की गई हैं। चूल्हा से सभी पैकेट, जिसका प्राप्तकर्ता 224.0.0.0/4 की सीमा में नहीं है, NAT के पीछे होगा , जो कि आवश्यकता को पूरा नहीं करता है "सभी कंटेनर NAT का उपयोग किए बिना किसी भी अन्य कंटेनर के साथ संवाद कर सकते हैं।" खैर, हम साबित करेंगे कि NAT की जरूरत क्यों नहीं है ...

चूल्हा रटना

अब हम फली को अनुकूलित करने के लिए तैयार हैं। चलो काम नोड्स में से एक के नाम के सभी नेटवर्क रिक्त स्थान को देखते हैं और उनमें से एक का विश्लेषण यहां nginx की तैनाती बनाने के बाद करते हैं । हम इच्छित प्रकार के नेमस्पेस (यानी net ) का चयन करने के लिए -t विकल्प के साथ lsns का उपयोग करेंगे:

 ubuntu@worker-0:~$ sudo lsns -t net NS TYPE NPROCS PID USER COMMAND 4026532089 net 113 1 root /sbin/init 4026532280 net 2 8046 root /pause 4026532352 net 4 16455 root /pause 4026532426 net 3 27255 root /pause 

ls लिए -i विकल्प का उपयोग करके हम उनके इनोड नंबर पा सकते हैं:

 ubuntu@worker-0:~$ ls -1i /var/run/netns 4026532352 cni-1d85bb0c-7c61-fd9f-2adc-f6e98f7a58af 4026532280 cni-7cec0838-f50c-416a-3b45-628a4237c55c 4026532426 cni-912bcc63-712d-1c84-89a7-9e10510808a0 

आप ip netns का उपयोग करके सभी नेटवर्क नामस्थानों को भी सूचीबद्ध कर सकते हैं:

 ubuntu@worker-0:~$ ip netns cni-912bcc63-712d-1c84-89a7-9e10510808a0 (id: 2) cni-1d85bb0c-7c61-fd9f-2adc-f6e98f7a58af (id: 1) cni-7cec0838-f50c-416a-3b45-628a4237c55c (id: 0) 

नेटवर्क स्पेस में चलने वाली सभी प्रक्रियाओं को देखने के लिए cni-912bcc63–712d-1c84–89a7–9e10510808a0 ( 4026532426 ), आप उदाहरण के लिए, निम्न कमांड चला सकते हैं:

 ubuntu@worker-0:~$ sudo ls -l /proc/[1-9]*/ns/net | grep 4026532426 | cut -f3 -d"/" | xargs ps -p PID TTY STAT TIME COMMAND 27255 ? Ss 0:00 /pause 27331 ? Ss 0:00 nginx: master process nginx -g daemon off; 27355 ? S 0:00 nginx: worker process 

यह देखा जा सकता है कि इस फली में pause अलावा, हमने nginx लॉन्च किया था। pause कंटेनर अन्य सभी पॉड कंटेनरों के साथ net और ipc नेमस्पेस साझा करता है। pause से पीआईडी ​​याद रखें - 27255; हम इसमें वापस लौटेंगे।

अब देखते हैं कि kubectl इस फली के बारे में क्या बताता है:

 $ kubectl get pods -o wide | grep nginx nginx-65899c769f-wxdx6 1/1 Running 0 5d 10.200.0.4 worker-0 

अधिक जानकारी:

 $ kubectl describe pods nginx-65899c769f-wxdx6 

 Name: nginx-65899c769f-wxdx6 Namespace: default Node: worker-0/10.240.0.20 Start Time: Thu, 05 Jul 2018 14:20:06 -0400 Labels: pod-template-hash=2145573259 run=nginx Annotations: <none> Status: Running IP: 10.200.0.4 Controlled By: ReplicaSet/nginx-65899c769f Containers: nginx: Container ID: containerd://4c0bd2e2e5c0b17c637af83376879c38f2fb11852921b12413c54ba49d6983c7 Image: nginx ... 

हम पॉड का नाम देखते हैं - nginx-65899c769f-wxdx6 - और इसके एक कंटेनर ( nginx ) की आईडी, लेकिन pause बारे में कुछ भी नहीं कहा गया है। सभी डेटा से मेल खाने के लिए एक गहरी कार्य नोड खोदें। याद रखें कि कुबेरनेट्स द हार्ड वे डोकर का उपयोग नहीं करते हैं, इसलिए कंटेनर के बारे में विवरण के लिए हम कंसोल यूटिलिटी कंटेनर - ctr (लेख को " कुबेरनेट्स के साथ कंटेनर का एकीकरण, डॉकटर की जगह, उत्पादन के लिए तैयार " - लगभग देखें ) का उपयोग करें । :

 ubuntu@worker-0:~$ sudo ctr namespaces ls NAME LABELS k8s.io 

k8s.io ( k8s.io ) k8s.io आप k8s.io कंटेनर आईडी प्राप्त कर सकते हैं:

 ubuntu@worker-0:~$ sudo ctr -n k8s.io containers ls | grep nginx 4c0bd2e2e5c0b17c637af83376879c38f2fb11852921b12413c54ba49d6983c7 docker.io/library/nginx:latest io.containerd.runtime.v1.linux 

... और pause भी:

 ubuntu@worker-0:~$ sudo ctr -n k8s.io containers ls | grep pause 0866803b612f2f55e7b6b83836bde09bd6530246239b7bde1e49c04c7038e43a k8s.gcr.io/pause:3.1 io.containerd.runtime.v1.linux 21640aea0210b320fd637c22ff93b7e21473178de0073b05de83f3b116fc8834 k8s.gcr.io/pause:3.1 io.containerd.runtime.v1.linux d19b1b1c92f7cc90764d4f385e8935d121bca66ba8982bae65baff1bc2841da6 k8s.gcr.io/pause:3.1 io.containerd.runtime.v1.linux 

में समाप्त होने वाला …983c7 कंटेनर आईडी …983c7 जो kubectl से मिला है। आइए देखें कि क्या हम पता लगा सकते हैं कि कौन सा pause कंटेनर nginx पॉड से संबंधित है:

 ubuntu@worker-0:~$ sudo ctr -n k8s.io task ls TASK PID STATUS ... d19b1b1c92f7cc90764d4f385e8935d121bca66ba8982bae65baff1bc2841da6 27255 RUNNING 4c0bd2e2e5c0b17c637af83376879c38f2fb11852921b12413c54ba49d6983c7 27331 RUNNING 

याद रखें कि PID 27331 और 27355 के साथ प्रक्रियाएं cni-912bcc63–712d-1c84–89a7–9e10510808a0 नेटवर्क नेमस्पेस चल रही हैं?

 ubuntu@worker-0:~$ sudo ctr -n k8s.io containers info d19b1b1c92f7cc90764d4f385e8935d121bca66ba8982bae65baff1bc2841da6 { "ID": "d19b1b1c92f7cc90764d4f385e8935d121bca66ba8982bae65baff1bc2841da6", "Labels": { "io.cri-containerd.kind": "sandbox", "io.kubernetes.pod.name": "nginx-65899c769f-wxdx6", "io.kubernetes.pod.namespace": "default", "io.kubernetes.pod.uid": "0b35e956-8080-11e8-8aa9-0a12b8818382", "pod-template-hash": "2145573259", "run": "nginx" }, "Image": "k8s.gcr.io/pause:3.1", ... 

... और:

 ubuntu@worker-0:~$ sudo ctr -n k8s.io containers info 4c0bd2e2e5c0b17c637af83376879c38f2fb11852921b12413c54ba49d6983c7 { "ID": "4c0bd2e2e5c0b17c637af83376879c38f2fb11852921b12413c54ba49d6983c7", "Labels": { "io.cri-containerd.kind": "container", "io.kubernetes.container.name": "nginx", "io.kubernetes.pod.name": "nginx-65899c769f-wxdx6", "io.kubernetes.pod.namespace": "default", "io.kubernetes.pod.uid": "0b35e956-8080-11e8-8aa9-0a12b8818382" }, "Image": "docker.io/library/nginx:latest", ... 

अब हम जानते हैं कि कौन से कंटेनर इस फली ( nginx-65899c769f-wxdx6 ) और नेटवर्क नेमस्पेस ( cni-912bcc63–712d-1c84–89a7–9e10510808a0 ) को चला रहे हैं:

• nginx (ID: 4c0bd2e2e5c0b17c637af83376879c38f2fb11852921b12413c54ba49d6983c7 );
• ठहराव (आईडी: d19b1b1c92f7cc90764d4f385e8935d121bca66ba8982bae65baff1bc2841da6 )।

यह नेटवर्क से कैसे जुड़ा हुआ है ( nginx-65899c769f-wxdx6 )? हम इसके नेटवर्क नेमस्पेस ( cni-912bcc63–712d-1c84–89a7–9e10510808a0 ) में कमांड चलाने के लिए पहले से प्राप्त PID 27255 का उपयोग करते हैं:

 ubuntu@worker-0:~$ sudo ip netns identify 27255 cni-912bcc63-712d-1c84-89a7-9e10510808a0 

इन उद्देश्यों के लिए, हम nsenter विकल्प के साथ nsenter का उपयोग करेंगे जो लक्ष्य PID को परिभाषित करता है, और -n एक फ़ाइल निर्दिष्ट किए बिना लक्ष्य प्रक्रिया के नेटवर्क नामस्थान में जाने के लिए (27255)। यहाँ क्या ip link show कहेंगे:

 ubuntu@worker-0:~$ sudo nsenter -t 27255 -n ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 3: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 0a:58:0a:c8:00:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0 

... और ifconfig eth0 :

 ubuntu@worker-0:~$ sudo nsenter -t 27255 -n ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.200.0.4 netmask 255.255.255.0 broadcast 0.0.0.0 inet6 fe80::2097:51ff:fe39:ec21 prefixlen 64 scopeid 0x20<link> ether 0a:58:0a:c8:00:04 txqueuelen 0 (Ethernet) RX packets 540 bytes 42247 (42.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 177 bytes 16530 (16.5 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

यह पुष्टि करता है कि kubectl get pod माध्यम से पहले प्राप्त IP पता eth0 इंटरफ़ेस पर कॉन्फ़िगर किया गया है। यह इंटरफ़ेस एक जोड़ी जोड़ी का हिस्सा है, जिसका एक छोर चूल्हा में है, और दूसरा रूट नेमस्पेस में है। दूसरे छोर के इंटरफ़ेस का पता लगाने के लिए, हम ethtool उपयोग करते हैं:

 ubuntu@worker-0:~$ sudo ip netns exec cni-912bcc63-712d-1c84-89a7-9e10510808a0 ethtool -S eth0 NIC statistics: peer_ifindex: 7 

हम देखते हैं कि दावत का ifindex 7. जाँच करें कि यह रूट नेमस्पेस में है। यह ip link का उपयोग करके किया जा सकता है:

 ubuntu@worker-0:~$ ip link | grep '^7:' 7: veth71f7d238@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cnio0 state UP mode DEFAULT group default 

अंत में यह सुनिश्चित करने के लिए, आइए देखें:

 ubuntu@worker-0:~$ sudo cat /sys/class/net/veth71f7d238/ifindex 7 

महान, अब वर्चुअल लिंक के साथ सब कुछ स्पष्ट है। brctl का उपयोग करते brctl आइए देखें कि लिनक्स ब्रिज से अन्य कौन जुड़ा है:

 ubuntu@worker-0:~$ brctl show cnio0 bridge name bridge id STP enabled interfaces cnio0 8000.0a580ac80001 no veth71f7d238 veth73f35410 vethf273b35f 

तो, चित्र इस प्रकार है:

रूटिंग चेक

हम वास्तव में यातायात को कैसे आगे बढ़ाते हैं? आइए नेटवर्क नेमस्पेस पॉड में राउटिंग टेबल देखें:

 ubuntu@worker-0:~$ sudo ip netns exec cni-912bcc63-712d-1c84-89a7-9e10510808a0 ip route show default via 10.200.0.1 dev eth0 10.200.0.0/24 dev eth0 proto kernel scope link src 10.200.0.4 

कम से कम हम जानते हैं कि रूट नेमस्पेस कैसे प्राप्त करें ( default via 10.200.0.1 )। अब मेजबान रूटिंग टेबल देखें:

 ubuntu@worker-0:~$ ip route list default via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.20 metric 100 10.200.0.0/24 dev cnio0 proto kernel scope link src 10.200.0.1 10.240.0.0/24 dev eth0 proto kernel scope link src 10.240.0.20 10.240.0.1 dev eth0 proto dhcp scope link src 10.240.0.20 metric 100 

हम जानते हैं कि एक VPC राउटर को पैकेट कैसे अग्रेषित किया जाता है (VPC में एक "निहित" राउटर होता है, जिसमें आमतौर पर सबनेट के मुख्य आईपी एड्रेस स्पेस से दूसरा पता होता है)। अब: क्या वीपीसी राउटर को पता है कि प्रत्येक चूल्हा के नेटवर्क को कैसे प्राप्त किया जाए? नहीं, वह नहीं करता है, इसलिए यह माना जाता है कि मार्गों को सीएनआई प्लग-इन या मैन्युअल रूप से कॉन्फ़िगर किया जाएगा (जैसा कि मैनुअल में है)। जाहिरा तौर पर, AWS CNI- प्लगइन AWS में हमारे लिए बस इतना ही करता है। याद रखें कि कई CNI प्लगइन्स हैं , और हम एक सरल नेटवर्क कॉन्फ़िगरेशन के उदाहरण पर विचार कर रहे हैं:

नैट में गहरा विसर्जन

kubectl create -f busybox.yaml प्रतिकृति नियंत्रक के साथ दो समान kubectl create -f busybox.yaml कंटेनर बनाएं:

 apiVersion: v1 kind: ReplicationController metadata: name: busybox0 labels: app: busybox0 spec: replicas: 2 selector: app: busybox0 template: metadata: name: busybox0 labels: app: busybox0 spec: containers: - image: busybox command: - sleep - "3600" imagePullPolicy: IfNotPresent name: busybox restartPolicy: Always 

( busybox.yaml )

हमें मिलता है:

 $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE busybox0-g6pww 1/1 Running 0 4s 10.200.1.15 worker-1 busybox0-rw89s 1/1 Running 0 4s 10.200.0.21 worker-0 ... 

एक कंटेनर से दूसरे कंटेनर में पिंग सफल होना चाहिए:

 $ kubectl exec -it busybox0-rw89s -- ping -c 2 10.200.1.15 PING 10.200.1.15 (10.200.1.15): 56 data bytes 64 bytes from 10.200.1.15: seq=0 ttl=62 time=0.528 ms 64 bytes from 10.200.1.15: seq=1 ttl=62 time=0.440 ms --- 10.200.1.15 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.440/0.484/0.528 ms 

ट्रैफ़िक के प्रवाह को समझने के लिए, आप tcpdump या conntrack का उपयोग करके पैकेट देख सकते हैं:

 ubuntu@worker-0:~$ sudo conntrack -L | grep 10.200.1.15 icmp 1 29 src=10.200.0.21 dst=10.200.1.15 type=8 code=0 id=1280 src=10.200.1.15 dst=10.240.0.20 type=0 code=0 id=1280 mark=0 use=1 

फली 10.200.0.21 से स्रोत आईपी मेजबान 10.240.0.20 के आईपी पते में अनुवादित है।

 ubuntu@worker-1:~$ sudo conntrack -L | grep 10.200.1.15 icmp 1 28 src=10.240.0.20 dst=10.200.1.15 type=8 code=0 id=1280 src=10.200.1.15 dst=10.240.0.20 type=0 code=0 id=1280 mark=0 use=1 

Iptables में, आप देख सकते हैं कि गिनती बढ़ रही है:

 ubuntu@worker-0:~$ sudo iptables -t nat -Z POSTROUTING -L -v Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination ... 5 324 CNI-be726a77f15ea47ff32947a3 all -- any any 10.200.0.0/24 anywhere /* name: "bridge" id: "631cab5de5565cc432a3beca0e2aece0cef9285482b11f3eb0b46c134e457854" */ Zeroing chain `POSTROUTING' 

दूसरी ओर, यदि आप "ipMasq": true CNI प्लगइन कॉन्फ़िगरेशन से "ipMasq": true है, तो आप निम्नलिखित देख सकते हैं (यह ऑपरेशन विशेष रूप से शैक्षिक उद्देश्यों के लिए किया जाता है - हम एक कार्यशील क्लस्टर पर कॉन्फ़िगरेशन बदलने की अनुशंसा नहीं करते हैं!):

 $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE busybox0-2btxn 1/1 Running 0 16s 10.200.0.15 worker-0 busybox0-dhpx8 1/1 Running 0 16s 10.200.1.13 worker-1 ... 

पिंग अभी भी पास होना चाहिए:

 $ kubectl exec -it busybox0-2btxn -- ping -c 2 10.200.1.13 PING 10.200.1.6 (10.200.1.6): 56 data bytes 64 bytes from 10.200.1.6: seq=0 ttl=62 time=0.515 ms 64 bytes from 10.200.1.6: seq=1 ttl=62 time=0.427 ms --- 10.200.1.6 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.427/0.471/0.515 ms 

और इस मामले में - NAT का उपयोग किए बिना:

 ubuntu@worker-0:~$ sudo conntrack -L | grep 10.200.1.13 icmp 1 29 src=10.200.0.15 dst=10.200.1.13 type=8 code=0 id=1792 src=10.200.1.13 dst=10.200.0.15 type=0 code=0 id=1792 mark=0 use=1 

इसलिए, हमने जाँच की कि "सभी कंटेनर NAT का उपयोग किए बिना किसी भी अन्य कंटेनर के साथ संचार कर सकते हैं।"

 ubuntu@worker-1:~$ sudo conntrack -L | grep 10.200.1.13 icmp 1 27 src=10.200.0.15 dst=10.200.1.13 type=8 code=0 id=1792 src=10.200.1.13 dst=10.200.0.15 type=0 code=0 id=1792 mark=0 use=1 

क्लस्टर नेटवर्क (10.32.0.0/24)

आपने busybox उदाहरण में देखा होगा कि busybox को दिए गए आईपी एड्रेस हर मामले में अलग थे। क्या होगा अगर हम इन कंटेनर को अन्य चूल्हा से संचार के लिए उपलब्ध कराना चाहते हैं? एक फली के वर्तमान आईपी पते ले सकते हैं, लेकिन वे बदल जाएंगे। इस कारण से, आपको Service संसाधन को कॉन्फ़िगर करने की आवश्यकता है, जो कई अल्पकालिक सुनवाई के अनुरोधों को प्रॉक्सी करेगा।

"कुबेरनेट्स में सेवा एक अमूर्तता है जो चूल्हों के तार्किक सेट और उन नीतियों को परिभाषित करती है जिनके द्वारा उन्हें एक्सेस किया जा सकता है।" ( कुबेरनेट्स सेवा प्रलेखन से)

किसी सेवा को प्रकाशित करने के विभिन्न तरीके हैं; डिफ़ॉल्ट प्रकार ClusterIP , जो क्लस्टर के CIDR ब्लॉक से IP पता सेट करता है (यानी, केवल क्लस्टर से सुलभ)। ऐसा ही एक उदाहरण कुबेरनेट्स द हार्ड वे में कॉन्फ़िगर किया गया डीएनएस क्लस्टर ऐड-ऑन है।

 # ... apiVersion: v1 kind: Service metadata: name: kube-dns namespace: kube-system labels: k8s-app: kube-dns kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "KubeDNS" spec: selector: k8s-app: kube-dns clusterIP: 10.32.0.10 ports: - name: dns port: 53 protocol: UDP - name: dns-tcp port: 53 protocol: TCP # ... 

( kube-dns.yaml )

kubectl दिखाता है कि Service समापन बिंदु को याद करती है और उनका अनुवाद करती है:

 $ kubectl -n kube-system describe services ... Selector: k8s-app=kube-dns Type: ClusterIP IP: 10.32.0.10 Port: dns 53/UDP TargetPort: 53/UDP Endpoints: 10.200.0.27:53 Port: dns-tcp 53/TCP TargetPort: 53/TCP Endpoints: 10.200.0.27:53 ... 

बिल्कुल कैसे? .. iptables फिर से। आइए इस उदाहरण के लिए बनाए गए नियमों से गुजरें। उनकी पूरी सूची को iptables-save कमांड के साथ देखा जा सकता है।

जैसे ही पैकेट प्रक्रिया ( OUTPUT ) द्वारा बनाए जाते हैं या नेटवर्क इंटरफेस ( PREROUTING ) पर आते हैं, वे निम्नलिखित iptables श्रृंखलाओं से गुजरते हैं:

 -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES -A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES 

निम्नलिखित लक्ष्य टीसीपी पैकेट के लिए 10 वें नंबर पर 10.32.0.10 पर भेजे गए हैं, और 53 वें पोर्ट के साथ प्राप्तकर्ता को 10.200.0.27 पर प्रेषित किया जाता है:

 -A KUBE-SERVICES -d 10.32.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 -A KUBE-SVC-ERIFXISQEP7F7OF4 -m comment --comment "kube-system/kube-dns:dns-tcp" -j KUBE-SEP-32LPCMGYG6ODGN3H -A KUBE-SEP-32LPCMGYG6ODGN3H -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp" -m tcp -j DNAT --to-destination 10.200.0.27:53 

UDP पैकेट के लिए समान (प्राप्तकर्ता 10.32.0.10:53 → 10.200.0.27:53)

 -A KUBE-SERVICES -d 10.32.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -j KUBE-SEP-LRUTK6XRXU43VLIG -A KUBE-SEP-LRUTK6XRXU43VLIG -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.200.0.27:53 

कुबेरनेट्स में अन्य प्रकार की Services । विशेष रूप से, कुबेरनेट्स द हार्ड वे NodePort बारे में NodePort करते हैं - स्मोक टेस्ट: सेवाएँ देखें ।

 kubectl expose deployment nginx --port 80 --type NodePort 

NodePort प्रत्येक नोड के IP पते पर सेवा को प्रकाशित करता है, इसे एक स्थिर पोर्ट पर रखता है (इसे NodePort कहा जाता है)। NodePort को क्लस्टर के बाहर से NodePort एक्सेस किया जा सकता है। आप kubectl का उपयोग करके समर्पित पोर्ट (इस मामले में - 31088) की जांच कर kubectl :

 $ kubectl describe services nginx ... Type: NodePort IP: 10.32.0.53 Port: <unset> 80/TCP TargetPort: 80/TCP NodePort: <unset> 31088/TCP Endpoints: 10.200.1.18:80 ... 

अब इंटरनेट से http://${EXTERNAL_IP}:31088/ । यहां EXTERNAL_IP किसी भी कामकाजी उदाहरण का सार्वजनिक IP पता है। इस उदाहरण में, मैंने कार्यकर्ता -0 के सार्वजनिक आईपी पते का उपयोग किया है। अनुरोध 10.240.0.20 (क्लाउड प्रदाता सार्वजनिक NAT में लगा हुआ है) के आंतरिक IP पते के साथ एक मेजबान द्वारा प्राप्त किया जाता है, हालांकि, सेवा वास्तव में एक अन्य होस्ट ( कार्यकर्ता -1) पर शुरू होती है, जिसे एंडपॉइंट के आईपी पते (10.200.1.18) द्वारा देखा जा सकता है:

 ubuntu@worker-0:~$ sudo conntrack -L | grep 31088 tcp 6 86397 ESTABLISHED src=173.38.XXX.XXX dst=10.240.0.20 sport=30303 dport=31088 src=10.200.1.18 dst=10.240.0.20 sport=80 dport=30303 [ASSURED] mark=0 use=1 

पैकेट को कार्यकर्ता -० से कार्यकर्ता -१ में भेजा जाता है, जहाँ वह अपना प्राप्तकर्ता पाता है:

 ubuntu@worker-1:~$ sudo conntrack -L | grep 80 tcp 6 86392 ESTABLISHED src=10.240.0.20 dst=10.200.1.18 sport=14802 dport=80 src=10.200.1.18 dst=10.240.0.20 sport=80 dport=14802 [ASSURED] mark=0 use=1 

क्या ऐसा सर्किट आदर्श है? शायद नहीं, लेकिन यह काम करता है। इस मामले में, प्रोग्राम किए गए iptables नियम इस प्रकार हैं:

 -A KUBE-NODEPORTS -p tcp -m comment --comment "default/nginx:" -m tcp --dport 31088 -j KUBE-SVC-4N57TFCL4MD7ZTDA -A KUBE-SVC-4N57TFCL4MD7ZTDA -m comment --comment "default/nginx:" -j KUBE-SEP-UGTFMET44DQG7H7H -A KUBE-SEP-UGTFMET44DQG7H7H -p tcp -m comment --comment "default/nginx:" -m tcp -j DNAT --to-destination 10.200.1.18:80 

दूसरे शब्दों में, पोर्ट 31088 के साथ पैकेट प्राप्त करने वाले का पता 10.200.1.18 को प्रसारित होता है। बंदरगाह भी प्रसारण कर रहा है, 31088 से 80 तक।

हमने किसी अन्य प्रकार की सेवा पर लोड नहीं किया - LoadBalancer - जो क्लाउड प्रदाता लोड बैलेंसर का उपयोग करके सेवा को सार्वजनिक रूप से उपलब्ध कराता है, लेकिन लेख पहले ही बड़ा हो गया है।

निष्कर्ष

ऐसा लग सकता है कि बहुत सारी जानकारी है, लेकिन हमने केवल हिमशैल के सिरे को छुआ है। भविष्य में मैं IPv6, IPVS, eBPF और कुछ दिलचस्प वर्तमान CNI प्लगइन्स के बारे में बात करने जा रहा हूँ।

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

• " कुबेरनेट्स पर नेटवर्किंग के लिए इलस्ट्रेटेड गाइड ";
• " कुबेरनेट्स के लिए नेटवर्क के प्रदर्शन की तुलना ";
• " कुबेरनेट्स में क्यूब-प्रॉक्सी और होस्ट की अयोग्यता के साथ प्रयोग ";
• " कुबेरनेट की विश्वसनीयता में सुधार: कैसे जल्दी से नोटिस करने के लिए कि एक नोड गिर गया है ";
• « Play with Kubernetes — K8s »;
• « Kubernetes » ( , Kubernetes) ;
• « Container Networking Interface (CNI) — Linux- ».