VPN Pod στο Kubernetes ή πύλη εξόδου: ποιος κατέχει το τούνελ;
Ένα Pod είναι ο δικός του χώρος ονομάτων δικτύου, άρα η πραγματική επιλογή είναι ποιο επίπεδο κατέχει το τούνελ: ταυτότητα ανά φόρτο εργασίας ή έξοδος καθοδηγούμενη από το CNI με μία κοινή πηγή.
Αναπτύσσετε ένα Pod με όνομα vpn-gateway, στρέφετε έναν δοκιμαστικό πελάτη στη διεύθυνσή του και βλέπετε τα πακέτα να εξαφανίζονται. Τίποτα στο manifest δεν είναι λάθος και το kubelet δεν έχει παράπονο. Ο λόγος είναι δομικός και όχι ρυθμιστικός: το Kubernetes δίνει σε κάθε Pod τον δικό του χώρο ονομάτων δικτύου, άρα ένα όνομα, μια ετικέτα ή ένας κοινός χώρος ονομάτων API δεν αλλάζουν τίποτα ως προς το πού πηγαίνουν τα πακέτα. Η απόφαση για το πώς η κίνηση VPN φεύγει από το cluster ξεκινά επομένως με ερώτημα ιδιοκτησίας, όχι με ερώτημα για images containers.
Δύο μηχανισμοί καλύπτουν τις περισσότερες πραγματικές αναπτύξεις και δεν είναι εναλλάξιμοι. Ο ένας βάζει το τούνελ μέσα στον χώρο ονομάτων δικτύου του ίδιου του φόρτου εργασίας. Ο άλλος ζητά από το CNI να κατευθύνει επιλεγμένη κίνηση μέσω ενός καθορισμένου κόμβου πύλης. Αποτυγχάνουν διαφορετικά, κλιμακώνονται διαφορετικά και απαντούν σε διαφορετικές ομάδες, γι’ αυτό το ερώτημα των containers παράγει συνήθως διαφωνίες που δεν τελειώνουν ποτέ.
Το όριο ενός Pod είναι χώρος ονομάτων, όχι host αναπήδησης
Ένας χώρος ονομάτων δικτύου Linux κατέχει τις διεπαφές, τις διευθύνσεις, τις διαδρομές και τους κανόνες firewall του και κάθε Pod λαμβάνει έναν. Τα containers μέσα σε αυτό το Pod προσχωρούν σε αυτόν, και γι’ αυτό ακριβώς ένα βοηθητικό container μπορεί να ξαναγράψει διαδρομές που ακολουθεί μετά η εφαρμογή. Ένα γειτονικό Pod έχει μια φαινομενικά ίδια αλλά εντελώς ξεχωριστή στοίβα. Δεν υπάρχει κοινός πίνακας για να κληρονομήσει ένα Pod πύλης, ούτε σιωπηρή παράδοση κίνησης από έναν χώρο ονομάτων σε άλλον.
Γι’ αυτό και το μοτίβο Pod πύλης λειτουργεί μόνο όταν κάτι ανάντη στέλνει πραγματικά πακέτα σε αυτό: ένα Service, μια στατική διαδρομή στον κόμβο ή πολιτική καθοδήγησης στο CNI. Μια διεύθυνση μόνη της δεν προσελκύει τίποτα.
Τι αγοράζει ένα τούνελ ανά Pod και τι κοστίζει
Ένα τούνελ που τρέχει στον χώρο ονομάτων του φόρτου εργασίας δίνει σε αυτόν τον φόρτο τη δική του ταυτότητα πελάτη, την οποία πολλές υπηρεσίες απομακρυσμένης πρόσβασης απαιτούν πριν εξουσιοδοτήσουν ή καταγράψουν μια συνεδρία. Και η ακτίνα βλάβης μένει τοπική: ένα χαλασμένο τούνελ βγάζει ένα Deployment αντί για την κοινή διαδρομή που χρησιμοποιούν όλα. Το πώς τρέχει εξαρτάται από την υλοποίηση, και εδώ οι άνθρωποι μαντεύουν λάθος.
Μια εγκατάσταση που χρειάζεται μόνο κατάσταση πυρήνα μπορεί να τελειώσει σε ένα init container και να βγει. Ένας δαίμονας χώρου χρήστη που πρέπει να μείνει ζωντανός για όλη τη ζωή του Pod χρειάζεται τη μορφή επανεκκινούμενου init container που εισήχθη ως εγγενές sidecar στο Kubernetes 1.29, και αυτή η διάκριση προέρχεται από την υλοποίηση του τούνελ και όχι από γούστο. Το κόστος αυτού του μοντέλου είναι η διπλοεγγραφή: κάθε ρέπλικα πιστοποιείται, παίρνει τη δική της διεύθυνση τούνελ και καταναλώνει μια θέση απομακρυσμένης συνεδρίας, άρα ένα γεγονός αυτοκλιμάκωσης γίνεται γεγονός χωρητικότητας στην άλλη πλευρά του συνδέσμου. Η αντιγραφή ενός διαπιστευτηρίου σε όλες τις ρέπλικες δεν αφαιρεί αυτό το κόστος, αφαιρεί το ίχνος ελέγχου. Οι δυνατότητες αξίζουν την ίδια εξέταση, γιατί ένα τούνελ που θέλει NET_ADMIN στον δικό του χώρο ονομάτων δεν έχει λόγο να κληρονομήσει την εξουσία σε όλο τον host από ένα παράδειγμα με privileged: true.
Όταν το CNI κατέχει την έξοδο
Αν το CNI το υποστηρίζει, μια πύλη εξόδου επιλέγει κίνηση κατά φόρτο εργασίας και εύρος προορισμού και μετά τη στέλνει μέσω επιλεγμένων κόμβων κάτω από μία προβλέψιμη διεύθυνση πηγής. Η έκδοση του Cilium είναι η συνήθης αναφορά, και η τεκμηρίωσή του δηλώνει ρητά ότι η λειτουργία απαιτεί συγκεκριμένη ρύθμιση Cilium συν κόμβους πύλης εφοδιασμένους με τις σωστές διεπαφές και διευθύνσεις. Σημειώνει επίσης μια αρχική περίοδο μετά τη δημιουργία του Pod κατά την οποία η καθοδήγηση δεν εφαρμόζεται ακόμη, κάτι που είναι δεδομένο σχεδιασμού και όχι υποσημείωση.
Διαβάστε αυτή την καθυστέρηση απέναντι στη δική σας υπόσχεση. Αν ο κανόνας είναι ότι καμία κίνηση δεν επιτρέπεται να φύγει από άλλη διαδρομή, ένα νέο Pod που μεταδίδει κατά τη διάρκεια του κενού τον έχει ήδη παραβιάσει, άρα η ακολουθία εκκίνησης χρειάζεται τη δική της απάντηση: κρατήστε την εφαρμογή έως ότου εφαρμοστεί η πολιτική, ή δεχτείτε το παράθυρο και τεκμηριώστε το.
Κρατήστε τον ισχυρισμό στενό. Μια πύλη εξόδου επιλέγει και μεταφράζει μια διαδρομή. Δεν τερματίζει ένα VPN και δεν μετατρέπει το cluster σε πελάτη του απομακρυσμένου σας δικτύου χωρίς υποστηριζόμενη σύνδεση πίσω της.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
Η μετάφραση αλλάζει σιωπηλά το τι βλέπει η απομακρυσμένη πλευρά
Μόλις η πύλη ξαναγράψει την πηγή, οι διευθύνσεις ανά Pod χάνονται, άρα μια λίστα επιτρεπόμενων βασισμένη στην ταυτότητα γίνεται λίστα βασισμένη σε μία κοινή διεύθυνση. Αυτό είναι ανταλλαγή και όχι ελάττωμα: λιγότεροι κανόνες για συντήρηση, πιο χονδρική απόδοση όταν κάτι συμπεριφέρεται άσχημα.
Η πιστοποίηση σε επίπεδο εφαρμογής και η καταγραφή αιτημάτων πρέπει να φέρουν ό,τι δεν αναφέρει πλέον το δίκτυο. Αντιμετωπίστε τη χωρητικότητα και την αντικατάσταση της πύλης ως κοινή υποδομή, γιατί η επανεκκίνηση ενός κόμβου διακόπτει πλέον κάθε φόρτο εργασίας πίσω του, και ελέγξτε τη διαδρομή επιστροφής νωρίς: το απομακρυσμένο άκρο πρέπει να ξέρει πώς να φτάσει τη μεταφρασμένη διεύθυνση, συνήθως μέσω διαδρομής ή NAT που πρέπει να κατέχει άνθρωπος, όχι manifest. Ο σχεδιασμός διευθύνσεων ανήκει επίσης εδώ, γιατί επικαλυπτόμενα εύρη cluster και απομακρυσμένου δικτύου σπάνε και τα δύο μοντέλα και η υιοθέτηση IPv6 δεν δικαιολογεί ένα αντιφατικό σχέδιο.
Αποφασίστε με βάση την ιδιοκτησία και μετά δοκιμάστε την αποτυχία που υποσχεθήκατε
Διαλέξτε το τούνελ ανά Pod όταν η απομακρυσμένη υπηρεσία πιστοποιεί μεμονωμένους φόρτους εργασίας, όταν μόνο λίγα Deployment χρειάζονται τον σύνδεσμο και όταν μια αποτυχία πρέπει να μείνει τοπική. Διαλέξτε την πύλη όταν μια ομάδα δικτύου κατέχει ήδη τη διαδρομή, όταν πολλοί φόρτοι εργασίας μοιράζονται έναν προορισμό και όταν μια σταθερή διεύθυνση πηγής είναι όλο το νόημα της άσκησης.
Όπως και να έχει, επαληθεύστε την ιδιότητα που πουλήσατε και όχι τη σταθερή κατάσταση. Δημιουργήστε ένα Pod, αφήστε το να μεταδώσει αμέσως και παρακολουθήστε τα πρώτα δευτερόλεπτα αν η υπόσχεση ήταν ότι τίποτα δεν διαφεύγει από το τούνελ. Κλιμακώστε σε πέντε ρέπλικες και μετρήστε τις συνεδρίες που αναφέρει το απομακρυσμένο άκρο αν η υπόσχεση ήταν ταυτότητα ανά φόρτο εργασίας. Αυτοί οι δύο έλεγχοι αποκαλύπτουν τα όρια του μηχανισμού πολύ γρηγορότερα από μια ανασκόπηση του manifest και σας λένε ποια ομάδα κατέχει το επόμενο περιστατικό.