Dobrý deň, chcem sa s vami podeliť o svoje skúsenosti s nastavením a používaním služby AWS EKS (Elastic Kubernetes Service) pre kontajnery Windows, respektíve o nemožnosti jej používania a o chybe zistenej v kontajneri systému AWS pre tých ktorí majú záujem o túto službu pre Windows kontajnery, prosím pod kat.
Viem, že Windows kontajnery nie sú populárnou témou a málokto ich používa, no aj tak som sa rozhodol napísať tento článok, keďže na Habré na kubernetes a Windowse bolo pár článkov a stále je takých ľudí.
začiatok
Všetko to začalo, keď sa rozhodlo o migrácii služieb v našej spoločnosti na kubernetes, čo je 70% Windows a 30% Linux. Pre tento účel bola ako jedna z možných možností zvažovaná cloudová služba AWS EKS. Do 8 bol AWS EKS Windows vo verejnom náhľade, začal som s ním, používala sa tam stará verzia kubernetes 2019, ale rozhodol som sa to aj tak skontrolovať a zistiť, v akom štádiu je táto cloudová služba, či funguje vôbec, ako sa ukázalo, nie, bola tam chyba s pridaním odstraňovania podov, pričom staré prestali reagovať cez internú ip z rovnakej podsiete ako windows worker node.
Preto bolo rozhodnuté upustiť od používania AWS EKS v prospech vlastného klastra na kubernetes na rovnakom EC2, len všetko vyvažovanie a HA by sme si museli popísať sami cez CloudFormation.
Podpora kontajnerov Amazon EKS Windows je teraz všeobecne dostupná
od Martina Beebyho | dňa 08
Skôr ako som stihol pridať šablónu do CloudFormation pre svoj vlastný klaster, videl som túto novinku
Samozrejme som odložil všetku svoju prácu a začal som študovať, čo urobili pre GA a ako sa všetko zmenilo s Public Preview. Áno, AWS, dobre urobil, aktualizoval obrázky pre pracovný uzol systému Windows na verziu 1.14, ako aj samotný klaster, verzia 1.14 v EKS, teraz podporuje uzly systému Windows. Project by Public Preview at Zakryli to a povedali, že teraz použite oficiálnu dokumentáciu tu:
Integrácia klastra EKS do aktuálnych VPC a podsietí
Vo všetkých zdrojoch, v odkaze vyššie v oznámení, ako aj v dokumentácii, bolo navrhnuté nasadenie klastra buď cez proprietárnu utilitu eksctl alebo cez CloudFormation + kubectl potom, iba pomocou verejných podsietí v Amazone, ako aj vytvorenie samostatné VPC pre nový klaster.
Táto možnosť nie je vhodná pre mnohých, po prvé, samostatný VPC znamená dodatočné náklady na jeho náklady + peeringovú návštevnosť vášho súčasného VPC. Čo by mali robiť tí, ktorí už majú pripravenú infraštruktúru v AWS s vlastnými účtami Multiple AWS, VPC, podsiete, smerovacie tabuľky, tranzitnú bránu a podobne? Samozrejme, nechcete to všetko pokaziť alebo prerobiť a musíte integrovať nový klaster EKS do súčasnej sieťovej infraštruktúry pomocou existujúceho VPC a na oddelenie nanajvýš vytvoriť nové podsiete pre klaster.
V mojom prípade bola zvolená táto cesta, použil som existujúce VPC, pridal som len 2 verejné podsiete a 2 privátne podsiete pre nový klaster, samozrejme boli zohľadnené všetky pravidlá podľa dokumentácie .
Bola tu tiež jedna podmienka: žiadne pracovné uzly vo verejných podsieťach používajúce EIP.
eksctl vs CloudFormation
Okamžite urobím výhradu, že som vyskúšal oba spôsoby nasadenia klastra, v oboch prípadoch bol obrázok rovnaký.
Ukážem príklad iba pomocou eksctl, pretože kód tu bude kratší. Pomocou eksctl nasaďte klaster v 3 krokoch:
1. Vytvoríme samotný klaster + pracovný uzol Linuxu, ktorý bude neskôr hostiť systémové kontajnery a ten istý nešťastný ovládač vpc.
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-networkingAk chcete nasadiť na existujúci VPC, stačí zadať ID vašich podsietí a eksctl určí VPC sám.
Aby ste zabezpečili, že vaše pracovné uzly budú nasadené iba do súkromnej podsiete, musíte pre skupinu uzlov zadať --node-private-networking.
2. Do nášho klastra nainštalujeme vpc-controller, ktorý bude následne spracovávať naše pracovné uzly, počítať počet voľných IP adries, ako aj počet ENI na inštancii, pridávať a odstraňovať ich.
eksctl utils install-vpc-controllers --name yyy --approve3. Po úspešnom spustení vašich systémových kontajnerov na vašom pracovnom uzle Linux, vrátane ovládača vpc, zostáva už len vytvoriť ďalšiu skupinu uzlov s pracovníkmi 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-networkingKeď sa váš uzol úspešne pripojí k vášmu klastru a všetko sa zdá byť v poriadku, je v stave Pripravené, ale nie.
Chyba v ovládači vpc
Ak sa pokúsime spustiť moduly na pracovnom uzle systému Windows, zobrazí sa chyba:
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]Ak sa pozrieme hlbšie, vidíme, že naša inštancia v AWS vyzerá takto:
A malo by to byť takto:
Z toho je zrejmé, že vpc-controller si z nejakého dôvodu nesplnil svoju časť a nemohol do inštancie pridať nové IP adresy, aby ich pody mohli využívať.
Pozrime sa na záznamy modulu vpc-controller a vidíme toto:
denník kubectl -n kube-systém
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.Hľadanie na Google k ničomu neviedlo, keďže očividne ešte nikto takúto chybu nezachytil, ani na ňu nenapísal problém, musel som si najprv premyslieť možnosti sám. Prvá vec, ktorá ma napadla, bola, že vpc-controller pravdepodobne nedokáže vyriešiť ip-10-xxx.ap-xxx.compute.internal a dosiahnuť ho, a preto sa vyskytujú chyby.
Áno, skutočne, vo VPC používame vlastné DNS servery a v zásade nepoužívame Amazonské, takže pre túto doménu ap-xxx.compute.internal nebolo nakonfigurované ani preposielanie. Túto možnosť som testoval a nepriniesla výsledky, možno test nebol čistý, a preto som ďalej pri komunikácii s technickou podporou podľahol ich nápadu.
Keďže v skutočnosti neexistovali žiadne nápady, všetky bezpečnostné skupiny vytvoril samotný eksctl, takže nebolo pochýb o ich použiteľnosti, správne boli aj tabuľky smerovania, nat, dns, bol tam aj prístup na internet s pracovnými uzlami.
Navyše, ak nasadíte pracovný uzol do verejnej podsiete bez použitia —node-private-networking, tento uzol bol okamžite aktualizovaný ovládačom vpc a všetko fungovalo ako hodinky.
Boli dve možnosti:
- Vzdajte to a počkajte, kým niekto túto chybu v AWS opíše a opraví, a potom môžete pokojne používať AWS EKS Windows, pretože práve vydali v GA (v čase písania tohto článku uplynulo 8 dní), mnohí pravdepodobne ísť rovnakou cestou ako ja.
- Napíšte na podporu AWS a povedzte im podstatu problému s množstvom logov odkiaľkoľvek a dokážte im, že ich služba nefunguje pri používaní vášho VPC a podsietí, nie nadarmo sme mali podporu podnikania, mali by ste použiť aspoň raz :)
Komunikácia s inžiniermi AWS
Po vytvorení tiketu na portáli som sa omylom rozhodol odpovedať mi cez web - e-mail alebo centrum podpory, prostredníctvom tejto možnosti vám môžu po niekoľkých dňoch odpovedať vôbec, napriek tomu, že môj tiket mal Závažnosť - Systém narušený, čo znamenalo odpoveď do <12 hodín, a keďže plán podpory podnikania má podporu 24 hodín denne, 7 dní v týždni, dúfal som v to najlepšie, ale dopadlo to ako vždy.
Môj lístok zostal od piatku do pondelka nepridelený, potom som sa rozhodol, že im znova napíšem a vybral som možnosť Chat odpoveď. Po krátkom čakaní bol za mnou určený Harshad Madhav a potom to začalo...
Ladili sme s ním online 3 hodiny v rade, prenášali sme protokoly, nasadzovali rovnaký klaster v laboratóriu AWS na emuláciu problému, znova sme klaster z mojej strany vytvorili atď., jediné, k čomu sme dospeli, je, že od v protokoloch bolo jasné, že rezol nefunguje AWS interné názvy domén, o ktorých som písal vyššie, a Harshad Madhav ma požiadal o vytvorenie presmerovania, údajne používame vlastné DNS a to by mohol byť problém.
presmerovanie
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)To sa stalo, deň sa skončil. Harshad Madhav napísal, aby to skontroloval a malo by to fungovať, ale nie, rozlíšenie vôbec nepomohlo.
Potom prebehla komunikácia s ďalšími 2 inžiniermi, jeden jednoducho vypadol z chatu, zrejme sa bál zložitého prípadu, druhý strávil môj deň opäť plným cyklom ladenia, posielania logov, vytvárania zhlukov na oboch stranách, v koniec len povedal dobre, mne to funguje, tu som Robím všetko krok za krokom v oficiálnej dokumentácii a vy aj vy uspejete.
Na čo som ho zdvorilo požiadal, aby odišiel a priradil k môjmu lístku niekoho iného, ak neviete, kde hľadať problém.
finále
Na tretí deň mi bol pridelený nový inžinier Arun B. a hneď od začiatku komunikácie s ním bolo jasné, že to nie sú 3 predchádzajúci inžinieri. Prečítal si celú históriu a okamžite požiadal o zhromaždenie protokolov pomocou vlastného skriptu na ps1, ktorý bol na jeho githube. Nasledovali opäť všetky iterácie vytvárania klastrov, výstup výsledkov príkazov, zbieranie logov, ale Arun B. sa podľa otázok, ktoré mi boli položené, uberal správnym smerom.
Kedy sme sa dostali k bodu povolenia -stderrthreshold=debug v ich ovládači vpc a čo sa stalo potom? samozrejme to nefunguje) modul jednoducho nezačne s touto možnosťou, funguje iba -stderrthreshold=info.
Tu sme skončili a Arun B. povedal, že sa pokúsi reprodukovať moje kroky, aby dostal rovnakú chybu. Nasledujúci deň som dostal odpoveď od Aruna B., ktorý neopustil tento prípad, ale prevzal kontrolný kód ich vpc-controllera a našiel miesto, kde to je a prečo to nefunguje:
Ak teda používate hlavnú smerovaciu tabuľku vo vašom VPC, potom štandardne nemá asociácie s potrebnými podsieťami, ktoré sú tak potrebné pre vpc-controller, v prípade verejnej podsiete má vlastnú smerovaciu tabuľku ktorá má asociáciu.
Manuálnym pridaním asociácií pre hlavnú smerovaciu tabuľku s potrebnými podsieťami a opätovným vytvorením skupiny uzlov všetko funguje perfektne.
Dúfam, že Arun B. túto chybu naozaj nahlási vývojárom EKS a dočkáme sa novej verzie vpc-controllera, kde bude všetko fungovať hneď po vybalení. Aktuálne je najnovšia verzia: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
má tento problém.
Ďakujem všetkým, ktorí dočítali až do konca, otestujte si pred implementáciou všetko, čo sa chystáte použiť vo výrobe.
Zdroj: hab.com