Calico για δικτύωση στο Kubernetes: εισαγωγή και λίγη εμπειρία

Σκοπός του άρθρου είναι να εισαγάγει τον αναγνώστη στα βασικά στοιχεία δικτύωσης και διαχείρισης πολιτικών δικτύου στο Kubernetes, καθώς και στην προσθήκη Calico τρίτων που επεκτείνει τις τυπικές δυνατότητες. Στην πορεία, η ευκολία διαμόρφωσης και ορισμένα χαρακτηριστικά θα αποδειχθούν χρησιμοποιώντας πραγματικά παραδείγματα από την εμπειρία λειτουργίας μας.

Μια γρήγορη εισαγωγή στη συσκευή δικτύωσης Kubernetes

Ένα σύμπλεγμα Kubernetes δεν μπορεί να φανταστεί χωρίς δίκτυο. Έχουμε ήδη δημοσιεύσει υλικό για τα βασικά τους:Ένας εικονογραφημένος οδηγός δικτύωσης στο Kubernetes"Και"Εισαγωγή στις πολιτικές δικτύου Kubernetes για επαγγελματίες ασφαλείας».

Στο πλαίσιο αυτού του άρθρου, είναι σημαντικό να σημειωθεί ότι το ίδιο το K8s δεν είναι υπεύθυνο για τη σύνδεση δικτύου μεταξύ κοντέινερ και κόμβων: για αυτό, διάφορα Πρόσθετα CNI (Διεπαφή Δικτύωσης Container). Περισσότερα για αυτήν την έννοια εμείς μου είπαν επίσης.

Για παράδειγμα, η πιο κοινή από αυτές τις προσθήκες είναι Φανέλα — παρέχει πλήρη συνδεσιμότητα δικτύου μεταξύ όλων των κόμβων συμπλέγματος ανυψώνοντας γέφυρες σε κάθε κόμβο, εκχωρώντας ένα υποδίκτυο σε αυτόν. Ωστόσο, η πλήρης και μη ρυθμιζόμενη προσβασιμότητα δεν είναι πάντα ωφέλιμη. Για να παρέχεται κάποιο είδος ελάχιστης απομόνωσης στο σύμπλεγμα, είναι απαραίτητο να παρέμβουμε στη διαμόρφωση του τείχους προστασίας. Στη γενική περίπτωση, τίθεται υπό τον έλεγχο του ίδιου CNI, γι' αυτό και τυχόν παρεμβάσεις τρίτων σε iptables μπορεί να ερμηνευθούν εσφαλμένα ή να αγνοηθούν εντελώς.

Και παρέχεται "out of the box" για την οργάνωση της διαχείρισης πολιτικής δικτύου σε ένα σύμπλεγμα 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 τύποι επισκεψιμότητας: η είσοδος στο pod (Είσοδος) και η έξοδος από αυτό (Έξοδος).

Στην πραγματικότητα, η πολιτική χωρίζεται σε αυτές τις 2 κατηγορίες με βάση την κατεύθυνση της κίνησης.

Το επόμενο απαιτούμενο χαρακτηριστικό είναι ένας επιλογέας. αυτός για τον οποίο ισχύει ο κανόνας. Αυτό μπορεί να είναι ένα pod (ή μια ομάδα λοβών) ή ένα περιβάλλον (δηλαδή ένας χώρος ονομάτων). Μια σημαντική λεπτομέρεια: και οι δύο τύποι αυτών των αντικειμένων πρέπει να περιέχουν μια ετικέτα (επιγραφή στην ορολογία Kubernetes) - αυτές είναι αυτές με τις οποίες λειτουργούν οι πολιτικοί.

Εκτός από έναν πεπερασμένο αριθμό επιλογέων που ενώνονται με κάποιο είδος ετικέτας, είναι δυνατό να γραφτούν κανόνες όπως "Να επιτρέπεται/άρνηση όλων/όλων" σε διαφορετικές παραλλαγές. Για το σκοπό αυτό χρησιμοποιούνται κατασκευές της φόρμας:

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

