🛕 ♐️ 🤳🏼 कुबेरनेट्स में नेटवर्किंग के लिए केलिको: जानना और थोड़ा अनुभव प्राप्त करना 🏂🏿 👛 😷

लेख का उद्देश्य पाठक को कुबेरनेट्स में नेटवर्किंग की नीतियों और नेटवर्क नीतियों के प्रबंधन के साथ-साथ एक तृतीय-पक्ष केलिको प्लग-इन शामिल करना है जो मानक सुविधाओं का विस्तार करता है। साथ ही, कॉन्फ़िगरेशन की सुविधा और कुछ सुविधाओं को हमारे ऑपरेशन के अनुभव से वास्तविक उदाहरणों के साथ प्रदर्शित किया जाएगा।

कुबेरनेट्स नेटवर्क डिवाइस का त्वरित परिचय

बिना नेटवर्क के कुबेरनेट क्लस्टर की कल्पना नहीं की जा सकती। हमने पहले से ही उनके मूल पर सामग्री प्रकाशित की है: " कुबेरनेट्स में नेटवर्किंग के लिए एक इलस्ट्रेटेड गाइड " और " सुरक्षा पेशेवरों के लिए कुबेरनेट्स नेटवर्क नीतियों का परिचय "।

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

उदाहरण के लिए, इनमें से सबसे आम प्लग-इन - फ़्लेनेल - प्रत्येक नोड पर पुलों को उठाकर क्लस्टर के सभी नोड्स के बीच पूर्ण नेटवर्क कनेक्टिविटी प्रदान करता है, इसके लिए एक सबनेट सुरक्षित करता है। हालांकि, पूर्ण और अनियमित उपलब्धता हमेशा उपयोगी नहीं होती है। क्लस्टर में कुछ न्यूनतम अलगाव प्रदान करने के लिए, फ़ायरवॉल के कॉन्फ़िगरेशन में हस्तक्षेप करना आवश्यक है। सामान्य तौर पर, यह बहुत CNI के प्रबंधन को दिया जाता है, जिसके कारण iptables में किसी भी तृतीय-पक्ष के हस्तक्षेप को गलत तरीके से समझा जा सकता है या पूरी तरह से अनदेखा किया जा सकता है।

और बॉक्स के बाहर, नेटवर्कपुलिस एपीआई कुबेरनेट क्लस्टर में नेटवर्क नीति प्रबंधन के आयोजन के लिए प्रदान किया जाता है। यह संसाधन, जो चयनित नामस्थानों तक विस्तृत है, इसमें एक एप्लिकेशन से दूसरे तक पहुंच को प्रतिबंधित करने के नियम हो सकते हैं। यह आपको विशिष्ट पोड, वातावरण (नेमस्पेस) या IP पतों के ब्लॉक के बीच पहुंच को कॉन्फ़िगर करने की अनुमति देता है:

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978

यह आधिकारिक दस्तावेज से सबसे प्रमुख उदाहरण नहीं है जो एक बार और सभी के लिए नेटवर्क नीतियों के तर्क को समझने की इच्छा को हतोत्साहित कर सकता है। हालाँकि, हम अभी भी नेटवर्क नीतियों का उपयोग करके यातायात के प्रवाह के मूल सिद्धांतों और तरीकों को समझने की कोशिश करते हैं ...

यह तर्कसंगत है कि 2 प्रकार के ट्रैफ़िक हैं: पॉड (इनग्रेशन) के लिए आने वाले और उससे बाहर जाने वाले (ईग्रेड)।

दरअसल, आंदोलन की दिशा में राजनीति को इन 2 श्रेणियों में विभाजित किया गया है।

अगली आवश्यक विशेषता एक चयनकर्ता है; वह जिस पर नियम लागू होता है। यह एक फली (या फली का एक समूह) या एक पर्यावरण (यानी एक नाम स्थान) हो सकता है। एक महत्वपूर्ण विवरण: इन दोनों प्रकार की वस्तुओं में एक लेबल (कुबेरनेट्स शब्दावली में लेबल ) होना चाहिए - ये ऐसी नीतियाँ हैं जो संचालित होती हैं।

कुछ लेबल द्वारा एकजुट चयनकर्ताओं की एक सीमित संख्या के अलावा, विभिन्न प्रकारों में "अनुमति दें / इनकार करें / सभी" जैसे नियम लिखने की संभावना है। इसके लिए, फॉर्म के निर्माण का उपयोग किया जाता है:

  podSelector: {} ingress: [] policyTypes: - Ingress

