🥇 क्यालिको Kubernetes मा नेटवर्किंग को लागी: परिचय र सानो अनुभव

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

Kubernetes नेटवर्किङ उपकरणको लागि द्रुत परिचय

एक Kubernetes क्लस्टर नेटवर्क बिना कल्पना गर्न सकिँदैन। हामीले पहिले नै तिनीहरूको आधारभूत सामग्रीहरू प्रकाशित गरिसकेका छौं: "Kubernetes मा नेटवर्किंग को लागी एक सचित्र गाइड"र"सुरक्षा पेशेवरहरूको लागि Kubernetes नेटवर्क नीतिहरूको परिचय"।

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

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

र Kubernetes क्लस्टर मा नेटवर्क नीति व्यवस्थापन संगठित गर्न को लागी "बक्स बाहिर" प्रदान गरिएको छ NetworkPolicy API। यो स्रोत, चयन गरिएको नेमस्पेसहरूमा वितरित, एक अनुप्रयोगबाट अर्कोमा पहुँच भिन्न गर्न नियमहरू समावेश हुन सक्छ। यसले तपाईंलाई विशिष्ट पोडहरू, वातावरणहरू (नेमस्पेसहरू) वा 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 प्रकारका ट्राफिकहरू छन्: पोडमा प्रवेश (इन्ग्रेस) र त्यसबाट बाहिर जाने (Egress)।

वास्तवमा आन्दोलनको दिशाका आधारमा राजनीतिलाई यी २ वर्गमा विभाजन गरिएको छ ।

अर्को आवश्यक विशेषता चयनकर्ता हो; जसलाई नियम लागू हुन्छ। यो पोड (वा पोडहरूको समूह) वा वातावरण (जस्तै नामस्थान) हुन सक्छ। एउटा महत्त्वपूर्ण विवरण: यी दुवै प्रकारका वस्तुहरूमा लेबल समावेश हुनुपर्छ (लेबल Kubernetes शब्दावलीमा) - यी हुन् जुन राजनीतिज्ञहरूले काम गर्छन्।

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

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

- यस उदाहरणमा, वातावरणमा सबै पोडहरू आगमन ट्राफिकबाट अवरुद्ध छन्। विपरीत व्यवहार निम्न निर्माण संग प्राप्त गर्न सकिन्छ:

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

त्यस्तै बहिर्गमनका लागि:

  podSelector: {}
  policyTypes:
  - Egress

- यसलाई बन्द गर्न। र यहाँ के समावेश छ:

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

क्लस्टरको लागि CNI प्लगइनको छनोटमा फर्केर, यो ध्यान दिन लायक छ हरेक नेटवर्क प्लगइनले NetworkPolicy लाई समर्थन गर्दैन। उदाहरण को लागी, पहिले नै उल्लेख गरिएको Flannel लाई थाहा छैन कसरी नेटवर्क नीतिहरू कन्फिगर गर्ने, जुन यो प्रत्यक्ष भनिएको छ आधिकारिक भण्डारमा। त्यहाँ एक विकल्प पनि उल्लेख गरिएको छ - एक खुला स्रोत परियोजना Calico, जसले नेटवर्क नीतिहरूको सन्दर्भमा Kubernetes API को मानक सेटलाई महत्त्वपूर्ण रूपमा विस्तार गर्दछ।

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

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

K8s "बक्स गरिएको" समाधान र क्यालिकोबाट एपीआई सेट प्रयोग गर्दा के अवसरहरू प्रदान गर्दछ?

NetworkPolicy मा बनाइएको कुरा यहाँ छ:

राजनीतिज्ञहरू वातावरण द्वारा सीमित छन्;
नीतिहरू लेबलहरू चिन्ह लगाइएका पोडहरूमा लागू हुन्छन्;
नियमहरू पोड, वातावरण वा सबनेटहरूमा लागू गर्न सकिन्छ;
नियमहरूले प्रोटोकलहरू, नामित वा प्रतीकात्मक पोर्ट विनिर्देशहरू समावेश गर्न सक्छन्।

यहाँ केलिकोले यी कार्यहरू कसरी विस्तार गर्दछ:

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