— σε αυτό το παράδειγμα, όλα τα pod στο περιβάλλον αποκλείονται από την εισερχόμενη κυκλοφορία. Η αντίθετη συμπεριφορά μπορεί να επιτευχθεί με την ακόλουθη κατασκευή:

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

Ομοίως για εξερχόμενες:

  podSelector: {}
  policyTypes:
  - Egress

- για να το απενεργοποιήσετε. Και εδώ είναι τι πρέπει να συμπεριλάβετε:

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

Επιστρέφοντας στην επιλογή ενός πρόσθετου CNI για ένα σύμπλεγμα, αξίζει να σημειωθεί ότι δεν υποστηρίζει κάθε πρόσθετο δικτύου το NetworkPolicy. Για παράδειγμα, το ήδη αναφερθέν Flannel δεν γνωρίζει πώς να διαμορφώσει τις πολιτικές δικτύου, οι οποίες λέγεται ευθέως στο επίσημο αποθετήριο. Εκεί αναφέρεται και μια εναλλακτική - ένα έργο ανοιχτού κώδικα τσίτι, το οποίο επεκτείνει σημαντικά το τυπικό σύνολο των Kubernetes API όσον αφορά τις πολιτικές δικτύου.

Γνωριμία με το Calico: θεωρία

Το πρόσθετο Calico μπορεί να χρησιμοποιηθεί σε ενοποίηση με το Flannel (υποέργο Κανάλι) ή ανεξάρτητα, καλύπτοντας τόσο τη συνδεσιμότητα δικτύου όσο και τις δυνατότητες διαχείρισης διαθεσιμότητας.

Τι ευκαιρίες προσφέρει η χρήση της λύσης "boxed" του K8 και του σετ API από την Calico;

Δείτε τι είναι ενσωματωμένο στο NetworkPolicy:

• Οι πολιτικοί περιορίζονται από το περιβάλλον.
• Οι πολιτικές εφαρμόζονται σε ομάδες που επισημαίνονται με ετικέτες.
• Οι κανόνες μπορούν να εφαρμοστούν σε pods, περιβάλλοντα ή υποδίκτυα.
• Οι κανόνες μπορεί να περιέχουν πρωτόκολλα, ονομασμένες ή συμβολικές προδιαγραφές θύρας.

Δείτε πώς το Calico επεκτείνει αυτές τις λειτουργίες:

• Οι πολιτικές μπορούν να εφαρμοστούν σε οποιοδήποτε αντικείμενο: pod, κοντέινερ, εικονική μηχανή ή διεπαφή.
• οι κανόνες μπορούν να περιέχουν μια συγκεκριμένη ενέργεια (απαγόρευση, άδεια, καταγραφή).
• ο στόχος ή η πηγή κανόνων μπορεί να είναι μια θύρα, μια σειρά από θύρες, πρωτόκολλα, χαρακτηριστικά HTTP ή ICMP, IP ή υποδίκτυο (4ης ή 6ης γενιάς), οποιοιδήποτε επιλογείς (κόμβοι, κεντρικοί υπολογιστές, περιβάλλοντα).
• Επιπλέον, μπορείτε να ρυθμίσετε τη διέλευση της κυκλοφορίας χρησιμοποιώντας τις ρυθμίσεις DNAT και τις πολιτικές προώθησης κίνησης.

Οι πρώτες δεσμεύσεις στο GitHub στο αποθετήριο Calico χρονολογούνται από τον Ιούλιο του 2016 και ένα χρόνο αργότερα το έργο κατέλαβε ηγετική θέση στην οργάνωση της συνδεσιμότητας δικτύου Kubernetes - αυτό αποδεικνύεται, για παράδειγμα, από τα αποτελέσματα της έρευνας, διευθύνεται από το The New Stack:

Πολλές μεγάλες διαχειριζόμενες λύσεις με K8, όπως π.χ Amazon EX, Azure AKS, Google GKE και άλλοι άρχισαν να το προτείνουν για χρήση.

