God eftermiddag, jag vill dela med mig av min erfarenhet av att installera och använda tjänsten AWS EKS (Elastic Kubernetes Service) för Windows-behållare, eller snarare om omöjligheten att använda den, och felet som finns i AWS-systembehållaren, för de som är intresserade av denna tjänst för Windows-containrar, vänligen under kat.
Jag vet att Windows-behållare inte är ett populärt ämne, och få människor använder dem, men jag bestämde mig ändå för att skriva den här artikeln, eftersom det fanns ett par artiklar om Habré om kubernetes och Windows och det finns fortfarande sådana människor.
börjar
Allt började med att man beslutade att migrera tjänsterna i vårt företag till kubernetes, som är 70 % Windows och 30 % Linux. För detta ändamål betraktades molntjänsten AWS EKS som ett av de möjliga alternativen. Fram till 8 oktober 2019 var AWS EKS Windows i Public Preview, jag började med det, den gamla 1.11-versionen av kubernetes användes där, men jag bestämde mig för att kontrollera det ändå och se i vilket skede denna molntjänst var, om den fungerade överhuvudtaget, som det visade sig, nej, det var en bugg med tillägg av att ta bort pods, medan de gamla slutade svara via intern ip från samma subnät som Windows-arbetarnoden.
Därför beslutades det att överge användningen av AWS EKS till förmån för vårt eget kluster på kubernetes på samma EC2, bara vi skulle behöva beskriva all balansering och HA själva via CloudFormation.
Amazon EKS Windows Container Support nu allmänt tillgänglig
av Martin Beeby | den 08 oktober 2019
Innan jag hann lägga till en mall till CloudFormation för mitt eget kluster såg jag den här nyheten
Naturligtvis lade jag allt mitt arbete åt sidan och började studera vad de gjorde för GA, och hur allt förändrades med Public Preview. Ja, AWS, bra jobbat, uppdaterade bilderna för Windows Worker Node till version 1.14, liksom själva klustret, version 1.14 i EKS, stöder nu Windows-noder. Projekt av Public Preview kl De täckte upp det och sa nu använd den officiella dokumentationen här:
Integrering av ett EKS-kluster i nuvarande VPC och undernät
I alla källor, i länken ovan på tillkännagivandet såväl som i dokumentationen, föreslogs det att distribuera klustret antingen genom det proprietära exctl-verktyget eller genom CloudFormation + kubectl efter, endast genom att använda offentliga subnät i Amazon, samt skapa en separat VPC för ett nytt kluster.
Det här alternativet är inte lämpligt för många, för det första innebär en separat VPC extra kostnader för dess kostnad + peering-trafik till din nuvarande VPC. Vad ska de som redan har en färdig infrastruktur i AWS med egna Multiple AWS-konton, VPC, subnät, rutttabeller, transitgateway och så vidare göra? Naturligtvis vill du inte bryta eller göra om allt detta, och du måste integrera det nya EKS-klustret i den nuvarande nätverksinfrastrukturen, med hjälp av befintlig VPC och, för separation, som mest skapa nya subnät för klustret.
I mitt fall valdes denna väg, jag använde den befintliga VPC, la bara till 2 offentliga undernät och 2 privata undernät för det nya klustret, naturligtvis togs alla regler i beaktande enligt dokumentationen .
Det fanns också ett villkor: inga arbetarnoder i offentliga undernät som använder EIP.
eksctl vs CloudFormation
Jag reserverar genast att jag provade båda metoderna för att distribuera ett kluster, i båda fallen var bilden densamma.
Jag kommer att visa ett exempel som endast använder eksctl eftersom koden här kommer att vara kortare. Använd eksctl, distribuera klustret i tre steg:
1. Vi skapar själva klustret + Linux-arbetarnoden, som senare kommer att vara värd för systembehållare och samma olyckliga vpc-kontroller.
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-networkingFör att distribuera till en befintlig VPC, ange bara ID:t för dina undernät, så kommer eksctl att avgöra själva VPC:n.
För att säkerställa att dina arbetarnoder endast distribueras till ett privat undernät, måste du ange --node-private-networking för nodgrupp.
2. Vi installerar vpc-controller i vårt kluster, som sedan kommer att bearbeta våra arbetarnoder, räkna antalet lediga IP-adresser, såväl som antalet ENIs på instansen, lägga till och ta bort dem.
eksctl utils install-vpc-controllers --name yyy --approve3. Efter att dina systembehållare framgångsrikt har lanserats på din Linux-arbetsnod, inklusive vpc-controller, återstår bara att skapa en ny nodgrupp med Windows-arbetare.
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 att din nod har anslutit till ditt kluster och allt verkar vara bra, är den i Klar-status, men nej.
Fel i vpc-controller
Om vi försöker köra pods på en Windows-arbetarnod får vi felet:
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]Om vi tittar djupare ser vi att vår instans i AWS ser ut så här:
Och det ska vara så här:
Av detta är det tydligt att vpc-kontrollern inte uppfyllde sin del av någon anledning och inte kunde lägga till nya IP-adresser till instansen så att poddarna kunde använda dem.
Låt oss titta på loggarna för vpc-controller pod och det här är vad vi ser:
kubectl logg -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ökningar på Google ledde inte till någonting, eftersom uppenbarligen ingen hade fångat en sådan bugg ännu, eller inte hade lagt upp ett problem på det, var jag tvungen att tänka på alternativ själv först. Det första som kom att tänka på var att vpc-kontrollern kanske inte kan lösa ip-10-xxx.ap-xxx.compute.internal och nå den och därför uppstår fel.
Ja, faktiskt, vi använder anpassade DNS-servrar i VPC:n och i princip använder vi inte Amazon-servrar, så även vidarebefordran konfigurerades inte för denna ap-xxx.compute.internal-domän. Jag testade det här alternativet, och det gav inga resultat, kanske testet inte var rent, och därför, när jag kommunicerade med teknisk support, gav jag efter för deras idé.
Eftersom det egentligen inte fanns några idéer skapades alla säkerhetsgrupper av eksctl själv, så det rådde ingen tvekan om deras användbarhet, rutttabellerna var också korrekta, nat, dns, internetåtkomst med arbetarnoder fanns också där.
Dessutom, om du distribuerar en arbetarnod till ett offentligt subnät utan att använda —node-private-networking, uppdaterades denna nod omedelbart av vpc-controllern och allt fungerade som en klocka.
Det fanns två alternativ:
- Ge upp det och vänta tills någon beskriver denna bugg i AWS och de fixar det, och då kan du säkert använda AWS EKS Windows, eftersom de precis släppts i GA (8 dagar har gått när den här artikeln skrivs), många kommer förmodligen att Följ samma väg som jag.
- Skriv till AWS Support och berätta för dem kärnan av problemet med en hel massa loggar från överallt och bevisa för dem att deras tjänst inte fungerar när du använder din VPC och subnät, det är inte för inte vi hade Business Support, du borde använda det minst en gång :)
Kommunikation med AWS-ingenjörer
Efter att ha skapat en biljett på portalen valde jag av misstag att svara mig via webben - e-post eller supportcenter, genom det här alternativet kan de svara dig efter några dagar överhuvudtaget, trots att min biljett hade svårighetsgrad - systemnedsättning, vilket innebar svar inom <12 timmar, och eftersom Business supportplanen har 24/7 support hoppades jag på det bästa, men det blev som alltid.
Min biljett lämnades otilldelad från fredag till måndag, sedan bestämde jag mig för att skriva till dem igen och valde alternativet Chattsvar. Efter att ha väntat en kort stund utsågs Harshad Madhav att träffa mig, och sedan började det...
Vi felsökte med det online i 3 timmar i rad, överförde loggar, distribuerade samma kluster i AWS-laboratoriet för att emulera problemet, återskapade klustret från min sida, och så vidare, det enda vi kom fram till är att från loggarna var det tydligt att resolen inte fungerade AWS interna domännamn, vilket jag skrev om ovan, och Harshad Madhav bad mig skapa vidarebefordran, påstås använda anpassad DNS och detta kan vara ett problem.
Vidarebefordran
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Det var vad som gjordes, dagen var över. Harshad Madhav skrev tillbaka för att kontrollera det och det borde fungera, men nej, upplösningen hjälpte inte alls.
Sedan kom det kommunikation med ytterligare två ingenjörer, en hoppade helt enkelt av chatten, uppenbarligen var han rädd för ett komplext fall, den andra tillbringade min dag igen på en hel cykel av felsökning, skicka loggar, skapa kluster på båda sidor, i slut sa han bara bra, det fungerar för mig, här är jag jag gör allt steg för steg i den officiella dokumentationen och du och du kommer att lyckas.
Till vilket jag artigt bad honom att gå och tilldela någon annan min biljett om du inte vet var du ska leta efter problemet.
finale
På den tredje dagen tilldelades en ny ingenjör Arun B. till mig, och redan från början av kommunikationen med honom stod det omedelbart klart att detta inte var de 3 tidigare ingenjörerna. Han läste hela historien och bad omedelbart att få samla loggarna med sitt eget skript på ps1, som fanns på hans github. Detta följdes igen av alla iterationer av att skapa kluster, mata ut kommandoresultat, samla in loggar, men Arun B. rörde sig i rätt riktning att döma av frågorna som ställdes till mig.
När kom vi till punkten att aktivera -stderrthreshold=debug i deras vpc-kontroller, och vad hände sedan? naturligtvis fungerar det inte) podden startar helt enkelt inte med det här alternativet, bara -stderrthreshold=info fungerar.
Vi avslutade här och Arun B. sa att han skulle försöka återskapa mina steg för att få samma fel. Nästa dag får jag ett svar från Arun B. han övergav inte det här fallet, utan tog upp recensionskoden för deras vpc-controller och hittade platsen där den är och varför den inte fungerar:
Således, om du använder huvudrutttabellen i din VPC, har den som standard inte associationer med de nödvändiga subnäten, som är så nödvändiga för vpc-kontrollern, i fallet med ett publikt subnät har den en anpassad rutttabell som har en förening.
Genom att manuellt lägga till associationer för huvudrutttabellen med nödvändiga subnät, och återskapa nodgruppen, fungerar allt perfekt.
Jag hoppas att Arun B. verkligen kommer att rapportera detta fel till EKS-utvecklarna och vi kommer att se en ny version av vpc-controller där allt kommer att fungera direkt. För närvarande är den senaste versionen: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
har detta problem.
Tack till alla som läser till slutet, testa allt du ska använda i produktionen innan implementering.
Källa: will.com