🥇Πώς ένα pod στο Kubernetes αποκτά διεύθυνση IP

Σημείωση. μετάφρ.: Αυτό το άρθρο, που γράφτηκε από έναν μηχανικό SRE από το LinkedIn, περιγράφει λεπτομερώς την εσωτερική μαγεία στο Kubernetes - πιο συγκεκριμένα, την αλληλεπίδραση του CRI, του CNI και του kube-apiserver - που συμβαίνει όταν στο επόμενο pod χρειάζεται να εκχωρηθεί μια διεύθυνση IP.

Μία από τις βασικές απαιτήσεις Μοντέλο δικτύου Kubernetes είναι ότι κάθε pod πρέπει να έχει τη δική του διεύθυνση IP και κάθε άλλο pod στο σύμπλεγμα πρέπει να μπορεί να επικοινωνήσει μαζί του σε αυτήν τη διεύθυνση. Υπάρχουν πολλοί «πάροχοι» δικτύου (Flannel, Calico, Canal, κ.λπ.) που βοηθούν στην εφαρμογή αυτού του μοντέλου δικτύου.

Όταν άρχισα να δουλεύω για πρώτη φορά με το Kubernetes, δεν ήταν απολύτως σαφές για μένα πώς ακριβώς τα pods παίρνουν τις διευθύνσεις IP τους. Ακόμη και με την κατανόηση του τρόπου λειτουργίας των επιμέρους στοιχείων, ήταν δύσκολο να τα φανταστεί κανείς να συνεργάζονται. Για παράδειγμα, ήξερα σε τι χρησιμεύουν τα πρόσθετα CNI, αλλά δεν είχα ιδέα πώς ακριβώς ονομάζονταν. Ως εκ τούτου, αποφάσισα να γράψω αυτό το άρθρο για να μοιραστώ γνώσεις σχετικά με τα διάφορα στοιχεία δικτύου και τον τρόπο με τον οποίο συνεργάζονται σε ένα σύμπλεγμα Kubernetes, το οποίο επιτρέπει σε κάθε ομάδα να αποκτήσει τη δική του μοναδική διεύθυνση IP.

Υπάρχουν διάφοροι τρόποι οργάνωσης δικτύωσης στο Kubernetes, όπως ακριβώς υπάρχουν διαφορετικές επιλογές χρόνου εκτέλεσης για κοντέινερ. Αυτή η δημοσίευση θα χρησιμοποιήσει Φανέλα να οργανώσει ένα δίκτυο σε ένα σύμπλεγμα και ως εκτελέσιμο περιβάλλον - Δοχείο. Υποθέτω επίσης ότι γνωρίζετε πώς λειτουργεί η δικτύωση μεταξύ εμπορευματοκιβωτίων, επομένως θα το θίξω εν συντομία, μόνο για το πλαίσιο.

Μερικές βασικές έννοιες

Containers and the Network: A Brief Overview

Υπάρχουν πολλές εξαιρετικές δημοσιεύσεις στο διαδίκτυο που εξηγούν πώς τα κοντέινερ επικοινωνούν μεταξύ τους μέσω ενός δικτύου. Επομένως, θα δώσω μόνο μια γενική επισκόπηση των κύριων εννοιών και θα περιοριστώ σε μία προσέγγιση, η οποία περιλαμβάνει τη δημιουργία Linux-γεφύρωση και ενθυλάκωση πακέτων. Παραλείπονται λεπτομέρειες, καθώς το ίδιο το θέμα της δικτύωσης κοντέινερ αξίζει ξεχωριστό άρθρο. Παρακάτω παρέχονται σύνδεσμοι προς ορισμένες ιδιαίτερα ενημερωτικές και διορατικές δημοσιεύσεις.

Δοχεία σε έναν κεντρικό υπολογιστή

Ένας τρόπος οργάνωσης της επικοινωνίας μέσω διευθύνσεων IP μεταξύ κοντέινερ που εκτελούνται στον ίδιο κεντρικό υπολογιστή περιλαμβάνει τη δημιουργία Linux-bridge. Για αυτό, δημιουργούνται εικονικές συσκευές στο Kubernetes (και στο Docker) veth (εικονικό Ethernet). Το ένα άκρο της συσκευής veth συνδέεται με τον χώρο ονομάτων δικτύου του κοντέινερ, το άλλο με Linux-γέφυρα στο δίκτυο υποδοχής.

