Guten Tag, ich möchte Ihnen meine Erfahrungen bei der Einrichtung und Nutzung des AWS EKS-Dienstes (Elastic Kubernetes Service) für Windows-Container mitteilen, bzw. über die Unmöglichkeit seiner Nutzung und den darin gefundenen Fehler im AWS-Systemcontainer Wer sich für diesen Service für Windows-Container interessiert, findet sich bitte unter Kat.
Ich weiß, dass Windows-Container kein beliebtes Thema sind und nur wenige Leute sie verwenden, aber ich habe mich trotzdem entschieden, diesen Artikel zu schreiben, da es auf Habré ein paar Artikel über Kubernetes und Windows gab und es immer noch solche Leute gibt.
Hauptseite
Alles begann mit der Entscheidung, die Dienste in unserem Unternehmen auf Kubernetes zu migrieren, das zu 70 % aus Windows und zu 30 % aus Linux besteht. Zu diesem Zweck wurde der Cloud-Service AWS EKS als eine der möglichen Optionen in Betracht gezogen. Bis zum 8. Oktober 2019 befand sich AWS EKS Windows in der Public Preview, ich habe damit angefangen, dort wurde die alte Version 1.11 von Kubernetes verwendet, aber ich habe mich trotzdem entschlossen, es zu überprüfen und zu sehen, in welchem Stadium sich dieser Cloud-Dienst befand und ob er funktionierte Wie sich herausstellte, gab es überhaupt einen Fehler beim Entfernen von Pods, während die alten nicht mehr über die interne IP aus demselben Subnetz wie der Windows-Worker-Knoten reagierten.
Daher wurde beschlossen, auf die Verwendung von AWS EKS zu verzichten und stattdessen einen eigenen Cluster auf Kubernetes auf demselben EC2 zu verwenden. Nur müssten wir den gesamten Ausgleich und HA selbst über CloudFormation beschreiben.
Amazon EKS-Windows-Container-Unterstützung jetzt allgemein verfügbar
von Martin Beeby | am 08
Bevor ich Zeit hatte, eine Vorlage für meinen eigenen Cluster zu CloudFormation hinzuzufügen, sah ich diese Neuigkeiten
Natürlich habe ich meine ganze Arbeit beiseite gelegt und angefangen zu studieren, was sie für GA getan haben und wie sich mit Public Preview alles verändert hat. Ja, AWS, gut gemacht, hat die Images für den Windows-Worker-Knoten auf Version 1.14 aktualisiert, und auch der Cluster selbst, Version 1.14 in EKS, unterstützt jetzt Windows-Knoten. Projekt von Public Preview unter Sie haben es vertuscht und gesagt, dass Sie jetzt die offizielle Dokumentation hier verwenden sollten:
Integration eines EKS-Clusters in die aktuelle VPC und Subnetze
In allen Quellen, im obigen Link zur Ankündigung sowie in der Dokumentation, wurde vorgeschlagen, den Cluster entweder über das proprietäre Dienstprogramm eksctl oder danach über CloudFormation + kubectl bereitzustellen, dabei nur öffentliche Subnetze in Amazon zu verwenden und ein zu erstellen separate VPC für einen neuen Cluster.
Diese Option ist für viele nicht geeignet; erstens bedeutet eine separate VPC zusätzliche Kosten für ihre Kosten + Peering-Verkehr zu Ihrer aktuellen VPC. Was sollten diejenigen tun, die bereits über eine vorgefertigte Infrastruktur in AWS mit ihren eigenen mehreren AWS-Konten, VPC, Subnetzen, Routentabellen, Transit-Gateways usw. verfügen? Natürlich möchte man das alles nicht kaputt machen oder wiederholen, sondern muss den neuen EKS-Cluster unter Nutzung der bestehenden VPC in die aktuelle Netzwerkinfrastruktur integrieren und zur Trennung allenfalls neue Subnetze für den Cluster erstellen.
In meinem Fall wurde dieser Weg gewählt, ich habe die bestehende VPC verwendet, nur 2 öffentliche Subnetze und 2 private Subnetze für den neuen Cluster hinzugefügt, natürlich wurden alle Regeln laut Dokumentation berücksichtigt .
Es gab auch eine Bedingung: keine Worker-Knoten in öffentlichen Subnetzen, die EIP verwenden.
eksctl vs. CloudFormation
Ich möchte gleich anmerken, dass ich beide Methoden zur Bereitstellung eines Clusters ausprobiert habe. In beiden Fällen war das Bild das gleiche.
Ich werde ein Beispiel nur mit eksctl zeigen, da der Code hier kürzer ist. Stellen Sie den Cluster mithilfe von eksctl in drei Schritten bereit:
1. Wir erstellen den Cluster selbst + den Linux-Worker-Knoten, der später Systemcontainer und denselben unglücklichen VPC-Controller hosten wird.
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-networkingUm die Bereitstellung in einer vorhandenen VPC durchzuführen, geben Sie einfach die ID Ihres Subnetzes an und eksctl ermittelt die VPC selbst.
Um sicherzustellen, dass Ihre Worker-Knoten nur in einem privaten Subnetz bereitgestellt werden, müssen Sie --node-private-networking für die Knotengruppe angeben.
2. Wir installieren den vpc-controller in unserem Cluster, der dann unsere Worker-Knoten verarbeitet, die Anzahl der freien IP-Adressen sowie die Anzahl der ENIs auf der Instanz zählt und diese hinzufügt und entfernt.
eksctl utils install-vpc-controllers --name yyy --approve3. Nachdem Ihre Systemcontainer, einschließlich des VPC-Controllers, erfolgreich auf Ihrem Linux-Worker-Knoten gestartet wurden, müssen Sie nur noch eine weitere Knotengruppe mit Windows-Worker erstellen.
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-networkingNachdem sich Ihr Knoten erfolgreich mit Ihrem Cluster verbunden hat und alles in Ordnung zu sein scheint, befindet er sich im Status „Bereit“, aber nein.
Fehler im VPC-Controller
Wenn wir versuchen, Pods auf einem Windows-Worker-Knoten auszuführen, erhalten wir die Fehlermeldung:
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]Wenn wir genauer hinschauen, sehen wir, dass unsere Instanz in AWS so aussieht:
Und es sollte so sein:
Daraus geht hervor, dass der VPC-Controller aus irgendeinem Grund seine Aufgabe nicht erfüllt hat und der Instanz keine neuen IP-Adressen hinzufügen konnte, damit die Pods sie verwenden könnten.
Schauen wir uns die Protokolle des VPC-Controller-Pods an und sehen Folgendes:
kubectl-Protokoll -n Kube-System
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.Suchanfragen bei Google führten zu nichts, da anscheinend noch niemand einen solchen Bug entdeckt hatte oder noch kein Problem dazu gepostet hatte, musste ich mir zunächst selbst Möglichkeiten überlegen. Das erste, was mir in den Sinn kam, war, dass der VPC-Controller möglicherweise ip-10-xxx.ap-xxx.compute.internal nicht auflösen und erreichen kann und daher Fehler auftreten.
Ja, tatsächlich verwenden wir benutzerdefinierte DNS-Server in der VPC und im Prinzip keine Amazon-Server, sodass für diese ap-xxx.compute.internal-Domäne nicht einmal eine Weiterleitung konfiguriert wurde. Ich habe diese Option getestet und sie hat keine Ergebnisse gebracht. Vielleicht war der Test nicht sauber, und deshalb bin ich bei der Kommunikation mit dem technischen Support ihrer Idee nachgegeben.
Da es keine wirklichen Ideen gab, wurden alle Sicherheitsgruppen von eksctl selbst erstellt, es gab also keinen Zweifel an deren Funktionsfähigkeit, die Routing-Tabellen stimmten auch, NAT, DNS, Internetzugang mit Worker-Knoten waren auch vorhanden.
Wenn Sie außerdem einen Worker-Knoten in einem öffentlichen Subnetz bereitstellen, ohne „node-private-networking“ zu verwenden, wurde dieser Knoten sofort vom VPC-Controller aktualisiert und alles funktionierte wie am Schnürchen.
Es gab zwei Möglichkeiten:
- Geben Sie es auf und warten Sie, bis jemand diesen Fehler in AWS beschreibt und ihn behebt, und dann können Sie AWS EKS Windows sicher verwenden, da es gerade erst in GA veröffentlicht wurde (8 Tage sind zum Zeitpunkt des Schreibens dieses Artikels vergangen), viele werden es wahrscheinlich tun Gehe den gleichen Weg wie ich.
- Schreiben Sie an den AWS-Support und erklären Sie ihm den Kern des Problems mit einer ganzen Reihe von Protokollen von überall und beweisen Sie ihm, dass sein Dienst bei Verwendung Ihrer VPC und Subnetze nicht funktioniert. Nicht umsonst hatten wir Business-Support, den Sie nutzen sollten es mindestens einmal :)
Kommunikation mit AWS-Ingenieuren
Nachdem ich ein Ticket auf dem Portal erstellt habe, habe ich mich fälschlicherweise dafür entschieden, mir per Web-E-Mail oder im Support-Center zu antworten. Mit dieser Option können sie Ihnen nach ein paar Tagen überhaupt antworten, obwohl mein Ticket den Schweregrad „Systembeeinträchtigt“ hatte bedeutete eine Antwort innerhalb von <12 Stunden, und da der Business-Supportplan einen 24/7-Support bietet, habe ich auf das Beste gehofft, aber es lief wie immer.
Mein Ticket war von Freitag bis Montag nicht zugewiesen, dann beschloss ich, ihnen erneut zu schreiben und wählte die Option „Chat-Antwort“. Nach kurzer Wartezeit wurde Harshad Madhav zu mir ernannt und dann ging es los...
Wir haben 3 Stunden hintereinander damit online debuggt, Protokolle übertragen, denselben Cluster im AWS-Labor bereitgestellt, um das Problem zu emulieren, den Cluster meinerseits neu erstellt und so weiter. Das Einzige, worauf wir gekommen sind, ist das Aus den Protokollen ging klar hervor, dass die Auflösung der AWS-internen Domänennamen, über die ich oben geschrieben habe, nicht funktionierte, und Harshad Madhav bat mich, eine Weiterleitung zu erstellen. Angeblich verwenden wir benutzerdefiniertes DNS und dies könnte ein Problem sein.
Weiterleitung
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Das war erledigt, der Tag war vorbei. Harshad Madhav schrieb zurück, um es zu überprüfen, und es sollte funktionieren, aber nein, die Lösung hat überhaupt nicht geholfen.
Dann gab es eine Kommunikation mit zwei weiteren Ingenieuren, einer brach einfach den Chat ab, anscheinend hatte er Angst vor einem komplexen Fall, der zweite verbrachte meinen Tag erneut mit einem vollständigen Debugging-Zyklus, dem Versenden von Protokollen und dem Erstellen von Clustern auf beiden Seiten Am Ende sagte er nur: „Gut, es funktioniert bei mir. Hier bin ich. Ich mache alles Schritt für Schritt in der offiziellen Dokumentation und Sie und Sie werden Erfolg haben.“
Daraufhin habe ich ihn höflich gebeten, zu gehen und jemand anderem mein Ticket zuzuweisen, wenn Sie nicht wissen, wo Sie das Problem suchen sollen.
Finale
Am dritten Tag wurde mir ein neuer Ingenieur, Arun B., zugeteilt und gleich zu Beginn der Kommunikation mit ihm war sofort klar, dass es sich nicht um die drei vorherigen Ingenieure handelte. Er las den gesamten Verlauf und bat sofort darum, die Protokolle mithilfe seines eigenen Skripts auf PS3 zu sammeln, das sich auf seinem Github befand. Es folgten noch einmal alle Iterationen des Erstellens von Clustern, der Ausgabe von Befehlsergebnissen und dem Sammeln von Protokollen, aber Arun B. bewegte sich in die richtige Richtung, wenn man die mir gestellten Fragen beurteilt.
Wann haben wir den Punkt erreicht, an dem wir -stderrthreshold=debug in ihrem VPC-Controller aktiviert haben, und was geschah als nächstes? funktioniert natürlich nicht) Der Pod startet mit dieser Option einfach nicht, nur -stderrthreshold=info funktioniert.
Wir waren hier fertig und Arun B. sagte, dass er versuchen würde, meine Schritte zu reproduzieren, um den gleichen Fehler zu erhalten. Am nächsten Tag erhalte ich eine Antwort von Arun B. Er hat diesen Fall nicht aufgegeben, sondern den Überprüfungscode seines VPC-Controllers aufgegriffen und herausgefunden, wo er sich befindet und warum er nicht funktioniert:
Wenn Sie also die Haupt-Routentabelle in Ihrer VPC verwenden, verfügt diese standardmäßig nicht über Zuordnungen zu den erforderlichen Subnetzen, die für den VPC-Controller so erforderlich sind. Im Fall eines öffentlichen Subnetzes verfügt sie über eine benutzerdefinierte Routing-Tabelle das hat einen Zusammenhang.
Durch das manuelle Hinzufügen von Zuordnungen für die Hauptroutentabelle mit den erforderlichen Subnetzen und das erneute Erstellen der Knotengruppe funktioniert alles perfekt.
Ich hoffe, dass Arun B. diesen Fehler wirklich den EKS-Entwicklern meldet und wir eine neue Version von vpc-controller sehen werden, bei der alles sofort funktioniert. Derzeit ist die neueste Version: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
hat dieses Problem.
Vielen Dank an alle, die bis zum Ende gelesen haben. Testen Sie vor der Implementierung alles, was Sie in der Produktion verwenden werden.
Source: habr.com