क्यालिको रिपोजिटरीमा GitHub मा पहिलो प्रतिबद्धता जुलाई 2016 मा फिर्ता भयो, र एक वर्ष पछि परियोजनाले Kubernetes नेटवर्क कनेक्टिविटी व्यवस्थित गर्न अग्रणी स्थान लियो - यो प्रमाण हो, उदाहरण को लागी, सर्वेक्षण परिणामहरु द्वारा, The New Stack द्वारा आयोजित:

K8 को साथ धेरै ठूला व्यवस्थित समाधानहरू, जस्तै अमेजन EKS, Azure AKS, गुगल GKE र अरूले यसलाई प्रयोगको लागि सिफारिस गर्न थाले।

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

परियोजना धेरै चाँडै विकास हुँदैछ, यसले लोकप्रिय समाधानहरू व्यवस्थित K8s, OpenShift, OpenStack मा कामलाई समर्थन गर्दछ, क्लस्टर प्रयोग गर्दा क्यालिको प्रयोग गर्न सम्भव छ। कोप्स, त्यहाँ सेवा जाल नेटवर्क को निर्माण को सन्दर्भहरु छन् (यहाँ एउटा उदाहरण हो Istio संग संयोजन मा प्रयोग गरिन्छ)।

क्यालिकोसँग अभ्यास गर्नुहोस्

vanilla Kubernetes प्रयोग गर्ने सामान्य अवस्थामा, CNI स्थापना गर्दा फाइल प्रयोग गर्न तल आउँछ calico.yaml, आधिकारिक वेबसाइटबाट डाउनलोड, प्रयोग गरेर kubectl apply -f.

नियमको रूपमा, प्लगइनको हालको संस्करण Kubernetes को नवीनतम 2-3 संस्करणहरूसँग उपयुक्त छ: पुरानो संस्करणहरूमा सञ्चालन परीक्षण गरिएको छैन र ग्यारेन्टी छैन। विकासकर्ताहरूका अनुसार, क्यालिकोले iptables वा IPVS को शीर्षमा CentOS 3.10, Ubuntu 7 वा Debian 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 Kubernetes बाकस बाहिर, तर कुनै पनि कुराले यसलाई प्रयोग गर्नबाट रोक्दैन क्यालिको डेलिभरीबाट उही नामको स्रोत। त्यहाँ वाक्यविन्यास अधिक विस्तृत छ, त्यसैले तपाईंले निम्न फारममा माथिको केसको लागि नियम पुन: लेख्न आवश्यक हुनेछ:

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

नियमित NetworkPolicy API मार्फत सबै ट्राफिकहरूलाई अनुमति दिने वा अस्वीकार गर्ने माथि उल्लिखित संरचनाहरूले बुझ्न र सम्झन गाह्रो हुने कोष्ठकहरू भएका निर्माणहरू समावेश गर्दछ। क्यालिकोको अवस्थामा, फायरवाल नियमको तर्कलाई विपरितमा परिवर्तन गर्न, केवल परिवर्तन गर्नुहोस् action: Allow मा action: Deny.

वातावरण द्वारा अलगाव

अब एउटा परिस्थितिको कल्पना गर्नुहोस् जहाँ एप्लिकेसनले प्रोमेथियसमा सङ्कलनका लागि व्यापार मेट्रिक्स र Grafana प्रयोग गरेर थप विश्लेषणहरू उत्पन्न गर्दछ। अपलोडमा संवेदनशील डेटा हुन सक्छ, जुन पूर्वनिर्धारित रूपमा सार्वजनिक रूपमा हेर्न मिल्छ। यो तथ्याङ्क लुकाउने आँखाबाट लुकाउनुहोस्:

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

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"]

VPN केस

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

ग्राहकहरू मानक UDP पोर्ट 1194 मार्फत VPN मा जडान हुन्छन् र जडान हुँदा, पोडहरू र सेवाहरूको क्लस्टर सबनेटहरूमा मार्गहरू प्राप्त गर्छन्। रिस्टार्ट र ठेगाना परिवर्तन गर्दा सेवाहरू गुमाउन नदिन सम्पूर्ण सबनेटहरू धकेलिन्छन्।