Όσο για τις επιδόσεις, όλα είναι υπέροχα εδώ. Κατά τη δοκιμή του προϊόντος της, η ομάδα ανάπτυξης της Calico επέδειξε αστρονομικές επιδόσεις, τρέχοντας περισσότερα από 50000 κοντέινερ σε 500 φυσικούς κόμβους με ρυθμό δημιουργίας 20 κοντέινερ ανά δευτερόλεπτο. Δεν εντοπίστηκαν προβλήματα με την κλιμάκωση. Τέτοια αποτελέσματα ανακοινώθηκαν ήδη στην ανακοίνωση της πρώτης έκδοσης. Ανεξάρτητες μελέτες που επικεντρώνονται στη διεκπεραίωση και την κατανάλωση πόρων επιβεβαιώνουν επίσης ότι η απόδοση της Calico είναι σχεδόν εξίσου καλή με της Flannel. Για παράδειγμα:

Το έργο αναπτύσσεται πολύ γρήγορα, υποστηρίζει εργασία σε δημοφιλείς λύσεις διαχείρισης K8, OpenShift, OpenStack, είναι δυνατή η χρήση του Calico κατά την ανάπτυξη ενός συμπλέγματος χρησιμοποιώντας λάκτισμα, υπάρχουν αναφορές στην κατασκευή δικτύων Service Mesh (εδώ είναι ένα παράδειγμα χρησιμοποιείται σε συνδυασμό με το Ίστιο).

Εξάσκηση με το Calico

Στη γενική περίπτωση χρήσης vanilla Kubernetes, η εγκατάσταση του CNI καταλήγει στη χρήση του αρχείου calico.yaml, κατεβάσει από την επίσημη ιστοσελίδα, με τη χρήση kubectl apply -f.

Κατά κανόνα, η τρέχουσα έκδοση της προσθήκης είναι συμβατή με τις τελευταίες 2-3 εκδόσεις του Kubernetes: η λειτουργία σε παλαιότερες εκδόσεις δεν ελέγχεται και δεν είναι εγγυημένη. Σύμφωνα με τους προγραμματιστές, το Calico τρέχει σε πυρήνες Linux πάνω από 3.10 με CentOS 7, Ubuntu 16 ή Debian 8, πάνω από iptables ή IPVS.

Απομόνωση μέσα στο περιβάλλον

Για μια γενική κατανόηση, ας δούμε μια απλή περίπτωση για να κατανοήσουμε πώς οι πολιτικές δικτύου στη σημειογραφία Calico διαφέρουν από τις τυπικές και πώς η προσέγγιση για τη δημιουργία κανόνων απλοποιεί την αναγνωσιμότητα και την ευελιξία διαμόρφωσής τους:

Υπάρχουν 2 εφαρμογές Ιστού που αναπτύσσονται στο σύμπλεγμα: στο Node.js και στην PHP, μία από τις οποίες χρησιμοποιεί Redis. Για να αποκλείσετε την πρόσβαση στο Redis από την PHP, ενώ διατηρείτε τη συνδεσιμότητα με το 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

Ουσιαστικά επιτρέψαμε την εισερχόμενη κίνηση στη θύρα Redis από το Node.js. Και σαφώς δεν απαγόρευσαν τίποτα άλλο. Μόλις εμφανιστεί το NetworkPolicy, όλοι οι επιλογείς που αναφέρονται σε αυτό αρχίζουν να απομονώνονται, εκτός εάν ορίζεται διαφορετικά. Ωστόσο, οι κανόνες απομόνωσης δεν ισχύουν για άλλα αντικείμενα που δεν καλύπτονται από τον επιλογέα.