- इस उदाहरण में, पर्यावरण के सभी पॉड्स आने वाले ट्रैफ़िक को बंद कर देते हैं। इस तरह के निर्माण से विपरीत व्यवहार को प्राप्त किया जा सकता है:

  podSelector: {} ingress: - {} policyTypes: - Ingress

इसी तरह आउटगोइंग के लिए:

  podSelector: {} policyTypes: - Egress

- इसे निष्क्रिय करना। और यहाँ क्या शामिल है:

  podSelector: {} egress: - {} policyTypes: - Egress

क्लस्टर के लिए CNI प्लगइन की पसंद पर वापस लौटना, यह ध्यान देने योग्य है कि प्रत्येक नेटवर्क प्लगइन NetworkPolicy के साथ काम करने का समर्थन नहीं करता है । उदाहरण के लिए, पहले से ही उल्लेख किए गए फलालैन को पता नहीं है कि नेटवर्क नीतियों को कैसे कॉन्फ़िगर किया जाए, जैसा कि आधिकारिक रिपॉजिटरी में स्पष्ट रूप से कहा गया है। वहाँ एक विकल्प का भी उल्लेख किया गया है - केलिको ओपन सोर्स प्रोजेक्ट, जो नेटवर्क नीतियों के संदर्भ में मानक कुबेरनेट एपीआई को बढ़ाता है।

मिलो कैलिको: सिद्धांत

Calico प्लगइन का उपयोग फ़्लेनेल (एक नहर सबप्रोजेक्ट) के साथ या अपने आप से किया जा सकता है, जो नेटवर्क कनेक्टिविटी और उपलब्धता प्रबंधन सुविधाओं को कवर करता है।

K8s बॉक्सिंग समाधान और कैलिको एपीआई सेट क्या विशेषताएं प्रदान करता है?

यहाँ है जो NetworkPolicy में बनाया गया है:

राजनेता पर्यावरण द्वारा सीमित होते हैं;
नीतियां लेबल के साथ टैग की गई पॉड्स पर लागू होती हैं।
नियमों को फली, पर्यावरण या सबनेट पर लागू किया जा सकता है;
नियमों में प्रोटोकॉल, नाम या प्रतीकात्मक बंदरगाह निर्देश शामिल हो सकते हैं।

और यहाँ बताया गया है कि केलिको इन सुविधाओं का विस्तार कैसे करता है:

नीतियों को किसी भी वस्तु पर लागू किया जा सकता है: फली, कंटेनर, वर्चुअल मशीन या इंटरफ़ेस;
नियमों में एक विशिष्ट कार्रवाई (निषेध, अनुमति, लॉगिंग) हो सकती है;
लक्ष्य या नियमों का स्रोत पोर्ट, पोर्ट रेंज, प्रोटोकॉल, HTTP या ICMP विशेषताएँ, IP या सबनेट (4 या 6 पीढ़ियाँ), कोई भी चयनकर्ता (नोड्स, होस्ट, वातावरण) हो सकता है;
इसके अतिरिक्त, DNAT सेटिंग्स और ट्रैफ़िक अग्रेषण नीतियों का उपयोग करके ट्रैफ़िक प्रवाह को नियंत्रित किया जा सकता है।

पहला GitHub कैलिको रिपॉजिटरी में जुलाई 2016 तक वापस चला जाता है, और एक साल बाद प्रोजेक्ट ने कुबेरनेट्स नेटवर्क कनेक्टिविटी के संगठन में एक अग्रणी स्थान लिया - यह संकेत दिया गया है, उदाहरण के लिए, द न्यू स्टैक द्वारा किए गए सर्वेक्षण के परिणामों से:

K8s के साथ कई बड़े प्रबंधित समाधान, जैसे कि अमेजन EKS , Azure AKS , Google GKE और अन्य, इसे उपयोग के लिए अनुशंसित करने लगे।

