Καλησπέρα, θέλω να μοιραστώ μαζί σας την εμπειρία μου από τη ρύθμιση και τη χρήση της υπηρεσίας AWS EKS (Elastic Kubernetes Service) για κοντέινερ Windows, ή μάλλον σχετικά με την αδυναμία χρήσης της και το σφάλμα που βρέθηκε στο κοντέινερ συστήματος AWS, για αυτούς όσοι ενδιαφέρονται για αυτήν την υπηρεσία για κοντέινερ Windows, παρακαλώ κάτω από cat.
Γνωρίζω ότι τα κοντέινερ των Windows δεν είναι δημοφιλές θέμα και λίγοι τα χρησιμοποιούν, αλλά αποφάσισα να γράψω αυτό το άρθρο, καθώς υπήρχαν μερικά άρθρα στο Habré για τα kubernetes και τα Windows και υπάρχουν ακόμα τέτοιοι άνθρωποι.
ΑΡΧΙΚΗ
Όλα ξεκίνησαν όταν αποφασίστηκε η μετεγκατάσταση των υπηρεσιών της εταιρείας μας στο kubernetes, που είναι κατά 70% Windows και 30% Linux. Για το σκοπό αυτό, η υπηρεσία cloud AWS EKS θεωρήθηκε ως μία από τις πιθανές επιλογές. Μέχρι τις 8 Οκτωβρίου 2019, το AWS EKS Windows ήταν σε δημόσια προεπισκόπηση, ξεκίνησα με αυτό, χρησιμοποιήθηκε η παλιά έκδοση 1.11 του kubernetes, αλλά αποφάσισα να το ελέγξω ούτως ή άλλως και να δω σε ποιο στάδιο ήταν αυτή η υπηρεσία cloud, αν λειτουργούσε καθόλου, όπως αποδείχτηκε, όχι, υπήρχε ένα σφάλμα με την προσθήκη αφαίρεσης pods, ενώ τα παλιά σταμάτησαν να ανταποκρίνονται μέσω εσωτερικής ip από το ίδιο υποδίκτυο με τον κόμβο εργασίας των Windows.
Ως εκ τούτου, αποφασίστηκε να εγκαταλείψουμε τη χρήση του AWS EKS υπέρ του δικού μας συμπλέγματος στα kubernetes στο ίδιο EC2, μόνο που θα έπρεπε να περιγράψουμε μόνοι μας όλη την εξισορρόπηση και το HA μέσω του CloudFormation.
Η υποστήριξη κοντέινερ Windows EKS της Amazon είναι τώρα γενικά διαθέσιμη
του Martin Beeby | στις 08 ΟΚΤΩΒΡΙΟΥ 2019
Πριν προλάβω να προσθέσω ένα πρότυπο στο CloudFormation για το δικό μου σύμπλεγμα, είδα αυτά τα νέα
Φυσικά, άφησα όλη τη δουλειά μου στην άκρη και άρχισα να μελετώ τι έκαναν για το GA και πώς άλλαξαν όλα με τη Δημόσια Προεπισκόπηση. Ναι, το AWS, μπράβο, ενημέρωσε τις εικόνες για τον κόμβο εργασίας των Windows στην έκδοση 1.14, καθώς και το ίδιο το σύμπλεγμα, έκδοση 1.14 στο EKS, υποστηρίζει πλέον κόμβους των Windows. Έργο από Δημόσια Προεπισκόπηση στο Το κάλυψαν και είπαν τώρα χρησιμοποιήστε την επίσημη τεκμηρίωση εδώ:
Ενσωμάτωση ενός συμπλέγματος EKS στο τρέχον VPC και στα υποδίκτυα
Σε όλες τις πηγές, στον παραπάνω σύνδεσμο της ανακοίνωσης καθώς και στην τεκμηρίωση, προτάθηκε η ανάπτυξη του συμπλέγματος είτε μέσω του αποκλειστικού βοηθητικού προγράμματος eksctl είτε μέσω του CloudFormation + kubectl μετά, χρησιμοποιώντας μόνο δημόσια υποδίκτυα στο Amazon, καθώς και τη δημιουργία ενός ξεχωριστό VPC για ένα νέο σύμπλεγμα.
Αυτή η επιλογή δεν είναι κατάλληλη για πολλούς· πρώτον, ένα ξεχωριστό VPC σημαίνει πρόσθετο κόστος για το κόστος του + κίνηση ομοτίμησης στο τρέχον VPC σας. Τι πρέπει να κάνουν όσοι έχουν ήδη μια έτοιμη υποδομή στο AWS με τους δικούς τους λογαριασμούς πολλαπλών AWS, VPC, υποδίκτυα, πίνακες διαδρομών, πύλη μεταφοράς και ούτω καθεξής; Φυσικά, δεν θέλετε να τα σπάσετε ή να τα ξανακάνετε όλα αυτά και πρέπει να ενσωματώσετε το νέο σύμπλεγμα EKS στην τρέχουσα υποδομή δικτύου, χρησιμοποιώντας το υπάρχον VPC και, για διαχωρισμό, το πολύ να δημιουργήσετε νέα υποδίκτυα για το σύμπλεγμα.
Στην περίπτωσή μου, επιλέχθηκε αυτή η διαδρομή, χρησιμοποίησα το υπάρχον VPC, πρόσθεσα μόνο 2 δημόσια υποδίκτυα και 2 ιδιωτικά υποδίκτυα για το νέο σύμπλεγμα, φυσικά, ελήφθησαν υπόψη όλοι οι κανόνες σύμφωνα με την τεκμηρίωση .
Υπήρχε επίσης μια προϋπόθεση: να μην υπάρχουν κόμβοι εργαζομένων σε δημόσια υποδίκτυα που χρησιμοποιούν EIP.
eksctl εναντίον CloudFormation
Θα κάνω μια κράτηση αμέσως ότι δοκίμασα και τις δύο μεθόδους ανάπτυξης ενός συμπλέγματος, και στις δύο περιπτώσεις η εικόνα ήταν η ίδια.
Θα δείξω ένα παράδειγμα μόνο χρησιμοποιώντας eksctl, καθώς ο κώδικας εδώ θα είναι πιο σύντομος. Χρησιμοποιώντας eksctl, αναπτύξτε το σύμπλεγμα σε 3 βήματα:
1. Δημιουργούμε το ίδιο το σύμπλεγμα + τον κόμβο εργασίας Linux, ο οποίος αργότερα θα φιλοξενεί κοντέινερ συστήματος και τον ίδιο κακόμοιρο vpc-controller.
eksctl create cluster
--name yyy
--region www
--version 1.14
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx
--asg-access
--nodegroup-name linux-workers
--node-type t3.small
--node-volume-size 20
--ssh-public-key wwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami auto
--node-private-networkingΠροκειμένου να αναπτυχθεί σε ένα υπάρχον VPC, απλώς καθορίστε το αναγνωριστικό των υποδικτύων σας και το eksctl θα καθορίσει το ίδιο το VPC.
Για να διασφαλίσετε ότι οι κόμβοι εργαζομένων σας αναπτύσσονται μόνο σε ένα ιδιωτικό υποδίκτυο, πρέπει να καθορίσετε --node-private-networking για την ομάδα κόμβων.
2. Εγκαθιστούμε vpc-controller στο σύμπλεγμα μας, το οποίο στη συνέχεια θα επεξεργαστεί τους κόμβους εργαζομένων μας, μετρώντας τον αριθμό των δωρεάν διευθύνσεων IP, καθώς και τον αριθμό των ENI στο στιγμιότυπο, προσθέτοντας και αφαιρώντας τους.
eksctl utils install-vpc-controllers --name yyy --approve3. Μετά την επιτυχή εκκίνηση των κοντέινερ του συστήματός σας στον κόμβο εργασίας Linux, συμπεριλαμβανομένου του ελεγκτή vpc, το μόνο που μένει είναι να δημιουργήσετε μια άλλη ομάδα κόμβων με τα Windows Workers.
eksctl create nodegroup
--region www
--cluster yyy
--version 1.14
--name windows-workers
--node-type t3.small
--ssh-public-key wwwwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami-family WindowsServer2019CoreContainer
--node-ami ami-0573336fc96252d05
--node-private-networkingΑφού ο κόμβος σας συνδεθεί επιτυχώς στο σύμπλεγμα σας και όλα φαίνονται να είναι καλά, βρίσκεται σε κατάσταση Έτοιμος, αλλά όχι.
Σφάλμα στον ελεγκτή vpc
Εάν προσπαθήσουμε να εκτελέσουμε pods σε έναν κόμβο εργασίας των Windows, θα λάβουμε το σφάλμα:
NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]Αν κοιτάξουμε βαθύτερα, βλέπουμε ότι η παρουσία μας στο AWS μοιάζει με αυτό:
Και θα πρέπει να είναι έτσι:
Από αυτό είναι σαφές ότι ο ελεγκτής vpc δεν εκπλήρωσε το μέρος του για κάποιο λόγο και δεν μπορούσε να προσθέσει νέες διευθύνσεις IP στο στιγμιότυπο, έτσι ώστε τα pods να μπορούν να τις χρησιμοποιήσουν.
Ας δούμε τα αρχεία καταγραφής του vpc-controller pod και αυτό είναι που βλέπουμε:
ημερολόγιο kubectl -n kube-σύστημα
I1011 06:32:03.910140 1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162 1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238 1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423 1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211 1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229 1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302 1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313 1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.Οι αναζητήσεις στο Google δεν οδήγησαν σε τίποτα, καθώς προφανώς κανείς δεν είχε εντοπίσει τέτοιο σφάλμα ακόμα, ή δεν είχε δημοσιεύσει κάποιο θέμα σε αυτό, έπρεπε πρώτα να σκεφτώ επιλογές μόνος μου. Το πρώτο πράγμα που μου ήρθε στο μυαλό ήταν ότι ίσως ο vpc-controller δεν μπορεί να επιλύσει το ip-10-xxx.ap-xxx.compute.internal και να το φτάσει και επομένως να προκύψουν σφάλματα.
Ναι, πράγματι, χρησιμοποιούμε προσαρμοσμένους διακομιστές DNS στο VPC και, καταρχήν, δεν χρησιμοποιούμε διακομιστές Amazon, επομένως ακόμη και η προώθηση δεν διαμορφώθηκε για αυτόν τον τομέα ap-xxx.compute.internal. Δοκίμασα αυτήν την επιλογή και δεν έφερε αποτελέσματα, ίσως η δοκιμή δεν ήταν καθαρή και επομένως, περαιτέρω, όταν επικοινωνούσα με την τεχνική υποστήριξη, υπέκυψα στην ιδέα τους.
Δεδομένου ότι δεν υπήρχαν πραγματικά ιδέες, όλες οι ομάδες ασφαλείας δημιουργήθηκαν από την ίδια την eksctl, επομένως δεν υπήρχε αμφιβολία για τη λειτουργικότητά τους, οι πίνακες διαδρομών ήταν επίσης σωστοί, nat, dns, πρόσβαση στο Διαδίκτυο με κόμβους εργαζομένων ήταν επίσης εκεί.
Επιπλέον, εάν αναπτύξετε έναν κόμβο εργασίας σε ένα δημόσιο υποδίκτυο χωρίς να χρησιμοποιήσετε το —node-private-networking, αυτός ο κόμβος ενημερώθηκε αμέσως από τον ελεγκτή vpc και όλα λειτουργούσαν σαν ρολόι.
Υπήρχαν δύο επιλογές:
- Εγκαταλείψτε το και περιμένετε μέχρι κάποιος να περιγράψει αυτό το σφάλμα στο AWS και να το διορθώσει και, στη συνέχεια, μπορείτε να χρησιμοποιήσετε με ασφάλεια τα Windows AWS EKS, επειδή μόλις κυκλοφόρησαν στο GA (έχουν περάσει 8 ημέρες τη στιγμή της συγγραφής αυτού του άρθρου), πολλοί πιθανότατα θα ακολουθήστε τον ίδιο δρόμο με εμένα.
- Γράψτε στην Υποστήριξη AWS και πείτε τους την ουσία του προβλήματος με ένα σωρό αρχεία καταγραφής από παντού και αποδείξτε τους ότι η υπηρεσία τους δεν λειτουργεί όταν χρησιμοποιείτε το VPC και τα υποδίκτυά σας. τουλάχιστον μια φορά :)
Επικοινωνία με μηχανικούς AWS
Έχοντας δημιουργήσει ένα εισιτήριο στην πύλη, επέλεξα κατά λάθος να μου απαντήσω μέσω Web - email ή κέντρου υποστήριξης, μέσω αυτής της επιλογής μπορούν να σας απαντήσουν μετά από λίγες ημέρες, παρά το γεγονός ότι το εισιτήριό μου είχε υποστεί σοβαρότητα - σύστημα, το οποίο σήμαινε απάντηση εντός <12 ωρών, και δεδομένου ότι το σχέδιο υποστήριξης επιχειρήσεων έχει υποστήριξη 24/7, ήλπιζα για το καλύτερο, αλλά αποδείχθηκε όπως πάντα.
Το εισιτήριό μου έμεινε χωρίς ανάθεση από την Παρασκευή μέχρι τη Δευτέρα, μετά αποφάσισα να τους ξαναγράψω και επέλεξα την επιλογή Απάντηση συνομιλίας. Αφού περίμενα για λίγο, διορίστηκε ο Harshad Madhav να με δει και μετά άρχισε...
Κάναμε διόρθωση σφαλμάτων με αυτό διαδικτυακά για 3 ώρες στη σειρά, μεταφέροντας αρχεία καταγραφής, αναπτύσσοντας το ίδιο σύμπλεγμα στο εργαστήριο AWS για την εξομοίωση του προβλήματος, δημιουργώντας εκ νέου το σύμπλεγμα από την πλευρά μου και ούτω καθεξής, το μόνο πράγμα που καταλήξαμε είναι ότι από τα αρχεία καταγραφής ήταν σαφές ότι η ανάλυση δεν λειτουργούσε εσωτερικά ονόματα τομέα AWS, για τα οποία έγραψα παραπάνω, και ο Harshad Madhav μου ζήτησε να δημιουργήσω προώθηση, φέρεται να χρησιμοποιούμε προσαρμοσμένο DNS και αυτό θα μπορούσε να είναι πρόβλημα.
Προώθηση
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Αυτό έγινε, η μέρα τελείωσε. Ο Harshad Madhav έγραψε πίσω για να το ελέγξει και θα έπρεπε να λειτουργήσει, αλλά όχι, η επίλυση δεν βοήθησε καθόλου.
Στη συνέχεια, υπήρξε επικοινωνία με άλλους 2 μηχανικούς, ο ένας απλώς έφυγε από τη συνομιλία, προφανώς φοβόταν μια περίπλοκη υπόθεση, ο δεύτερος πέρασε τη μέρα μου ξανά σε έναν πλήρη κύκλο εντοπισμού σφαλμάτων, αποστολή αρχείων καταγραφής, δημιουργία συμπλεγμάτων και στις δύο πλευρές, στο τελος απλα ειπε καλα μου δουλευει εδω ειμαι κανω τα παντα βαθμιαια στην επισημη τεκμηριωση και εσυ και εσυ θα τα καταφερετε.
Για το οποίο του ζήτησα ευγενικά να φύγει και να ορίσει κάποιον άλλο στο εισιτήριό μου αν δεν ξέρετε πού να αναζητήσετε το πρόβλημα.
Φινάλε
Την τρίτη μέρα, μου ανατέθηκε ένας νέος μηχανικός Arun B. και από την αρχή της επικοινωνίας μαζί του φάνηκε αμέσως ότι δεν ήταν οι 3 προηγούμενοι μηχανικοί. Διάβασε ολόκληρο το ιστορικό και ζήτησε αμέσως να συλλέξει τα αρχεία καταγραφής χρησιμοποιώντας το δικό του σενάριο στο ps1, το οποίο βρισκόταν στο github του. Ακολούθησαν πάλι όλες οι επαναλήψεις της δημιουργίας συμπλεγμάτων, της εξαγωγής αποτελεσμάτων εντολών, της συλλογής αρχείων καταγραφής, αλλά ο Arun B. κινούνταν προς τη σωστή κατεύθυνση, αν κρίνω από τις ερωτήσεις που μου έκαναν.
Πότε φτάσαμε στο σημείο να ενεργοποιήσουμε το -stderrthreshold=debug στον vpc-ελεγκτή τους και τι συνέβη στη συνέχεια; φυσικά δεν λειτουργεί) το pod απλά δεν ξεκινά με αυτήν την επιλογή, λειτουργεί μόνο -stderrthreshold=info.
Τελειώσαμε εδώ και ο Arun B. είπε ότι θα προσπαθήσει να αναπαράγει τα βήματά μου για να πάρει το ίδιο σφάλμα. Την επόμενη μέρα έλαβα μια απάντηση από τον Arun B. δεν εγκατέλειψε αυτήν την υπόθεση, αλλά πήρε τον κωδικό ελέγχου του vpc-controller τους και βρήκε το μέρος όπου βρίσκεται και γιατί δεν λειτουργεί:
Έτσι, εάν χρησιμοποιείτε τον κύριο πίνακα διαδρομών στο VPC σας, τότε από προεπιλογή δεν έχει συσχετίσεις με τα απαραίτητα υποδίκτυα, τα οποία είναι τόσο απαραίτητα για τον ελεγκτή vpc, στην περίπτωση ενός δημόσιου υποδικτύου, έχει έναν προσαρμοσμένο πίνακα διαδρομών που έχει συνειρμό.
Προσθέτοντας μη αυτόματα συσχετίσεις για τον κύριο πίνακα διαδρομών με τα απαραίτητα υποδίκτυα και δημιουργώντας εκ νέου την ομάδα κόμβων, όλα λειτουργούν τέλεια.
Ελπίζω ότι ο Arun B. θα αναφέρει πραγματικά αυτό το σφάλμα στους προγραμματιστές του EKS και θα δούμε μια νέα έκδοση του vpc-controller όπου όλα θα λειτουργούν εκτός του κουτιού. Αυτήν τη στιγμή η τελευταία έκδοση είναι: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
έχει αυτό το πρόβλημα.
Ευχαριστώ όλους όσους διάβασαν μέχρι το τέλος, δοκιμάστε όλα όσα πρόκειται να χρησιμοποιήσετε στην παραγωγή πριν από την εφαρμογή.
Πηγή: www.habr.com