God eftermiddag, jeg vil gerne dele med dig min erfaring med opsætning og brug af AWS EKS (Elastic Kubernetes Service)-tjenesten til Windows-containere, eller rettere om umuligheden af at bruge den, og fejlen fundet i AWS-systemcontaineren, for dem der er interesseret i denne service til Windows-containere, venligst under kat.
Jeg ved, at Windows-containere ikke er et populært emne, og få mennesker bruger dem, men jeg besluttede mig alligevel for at skrive denne artikel, da der var et par artikler om Habré om kubernetes og Windows, og der er stadig sådanne mennesker.
begynder
Det hele startede, da det blev besluttet at migrere tjenesterne i vores virksomhed til kubernetes, som er 70 % Windows og 30 % Linux. Til dette formål blev AWS EKS cloud-tjenesten betragtet som en af de mulige muligheder. Indtil den 8. oktober 2019 var AWS EKS Windows i Public Preview, jeg startede med det, den gamle 1.11-version af kubernetes blev brugt der, men jeg besluttede at tjekke det alligevel og se på hvilket stadium denne cloud-tjeneste var, om den virkede overhovedet, som det viste sig, nej, det var der en fejl med tilføjelse af sletning af pods, mens de gamle holdt op med at reagere via intern ip fra det samme undernet som windows worker node.
Derfor blev det besluttet at opgive brugen af AWS EKS til fordel for vores egen klynge på kubernetes på samme EC2, blot skulle vi selv beskrive al balancering og HA via CloudFormation.
Amazon EKS Windows Container Support nu generelt tilgængelig
af Martin Beeby | den 08. OKT 2019
Før jeg nåede at tilføje en skabelon til CloudFormation til min egen klynge, så jeg denne nyhed
Selvfølgelig lagde jeg alt mit arbejde til side og begyndte at studere, hvad de gjorde for GA, og hvordan alting ændrede sig med Public Preview. Ja, AWS, godt gået, opdaterede billederne til windows worker node til version 1.14, såvel som selve klyngen, version 1.14 i EKS, understøtter nu windows noder. Projekt af Public Preview kl De dækkede det op og sagde nu, brug den officielle dokumentation her:
Integrering af en EKS-klynge i den nuværende VPC og undernet
I alle kilder, i linket ovenfor på meddelelsen såvel som i dokumentationen, blev det foreslået at implementere klyngen enten gennem det proprietære eksctl-værktøj eller gennem CloudFormation + kubectl efter, kun ved brug af offentlige undernet i Amazon, samt oprettelse af en separat VPC for en ny klynge.
Denne mulighed er ikke egnet for mange; for det første betyder en separat VPC ekstra omkostninger for dets omkostninger + peering-trafik til din nuværende VPC. Hvad skal de, der allerede har en færdiglavet infrastruktur i AWS med deres egne Multiple AWS-konti, VPC, undernet, rutetabeller, transitgateway og så videre gøre? Selvfølgelig vil du ikke bryde eller lave alt dette om, og du skal integrere den nye EKS-klynge i den nuværende netværksinfrastruktur ved at bruge den eksisterende VPC og højst oprette nye undernet til klyngen til adskillelse.
I mit tilfælde blev denne vej valgt, jeg brugte den eksisterende VPC, tilføjede kun 2 offentlige undernet og 2 private undernet til den nye klynge, selvfølgelig blev alle reglerne taget i betragtning i henhold til dokumentationen .
Der var også én betingelse: ingen arbejderknudepunkter i offentlige undernet, der bruger EIP.
eksctl vs CloudFormation
Jeg tager straks forbehold for, at jeg prøvede begge metoder til at implementere en klynge, i begge tilfælde var billedet det samme.
Jeg vil vise et eksempel, der kun bruger eksctl, da koden her vil være kortere. Brug eksctl til at implementere klyngen i 3 trin:
1. Vi opretter selve klyngen + Linux-arbejderknudepunktet, som senere vil være vært for systemcontainere og den samme skæbnesvangre 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-networkingFor at implementere til en eksisterende VPC skal du blot angive id'et for dine undernet, og eksctl bestemmer selv VPC'en.
For at sikre, at dine arbejdernoder kun er implementeret til et privat undernet, skal du angive --node-private-networking for nodegroup.
2. Vi installerer vpc-controller i vores klynge, som derefter behandler vores arbejdernoder, tæller antallet af ledige IP-adresser samt antallet af ENI'er på instansen, tilføjer og fjerner dem.
eksctl utils install-vpc-controllers --name yyy --approve3. Efter at dine systemcontainere er blevet startet på din Linux-arbejderknude, inklusive vpc-controller, er der kun tilbage at oprette en anden nodegruppe med Windows-arbejdere.
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-networkingEfter at din node har oprettet forbindelse til din klynge, og alt ser ud til at være i orden, er den i Klar-status, men nej.
Fejl i vpc-controller
Hvis vi prøver at køre pods på en Windows-arbejderknude, får vi fejlen:
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]Hvis vi ser dybere, ser vi, at vores instans i AWS ser sådan ud:
Og det skal være sådan her:
Heraf er det klart, at vpc-controlleren af en eller anden grund ikke opfyldte sin del og ikke kunne tilføje nye IP-adresser til instansen, så pods kunne bruge dem.
Lad os se på logfilerne for vpc-controller pod'en, og dette er, hvad vi ser:
kubectl log -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.Søgninger på Google førte ikke til noget, da der tilsyneladende ikke var nogen, der havde fanget en sådan fejl endnu, eller ikke havde postet et problem på den, jeg skulle selv tænke på muligheder først. Det første, der kom til at tænke på, var, at vpc-controller måske ikke kan løse ip-10-xxx.ap-xxx.compute.internal og nå det, og det er derfor, der opstår fejl.
Ja, faktisk bruger vi brugerdefinerede DNS-servere i VPC'en, og i princippet bruger vi ikke Amazon-servere, så selv videresendelse var ikke konfigureret for dette ap-xxx.compute.internal domæne. Jeg testede denne mulighed, og den gav ikke resultater, måske var testen ikke ren, og derfor bukkede jeg under for deres idé, da jeg kommunikerede med teknisk support.
Da der ikke rigtig var nogen idéer, blev alle sikkerhedsgrupper oprettet af eksctl selv, så der var ingen tvivl om deres brugbarhed, rutetabellerne var også korrekte, nat, dns, internetadgang med arbejdernoder var der også.
Desuden, hvis du implementerer en arbejderknude til et offentligt undernet uden at bruge —node-private-networking, blev denne node straks opdateret af vpc-controlleren, og alt fungerede som smurt.
Der var to muligheder:
- Opgiv det og vent til nogen beskriver denne fejl i AWS og de fikser det, og så kan du roligt bruge AWS EKS Windows, fordi de netop er udgivet i GA (der er gået 8 dage på tidspunktet for skrivning af denne artikel), mange vil sikkert følge samme vej som mig.
- Skriv til AWS Support og fortæl dem essensen af problemet med en hel masse logfiler fra alle steder og bevis for dem, at deres service ikke virker, når du bruger din VPC og undernet, det er ikke for ingenting, vi havde Business support, du bør bruge det mindst en gang :)
Kommunikation med AWS ingeniører
Efter at have oprettet en billet på portalen, valgte jeg fejlagtigt at svare mig via Web - e-mail eller supportcenter, gennem denne mulighed kan de overhovedet svare dig efter et par dage, på trods af at min billet havde Sværhedsgrad - System svækket, hvilket betød svar indenfor <12 timer, og da Business support planen har 24/7 support, håbede jeg på det bedste, men det blev som altid.
Min billet blev ikke tildelt fra fredag til mandag, så besluttede jeg at skrive til dem igen og valgte chat-svar-muligheden. Efter at have ventet i kort tid, blev Harshad Madhav udpeget til at se mig, og så begyndte det...
Vi fejlede med det online i 3 timer i træk, overførte logfiler, implementerede den samme klynge i AWS-laboratoriet for at efterligne problemet, genskabte klyngen fra min side og så videre, det eneste, vi kom til, er, at fra logfilerne var det klart, at resolen ikke fungerede AWS interne domænenavne, som jeg skrev om ovenfor, og Harshad Madhav bad mig om at oprette videresendelse, angiveligt bruger vi tilpasset DNS, og dette kunne være et problem.
Videresendelse
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Det var det, der blev gjort, dagen var forbi. Harshad Madhav skrev tilbage for at tjekke det, og det burde virke, men nej, opløsningen hjalp overhovedet ikke.
Så var der kommunikation med yderligere 2 ingeniører, den ene droppede simpelthen ud af chatten, tilsyneladende var han bange for en kompleks sag, den anden brugte min dag igen på en fuld cyklus af fejlretning, afsendelse af logfiler, oprettelse af klynger på begge sider, i ende sagde han bare godt, det virker for mig, her er jeg jeg gør alt trin for trin i den officielle dokumentation, og du og du vil lykkes.
Hvortil jeg høfligt bad ham om at gå og tildele en anden til min billet, hvis du ikke ved, hvor du skal lede efter problemet.
finale
På tredjedagen fik jeg tildelt en ny ingeniør Arun B., og lige fra begyndelsen af kommunikationen med ham stod det straks klart, at det ikke var de 3 tidligere ingeniører. Han læste hele historien og bad straks om at samle logfilerne ved hjælp af sit eget script på ps1, som var på hans github. Dette blev efterfulgt igen af alle gentagelserne med at oprette klynger, udsende kommandoresultater, indsamle logs, men Arun B. bevægede sig i den rigtige retning at dømme efter de spørgsmål, der blev stillet til mig.
Hvornår kom vi til det punkt at aktivere -stderrthreshold=debug i deres vpc-controller, og hvad skete der derefter? selvfølgelig virker det ikke) poden starter simpelthen ikke med denne mulighed, kun -stderrthreshold=info virker.
Vi sluttede her, og Arun B. sagde, at han ville prøve at gengive mine trin for at få den samme fejl. Den næste dag modtager jeg et svar fra Arun B. han opgav ikke denne sag, men tog revisionskoden til deres vpc-controller op og fandt stedet, hvor den er, og hvorfor den ikke virker:
Således, hvis du bruger hovedrutetabellen i din VPC, så har den som standard ikke tilknytninger til de nødvendige undernet, som er så nødvendige for vpc-controlleren, i tilfælde af et offentligt undernet har den en tilpasset rutetabel der har en forening.
Ved manuelt at tilføje tilknytninger til hovedrutetabellen med de nødvendige undernet, og genskabe nodegruppen, fungerer alt perfekt.
Jeg håber, at Arun B. virkelig vil rapportere denne fejl til EKS-udviklerne, og vi vil se en ny version af vpc-controller, hvor alt vil fungere ud af boksen. I øjeblikket er den seneste version: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
har dette problem.
Tak til alle der læser til ende, test alt hvad du skal bruge i produktionen før implementering.
Kilde: www.habr.com