Το παράδειγμα χρησιμοποιεί apiVersion Kubernetes out of the box, αλλά τίποτα δεν σας εμποδίζει να το χρησιμοποιήσετε ο ομώνυμος πόρος από την παράδοση Calico. Η σύνταξη εκεί είναι πιο λεπτομερής, επομένως θα χρειαστεί να ξαναγράψετε τον κανόνα για την παραπάνω περίπτωση με την ακόλουθη μορφή:

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 περιέχουν δομές με παρενθέσεις που είναι δύσκολο να κατανοηθούν και να απομνημονευθούν. Στην περίπτωση του Calico, για να αλλάξετε τη λογική ενός κανόνα του τείχους προστασίας στο αντίθετο, απλώς αλλάξτε action: Allow επί action: Deny.

Απομόνωση από το περιβάλλον

Τώρα φανταστείτε μια κατάσταση όπου μια εφαρμογή δημιουργεί επιχειρηματικές μετρήσεις για συλλογή στον Prometheus και περαιτέρω ανάλυση χρησιμοποιώντας το Grafana. Η μεταφόρτωση μπορεί να περιέχει ευαίσθητα δεδομένα, τα οποία είναι και πάλι δημόσια ορατά από προεπιλογή. Ας κρύψουμε αυτά τα δεδομένα από τα αδιάκριτα βλέμματα:

Ο Prometheus, κατά κανόνα, τοποθετείται σε ξεχωριστό περιβάλλον υπηρεσίας - στο παράδειγμα θα είναι ένας χώρος ονομάτων όπως αυτός:

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

Πεδίο metadata.labels αυτό αποδείχθηκε ότι δεν ήταν τυχαίο. Οπως αναφέρθηκε προηγουμένως, namespaceSelector (καθώς podSelector) λειτουργεί με ετικέτες. Επομένως, για να επιτρέψετε τη λήψη μετρήσεων από όλα τα pods σε μια συγκεκριμένη θύρα, θα πρέπει να προσθέσετε κάποιο είδος ετικέτας (ή να λάβετε από υπάρχουσες) και στη συνέχεια να εφαρμόσετε μια διαμόρφωση όπως:

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

Και αν χρησιμοποιείτε πολιτικές Calico, η σύνταξη θα είναι η εξής:

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

Γενικά, προσθέτοντας αυτού του είδους τις πολιτικές για συγκεκριμένες ανάγκες, μπορείτε να προστατεύσετε από κακόβουλες ή τυχαίες παρεμβολές στη λειτουργία των εφαρμογών στο σύμπλεγμα.

Η καλύτερη πρακτική, σύμφωνα με τους δημιουργούς του Calico, είναι η προσέγγιση «Αποκλείστε τα πάντα και ανοίξτε ρητά αυτό που χρειάζεστε», που τεκμηριώνεται στο επίσημη τεκμηρίωση (άλλοι ακολουθούν παρόμοια προσέγγιση - συγκεκριμένα, στο ήδη αναφερόμενο άρθρο).

Χρήση πρόσθετων αντικειμένων Calico

