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

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

कुबेरनेट्स नेटवर्किंग उपकरण का एक त्वरित परिचय

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

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

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

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

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 प्लगइन की पसंद पर लौटते हुए, यह ध्यान देने योग्य है प्रत्येक नेटवर्क प्लगइन नेटवर्कपॉलिसी का समर्थन नहीं करता है. उदाहरण के लिए, पहले से उल्लिखित फ़्लानेल को यह नहीं पता कि नेटवर्क नीतियों को कैसे कॉन्फ़िगर किया जाए यह सीधे तौर पर कहा गया है आधिकारिक भंडार में. वहां एक विकल्प का भी उल्लेख किया गया है - एक ओपन सोर्स प्रोजेक्ट कैलिकौ, जो नेटवर्क नीतियों के संदर्भ में कुबेरनेट्स एपीआई के मानक सेट का महत्वपूर्ण रूप से विस्तार करता है।

केलिको को जानना: सिद्धांत

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

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

यहां बताया गया है कि नेटवर्कपॉलिसी में क्या बनाया गया है:

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

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

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

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

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

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

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

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

वेनिला कुबेरनेट्स का उपयोग करने के सामान्य मामले में, सीएनआई स्थापित करना फ़ाइल का उपयोग करने के लिए नीचे आता है calico.yaml, आधिकारिक वेबसाइट से डाउनलोड किया गया, с омощью kubectl apply -f.

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

पर्यावरण के भीतर अलगाव

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

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

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 से रेडिस पोर्ट पर आने वाले ट्रैफ़िक की अनुमति दी। और उन्होंने स्पष्ट रूप से किसी और चीज़ पर रोक नहीं लगाई। जैसे ही नेटवर्कपॉलिसी प्रकट होती है, इसमें उल्लिखित सभी चयनकर्ता अलग-थलग होने लगते हैं, जब तक कि अन्यथा निर्दिष्ट न हो। हालाँकि, अलगाव नियम चयनकर्ता द्वारा कवर नहीं की गई अन्य वस्तुओं पर लागू नहीं होते हैं।

उदाहरण का उपयोग करता है 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: Deny.

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

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

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

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

क्षेत्र metadata.labels यह कोई दुर्घटना नहीं थी। जैसा ऊपर उल्लिखित है, namespaceSelector (साथ ही 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 अनुरोधों को पारित करने की क्षमता बंद है (उदाहरण के लिए, पॉड से नोड तक, पॉड्स के बीच, या नोड से IP पॉड तक पिंग):

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 का उपयोग नहीं किया जा सकता है और इसके लिए सर्वर इंस्टेंस की संख्या को स्केल करना असंभव है दोष सहनशीलता के उद्देश्य. साथ ही, आपको पोर्ट की डिफ़ॉल्ट श्रेणी बदलनी होगी...

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

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

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

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 नेटवर्क को लागू करना एक फ्लैट नेटवर्क पर एक साधारण कुबेरनेट्स इंस्टॉलेशन में राक्षसी दिखता है... हालाँकि, अन्यथा उपकरण काफी व्यवहार्य और उपयोगी दिखता है .

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

पुनश्च

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

• «सुरक्षा पेशेवरों के लिए कुबेरनेट्स नेटवर्क नीतियों का परिचय";
• "कुबेरनेट्स में नेटवर्किंग के लिए एक सचित्र मार्गदर्शिका": भाग 1 और 2 (नेटवर्क मॉडल, ओवरले नेटवर्क), भाग 3 (सेवाएँ और यातायात प्रसंस्करण);
• «कंटेनर नेटवर्किंग इंटरफ़ेस (सीएनआई) - नेटवर्क इंटरफ़ेस और लिनक्स कंटेनरों के लिए मानक'.

स्रोत: www.habr.com