प्रदर्शन के लिए, यहाँ सब कुछ बहुत अच्छा है। अपने उत्पाद का परीक्षण करते समय, कैलिको विकास टीम ने 500 भौतिक नोड्स पर 50,000 से अधिक कंटेनर लॉन्च करके खगोलीय प्रदर्शन का प्रदर्शन किया, जिसमें प्रति सेकंड 20 कंटेनर बनाने की गति थी। स्केलिंग की कोई समस्या नहीं थी। इस तरह के परिणाम पहले संस्करण की घोषणा के समय घोषित किए गए थे । बैंडविड्थ और संसाधन खपत पर स्वतंत्र शोध भी कैलिको के प्रदर्शन की पुष्टि करता है, जो कि फ्लानेल के लगभग समान है। उदाहरण के लिए :

यह परियोजना बहुत तेजी से विकसित हो रही है, यह K8s, OpenShift, OpenStack जैसे लोकप्रिय समाधानों में काम का समर्थन करता है, कैलोप्स का उपयोग करते हुए एक क्लस्टर को तैनात करते समय कैलिको का उपयोग करना संभव है, सेवा जाल नेटवर्क के निर्माण के संदर्भ हैं ( यहां इस्तियो के साथ इसका उपयोग करने का एक उदाहरण है )।

कैलिको के साथ अभ्यास करें

वेनिला कुबेरनेट्स का उपयोग करने के सामान्य मामले में, सीएनआई को स्थापित करने के लिए आधिकारिक साइट से डाउनलोड calico.yaml . calico.yaml फ़ाइल का उपयोग करने के लिए फोड़ा जाता है।

एक नियम के रूप में, प्लगइन का वर्तमान संस्करण कुबेरनेट्स के नवीनतम 2-3 संस्करणों के साथ संगत है: पुराने संस्करणों में काम का परीक्षण नहीं किया जाता है और गारंटी नहीं देता है। डेवलपर्स के अनुसार, कैलिको लिनक्स के कर्नेल पर 3.10 से ऊपर सेंटोस 7, उबंटू 16 या डेबियन 8 के तहत, आईपबल या आईपीवीएस के शीर्ष पर चलता है।

पर्यावरण के अंदर इन्सुलेशन

एक सामान्य समझ के लिए, यह समझने के लिए एक साधारण मामले पर विचार करें कि कैलिको संकेतन में नेटवर्क नीतियां मानक लोगों से कैसे भिन्न हैं और नियमों को संकलित करने का तरीका उनकी पठनीयता और विन्यास लचीलेपन को सरल करता है:

क्लस्टर में 2 वेब एप्लिकेशन तैनात हैं: Node.js और PHP, जिनमें से एक Redis का उपयोग करता है। PHP से Redis तक पहुँच को ब्लॉक करने के लिए, Node.js के साथ कनेक्टिविटी छोड़ते समय, यह निम्नलिखित नीति को लागू करने के लिए पर्याप्त है:

 kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-redis-nodejs spec: podSelector: matchLabels: service: redis ingress: - from: - podSelector: matchLabels: service: nodejs ports: - protocol: TCP port: 6379

अनिवार्य रूप से, हमने Node.js. से Redis पोर्ट पर आने वाले ट्रैफ़िक की अनुमति दी और जाहिर है कि उन्होंने और कुछ भी मना नहीं किया। जैसे ही NetworkPolicy प्रकट होता है, तब इसमें बताए गए सभी चयनकर्ता अलग-अलग होने लगते हैं, जब तक कि अन्यथा संकेत न दिया जाए। इसके अलावा, अलगाव नियम अन्य वस्तुओं पर लागू नहीं होते हैं जो चयनकर्ता द्वारा कवर नहीं किए जाते हैं।

उदाहरण apiVersion एपिवर्सन "बॉक्स से बाहर" का उपयोग करता है, लेकिन कैलिको डिलीवरी से समान नाम के संसाधन का उपयोग करने से कुछ भी नहीं रोकता है। वाक्यविन्यास वहाँ अधिक व्यापक है, इसलिए आपको निम्नलिखित मामले में उपरोक्त मामले के लिए नियम को फिर से लिखना होगा:

 apiVersion: crd.projectcalico.org/v1 kind: NetworkPolicy metadata: name: allow-redis-nodejs spec: selector: service == 'redis' ingress: - action: Allow protocol: TCP source: selector: service == 'nodejs' destination: ports: - 6379

सामान्य नेटवर्कपॉलिशी एपीआई के माध्यम से सभी ट्रैफ़िक को अनुमति देने या प्रतिबंधित करने के लिए ऊपर उल्लिखित निर्माण में ब्रैकेट्स के साथ संरचनाएं शामिल हैं जिन्हें समझना और याद रखना मुश्किल है। केलिको के मामले में, फ़ायरवॉल नियम के तर्क को विपरीत में बदलने के लिए, बस action: Allow बदलें action: Allow action: Deny करने की action: Allow action: Deny ।