Επιτρέψτε μου να σας υπενθυμίσω ότι μέσω του εκτεταμένου συνόλου Calico API μπορείτε να ρυθμίσετε τη διαθεσιμότητα των κόμβων, χωρίς να περιορίζεται σε pods. Στο παρακάτω παράδειγμα χρησιμοποιώντας GlobalNetworkPolicy η δυνατότητα μεταβίβασης αιτημάτων ICMP στο σύμπλεγμα είναι κλειστή (για παράδειγμα, ping από μια ομάδα σε έναν κόμβο, μεταξύ ομάδων ή από έναν κόμβο σε μια ομάδα 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

Τέλος, θα δώσω ένα πολύ πραγματικό παράδειγμα χρήσης των συναρτήσεων Calico για την περίπτωση αλληλεπίδρασης κοντά στο σύμπλεγμα, όταν ένα τυπικό σύνολο πολιτικών δεν είναι αρκετό. Για πρόσβαση στην εφαρμογή Ιστού, οι πελάτες χρησιμοποιούν μια σήραγγα VPN και αυτή η πρόσβαση ελέγχεται αυστηρά και περιορίζεται σε μια συγκεκριμένη λίστα υπηρεσιών που επιτρέπονται για χρήση:

Οι πελάτες συνδέονται στο VPN μέσω της τυπικής θύρας UDP 1194 και, όταν συνδέονται, λαμβάνουν διαδρομές προς τα υποδίκτυα συμπλέγματος των ομάδων και υπηρεσιών. Ολόκληρα υποδίκτυα ωθούνται για να μην χαθούν οι υπηρεσίες κατά την επανεκκίνηση και τις αλλαγές διευθύνσεων.

Η θύρα στη διαμόρφωση είναι τυπική, γεγονός που επιβάλλει ορισμένες αποχρώσεις στη διαδικασία διαμόρφωσης της εφαρμογής και μεταφοράς της στο σύμπλεγμα Kubernetes. Για παράδειγμα, στο ίδιο AWS LoadBalancer για UDP εμφανίστηκε κυριολεκτικά στο τέλος του περασμένου έτους σε μια περιορισμένη λίστα περιοχών και το NodePort δεν μπορεί να χρησιμοποιηθεί λόγω της προώθησης του σε όλους τους κόμβους συμπλέγματος και είναι αδύνατο να κλιμακωθεί ο αριθμός των παρουσιών διακομιστή για σκοπούς ανοχής σφαλμάτων. Επιπλέον, θα πρέπει να αλλάξετε το προεπιλεγμένο εύρος των θυρών...

Ως αποτέλεσμα της αναζήτησης πιθανών λύσεων, επιλέχθηκαν τα ακόλουθα:

1. Τα pods με VPN έχουν προγραμματιστεί ανά κόμβο σε hostNetwork, δηλαδή στην πραγματική IP.
2. Η υπηρεσία αναρτάται έξω μέσω ClusterIP. Στον κόμβο είναι εγκατεστημένη μια θύρα, η οποία είναι προσβάσιμη από το εξωτερικό με μικρές κρατήσεις (υπό όρους παρουσία πραγματικής διεύθυνσης IP).
3. Ο προσδιορισμός του κόμβου στον οποίο αυξήθηκε ο λοβός είναι πέρα ​​από το πεδίο της ιστορίας μας. Θα πω απλώς ότι μπορείτε να "καρφώσετε" σφιχτά την υπηρεσία σε έναν κόμβο ή να γράψετε μια μικρή υπηρεσία sidecar που θα παρακολουθεί την τρέχουσα διεύθυνση IP της υπηρεσίας 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 της Calico, μπορείτε να διαμορφώσετε και να αλλάξετε δυναμικά τη δρομολόγηση μέσα και γύρω από το σύμπλεγμα. Γενικά, η χρήση του μπορεί να μοιάζει με πυροβολισμό σπουργίτων με κανόνι, και η υλοποίηση ενός δικτύου L3 με σήραγγες BGP και IP-IP φαίνεται τερατώδη σε μια απλή εγκατάσταση Kubernetes σε επίπεδο δίκτυο... Ωστόσο, διαφορετικά το εργαλείο φαίνεται αρκετά βιώσιμο και χρήσιμο .

Η απομόνωση ενός συμπλέγματος για την ικανοποίηση των απαιτήσεων ασφαλείας μπορεί να μην είναι πάντα εφικτή και εδώ είναι που το Calico (ή μια παρόμοια λύση) έρχεται να σώσει. Τα παραδείγματα που δίνονται σε αυτό το άρθρο (με μικρές τροποποιήσεις) χρησιμοποιούνται σε πολλές εγκαταστάσεις των πελατών μας στο AWS.

PS

Διαβάστε επίσης στο blog μας:

• «Εισαγωγή στις πολιτικές δικτύου Kubernetes για επαγγελματίες ασφαλείας"?
• "Ένας εικονογραφημένος οδηγός για τη δικτύωση στο Kubernetes": μέρη 1 και 2 (μοντέλο δικτύου, δίκτυα επικάλυψης), μέρος 3 (υπηρεσίες και διεκπεραίωση κυκλοφορίας);
• «Container Networking Interface (CNI) - διεπαφή δικτύου και πρότυπο για κοντέινερ Linux».

Πηγή: www.habr.com