कन्फिगरेसनमा रहेको पोर्ट मानक हो, जसले अनुप्रयोगलाई कन्फिगर गर्ने र यसलाई Kubernetes क्लस्टरमा स्थानान्तरण गर्ने प्रक्रियामा केही सूक्ष्मताहरू लागू गर्दछ। उदाहरणका लागि, उही AWS लोडब्यालेन्सरमा UDP का लागि गत वर्षको अन्त्यमा क्षेत्रहरूको सीमित सूचीमा शाब्दिक रूपमा देखा पर्‍यो, र NodePort सबै क्लस्टर नोडहरूमा फर्वार्डिङको कारणले प्रयोग गर्न सकिँदैन र सर्भर उदाहरणहरूको संख्या मापन गर्न असम्भव छ। दोष सहिष्णुता उद्देश्य। साथै, तपाईंले पोर्टहरूको पूर्वनिर्धारित दायरा परिवर्तन गर्नुपर्नेछ ...

सम्भावित समाधानहरू खोज्ने परिणामको रूपमा, निम्न छनौट गरिएको थियो:

VPN का साथ पोडहरू प्रति नोडमा निर्धारित छन् hostNetwork, त्यो हो, वास्तविक IP मा।
सेवा बाहिर मार्फत पोस्ट गरिएको छ ClusterIP। एउटा पोर्ट भौतिक रूपमा नोडमा स्थापित छ, जुन बाहिरबाट साना आरक्षणहरू (वास्तविक आईपी ठेगानाको सशर्त उपस्थिति) संग पहुँचयोग्य छ।
पोड गुलाबको नोड निर्धारण गर्ने हाम्रो कथाको दायरा बाहिर छ। म मात्र भन्छु कि तपाइँ नोडमा सेवालाई कडाई "नेल" गर्न सक्नुहुन्छ वा सानो साइडकार सेवा लेख्न सक्नुहुन्छ जसले VPN सेवाको हालको आईपी ठेगाना निगरानी गर्नेछ र ग्राहकहरूसँग दर्ता भएका DNS रेकर्डहरू सम्पादन गर्नेछ - जोसँग पर्याप्त कल्पना छ।

रूटिङ परिप्रेक्ष्यबाट, हामी VPN सर्भरद्वारा जारी गरिएको IP ठेगानाद्वारा VPN क्लाइन्टलाई विशिष्ट रूपमा पहिचान गर्न सक्छौं। सेवाहरूमा त्यस्ता ग्राहकको पहुँचलाई प्रतिबन्धित गर्ने आदिम उदाहरण तल दिइएको छ, माथि उल्लिखित Redis मा चित्रण गरिएको छ:

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 मा जडान गर्न कडा रूपमा निषेध गरिएको छ, तर एकै समयमा DNS सेवाको सञ्चालन सुरक्षित गरिएको छ, जसको कार्य नियमहरू बनाउँदा प्रायः पीडा हुन्छ। किनभने, पहिले उल्लेख गरिए अनुसार, जब चयनकर्ता देखा पर्दछ, पूर्वनिर्धारित अस्वीकार नीति लागू हुन्छ अन्यथा निर्दिष्ट नगरेसम्म।

परिणामहरू

यसरी, क्यालिकोको उन्नत API प्रयोग गरेर, तपाइँ लचिलो रूपमा कन्फिगर गर्न सक्नुहुन्छ र गतिशील रूपमा क्लस्टर भित्र र वरपर मार्ग परिवर्तन गर्न सक्नुहुन्छ। सामान्यतया, यसको प्रयोगले तोपले भँगेरालाई गोली हानेको जस्तो देखिन सक्छ, र BGP र IP-IP टनेलहरूको साथ L3 नेटवर्क कार्यान्वयन गर्दा फ्ल्याट नेटवर्कमा साधारण Kubernetes स्थापनामा राक्षसी देखिन्छ... यद्यपि, अन्यथा उपकरण एकदम व्यवहार्य र उपयोगी देखिन्छ। ।

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

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

«सुरक्षा पेशेवरहरूको लागि Kubernetes नेटवर्क नीतिहरूको परिचय»;
"कुबर्नेट्समा नेटवर्किङको लागि एउटा इलस्ट्रेटेड गाइड": भाग १ र २ (नेटवर्क मोडेल, ओभरले नेटवर्क), भाग ३ (सेवा र यातायात प्रशोधन);
«कन्टेनर नेटवर्किङ इन्टरफेस (CNI) - नेटवर्क इन्टरफेस र लिनक्स कन्टेनरहरूको लागि मानक"।

स्रोत: www.habr.com

Kubernetes मा नेटवर्किंग को लागी क्यालिको: परिचय र एक सानो अनुभव