Όλα τα κοντέινερ σε έναν μόνο κεντρικό υπολογιστή έχουν το ένα άκρο του veth συνδεδεμένο με μια γέφυρα μέσω της οποίας μπορούν να επικοινωνούν μεταξύ τους μέσω διευθύνσεων IP. Linux-η γέφυρα έχει επίσης μια διεύθυνση IP και λειτουργεί ως πύλη για την εξερχόμενη (έξοδο) κίνηση από pods που προορίζονται για άλλους κόμβους.

Δοχεία σε διαφορετικούς κεντρικούς υπολογιστές

Η ενθυλάκωση πακέτων είναι μια μέθοδος που επιτρέπει στα κοντέινερ σε διαφορετικούς κόμβους να επικοινωνούν μεταξύ τους χρησιμοποιώντας διευθύνσεις IP. Στη Flannel, η τεχνολογία είναι υπεύθυνη για αυτήν την ευκαιρία. vxlan, το οποίο «πακετάρει» το αρχικό πακέτο σε ένα πακέτο UDP και στη συνέχεια το στέλνει στον προορισμό του.

Σε ένα σύμπλεγμα Kubernetes, το Flannel δημιουργεί μια συσκευή vxlan και ενημερώνει τον πίνακα δρομολογίων σε κάθε κόμβο ανάλογα. Κάθε πακέτο που προορίζεται για ένα κοντέινερ σε διαφορετικό κεντρικό υπολογιστή περνά μέσα από τη συσκευή vxlan και ενσωματώνεται σε ένα πακέτο UDP. Στον προορισμό, το ένθετο πακέτο εξάγεται και προωθείται στο επιθυμητό pod.

Σημείωση: Αυτός είναι μόνο ένας τρόπος οργάνωσης της επικοινωνίας δικτύου μεταξύ κοντέινερ.

Τι είναι το CRI;

CRI (Διεπαφή χρόνου εκτέλεσης κοντέινερ) είναι ένα πρόσθετο που επιτρέπει στο kubelet να χρησιμοποιεί διαφορετικά περιβάλλοντα χρόνου εκτέλεσης κοντέινερ. Το CRI API είναι ενσωματωμένο σε διάφορους χρόνους εκτέλεσης, ώστε οι χρήστες να μπορούν να επιλέξουν το χρόνο εκτέλεσης της επιλογής τους.

Τι είναι το CNI;

Έργο CNI είναι α προσδιορισμός να οργανώσει μια καθολική λύση δικτύου για Linux-δοχεία. Επιπλέον, περιλαμβάνει πρόσθετα, υπεύθυνος για διάφορες λειτουργίες κατά τη ρύθμιση ενός δικτύου pod. Το πρόσθετο CNI είναι ένα εκτελέσιμο αρχείο που συμμορφώνεται με τις προδιαγραφές (θα συζητήσουμε μερικά πρόσθετα παρακάτω).

Κατανομή υποδικτύων σε κόμβους για την εκχώρηση διευθύνσεων IP σε pods

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

Ελεγκτής IPAM κόμβου

Όταν nodeipam πέρασε ως παράμετρος σημαίας --controllers kube-ελεγκτής-διαχειριστής, εκχωρεί ένα ξεχωριστό υποδίκτυο (podCIDR) σε κάθε κόμβο από το σύμπλεγμα CIDR (δηλαδή, το εύρος των διευθύνσεων IP για το δίκτυο συμπλέγματος). Δεδομένου ότι αυτά τα podCIDR δεν επικαλύπτονται, καθίσταται δυνατό σε κάθε ομάδα να εκχωρηθεί μια μοναδική διεύθυνση IP.

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

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet, Container Runtime και πρόσθετα CNI: πώς λειτουργούν όλα

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

Ο προγραμματισμός ενός pod σε έναν συγκεκριμένο κόμβο ενεργοποιεί την ακόλουθη αλυσίδα γεγονότων:

Βοήθεια: Architecture of Containerd CRI plugins.

Αλληλεπίδραση μεταξύ χρόνου εκτέλεσης κοντέινερ και προσθηκών CNI

