Jó napot, szeretném megosztani veletek tapasztalataimat az AWS EKS (Elastic Kubernetes Service) Windows konténerekhez való beállításával és használatával kapcsolatban, vagy inkább használatának lehetetlenségéről, illetve az AWS rendszertárolóban talált hibáról azok számára akit érdekel ez a szolgáltatás Windows konténerekhez, kérjük, a kat.
Tudom, hogy a Windows konténerek nem egy népszerű téma, és kevesen használják őket, de mégis úgy döntöttem, hogy megírom ezt a cikket, mivel Habréról volt pár cikk a kubernetesről és a Windowsról, és még mindig vannak ilyen emberek.
kezdet
Az egész akkor kezdődött, amikor elhatározták, hogy cégünk szolgáltatásait átállítjuk a kubernetesre, ami 70%-ban Windows és 30%-ban Linux. Ebből a célból az AWS EKS felhőszolgáltatást tekintettük az egyik lehetséges lehetőségnek. 8. október 2019-ig az AWS EKS Windows Public Preview-ban volt, azzal kezdtem, ott a kubernetes régi 1.11-es verziója volt használva, de úgy döntöttem, mégis megnézem, és megnézem, melyik szakaszban van ez a felhőszolgáltatás, működik-e egyáltalán, mint kiderült, nem, ez egy hiba volt a podok eltávolításával, miközben a régiek nem válaszoltak belső IP-n keresztül ugyanarról az alhálózatról, mint a Windows Worker csomópont.
Ezért úgy döntöttünk, hogy felhagyunk az AWS EKS használatával, saját fürtünk helyett a kubernetes ugyanazon az EC2-n, csak nekünk magunknak kell leírnunk az összes kiegyensúlyozást és HA-t a CloudFormation segítségével.
Az Amazon EKS Windows Container támogatása már általánosan elérhető
szerző: Martin Beeby | 08. október 2019-án
Mielőtt volt időm hozzáadni egy sablont a CloudFormationhez a saját fürtömhöz, láttam ezt a hírt
Természetesen minden munkámat félretettem, és elkezdtem tanulmányozni, mit tettek a GA-nak, és hogyan változott meg minden a Public Preview segítségével. Igen, az AWS, jól sikerült, frissítette a Windows Worker csomóponthoz tartozó képeket az 1.14-es verzióra, valamint magát a fürtöt, az EKS 1.14-es verzióját, most már támogatja a Windows csomópontokat. Project by Public Preview at Elfedték, és azt mondták, most használd az itt található hivatalos dokumentációt:
EKS-fürt integrálása a jelenlegi VPC-be és alhálózatokba
Minden forrásban, a közlemény fenti linkjén és a dokumentációban javasolták a fürt telepítését vagy a szabadalmaztatott eksctl segédprogramon keresztül, vagy a CloudFormation + kubectl után, csak nyilvános alhálózatok használatával az Amazonban, valamint egy külön VPC-t egy új fürthöz.
Ez az opció sokak számára nem megfelelő; először is, egy külön VPC többletköltséget jelent a költségeihez + az aktuális VPC-hez való társítási forgalom. Mit tegyenek azok, akik már rendelkeznek kész infrastruktúrával az AWS-ben saját több AWS-fiókkal, VPC-vel, alhálózatokkal, útvonaltáblázatokkal, tranzitátjárókkal és így tovább? Természetesen mindezt nem akarja megtörni vagy újraépíteni, és az új EKS klasztert a meglévő hálózati infrastruktúrába kell integrálni, a meglévő VPC felhasználásával, és a szétválasztáshoz legfeljebb új alhálózatokat kell létrehozni a fürt számára.
Az én esetemben ezt az utat választottam, a meglévő VPC-t használtam, csak 2 nyilvános alhálózatot és 2 privát alhálózatot adtam hozzá az új klaszterhez, természetesen minden szabályt figyelembe vettek a dokumentáció szerint .
Volt egy feltétel is: az EIP-t használó nyilvános alhálózatokban nincs dolgozó csomópont.
exctl vs CloudFormation
Azonnal lefoglalom, hogy mindkét módszert kipróbáltam a fürt telepítésére, mindkét esetben ugyanaz volt a kép.
Csak az eksctl használatával mutatok be egy példát, mivel itt a kód rövidebb lesz. Az eksctl használatával telepítse a fürtöt 3 lépésben:
1. Létrehozzuk magát a fürtöt + Linux worker csomópontot, amely később rendszerkonténereket és ugyanazt a balszerencsés vpc-vezérlőt fogja tárolni.
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-networkingEgy meglévő VPC-re történő telepítéshez csak adja meg az alhálózatok azonosítóját, és az eksctl magát a VPC-t határozza meg.
Annak biztosításához, hogy a dolgozói csomópontok csak privát alhálózaton legyenek üzembe helyezve, meg kell adnia a --node-private-networking értéket a csomópontcsoporthoz.
2. Telepítjük a fürtünkbe a vpc-controllert, amely ezután feldolgozza a dolgozó csomópontjainkat, megszámolja a szabad IP-címek számát, valamint a példányon lévő ENI-k számát, hozzáadva és eltávolítva azokat.
eksctl utils install-vpc-controllers --name yyy --approve3. Miután a rendszerkonténerek sikeresen elindultak a Linux-munkás csomóponton, beleértve a vpc-vezérlőt is, már csak egy másik csomópontcsoport létrehozása marad a Windows dolgozóival.
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-networkingMiután a csomópont sikeresen csatlakozott a fürthöz, és úgy tűnik, hogy minden rendben van, kész állapotban van, de nem.
Hiba a vpc-vezérlőben
Ha megpróbáljuk a podokat futtatni egy Windows Worker csomóponton, a következő hibát kapjuk:
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]Ha mélyebben nézünk, azt látjuk, hogy az AWS-ben lévő példányunk így néz ki:
És ennek így kell lennie:
Ebből jól látszik, hogy a vpc-vezérlő valamiért nem teljesítette a rá eső részét, és nem tudott új IP címeket hozzáadni a példányhoz, hogy a podok használhassák azokat.
Nézzük meg a vpc-controller pod naplóit, és ezt látjuk:
kubectl napló -n kube-rendszer
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.A Google-ben végzett keresések nem vezettek semmire, mivel láthatóan még senki nem fogott el ilyen hibát, vagy nem írt rá problémát, először magamnak kellett átgondolnom a lehetőségeket. Az első dolog, ami eszembe jutott, az volt, hogy a vpc-vezérlő nem tudja feloldani és elérni az ip-10-xxx.ap-xxx.compute.internal fájlt, és ezért hibák lépnek fel.
Igen, valóban, egyedi DNS-szervereket használunk a VPC-ben, és elvileg nem használunk Amazon-szervereket, így ehhez az ap-xxx.compute.internal tartományhoz még a továbbítás sem volt konfigurálva. Kipróbáltam ezt az opciót, de nem hozott eredményt, talán nem volt tiszta a teszt, ezért a továbbiakban a technikai támogatással való kommunikáció során engedtem az ötletüknek.
Mivel nem igazán voltak ötletek, az összes biztonsági csoportot maga az eksctl hozta létre, így a szervizelhetőségükhöz nem férhetett kétség, az útvonaltáblázatok is korrektek voltak, nat, dns, munkavégző csomópontokkal internetelérés is megvolt.
Ezenkívül, ha a —node-private-networking használata nélkül telepít egy dolgozó csomópontot egy nyilvános alhálózatra, akkor ezt a csomópontot azonnal frissítette a vpc-vezérlő, és minden úgy működött, mint a karikacsapás.
Két lehetőség volt:
- Add fel, és várd meg, amíg valaki leírja ezt a hibát az AWS-ben és kijavítja, majd nyugodtan használhatod az AWS EKS Windows-t, mert most jelent meg GA-ban (8 nap telt el a cikk írásakor), valószínűleg sokan kövesse ugyanazt az utat, mint én.
- Írjon az AWS ügyfélszolgálatának, és mondja el nekik a probléma lényegét egy csomó naplóval mindenhonnan, és bizonyítsa be nekik, hogy a szolgáltatásuk nem működik a VPC és az alhálózatok használatakor, nem hiába volt üzleti támogatásunk, érdemes használni legalább egyszer :)
Kommunikáció az AWS mérnökeivel
Miután létrehoztam egy jegyet a portálon, tévedésből úgy döntöttem, hogy webes - e-mail vagy ügyfélszolgálati központon keresztül válaszolok nekem, ezen a lehetőségen keresztül néhány nap múlva egyáltalán tudnak válaszolni, annak ellenére, hogy a jegyem Súlyosság - Rendszer károsodott, ami 12 órán belüli választ jelentett, és mivel az Üzleti támogatási terv 24 órás támogatással rendelkezik, reméltem a legjobbakat, de most is úgy lett, mint mindig.
A jegyem péntektől hétfőig kiosztva maradt, majd úgy döntöttem, hogy újra írok nekik, és a Chat válaszlehetőséget választottam. Rövid várakozás után kinevezték Harshad Madhavot, hogy találkozzon velem, aztán elkezdődött...
Egymás után 3 órán keresztül hibakeresést végeztünk vele online, naplókat vittünk át, ugyanazt a fürtöt telepítettük az AWS-laboratóriumban a probléma emulálására, részemről újra létrehoztuk a fürtöt, és így tovább, csak arra jutottunk, hogy A naplókból egyértelműen kiderült, hogy a resol nem működik AWS belső domain nevekkel, amiről fentebb írtam, és Harshad Madhav megkért, hogy hozzak létre továbbítást, állítólag egyedi DNS-t használunk, és ez gond lehet.
Szállítmányozás
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Ez megtörtént, vége a napnak. Harshad Madhav visszaírt, hogy ellenőrizze, és működnie kell, de nem, a felbontás egyáltalán nem segített.
Aztán volt még 2 mérnökkel a kommunikáció, az egyik egyszerűen kiesett a chatből, láthatóan félt egy bonyolult esettől, a másik pedig ismét egy teljes cikluson töltötte a napomat a hibakereséssel, naplók küldésével, klaszterek létrehozásával mindkét oldalon, a vége csak azt mondta jól, nekem működik, itt vagyok én mindent lépésről lépésre megcsinálok a hivatalos dokumentációban és neked és neked sikerülni fog.
Amire udvariasan megkértem, hogy menjen el és rendeljen valaki mást a jegyemhez, ha nem tudja, hol keresse a problémát.
finálé
A harmadik napon egy új mérnököt, Arun B.-t rendeltek hozzám, akivel már a kommunikáció kezdetekor egyértelmű volt, hogy ez nem az előző 3 mérnök. Elolvasta a teljes előzményt, és azonnal kérte, hogy gyűjtse össze a naplókat a ps1-en lévő saját szkriptje segítségével, amely a githubon volt. Ezt ismét követte a fürtök létrehozásának, a parancseredmények kiadásának, a naplók gyűjtésének minden iterációja, de Arun B. a nekem feltett kérdések alapján jó irányba haladt.
Mikor jutottunk el odáig, hogy engedélyezzük a -stderrthreshold=debug funkciót a vpc-vezérlőjükben, és mi történt ezután? természetesen nem működik) a pod egyszerűen nem indul el ezzel az opcióval, csak a -stderrthreshold=info működik.
Itt befejeztük, és Arun B. azt mondta, hogy megpróbálja reprodukálni a lépéseimet, hogy ugyanazt a hibát kapja. Másnap választ kapok Arun B.-től, nem hagyta abba az ügyet, hanem elővette a vpc-vezérlőjük felülvizsgálati kódját, és megtalálta a helyet, ahol az van, és miért nem működik:
Így ha a fő útvonaltáblázatot használod a VPC-dben, akkor alapértelmezés szerint nincs asszociációja a szükséges alhálózatokkal, amelyek annyira szükségesek a vpc-vezérlőhöz, nyilvános alhálózat esetén egyedi útvonaltáblázattal rendelkezik. amelynek van társulása.
Ha manuálisan ad hozzá társításokat a fő útvonaltáblához a szükséges alhálózatokkal, és újra létrehozza a csomópontcsoportot, minden tökéletesen működik.
Remélem, hogy Arun B. valóban jelenteni fogja ezt a hibát az EKS fejlesztőinek, és látni fogjuk a vpc-vezérlő új verzióját, ahol minden a dobozból fog működni. Jelenleg a legújabb verzió: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
van ez a probléma.
Köszönet mindenkinek, aki a végéig elolvasta, tesztelje le mindazt, amit a termelésben használni fog a megvalósítás előtt.
Forrás: will.com