Bonjour, je souhaite partager avec vous mon expérience dans la mise en place et l'utilisation du service AWS EKS (Elastic Kubernetes Service) pour les conteneurs Windows, ou plutôt sur l'impossibilité de l'utiliser, et le bug trouvé dans le conteneur système AWS, pour ceux qui sont intéressés par ce service pour les conteneurs Windows, veuillez sous cat.
Je sais que les conteneurs Windows ne sont pas un sujet populaire et que peu de gens les utilisent, mais j'ai quand même décidé d'écrire cet article, car il y avait quelques articles sur Habré sur Kubernetes et Windows et il y a toujours de telles personnes.
début
Tout a commencé lorsqu'il a été décidé de migrer les services de notre entreprise vers Kubernetes, qui est à 70 % Windows et 30 % Linux. À cette fin, le service cloud AWS EKS a été considéré comme l'une des options possibles. Jusqu'au 8 octobre 2019, AWS EKS Windows était en version préliminaire publique, j'ai commencé avec, l'ancienne version 1.11 de Kubernetes y était utilisée, mais j'ai quand même décidé de le vérifier et de voir à quel stade en était ce service cloud, s'il fonctionnait du tout, il s'est avéré que non, il y avait un bug avec l'ajout de la suppression des pods, tandis que les anciens ont cessé de répondre via l'adresse IP interne du même sous-réseau que le nœud de travail Windows.
Par conséquent, il a été décidé d'abandonner l'utilisation d'AWS EKS au profit de notre propre cluster sur kubernetes sur le même EC2, il suffirait que nous devions décrire nous-mêmes tout l'équilibrage et la haute disponibilité via CloudFormation.
La prise en charge des conteneurs Windows Amazon EKS est désormais généralement disponible
de Martin Beeby | le 08 octobre 2019
Avant d'avoir le temps d'ajouter un modèle à CloudFormation pour mon propre cluster, j'ai vu cette news
Bien sûr, j'ai mis tout mon travail de côté et j'ai commencé à étudier ce qu'ils avaient fait pour GA et comment tout avait changé avec l'aperçu public. Oui, AWS, bravo, a mis à jour les images du nœud de travail Windows vers la version 1.14, ainsi que le cluster lui-même, la version 1.14 dans EKS, prend désormais en charge les nœuds Windows. Projet en avant-première publique à Ils l'ont dissimulé et ont dit d'utiliser maintenant la documentation officielle ici :
Intégration d'un cluster EKS dans le VPC et les sous-réseaux actuels
Dans toutes les sources, dans le lien ci-dessus sur l'annonce ainsi que dans la documentation, il a été proposé de déployer le cluster soit via l'utilitaire propriétaire eksctl, soit via CloudFormation + kubectl après, en utilisant uniquement des sous-réseaux publics dans Amazon, ainsi qu'en créant un VPC séparé pour un nouveau cluster.
Cette option ne convient pas à beaucoup : premièrement, un VPC séparé signifie des coûts supplémentaires pour son coût + trafic de peering vers votre VPC actuel. Que devraient faire ceux qui disposent déjà d'une infrastructure prête à l'emploi dans AWS avec leurs propres comptes AWS multiples, VPC, sous-réseaux, tables de routage, passerelle de transit, etc. ? Bien sûr, vous ne voulez pas casser ou refaire tout cela, et vous devez intégrer le nouveau cluster EKS dans l'infrastructure réseau actuelle, en utilisant le VPC existant et, pour la séparation, tout au plus créer de nouveaux sous-réseaux pour le cluster.
Dans mon cas, ce chemin a été choisi, j'ai utilisé le VPC existant, ajouté seulement 2 sous-réseaux publics et 2 sous-réseaux privés pour le nouveau cluster, bien sûr, toutes les règles ont été prises en compte selon la documentation .
Il y avait également une condition : aucun nœud de travail dans les sous-réseaux publics utilisant EIP.
eksctl et CloudFormation
Je ferai une réserve tout de suite sur le fait que j'ai essayé les deux méthodes de déploiement d'un cluster, dans les deux cas, l'image était la même.
Je vais montrer un exemple utilisant uniquement eksctl puisque le code ici sera plus court. À l'aide d'eksctl, déployez le cluster en 3 étapes :
1. Nous créons le cluster lui-même + le nœud de travail Linux, qui hébergera plus tard les conteneurs système et ce même contrôleur vpc malheureux.
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-networkingAfin de déployer sur un VPC existant, spécifiez simplement l'identifiant de vos sous-réseaux et eksctl déterminera lui-même le VPC.
Pour garantir que vos nœuds de travail sont déployés uniquement sur un sous-réseau privé, vous devez spécifier --node-private-networking pour nodegroup.
2. Nous installons vpc-controller dans notre cluster, qui traitera ensuite nos nœuds de travail, en comptant le nombre d'adresses IP libres, ainsi que le nombre d'ENI sur l'instance, en les ajoutant et en les supprimant.
eksctl utils install-vpc-controllers --name yyy --approve3.Une fois vos conteneurs système lancés avec succès sur votre nœud de travail Linux, y compris le contrôleur VPC, il ne reste plus qu'à créer un autre groupe de nœuds avec des travailleurs Windows.
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-networkingUne fois que votre nœud s'est connecté avec succès à votre cluster et que tout semble aller bien, il est à l'état Prêt, mais non.
Erreur dans le contrôleur VPC
Si nous essayons d'exécuter des pods sur un nœud de travail Windows, nous obtiendrons l'erreur :
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]Si nous regardons plus en profondeur, nous voyons que notre instance dans AWS ressemble à ceci :
Et ça devrait être comme ça :
Il ressort clairement de cela que le contrôleur VPC n'a pas rempli son rôle pour une raison quelconque et n'a pas pu ajouter de nouvelles adresses IP à l'instance afin que les pods puissent les utiliser.
Regardons les logs du pod vpc-controller et voici ce que nous voyons :
journal Kubectl -n système 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.Les recherches sur Google n'ont abouti à rien, car apparemment personne n'avait encore détecté un tel bug ou n'avait posté de problème à ce sujet, j'ai d'abord dû réfléchir moi-même aux options. La première chose qui m'est venue à l'esprit était que le contrôleur VPC ne pouvait peut-être pas résoudre ip-10-xxx.ap-xxx.compute.internal et l'atteindre et que des erreurs se produisaient donc.
Oui, en effet, nous utilisons des serveurs DNS personnalisés dans le VPC et, en principe, nous n'utilisons pas ceux d'Amazon, donc même le transfert n'a pas été configuré pour ce domaine ap-xxx.compute.internal. J'ai testé cette option, et elle n'a donné aucun résultat, peut-être que le test n'était pas propre, et donc, en communiquant avec le support technique, j'ai succombé à leur idée.
Comme il n'y avait pas vraiment d'idées, tous les groupes de sécurité ont été créés par eksctl lui-même, donc il n'y avait aucun doute sur leur utilité, les tables de routage étaient également correctes, nat, dns, l'accès Internet avec les nœuds de travail était également là.
De plus, si vous déployez un nœud de travail sur un sous-réseau public sans utiliser —node-private-networking, ce nœud a été immédiatement mis à jour par le contrôleur vpc et tout a fonctionné comme sur des roulettes.
Il y avait deux options:
- Abandonnez-le et attendez que quelqu'un décrive ce bug dans AWS et le corrige, et vous pourrez alors utiliser AWS EKS Windows en toute sécurité, car ils viennent de sortir en GA (8 jours se sont écoulés au moment de la rédaction de cet article), beaucoup le feront probablement suivez le même chemin que moi.
- Écrivez à AWS Support et expliquez-leur l'essence du problème avec tout un tas de logs de partout et prouvez-leur que leur service ne fonctionne pas lors de l'utilisation de votre VPC et de vos sous-réseaux, ce n'est pas pour rien que nous avons eu un support Business, vous devriez utiliser ça au moins une fois :)
Communication avec les ingénieurs AWS
Après avoir créé un ticket sur le portail, j'ai choisi par erreur de me répondre via Web - email ou centre d'assistance, grâce à cette option, ils peuvent vous répondre au bout de quelques jours, malgré le fait que mon ticket avait une gravité - Système altéré, ce qui signifiait une réponse dans un délai de <12 heures, et comme le plan de support Business dispose d'une assistance 24h/7 et XNUMXj/XNUMX, j'espérais le meilleur, mais cela s'est avéré comme toujours.
Mon ticket est resté non attribué du vendredi au lundi, puis j'ai décidé de leur écrire à nouveau et j'ai choisi l'option de réponse par Chat. Après avoir attendu un court moment, Harshad Madhav a été nommé pour me voir, et puis tout a commencé...
Nous l'avons débogué en ligne pendant 3 heures d'affilée, transférant les logs, déployant le même cluster dans le laboratoire AWS pour émuler le problème, recréant le cluster de ma part, et ainsi de suite, la seule chose à laquelle nous sommes arrivés est que de dans les journaux, il était clair que la résolution ne fonctionnait pas avec les noms de domaine internes d'AWS, dont j'ai parlé ci-dessus, et Harshad Madhav m'a demandé de créer un transfert, prétendument nous utilisons un DNS personnalisé et cela pourrait être un problème.
Renvoi
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)C’est ce qui a été fait, la journée était terminée, Harshad Madhav a répondu pour vérifier et ça devrait marcher, mais non, la résolution n’a pas aidé du tout.
Ensuite, il y a eu une communication avec 2 autres ingénieurs, l'un a simplement abandonné le chat, apparemment il avait peur d'un cas complexe, le second a encore passé ma journée sur un cycle complet de débogage, d'envoi de journaux, de création de clusters des deux côtés, dans le fin il vient de dire bien, ça marche pour moi, me voilà je fais tout étape par étape dans la documentation officielle et vous et vous réussirez.
Ce à quoi je lui ai poliment demandé de partir et d'affecter quelqu'un d'autre à mon ticket si vous ne savez pas où chercher le problème.
Final
Le troisième jour, un nouvel ingénieur Arun B. m'a été affecté, et dès le début de la communication avec lui, il était immédiatement clair qu'il ne s'agissait pas des 3 ingénieurs précédents. Il a lu l'intégralité de l'historique et a immédiatement demandé à collecter les journaux en utilisant son propre script sur PS1, qui se trouvait sur son github. Cela a été suivi à nouveau par toutes les itérations de création de clusters, d'affichage des résultats des commandes, de collecte de journaux, mais Arun B. allait dans la bonne direction à en juger par les questions qui m'ont été posées.
Quand en sommes-nous arrivés au point d'activer -stderrthreshold=debug dans leur contrôleur VPC, et que s'est-il passé ensuite ? bien sûr, cela ne fonctionne pas), le pod ne démarre tout simplement pas avec cette option, seul -stderrthreshold=info fonctionne.
Nous avons terminé ici et Arun B. a dit qu'il essaierait de reproduire mes étapes pour obtenir la même erreur. Le lendemain, je reçois une réponse d'Arun B. il n'a pas abandonné ce cas, mais a repris le code de révision de leur contrôleur vpc et a trouvé l'endroit où il se trouve et pourquoi il ne fonctionne pas :
Ainsi, si vous utilisez la table de routage principale dans votre VPC, alors par défaut, elle n'a pas d'associations avec les sous-réseaux nécessaires, si nécessaires au contrôleur VPC, dans le cas d'un sous-réseau public, elle a une table de routage personnalisée qui a une association.
En ajoutant manuellement des associations pour la table de routage principale avec les sous-réseaux nécessaires et en recréant le groupe de nœuds, tout fonctionne parfaitement.
J'espère qu'Arun B. signalera vraiment ce bug aux développeurs EKS et nous verrons une nouvelle version de vpc-controller où tout fonctionnera immédiatement. Actuellement, la dernière version est : 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
a ce problème.
Merci à tous ceux qui ont lu jusqu'au bout, testez tout ce que vous allez utiliser en production avant la mise en œuvre.
Source: habr.com