Dobré odpoledne, chci se s vámi podělit o své zkušenosti s nastavením a používáním služby AWS EKS (Elastic Kubernetes Service) pro kontejnery Windows, respektive o nemožnosti jejího použití a o chybě nalezené v kontejneru systému AWS, pro ty kdo má zájem o tuto službu pro kontejnery Windows, prosím pod kat.
Vím, že kontejnery pro Windows nejsou oblíbené téma a málokdo je používá, ale i tak jsem se rozhodl napsat tento článek, jelikož na Habré na kubernetes a Windows bylo pár článků a takoví stále jsou.
začátek
Vše začalo, když bylo rozhodnuto o migraci služeb v naší společnosti na kubernetes, což je ze 70 % Windows a 30 % Linux. Pro tento účel byla jako jedna z možných variant zvažována cloudová služba AWS EKS. Do 8. října 2019 byla AWS EKS Windows ve Public Preview, začínal jsem s ní, používala se tam stará verze kubernetes 1.11, ale rozhodl jsem se to přesto zkontrolovat a podívat se, v jaké fázi tato cloudová služba byla, zda funguje vůbec, jak se ukázalo, ne, byla tam chyba s přidáním odstraňování podů, zatímco ty staré přestaly reagovat přes interní ip ze stejné podsítě jako uzel windows worker.
Proto bylo rozhodnuto opustit používání AWS EKS ve prospěch vlastního clusteru na kubernetes na stejném EC2, jen bychom si veškeré balancování a HA museli popsat sami přes CloudFormation.
Podpora Amazon EKS Windows Container je nyní obecně dostupná
od Martina Beebyho | dne 08. října 2019
Než jsem stačil přidat šablonu do CloudFormation pro svůj vlastní cluster, viděl jsem tuto novinku
Samozřejmě jsem odložil všechnu svou práci a začal jsem studovat, co udělali pro GA a jak se vše změnilo s Public Preview. Ano, AWS, výborně, aktualizoval obrázky pro pracovní uzel Windows na verzi 1.14, stejně jako samotný cluster, verze 1.14 v EKS, nyní podporuje uzly Windows. Project by Public Preview at Zakryli to a řekli, že nyní použijte oficiální dokumentaci zde:
Integrace clusteru EKS do aktuálních VPC a podsítí
Ve všech zdrojích, ve výše uvedeném odkazu na oznámení i v dokumentaci, bylo navrženo nasazení clusteru buď prostřednictvím proprietárního nástroje eksctl, nebo pomocí CloudFormation + kubectl after, pouze pomocí veřejných podsítí v Amazonu, stejně jako vytvoření samostatné VPC pro nový cluster.
Tato možnost není pro mnohé vhodná, za prvé, samostatný VPC znamená dodatečné náklady na jeho cenu + peeringový provoz na váš aktuální VPC. Co by měli dělat ti, kteří již mají připravenou infrastrukturu v AWS s vlastními účty Multiple AWS, VPC, podsítěmi, směrovacími tabulkami, tranzitní bránou a tak dále? Samozřejmě toto všechno nechcete rozbíjet nebo předělávat a potřebujete integrovat nový cluster EKS do aktuální síťové infrastruktury pomocí stávajícího VPC a pro oddělení nanejvýš vytvořit nové podsítě pro cluster.
V mém případě byla zvolena tato cesta, použil jsem stávající VPC, přidal pouze 2 veřejné podsítě a 2 privátní podsítě pro nový cluster, samozřejmě byla zohledněna všechna pravidla dle dokumentace .
Byla zde také jedna podmínka: žádné pracovní uzly ve veřejných podsítích používajících EIP.
eksctl vs CloudFormation
Okamžitě udělám výhradu, že jsem vyzkoušel oba způsoby nasazení clusteru, v obou případech byl obrázek stejný.
Ukážu příklad pouze pomocí eksctl, protože kód zde bude kratší. Pomocí eksctl nasaďte cluster ve 3 krocích:
1. Vytvoříme samotný cluster + pracovní uzel Linuxu, který bude později hostovat systémové kontejnery a ten samý nešťastný 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-networkingChcete-li nasadit na existující VPC, stačí zadat ID vašich podsítí a eksctl určí VPC sám.
Chcete-li zajistit, aby byly vaše pracovní uzly nasazeny pouze do soukromé podsítě, musíte pro skupinu uzlů zadat --node-private-networking.
2. Do našeho clusteru nainstalujeme vpc-controller, který bude následně zpracovávat naše pracovní uzly, počítat počet volných IP adres a také počet ENI na instanci, přidávat a odebírat je.
eksctl utils install-vpc-controllers --name yyy --approve3. Poté, co se vaše systémové kontejnery úspěšně spustily na vašem pracovním uzlu Linux, včetně řadiče vpc, zbývá pouze vytvořit další skupinu uzlů s pracovníky systému 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-networkingPoté, co se váš uzel úspěšně připojil k vašemu clusteru a vše se zdá být v pořádku, je ve stavu Připraveno, ale ne.
Chyba v řadiči vpc
Pokud se pokusíme spustit moduly na pracovním uzlu systému Windows, zobrazí se 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]Pokud se podíváme hlouběji, vidíme, že naše instance v AWS vypadá takto:
A mělo by to být takto:
Z toho je jasné, že vpc-controller z nějakého důvodu nesplnil svou část a nemohl do instance přidat nové IP adresy, aby je pody mohly používat.
Podívejme se na protokoly modulu vpc-controller a vidíme toto:
kubectl log -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.Vyhledávání na Googlu k ničemu nevedlo, protože takovou chybu zřejmě ještě nikdo nezachytil nebo na ni nenapsal problém, musel jsem si nejprve promyslet možnosti sám. První, co mě napadlo, bylo, že vpc-controller možná nedokáže vyřešit ip-10-xxx.ap-xxx.compute.internal a dostat se k němu, a proto dochází k chybám.
Ano, skutečně používáme vlastní DNS servery ve VPC a v zásadě nepoužíváme Amazonské, takže pro tuto doménu ap-xxx.compute.internal nebylo nakonfigurováno ani přesměrování. Tuto možnost jsem testoval a nepřinesla výsledky, možná test nebyl čistý, a proto jsem dále při komunikaci s technickou podporou podlehl jejich nápadu.
Protože ve skutečnosti nebyly žádné nápady, všechny bezpečnostní skupiny vytvořil eksctl sám, takže o jejich provozuschopnosti nebylo pochyb, směrovací tabulky byly také správné, nat, dns, byl tam také přístup k internetu s pracovními uzly.
Navíc, pokud nasadíte pracovní uzel do veřejné podsítě bez použití —node-private-networking, tento uzel byl okamžitě aktualizován řadičem vpc a vše fungovalo jako hodinky.
Byly dvě možnosti:
- Vzdejte to a počkejte, až někdo popíše tuto chybu v AWS a opraví ji, a pak můžete klidně používat AWS EKS Windows, protože právě vydali v GA (uběhlo 8 dní v době psaní tohoto článku), mnozí pravděpodobně jít stejnou cestou jako já.
- Napište na podporu AWS a řekněte jim podstatu problému s celou hromadou logů odkudkoli a dokažte jim, že jejich služba nefunguje při použití vašich VPC a podsítí, ne nadarmo jsme měli podporu podnikání, měli byste použít aspoň jednou :)
Komunikace s inženýry AWS
Po vytvoření tiketu na portálu jsem se omylem rozhodl odpovědět mi přes web - e-mail nebo centrum podpory, prostřednictvím této možnosti vám mohou po několika dnech vůbec odpovědět, a to i přesto, že můj tiket měl Závažnost - Zhoršený systém, což znamenalo odpověď do <12 hodin, a protože plán podpory podnikání má podporu 24/7, doufal jsem v nejlepší, ale dopadlo to jako vždy.
Můj tiket zůstal od pátku do pondělí nezadaný, pak jsem se rozhodl jim napsat znovu a zvolil jsem možnost Odpověď na chat. Po krátkém čekání byl Harshad Madhav jmenován, aby mě navštívil, a pak to začalo...
Ladili jsme s ním online 3 hodiny v řadě, přenášeli jsme protokoly, nasazovali stejný cluster v laboratoři AWS, abychom problém napodobili, znovu vytvořili cluster z mé strany a tak dále, jediné, k čemu jsme dospěli, je, že od z logů bylo jasné, že resol nefunguje AWS interní názvy domén, o kterých jsem psal výše, a Harshad Madhav mě požádal o vytvoření přesměrování, údajně používáme vlastní DNS a to by mohl být problém.
Přesměrování
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)To se stalo, den skončil. Harshad Madhav odepsal, aby to zkontroloval a mělo by to fungovat, ale ne, rozlišení vůbec nepomohlo.
Pak proběhla komunikace s dalšími 2 inženýry, jeden prostě vypadl z chatu, zřejmě se bál složitého případu, druhý strávil můj den opět plným cyklem ladění, odesílání logů, vytváření clusterů na obou stranách, v konec jen řekl dobře, funguje mi to, tady jsem Dělám vše krok za krokem v oficiální dokumentaci a vy i vy uspějete.
Na což jsem ho zdvořile požádal, aby odešel a přidělil mi někoho jiného, pokud nevíte, kde hledat problém.
Konečný
Třetí den mi byl přidělen nový inženýr Arun B. a od samého začátku komunikace s ním bylo hned jasné, že to nejsou 3 předchozí inženýři. Přečetl si celou historii a okamžitě požádal o sběr protokolů pomocí vlastního skriptu na ps1, který byl na jeho githubu. Následovaly opět všechny iterace vytváření clusterů, výstup výsledků příkazů, shromažďování logů, ale Arun B. se podle otázek, které mi byly kladeny, ubíral správným směrem.
Kdy jsme se dostali do bodu povolení -stderrthreshold=debug v jejich vpc-controlleru a co se stalo potom? samozřejmě to nefunguje) pod touto volbou jednoduše nezačíná, funguje pouze -stderrthreshold=info.
Skončili jsme tady a Arun B. řekl, že se pokusí reprodukovat moje kroky, aby dostal stejnou chybu. Následující den dostávám odpověď od Aruna B., který tento případ neopustil, ale vzal si kontrolní kód jejich vpc-controlleru a našel místo, kde to je a proč to nefunguje:
Pokud tedy ve svém VPC používáte hlavní směrovací tabulku, pak ve výchozím nastavení nemá asociace s potřebnými podsítěmi, které jsou pro vpc-controller tak nutné, v případě veřejné podsítě má vlastní směrovací tabulku která má asociaci.
Ručním přidáním asociací pro hlavní směrovací tabulku s nezbytnými podsítěmi a opětovným vytvořením skupiny uzlů vše funguje perfektně.
Doufám, že Arun B. opravdu nahlásí tuto chybu vývojářům EKS a dočkáme se nové verze vpc-controlleru, kde bude vše fungovat hned po vybalení. Aktuálně nejnovější verze je: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
má tento problém.
Díky všem, kteří dočetli až do konce, otestujte si před implementací vše, co budete ve výrobě používat.
Zdroj: www.habr.com