पर्यावरण अलगाव

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

प्रोमेथियस, एक नियम के रूप में, एक अलग सेवा वातावरण में रखा जाता है - उदाहरण में, यह निम्नलिखित का एक नाम स्थान होगा:

 apiVersion: v1 kind: Namespace metadata: labels: module: prometheus name: kube-prometheus

यहां metadata.labels फील्ड आकस्मिक नहीं था। जैसा कि ऊपर उल्लेख किया गया है, podSelector (जैसे podSelector ) लेबल पर संचालित होता है। इसलिए, एक विशिष्ट पोर्ट पर सभी पॉड्स से मैट्रिक्स लेने की अनुमति देने के लिए, आपको कुछ लेबल जोड़ना होगा (या मौजूदा वाले से लेना), और फिर एक कॉन्फ़िगरेशन लागू करना होगा जैसे:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-metrics-prom spec: podSelector: {} ingress: - from: - namespaceSelector: matchLabels: module: prometheus ports: - protocol: TCP port: 9100

और यदि आप कैलिको नीतियों का उपयोग करते हैं, तो सिंटैक्स होगा:

 apiVersion: crd.projectcalico.org/v1 kind: NetworkPolicy metadata: name: allow-metrics-prom spec: ingress: - action: Allow protocol: TCP source: namespaceSelector: module == 'prometheus' destination: ports: - 9100

सामान्य तौर पर, विशिष्ट आवश्यकताओं के लिए इस तरह की नीति को जोड़कर, आप क्लस्टर में अनुप्रयोगों के संचालन में दुर्भावनापूर्ण या आकस्मिक हस्तक्षेप से रक्षा कर सकते हैं।

केलिको के रचनाकारों के अनुसार, सबसे अच्छा अभ्यास, " आधिकारिक सब कुछ और स्पष्ट रूप से खोज की आवश्यकता है" दृष्टिकोण है, जैसा कि आधिकारिक दस्तावेज में दर्ज किया गया है (अन्य विशेष रूप से, पहले से उल्लेखित लेख में इसी तरह के दृष्टिकोण का पालन करते हैं)।

कैलिको वैकल्पिक वस्तुओं का उपयोग करना

आपको याद दिला दूं कि कैलिको एपीआई के विस्तारित सेट के माध्यम से, आप नोड्स की उपलब्धता को नियंत्रित कर सकते हैं, न कि फली तक सीमित। निम्न उदाहरण में, GlobalNetworkPolicy का उपयोग करने से क्लस्टर में ICMP अनुरोधों को पारित करने की संभावना बंद हो जाती है (उदाहरण के लिए, फली से नोड तक, फली के बीच या नोड से आईपी पॉड के लिए):

 apiVersion: crd.projectcalico.org/v1 kind: GlobalNetworkPolicy metadata: name: block-icmp spec: order: 200 selector: all() types: - Ingress - Egress ingress: - action: Deny protocol: ICMP egress: - action: Deny protocol: ICMP

उपरोक्त मामले में, क्लस्टर नोड्स अभी भी ICMP के माध्यम से एक दूसरे तक "पहुंच" करने में सक्षम हैं। और यह सवाल GlobalNetworkPolicy माध्यम से HostEndpoint संस्था पर लागू होता है:

 apiVersion: crd.projectcalico.org/v1 kind: GlobalNetworkPolicy metadata: name: deny-icmp-kube-02 spec: selector: "role == 'k8s-node'" order: 0 ingress: - action: Allow protocol: ICMP egress: - action: Allow protocol: ICMP --- apiVersion: crd.projectcalico.org/v1 kind: HostEndpoint metadata: name: kube-02-eth0 labels: role: k8s-node spec: interfaceName: eth0 node: kube-02 expectedIPs: ["192.168.2.2"]

वीपीएन मामला

अंत में, मैं निकट-क्लस्टर इंटरैक्शन के साथ मामले के लिए कैलिको फ़ंक्शन का उपयोग करने का एक बहुत ही वास्तविक उदाहरण दूंगा, जब नीतियों का मानक सेट पर्याप्त नहीं है। एक वीपीएन सुरंग का उपयोग क्लाइंट द्वारा वेब एप्लिकेशन को एक्सेस करने के लिए किया जाता है, और यह एक्सेस नियंत्रित सेवाओं की एक विशिष्ट सूची तक कसकर नियंत्रित और सीमित है:

ग्राहक मानक यूडीपी पोर्ट 1194 के माध्यम से वीपीएन से जुड़ते हैं और कनेक्ट होने पर, फली और सेवाओं के क्लस्टर सबनेट के लिए मार्ग प्राप्त करते हैं। पुश सबनेट पूरी तरह से पुनरारंभ और पते में परिवर्तन के दौरान सेवाओं को नहीं खोने के लिए हैं।

कॉन्फ़िगरेशन में पोर्ट मानक है, जो एप्लिकेशन को कॉन्फ़िगर करने की प्रक्रिया और कुबेरनेट क्लस्टर में इसके हस्तांतरण पर कुछ बारीकियों को लगाता है। उदाहरण के लिए, एक ही AWS में, UDP के लिए LoadBalancer, पिछले साल के अंत में क्षेत्रों की एक सीमित सूची में दिखाई दिया, और NodePort को सभी क्लस्टर नोड्स पर अग्रेषित करने के कारण उपयोग नहीं किया जा सकता है और गलती सहिष्णुता के लिए सर्वर इंस्टेंस की संख्या को मापना असंभव है। साथ ही, आपको डिफ़ॉल्ट पोर्ट रेंज को बदलना होगा ...

संभावित समाधानों की खोज के परिणामस्वरूप, निम्नलिखित को चुना गया:

वीपीएन पॉड्स को hostNetwork मोड में प्रति होस्ट पर निर्धारित किया hostNetwork है, अर्थात वास्तविक आईपी पर।
सेवा ClusterIP पोस्ट के माध्यम से पोस्ट की गई है। बंदरगाह शारीरिक रूप से मेजबान पर उगता है, जो बाहर से कुछ कैविट्स (वास्तविक आईपी पते की सशर्त उपलब्धता) के साथ सुलभ है।
नोड की परिभाषा जिस पर फली गुलाब हमारी कहानी के दायरे से परे है। मैं केवल इतना ही कह सकता हूं कि आप होस्ट को सेवा को मजबूती से "नेल" कर सकते हैं या एक छोटी सी सेवा लिख सकते हैं जो वीपीएन सेवा के वर्तमान आईपी पते की निगरानी करेगा और क्लाइंट के साथ पंजीकृत डीएनएस रिकॉर्ड को संपादित करेगा - जिसके पास पर्याप्त कल्पना है।

रूटिंग के दृष्टिकोण से, हम वीपीएन के लिए ग्राहक को वीपीएन सर्वर द्वारा जारी किए गए अपने आईपी पते से विशिष्ट रूप से पहचान सकते हैं। नीचे इस तरह के एक ग्राहक को सेवाओं तक पहुंच को प्रतिबंधित करने का एक आदिम उदाहरण है, उपर्युक्त रेडिस पर एक दृष्टांत:

 apiVersion: crd.projectcalico.org/v1 kind: HostEndpoint metadata: name: vpnclient-eth0 labels: role: vpnclient environment: production spec: interfaceName: "*" node: kube-02 expectedIPs: ["172.176.176.2"] --- apiVersion: crd.projectcalico.org/v1 kind: GlobalNetworkPolicy metadata: name: vpn-rules spec: selector: "role == 'vpnclient'" order: 0 applyOnForward: true preDNAT: true ingress: - action: Deny protocol: TCP destination: ports: [6379] - action: Allow protocol: UDP destination: ports: [53, 67]

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

परिणाम

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

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

पुनश्च

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

" सुरक्षा पेशेवरों के लिए कुबेरनेट्स नेटवर्क नीतियों का परिचय ";
"कुबर्नेट्स में नेटवर्किंग के लिए इलस्ट्रेटेड गाइड": भाग 1 और 2 (नेटवर्क मॉडल, ओवरले नेटवर्क) , भाग 3 (सेवाएं और यातायात प्रसंस्करण) ;
" कंटेनर नेटवर्किंग इंटरफ़ेस (CNI) लिनक्स कंटेनर के लिए नेटवर्क इंटरफ़ेस और मानक है ।"

कुबेरनेट्स में नेटवर्किंग के लिए केलिको: जानना और थोड़ा अनुभव प्राप्त करना