God ettermiddag, jeg vil dele med deg min erfaring med å sette opp og bruke AWS EKS (Elastic Kubernetes Service)-tjenesten for Windows-beholdere, eller snarere om umuligheten av å bruke den, og feilen som finnes i AWS-systembeholderen, for de som er interessert i denne tjenesten for Windows-beholdere, vennligst under kat.
Jeg vet at Windows-beholdere ikke er et populært emne, og få mennesker bruker dem, men jeg bestemte meg likevel for å skrive denne artikkelen, siden det var et par artikler om Habré på kubernetes og Windows, og det er fortsatt slike mennesker.
begynner
Det hele startet da det ble besluttet å migrere tjenestene i selskapet vårt til kubernetes, som er 70 % Windows og 30 % Linux. For dette formålet ble skytjenesten AWS EKS vurdert som et av de mulige alternativene. Fram til 8. oktober 2019 var AWS EKS Windows i offentlig forhåndsvisning, jeg begynte med den, den gamle 1.11-versjonen av kubernetes ble brukt der, men jeg bestemte meg for å sjekke den uansett og se på hvilket stadium denne skytjenesten var, om den fungerte i det hele tatt, som det viste seg, nei, det var en feil med tillegg av å fjerne pods, mens de gamle sluttet å svare via intern ip fra samme subnett som Windows-arbeidernoden.
Derfor ble det besluttet å forlate bruken av AWS EKS til fordel for vår egen klynge på kubernetes på samme EC2, bare vi måtte beskrive all balansering og HA selv via CloudFormation.
Amazon EKS Windows Container Support nå generelt tilgjengelig
av Martin Beeby | den 08. OKT 2019
Før jeg rakk å legge til en mal i CloudFormation for min egen klynge, så jeg denne nyheten
Jeg la selvfølgelig alt arbeidet til side og begynte å studere hva de gjorde for GA, og hvordan alt endret seg med Public Preview. Ja, AWS, godt gjort, oppdaterte bildene for windows worker node til versjon 1.14, så vel som selve klyngen, versjon 1.14 i EKS, støtter nå windows noder. Prosjekt av Public Preview kl De dekket det opp og sa nå bruk den offisielle dokumentasjonen her:
Integrering av en EKS-klynge i gjeldende VPC og undernett
I alle kilder, i lenken over på kunngjøringen så vel som i dokumentasjonen, ble det foreslått å distribuere klyngen enten gjennom det proprietære eksctl-verktøyet eller gjennom CloudFormation + kubectl etter, kun ved å bruke offentlige undernett i Amazon, samt opprette en egen VPC for en ny klynge.
Dette alternativet passer ikke for mange; for det første betyr en separat VPC ekstra kostnader for kostnadene + peering-trafikk til din nåværende VPC. Hva skal de som allerede har en ferdig infrastruktur i AWS med egne Multiple AWS-kontoer, VPC, subnett, rutetabeller, transit gateway og så videre gjøre? Selvfølgelig vil du ikke bryte eller gjøre om alt dette, og du må integrere den nye EKS-klyngen i den nåværende nettverksinfrastrukturen, ved å bruke den eksisterende VPC-en og, for separasjon, maksimalt opprette nye undernett for klyngen.
I mitt tilfelle ble denne banen valgt, jeg brukte den eksisterende VPC, la bare til 2 offentlige undernett og 2 private undernett for den nye klyngen, selvfølgelig ble alle reglene tatt i betraktning i henhold til dokumentasjonen .
Det var også en betingelse: ingen arbeidernoder i offentlige undernett som bruker EIP.
eksctl vs CloudFormation
Jeg tar umiddelbart forbehold om at jeg prøvde begge metodene for å distribuere en klynge, i begge tilfeller var bildet det samme.
Jeg vil vise et eksempel bare ved å bruke eksctl siden koden her vil være kortere. Bruk eksctl, distribuer klyngen i 3 trinn:
1. Vi lager selve klyngen + Linux-arbeidernoden, som senere vil være vert for systembeholdere og den samme skjebnesvangre vpc-kontrolleren.
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 å distribuere til en eksisterende VPC, spesifiser bare IDen til undernettene dine, og eksctl vil bestemme selve VPCen.
For å sikre at arbeidsnodene dine bare distribueres til et privat undernett, må du spesifisere --node-private-networking for nodegruppe.
2. Vi installerer vpc-kontroller i klyngen vår, som deretter behandler arbeidernodene våre, teller antall ledige IP-adresser, samt antall ENI-er på instansen, legger til og fjerner dem.
eksctl utils install-vpc-controllers --name yyy --approve3. Etter at systembeholderne har blitt lansert på Linux-arbeidernoden, inkludert vpc-kontrolleren, gjenstår det bare å opprette en ny nodegruppe med Windows-arbeidere.
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-networkingEtter at noden din har koblet til klyngen din og alt ser ut til å være i orden, er den i Klar-status, men nei.
Feil i vpc-kontrolleren
Hvis vi prøver å kjøre pods på en Windows-arbeidernode, får vi feilen:
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 dypere, ser vi at vår instans i AWS ser slik ut:
Og det skal være slik:
Fra dette er det klart at vpc-kontrolleren ikke oppfylte sin del av en eller annen grunn og ikke kunne legge til nye IP-adresser til instansen slik at podene kunne bruke dem.
La oss se på loggene til vpc-kontroller-poden og dette er hva 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øk på Google førte ikke til noe, siden tilsynelatende ingen hadde fanget en slik feil ennå, eller ikke hadde lagt ut et problem på den, måtte jeg tenke på alternativer selv først. Det første som kom til tankene var at kanskje ikke vpc-kontrolleren kan løse ip-10-xxx.ap-xxx.compute.internal og nå den og derfor oppstår feil.
Ja, faktisk, vi bruker tilpassede DNS-servere i VPC, og i prinsippet bruker vi ikke Amazon-servere, så selv videresending ble ikke konfigurert for dette ap-xxx.compute.internal domenet. Jeg testet dette alternativet, og det ga ikke resultater, kanskje testen ikke var ren, og derfor, da jeg kommuniserte med teknisk støtte, ga jeg etter for ideen deres.
Siden det egentlig ikke var noen ideer, ble alle sikkerhetsgrupper opprettet av eksctl selv, så det var ingen tvil om deres brukbarhet, rutetabellene var også korrekte, nat, dns, Internett-tilgang med arbeidernoder var også der.
Dessuten, hvis du distribuerer en arbeidernode til et offentlig undernett uten å bruke —node-private-nettverk, ble denne noden umiddelbart oppdatert av vpc-kontrolleren og alt fungerte som smurt.
Det var to alternativer:
- Gi det opp og vent til noen beskriver denne feilen i AWS og de fikser det, og da kan du trygt bruke AWS EKS Windows, fordi de nettopp har gitt ut i GA (8 dager har gått på tidspunktet for skriving av denne artikkelen), mange vil nok Følg samme vei som meg.
- Skriv til AWS Support og fortell dem essensen av problemet med en hel haug med logger fra overalt og bevis for dem at tjenesten deres ikke fungerer når du bruker din VPC og subnett, det er ikke for ingenting vi hadde Business Support, du bør bruke det minst en gang :)
Kommunikasjon med AWS-ingeniører
Etter å ha opprettet en billett på portalen, valgte jeg feilaktig å svare meg via Web - e-post eller støttesenter, gjennom dette alternativet kan de svare deg etter noen dager i det hele tatt, til tross for at billetten min hadde alvorlighetsgrad - System svekket, som betydde svar innen <12 timer, og siden Business support planen har 24/7 support, håpet jeg på det beste, men det ble som alltid.
Billetten min ble ikke tildelt fra fredag til mandag, så bestemte jeg meg for å skrive til dem igjen og valgte Chat-svar-alternativet. Etter å ha ventet en kort stund, ble Harshad Madhav oppnevnt til å se meg, og så begynte det...
Vi feilsøkte med den på nettet i 3 timer på rad, overførte logger, distribuerte den samme klyngen i AWS-laboratoriet for å etterligne problemet, gjenskapte klyngen fra min side, og så videre, det eneste vi kom til er at fra loggene var det tydelig at resolen ikke fungerte AWS interne domenenavn, som jeg skrev om ovenfor, og Harshad Madhav ba meg lage videresending, angivelig bruker vi tilpasset DNS og dette kan være et problem.
Videresending
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Det var det som ble gjort, dagen var over. Harshad Madhav skrev tilbake for å sjekke det, og det skulle fungere, men nei, oppløsningen hjalp ikke i det hele tatt.
Så var det kommunikasjon med 2 ingeniører til, den ene droppet rett og slett ut av chatten, tilsynelatende var han redd for en kompleks sak, den andre brukte dagen min igjen på en full syklus med feilsøking, sending av logger, opprettelse av klynger på begge sider, i slutt sa han bare bra, det fungerer for meg, her er jeg jeg gjør alt steg for steg i den offisielle dokumentasjonen og du og du vil lykkes.
Som jeg høflig ba ham om å forlate og tildele noen andre til billetten min hvis du ikke vet hvor du skal lete etter problemet.
finale
På den tredje dagen ble en ny ingeniør Arun B. tildelt meg, og helt fra begynnelsen av kommunikasjonen med ham var det umiddelbart klart at dette ikke var de 3 tidligere ingeniørene. Han leste hele historien og ba umiddelbart om å samle loggene ved å bruke sitt eget skript på ps1, som var på githuben hans. Dette ble etterfulgt igjen av alle gjentakelsene med å lage klynger, skrive ut kommandoresultater, samle logger, men Arun B. beveget seg i riktig retning etter spørsmålene som ble stilt til meg.
Når kom vi til poenget med å aktivere -stderrthreshold=debug i deres vpc-kontroller, og hva skjedde deretter? selvfølgelig fungerer det ikke) poden starter ganske enkelt ikke med dette alternativet, bare -stderrthreshold=info fungerer.
Vi avsluttet her og Arun B. sa at han ville prøve å gjengi trinnene mine for å få samme feil. Dagen etter får jeg svar fra Arun B. han forlot ikke denne saken, men tok opp gjennomgangskoden til vpc-kontrolleren deres og fant stedet der den er og hvorfor den ikke fungerer:
Derfor, hvis du bruker hovedrutetabellen i VPC-en din, har den som standard ikke assosiasjoner til de nødvendige undernettene, som er så nødvendige for vpc-kontrolleren, i tilfelle av et offentlig undernett, har den en tilpasset rutetabell som har en forening.
Ved å manuelt legge til assosiasjoner for hovedrutetabellen med nødvendige subnett, og gjenopprette nodegruppen, fungerer alt perfekt.
Jeg håper at Arun B. virkelig vil rapportere denne feilen til EKS-utviklerne og vi vil se en ny versjon av vpc-kontrolleren der alt vil fungere ut av boksen. For øyeblikket er den nyeste versjonen: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
har dette problemet.
Takk til alle som leser til slutt, test alt du skal bruke i produksjonen før implementering.
Kilde: www.habr.com