Κάθε πάροχος δικτύου έχει το δικό του πρόσθετο CNI. Ο χρόνος εκτέλεσης του κοντέινερ το εκτελεί για να διαμορφώσει το δίκτυο για το pod κατά την εκκίνηση. Στην περίπτωση του κοντέινερ, το πρόσθετο CNI εκκινείται από το πρόσθετο Container CRI.

Επιπλέον, κάθε πάροχος έχει τον δικό του αντιπρόσωπο. Είναι εγκατεστημένο σε όλους τους κόμβους Kubernetes και είναι υπεύθυνος για τη διαμόρφωση δικτύου των pods. Αυτός ο πράκτορας είτε περιλαμβάνεται στη διαμόρφωση CNI είτε τον δημιουργεί ανεξάρτητα στον κόμβο. Η διαμόρφωση βοηθά το πρόσθετο CRI να ορίσει ποιο πρόσθετο CNI θα καλέσει.

Η θέση της διαμόρφωσης CNI μπορεί να προσαρμοστεί. από προεπιλογή είναι μέσα /etc/cni/net.d/<config-file>. Οι διαχειριστές συμπλέγματος είναι επίσης υπεύθυνοι για την εγκατάσταση προσθηκών CNI σε κάθε κόμβο συμπλέγματος. Η τοποθεσία τους είναι επίσης προσαρμόσιμη. προεπιλεγμένος κατάλογος - /opt/cni/bin.

Όταν χρησιμοποιείτε κοντέινερ, οι διαδρομές για τη διαμόρφωση της προσθήκης και τα δυαδικά αρχεία μπορούν να οριστούν στην ενότητα [plugins.«io.containerd.grpc.v1.cri».cni] в αρχείο διαμόρφωσης κοντέινερ.

Επειδή χρησιμοποιούμε το Flannel ως πάροχο δικτύου, ας μιλήσουμε λίγο για τη ρύθμισή του:

Το Flanneld (ο δαίμονας του Flannel) εγκαθίσταται συνήθως σε ένα σύμπλεγμα ως DaemonSet με install-cni ως δοχείο έναρξης.
Install-cni δημιουργεί Αρχείο διαμόρφωσης CNI (/etc/cni/net.d/10-flannel.conflist) σε κάθε κόμβο.
Ο Flanneld δημιουργεί μια συσκευή vxlan, ανακτά μεταδεδομένα δικτύου από τον διακομιστή API και παρακολουθεί τις ενημερώσεις pod. Καθώς δημιουργούνται, διανέμει διαδρομές σε όλα τα pods σε όλο το σύμπλεγμα.
Αυτές οι διαδρομές επιτρέπουν στα pods να επικοινωνούν μεταξύ τους μέσω διευθύνσεων IP.

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

Ακολουθεί ένα διάγραμμα της αλληλεπίδρασης μεταξύ της προσθήκης Containerd CRI και των προσθηκών CNI:

Όπως μπορείτε να δείτε παραπάνω, το kubelet καλεί το πρόσθετο Containerd CRI για να δημιουργήσει το pod, το οποίο στη συνέχεια καλεί το πρόσθετο CNI για να διαμορφώσει το δίκτυο του pod. Με αυτόν τον τρόπο, η προσθήκη CNI του παρόχου δικτύου καλεί άλλες βασικές προσθήκες CNI για να διαμορφώσει διάφορες πτυχές του δικτύου.

Αλληλεπίδραση μεταξύ προσθηκών CNI

Υπάρχουν διάφορα πρόσθετα CNI των οποίων η δουλειά είναι να βοηθούν στη ρύθμιση της επικοινωνίας δικτύου μεταξύ κοντέινερ στον κεντρικό υπολογιστή. Αυτό το άρθρο θα συζητήσει τρεις από αυτές.

Πρόσθετο CNI Flannel

Όταν χρησιμοποιείτε το Flannel ως πάροχο δικτύου, καλείται το στοιχείο Containerd CRI Πρόσθετο CNI Flannelχρησιμοποιώντας το αρχείο διαμόρφωσης CNI /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

Το πρόσθετο Flannel CNI λειτουργεί σε συνδυασμό με το Flanneld. Κατά την εκκίνηση, ο Flanneld ανακτά το podCIDR και άλλες λεπτομέρειες που σχετίζονται με το δίκτυο από τον διακομιστή API και τις αποθηκεύει σε ένα αρχείο /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

Η προσθήκη Flannel CNI χρησιμοποιεί δεδομένα από /run/flannel/subnet.env για να ρυθμίσετε και να καλέσετε το πρόσθετο CNI bridge.

