Dober dan, z vami želim deliti svojo izkušnjo pri nastavitvi in uporabi storitve AWS EKS (Elastic Kubernetes Service) za vsebnike Windows oziroma o nezmožnosti uporabe in napaki, najdeni v vsebniku sistema AWS, za tiste ki jih zanima ta storitev za Windows kontejnerje, prosim pod kat.
Vem, da Windows kontejnerji niso priljubljena tema in jih malo ljudi uporablja, vendar sem se vseeno odločil napisati ta članek, saj je bilo na Habréju nekaj člankov o kubernetesu in Windowsih in še vedno obstajajo takšni ljudje.
začenja
Vse se je začelo, ko smo se odločili, da storitve v našem podjetju preselimo na kubernetes, ki je 70 % Windows in 30 % Linux. V ta namen je bila kot ena od možnih možnosti obravnavana oblačna storitev AWS EKS. Do 8. oktobra 2019 je bil AWS EKS Windows v javnem predogledu, začel sem z njim, tam je bila uporabljena stara različica kubernetesa 1.11, a sem se odločil, da ga vseeno preverim in vidim, v kateri fazi je ta oblačna storitev, ali deluje sploh, kot se je izkazalo, ne, bila je napaka z dodatkom odstranjevanja podov, medtem ko so se stari nehali odzivati preko internega ip-ja iz istega podomrežja kot windows worker node.
Zato je bilo odločeno, da opustimo uporabo AWS EKS v korist lastnega grozda na kubernetesu na istem EC2, le da bi morali vsa uravnoteženja in HA opisati sami preko CloudFormation.
Podpora za Amazon EKS Windows Container je zdaj splošno na voljo
avtor Martin Beeby | dne 08. OKT 2019
Preden sem imel čas dodati predlogo v CloudFormation za svojo gručo, sem videl to novico
Seveda sem vse svoje delo pustil na strani in začel preučevati, kaj so storili za GA in kako se je vse spremenilo z javnim predogledom. Ja, AWS, dobro opravljeno, posodobil slike za windows worker node na različico 1.14, pa tudi samo gručo, različica 1.14 v EKS, zdaj podpira windows node. Projekt z javnim predogledom na To so zakrili in rekli, da zdaj uporabite uradno dokumentacijo tukaj:
Integracija gruče EKS v trenutni VPC in podomrežja
V vseh virih, na zgornji povezavi v objavi in v dokumentaciji, je bilo predlagano, da se gruče uvede prek lastniškega pripomočka eksctl ali prek CloudFormation + kubectl po tem, samo z uporabo javnih podomrežij v Amazonu, kot tudi ustvarjanje ločen VPC za novo gručo.
Ta možnost ni primerna za mnoge; prvič, ločen VPC pomeni dodatne stroške za svoje stroške + peering promet do vašega trenutnega VPC. Kaj naj storijo tisti, ki že imajo pripravljeno infrastrukturo v AWS z lastnimi računi Multiple AWS, VPC, podomrežji, tabelami poti, tranzitnim prehodom in tako naprej? Seveda ne želite vsega tega pokvariti ali ponoviti, zato morate novo gručo EKS integrirati v trenutno omrežno infrastrukturo z uporabo obstoječega VPC in za ločitev kvečjemu ustvariti nova podomrežja za gručo.
V mojem primeru je bila izbrana ta pot, uporabil sem obstoječi VPC, dodal samo 2 javni podomrežji in 2 zasebni podomrežji za novo gručo, seveda so bila upoštevana vsa pravila po dokumentaciji .
Obstajal je tudi en pogoj: brez delovnih vozlišč v javnih podomrežjih, ki uporabljajo EIP.
eksctl proti CloudFormation
Takoj bom rezerviral, da sem preizkusil oba načina uvajanja gruče, v obeh primerih je bila slika enaka.
Prikazal bom primer samo z uporabo eksctl, ker bo tukaj koda krajša. Z eksctl razmestite gručo v 3 korakih:
1. Ustvarimo samo gručo + delovno vozlišče Linuxa, ki bo kasneje gostilo sistemske vsebnike in ta isti nesrečni krmilnik 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-networkingZa namestitev v obstoječi VPC samo navedite ID svojih podomrežij in eksctl bo sam določil VPC.
Če želite zagotoviti, da so vaša delovna vozlišča razporejena samo v zasebno podomrežje, morate podati --node-private-networking za skupino vozlišč.
2. V našo gručo namestimo vpc-krmilnik, ki bo nato obdelal naša delovna vozlišča, pri čemer bo štel število prostih naslovov IP in število ENI-jev na instanci ter jih dodal in odstranil.
eksctl utils install-vpc-controllers --name yyy --approve3. Ko se vaši sistemski vsebniki uspešno zaženejo na delovnem vozlišču Linux, vključno z vpc-krmilnikom, je vse, kar ostane, ustvariti drugo skupino vozlišč z delavci 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-networkingKo se vaše vozlišče uspešno poveže z vašo gručo in se zdi, da je vse v redu, je v stanju pripravljenosti, vendar ne.
Napaka v krmilniku vpc
Če poskušamo zagnati pods v vozlišču Windows Worker, bomo dobili napako:
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]Če pogledamo globlje, vidimo, da je naš primerek v AWS videti takole:
In moralo bi biti takole:
Iz tega je razvidno, da vpc-krmilnik iz nekega razloga ni izpolnil svoje naloge in ni mogel dodati novih naslovov IP instanci, da bi jih pods lahko uporabljali.
Poglejmo dnevnike sklopa vpc-controller in vidimo tole:
dnevnik kubectl -n sistem kube
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.Iskanje v Googlu ni privedlo do ničesar, ker očitno še nihče ni ujel takšnega hrošča ali ni objavil težave na njem, sem moral najprej sam razmišljati o možnostih. Prva stvar, ki mi je prišla na misel, je bila, da morda vpc-krmilnik ne more razrešiti ip-10-xxx.ap-xxx.compute.internal in ga doseči, zato prihaja do napak.
Da, res, v VPC uporabljamo DNS strežnike po meri in Amazonovih načeloma ne uporabljamo, tako da tudi posredovanje ni bilo nastavljeno za to domeno ap-xxx.compute.internal. Preizkusil sem to možnost in ni prinesla rezultatov, morda test ni bil čist, zato sem nadalje, ko sem komuniciral s tehnično podporo, podlegel njihovi ideji.
Ker idej pravzaprav ni bilo, je vse varnostne skupine ustvaril sam eksctl, tako da ni bilo nobenega dvoma o njihovi uporabnosti, prav tako so bile route table pravilne, nat, dns, dostop do interneta z worker nodi je bil tudi tam.
Poleg tega, če uvedete delovno vozlišče v javno podomrežje brez uporabe —node-private-networking, je to vozlišče takoj posodobil krmilnik vpc in vse je delovalo kot po maslu.
Obstajali sta dve možnosti:
- Opustite in počakajte, da nekdo opiše to napako v AWS in jo popravi, nato pa lahko varno uporabljate AWS EKS Windows, ker so pravkar izdali v GA (8 dni je minilo v času pisanja tega članka), mnogi verjetno bodo sledite isti poti kot jaz.
- Pišite AWS podpori in jim povejte bistvo problema s celim kupom dnevnikov od vsepovsod in jim dokažite, da njihova storitev ne deluje, ko uporabljate vaš VPC in podomrežja, ni zaman, da smo imeli poslovno podporo, uporabite vsaj enkrat :)
Komunikacija z AWS inženirji
Po kreiranju tiketa na portalu sem pomotoma izbral, da mi odgovorijo preko spleta - e-pošte ali centra za podporo, prek te možnosti ti lahko sploh odgovorijo po nekaj dneh, kljub temu, da je imel moj tiket Resnost - System impaired, kar pomenilo odgovor v manj kot 12 urah, in ker ima načrt poslovne podpore podporo 24/7, sem upal na najboljše, a se je izkazalo kot vedno.
Moja prijava je ostala nedodeljena od petka do ponedeljka, nato pa sem se odločil, da jim ponovno pišem in izbral možnost odgovora prek klepeta. Po kratkem čakanju je bil Harshad Madhav imenovan, da me vidi, nato pa se je začelo...
Z njim smo 3 ure zapored odpravljali napake na spletu, prenašali dnevnike, uvedli isto gručo v laboratoriju AWS za posnemanje težave, ponovno ustvarili gručo z moje strani in tako naprej, edina stvar, do katere smo prišli, je, da iz iz dnevnikov je bilo jasno, da resol ne deluje z notranjimi domenskimi imeni AWS, o čemer sem pisal zgoraj, in Harshad Madhav me je prosil, naj ustvarim posredovanje, domnevno uporabljamo DNS po meri in to bi lahko bila težava.
Posredovanje
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)To je bilo storjeno, dan je mimo. Harshad Madhav je odgovoril, da bi preveril in bi moralo delovati, vendar ne, resolucija sploh ni pomagala.
Potem je prišlo do komunikacije s še 2 inženirjema, eden je preprosto izpadel iz klepeta, očitno se je bal zapletenega primera, drugi je spet preživel moj dan na polnem ciklu odpravljanja napak, pošiljanja dnevnikov, ustvarjanja grozdov na obeh straneh, v na koncu je samo rekel dobro, meni deluje, tukaj sem, naredim vse korak za korakom v uradni dokumentaciji in tebi in tebi bo uspelo.
Na kar sem ga vljudno prosil, naj odide in dodeli mojo karto nekomu drugemu, če ne veš, kje iskati težavo.
Končno
Tretji dan mi je bil dodeljen nov inženir Arun B. in že na samem začetku komunikacije z njim je bilo takoj jasno, da to niso 3 prejšnji inženirji. Prebral je celotno zgodovino in takoj prosil za zbiranje dnevnikov z lastnim skriptom na ps1, ki je bil na njegovem githubu. Sledile so spet vse iteracije ustvarjanja gruč, izpisovanja rezultatov ukazov, zbiranja dnevnikov, vendar je Arun B. šel v pravo smer sodeč po vprašanjih, ki so mi bila zastavljena.
Kdaj smo prišli do točke, ko smo omogočili -stderrthreshold=debug v njihovem krmilniku vpc in kaj se je zgodilo potem? seveda ne deluje) pod se preprosto ne zažene s to možnostjo, deluje samo -stderrthreshold=info.
Tukaj smo končali in Arun B. je rekel, da bo poskusil reproducirati moje korake, da bi dobil isto napako. Naslednji dan prejmem odgovor Aruna B. tega primera ni opustil, ampak je prevzel kodo za pregled njihovega krmilnika vpc in našel mesto, kjer je in zakaj ne deluje:
Torej, če uporabljate glavno tabelo poti v vašem VPC, potem privzeto nima povezav s potrebnimi podomrežji, ki so tako potrebna za krmilnik vpc, v primeru javnega podomrežja ima tabelo poti po meri ki ima asociacijo.
Z ročnim dodajanjem povezav za glavno tabelo poti s potrebnimi podomrežji in ponovnim ustvarjanjem skupine vozlišč vse deluje brezhibno.
Upam, da bo Arun B. res prijavil to napako razvijalcem EKS in bomo videli novo različico vpc-controllerja, kjer bo vse delovalo kot iz škatlice. Trenutno najnovejša različica je: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ima ta problem.
Hvala vsem, ki ste prebrali do konca, pred implementacijo testirajte vse, kar boste uporabljali v proizvodnji.
Vir: www.habr.com