Goedemiddag, ik wil mijn ervaring met u delen bij het opzetten en gebruiken van de AWS EKS-service (Elastic Kubernetes Service) voor Windows-containers, of beter gezegd over de onmogelijkheid om deze te gebruiken, en de bug gevonden in de AWS-systeemcontainer, voor degenen die geïnteresseerd zijn in deze service voor Windows-containers, gelieve onder cat.
Ik weet dat Windows-containers geen populair onderwerp zijn, en dat maar weinig mensen ze gebruiken, maar ik besloot toch dit artikel te schrijven, omdat er een paar artikelen over Habré op kubernetes en Windows waren en er nog steeds zulke mensen zijn.
begin
Het begon allemaal toen besloten werd om de diensten in ons bedrijf te migreren naar kubernetes, wat voor 70% Windows en 30% Linux is. Voor dit doel werd de AWS EKS-clouddienst als een van de mogelijke opties beschouwd. Tot 8 oktober 2019 stond AWS EKS Windows in Public Preview, ik ben ermee begonnen, daar werd de oude 1.11 versie van kubernetes gebruikt, maar ik besloot het toch te controleren en te kijken in welk stadium deze clouddienst was, of deze werkte helemaal niet, zoals later bleek, nee, er was een bug bij de toevoeging van het verwijderen van pods, terwijl de oude niet meer reageerden via het interne IP-adres van hetzelfde subnet als het Windows Worker-knooppunt.
Daarom werd besloten om het gebruik van AWS EKS achterwege te laten ten gunste van een eigen cluster op kubernetes op dezelfde EC2, alleen zouden we alle balancering en HA zelf moeten beschrijven via CloudFormation.
Amazon EKS Windows Container-ondersteuning nu algemeen beschikbaar
door Martin Beeby | op 08 OKT 2019
Voordat ik tijd had om een template toe te voegen aan CloudFormation voor mijn eigen cluster, zag ik dit nieuws
Natuurlijk legde ik al mijn werk opzij en begon te bestuderen wat ze voor GA deden, en hoe alles veranderde met Public Preview. Ja, AWS, goed gedaan, heeft de images voor het Windows Worker-knooppunt bijgewerkt naar versie 1.14, evenals het cluster zelf, versie 1.14 in EKS, ondersteunt nu Windows-knooppunten. Project door openbare preview op Ze hebben het verborgen gehouden en gezegd dat je nu de officiële documentatie hier moet gebruiken:
Integratie van een EKS-cluster in de huidige VPC en subnetten
In alle bronnen, zowel in de link hierboven op de aankondiging als in de documentatie, werd voorgesteld om het cluster te implementeren via het eigen hulpprogramma eksctl of daarna via CloudFormation + kubectl, waarbij alleen openbare subnetten in Amazon zouden worden gebruikt, en ook een afzonderlijke VPC voor een nieuw cluster.
Deze optie is voor velen niet geschikt; ten eerste betekent een aparte VPC extra kosten voor de kosten + peering verkeer naar je huidige VPC. Wat moeten degenen die al een kant-en-klare infrastructuur in AWS hebben met hun eigen meerdere AWS-accounts, VPC, subnetten, routetabellen, transitgateway enzovoort doen? Je wilt dit natuurlijk niet kapot maken of opnieuw doen, en je moet het nieuwe EKS-cluster integreren in de huidige netwerkinfrastructuur, gebruikmakend van de bestaande VPC, en ter scheiding hoogstens nieuwe subnetten voor het cluster creëren.
In mijn geval werd dit pad gekozen, ik gebruikte de bestaande VPC, voegde slechts 2 openbare subnetten en 2 privé-subnetten toe voor het nieuwe cluster, uiteraard werd met alle regels rekening gehouden volgens de documentatie .
Er was ook één voorwaarde: er waren geen werkknooppunten in openbare subnetten die EIP gebruikten.
eksctl versus CloudFormation
Ik maak meteen een voorbehoud dat ik beide methoden voor het inzetten van een cluster heb geprobeerd, in beide gevallen was het beeld hetzelfde.
Ik zal een voorbeeld laten zien dat alleen eksctl gebruikt, omdat de code hier korter zal zijn. Gebruik eksctl om het cluster in 3 stappen te implementeren:
1. We creëren het cluster zelf + Linux-werkknooppunt, dat later systeemcontainers en diezelfde noodlottige vpc-controller zal hosten.
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-networkingOm te implementeren op een bestaande VPC hoeft u alleen maar de ID van uw subnetten op te geven, en eksctl zal de VPC zelf bepalen.
Om ervoor te zorgen dat uw werkknooppunten alleen in een privé-subnet worden geïmplementeerd, moet u --node-private-networking opgeven voor nodegroup.
2. We installeren vpc-controller in ons cluster, dat vervolgens onze werkknooppunten zal verwerken, het aantal vrije IP-adressen zal tellen, evenals het aantal ENI's op de instantie, en deze zal toevoegen en verwijderen.
eksctl utils install-vpc-controllers --name yyy --approve3. Nadat uw systeemcontainers met succes zijn gestart op uw Linux-werkknooppunt, inclusief vpc-controller, hoeft u alleen nog maar een nieuwe knooppuntgroep met Windows-werknemers te maken.
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-networkingNadat uw knooppunt met succes verbinding heeft gemaakt met uw cluster en alles in orde lijkt te zijn, heeft het knooppunt de status Gereed, maar nee.
Fout in vpc-controller
Als we proberen pods uit te voeren op een Windows Worker-knooppunt, krijgen we de foutmelding:
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]Als we dieper kijken, zien we dat onze instantie in AWS er als volgt uitziet:
En het zou zo moeten zijn:
Hieruit blijkt duidelijk dat de vpc-controller om een of andere reden zijn taak niet vervulde en geen nieuwe IP-adressen aan de instance kon toevoegen zodat de pods deze konden gebruiken.
Laten we eens kijken naar de logs van de vpc-controller pod en dit is wat we zien:
kubectl-logboek -n kube-systeem
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.Zoekopdrachten op Google leverden niets op, aangezien blijkbaar nog niemand zo'n bug had opgemerkt, of er geen issue op had gepost, moest ik eerst zelf opties bedenken. Het eerste dat in me opkwam was dat de vpc-controller ip-10-xxx.ap-xxx.compute.internal misschien niet kan omzetten en bereiken en dat er daarom fouten optreden.
Ja, inderdaad, we gebruiken aangepaste DNS-servers in de VPC en in principe gebruiken we geen Amazon-servers, dus zelfs het doorsturen was niet geconfigureerd voor dit ap-xxx.compute.internal domein. Ik heb deze optie getest en het leverde geen resultaten op, misschien was de test niet schoon, en daarom bezweek ik verder, toen ik met technische ondersteuning communiceerde, voor hun idee.
Omdat er niet echt ideeën waren, werden alle beveiligingsgroepen door eksctl zelf gemaakt, dus er bestond geen twijfel over hun bruikbaarheid, de routetabellen waren ook correct, nat, dns, internettoegang met werkknooppunten was er ook.
Bovendien, als je een werkknooppunt in een openbaar subnet implementeert zonder —node-private-networking te gebruiken, werd dit knooppunt onmiddellijk bijgewerkt door de vpc-controller en werkte alles op rolletjes.
Er waren twee opties:
- Geef het op en wacht tot iemand deze bug in AWS beschrijft en deze repareert, en dan kun je veilig AWS EKS Windows gebruiken, omdat ze zojuist in GA zijn uitgebracht (8 dagen zijn verstreken op het moment dat dit artikel werd geschreven), velen zullen dat waarschijnlijk doen volg hetzelfde pad als ik.
- Schrijf naar AWS Support en vertel hen de essentie van het probleem met een hele reeks logs van overal en bewijs hen dat hun service niet werkt bij gebruik van uw VPC en subnetten, het is niet voor niets dat we zakelijke ondersteuning hadden, u zou deze moeten gebruiken minstens één keer :)
Communicatie met AWS-ingenieurs
Nadat ik een ticket op de portal had aangemaakt, heb ik er ten onrechte voor gekozen om op mij te reageren via web-e-mail of een ondersteuningscentrum. Via deze optie kunnen ze u na een paar dagen antwoorden, ondanks het feit dat mijn ticket Severity - System Disabled had, wat betekende binnen <12 uur een reactie, en aangezien het Business support plan 24/7 ondersteuning biedt, hoopte ik er het beste van, maar het bleek zoals altijd.
Mijn ticket bleef van vrijdag tot maandag niet toegewezen, daarna besloot ik ze opnieuw te schrijven en de chatreactieoptie te kiezen. Na een korte tijd te hebben gewacht, werd Harshad Madhav aangesteld om mij te ontmoeten, en toen begon het...
We hebben er drie uur achter elkaar online debuggen mee gedaan, logs overgedragen, hetzelfde cluster in het AWS-laboratorium ingezet om het probleem te emuleren, het cluster van mijn kant opnieuw gemaakt, enzovoort. Het enige waar we op uitkwamen is dat van uit de logs was het duidelijk dat de resol niet werkte AWS interne domeinnamen, waarover ik hierboven schreef, en Harshad Madhav vroeg me om doorsturing te creëren, naar verluidt gebruiken we aangepaste DNS en dit zou een probleem kunnen zijn.
Expeditie
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Dat is wat er gebeurde, de dag was voorbij. Harshad Madhav schreef terug om het te controleren en het zou moeten werken, maar nee, de resolutie hielp helemaal niet.
Toen was er communicatie met nog 2 ingenieurs, één stopte gewoon met de chat, blijkbaar was hij bang voor een complexe zaak, de tweede bracht mijn dag opnieuw door met een volledige cyclus van foutopsporing, het verzenden van logs, het maken van clusters aan beide kanten, in de einde zei hij gewoon goed, het werkt voor mij, hier ben ik, ik doe alles stap voor stap in de officiële documentatie en jij en jij zullen slagen.
Waarop ik hem beleefd vroeg om te vertrekken en iemand anders aan mijn ticket toe te wijzen als je niet weet waar je het probleem moet zoeken.
slotstuk
Op de derde dag werd mij een nieuwe ingenieur Arun B. toegewezen, en vanaf het allereerste begin van de communicatie met hem was het meteen duidelijk dat dit niet de 3 vorige ingenieurs waren. Hij las de hele geschiedenis en vroeg onmiddellijk om de logs te verzamelen met zijn eigen script op ps1, dat op zijn github stond. Dit werd opnieuw gevolgd door alle herhalingen van het maken van clusters, het uitvoeren van opdrachtresultaten en het verzamelen van logbestanden, maar Arun B. ging in de goede richting, te oordelen naar de vragen die aan mij werden gesteld.
Wanneer kwamen we op het punt om -stderrthreshold=debug in hun vpc-controller in te schakelen, en wat gebeurde er daarna? natuurlijk werkt het niet) de pod start eenvoudigweg niet met deze optie, alleen -stderrthreshold=info werkt.
We waren hier klaar en Arun B. zei dat hij zou proberen mijn stappen te reproduceren om dezelfde fout te krijgen. De volgende dag ontvang ik een reactie van Arun B. hij heeft deze zaak niet in de steek gelaten, maar de reviewcode van hun vpc-controller overgenomen en de plaats gevonden waar deze zich bevindt en waarom deze niet werkt:
Als u dus de hoofdroutetabel in uw VPC gebruikt, heeft deze standaard geen associaties met de noodzakelijke subnetten, die zo noodzakelijk zijn voor de vpc-controller. In het geval van een openbaar subnet heeft deze een aangepaste routetabel dat heeft een associatie.
Door handmatig associaties toe te voegen voor de hoofdroutetabel met de benodigde subnetten, en de knooppuntengroep opnieuw aan te maken, werkt alles perfect.
Ik hoop dat Arun B. deze bug echt aan de EKS-ontwikkelaars zal rapporteren en dat we een nieuwe versie van vpc-controller zullen zien waarin alles out-of-the-box zal werken. Momenteel is de nieuwste versie: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
heeft dit probleem.
Bedankt aan iedereen die tot het einde heeft gelezen, test alles wat je in de productie gaat gebruiken vóór de implementatie.
Bron: www.habr.com