Πρόσθετο CNI Bridge

Αυτό το πρόσθετο καλείται με την ακόλουθη διαμόρφωση:

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

Στην πρώτη κλήση δημιουργεί Linux-γέφυρα με «name»: «cni0», το οποίο καθορίζεται στη διαμόρφωση. Στη συνέχεια, δημιουργείται ένα ζεύγος veth για κάθε pod. Το ένα άκρο συνδέεται με τον χώρο ονομάτων δικτύου του κοντέινερ, το άλλο περιλαμβάνεται στο Linux-γέφυρα στο δίκτυο υποδοχής. Πρόσθετο CNI Bridge συνδέει όλα τα κοντέινερ κεντρικού υπολογιστή με Linux-γέφυρα στο δίκτυο υποδοχής.

Αφού ολοκληρώσετε τη ρύθμιση του ζεύγους veth, η προσθήκη Bridge καλεί την προσθήκη κεντρικού-τοπικού IPAM CNI. Ο τύπος προσθήκης IPAM μπορεί να διαμορφωθεί στη διαμόρφωση CNI που χρησιμοποιεί η προσθήκη CRI για να καλέσει την προσθήκη Flannel CNI.

Προσθήκες κεντρικού-τοπικού IPAM CNI

Γέφυρα CNI κλήσεις υποδοχή-τοπική προσθήκη IPAM CNI με την ακόλουθη διαμόρφωση:

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

Προσθήκη κεντρικού-τοπικού IPAM (IP Aροσφώνηση Mδιαχείριση - διαχείριση διευθύνσεων IP) επιστρέφει τη διεύθυνση IP για το κοντέινερ από το υποδίκτυο και αποθηκεύει την εκχωρημένη IP στον κεντρικό υπολογιστή στον κατάλογο που καθορίζεται στην ενότητα dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Αυτό το αρχείο περιέχει το αναγνωριστικό του κοντέινερ στο οποίο έχει εκχωρηθεί αυτή η διεύθυνση IP.

Κατά την κλήση της προσθήκης κεντρικού-τοπικού IPAM, επιστρέφει τα ακόλουθα δεδομένα:

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

Περίληψη

Το Kube-controller-manager εκχωρεί ένα podCIDR σε κάθε κόμβο. Τα pods κάθε κόμβου λαμβάνουν διευθύνσεις IP από τον χώρο διευθύνσεων στην εκχωρημένη περιοχή podCIDR. Δεδομένου ότι τα podCIDR των κόμβων δεν επικαλύπτονται, όλα τα pods λαμβάνουν μοναδικές διευθύνσεις IP.

Ο διαχειριστής συμπλέγματος Kubernetes διαμορφώνει και εγκαθιστά το kubelet, τον χρόνο εκτέλεσης κοντέινερ, τον παράγοντα παροχής δικτύου και αντιγράφει τα πρόσθετα CNI σε κάθε κόμβο. Κατά την εκκίνηση, ο παράγοντας παροχής δικτύου δημιουργεί μια διαμόρφωση CNI. Όταν ένα pod έχει προγραμματιστεί σε έναν κόμβο, το kubelet καλεί το πρόσθετο CRI για να το δημιουργήσει. Στη συνέχεια, εάν χρησιμοποιείται containerd, η προσθήκη Containerd CRI καλεί την προσθήκη CNI που καθορίζεται στη διαμόρφωση CNI για να διαμορφώσει το δίκτυο του pod. Ως αποτέλεσμα, το pod λαμβάνει μια διεύθυνση IP.

Μου πήρε λίγο χρόνο για να καταλάβω όλες τις λεπτότητες και τις αποχρώσεις όλων αυτών των αλληλεπιδράσεων. Ελπίζω ότι αυτή η εμπειρία θα σας βοηθήσει να κατανοήσετε καλύτερα πώς λειτουργεί το Kubernetes. Αν κάνω λάθος σε οτιδήποτε, επικοινωνήστε μαζί μου στο Twitter ή στη διεύθυνση hello@ronaknathani.com. Μη διστάσετε να επικοινωνήσετε αν θέλετε να συζητήσετε πτυχές αυτού του άρθρου ή οτιδήποτε άλλο. Θα ήθελα πολύ να συνομιλήσω μαζί σας!