Laba diena, noriu pasidalinti su jumis savo patirtimi nustatant ir naudojant AWS EKS (Elastic Kubernetes Service) paslaugą, skirtą Windows konteineriams, arba, tiksliau, apie jos naudojimo negalimumą ir AWS sistemos konteineryje rastą klaidą tiems kurie domisi šia paslauga, skirta Windows konteineriams, prašome pagal kat.
Žinau, kad „Windows“ konteineriai nėra populiari tema, ir mažai žmonių jais naudojasi, bet aš vis tiek nusprendžiau parašyti šį straipsnį, nes buvo keletas straipsnių apie Habré apie „kubernetes“ ir „Windows“, ir tokių žmonių vis dar yra.
Pradėti
Viskas prasidėjo nuo to, kad mūsų įmonėje buvo nuspręsta paslaugas migruoti į kubernetes, kurios 70% yra Windows ir 30% Linux. Šiuo tikslu AWS EKS debesijos paslauga buvo svarstoma kaip vienas iš galimų variantų. Iki 8 m. spalio 2019 d. AWS EKS Windows buvo viešoje peržiūroje, pradėjau nuo jos, ten buvo naudojama senoji 1.11 kubernetes versija, bet vis tiek nusprendžiau patikrinti ir pažiūrėti, kokiame etape yra ši debesies paslauga, ar ji veikia iš viso, kaip paaiškėjo, ne, tai buvo klaida, kai buvo pašalintas pods, o senieji nustojo reaguoti per vidinį ip iš to paties potinklio kaip ir windows worker mazgas.
Todėl buvo nuspręsta atsisakyti AWS EKS naudojimo ir pasirinkti savo klasterį kubernetes tame pačiame EC2, tik mes patys turėsime aprašyti visą balansavimą ir HA per CloudFormation.
„Amazon EKS Windows“ konteinerių palaikymas dabar paprastai pasiekiamas
pateikė Martin Beeby | 08 m. spalio 2019 d
Dar nespėjęs pridėti šablono prie „CloudFormation“ savo klasteriui, pamačiau šią naujieną
Žinoma, atidėjau visą savo darbą ir pradėjau tyrinėti, ką jie padarė GA ir kaip viskas pasikeitė su vieša peržiūra. Taip, AWS, gerai padaryta, atnaujino Windows Worker mazgo vaizdus į 1.14 versiją, taip pat patį klasterį, 1.14 versiją EKS, dabar palaiko Windows mazgus. Projekto viešoji peržiūra adresu Jie tai uždengė ir pasakė, kad dabar naudokitės čia esančiais oficialiais dokumentais:
EKS klasterio integravimas į dabartinį VPC ir potinklius
Visuose šaltiniuose, aukščiau esančioje pranešimo nuorodoje ir dokumentacijoje, buvo pasiūlyta diegti klasterį per patentuotą eksctl įrankį arba per „CloudFormation + kubectl after“, tik naudojant viešuosius potinklius „Amazon“, taip pat sukurti atskiras VPC naujam klasteriui.
Ši parinktis daugeliui netinka; pirma, atskiras VPC reiškia papildomas išlaidas už jo kainą + srauto nukreipimą į dabartinį VPC. Ką turėtų daryti tie, kurie jau turi paruoštą AWS infrastruktūrą su savo keliomis AWS paskyromis, VPC, potinkliais, maršrutų lentelėmis, tranzito šliuzu ir pan.? Žinoma, nenorite viso to laužyti ar perdaryti, o naują EKS klasterį reikia integruoti į esamą tinklo infrastruktūrą, naudojant esamą VPC ir, norint atskirti, daugiausia sukurti naujus klasteriui skirtus potinklius.
Mano atveju pasirinktas toks kelias, naudojau esamą VPC, naujam klasteriui pridėjau tik 2 viešuosius potinklius ir 2 privačius potinklius, žinoma, buvo atsižvelgta į visas taisykles pagal dokumentaciją .
Taip pat buvo viena sąlyga: viešuosiuose potinkluose, naudojantys EIP, nėra darbuotojų mazgų.
eksctl vs CloudFormation
Iš karto padarysiu išlygą, kad išbandžiau abu klasterio diegimo būdus, abiem atvejais vaizdas buvo toks pat.
Aš parodysiu pavyzdį tik naudodamas eksctl, nes kodas čia bus trumpesnis. Naudodami eksctl įdiekite klasterį 3 veiksmais:
1. Sukuriame patį klasterį + Linux darbuotojo mazgą, kuris vėliau priglobs sistemos konteinerius ir tą patį nelaimingą vpc valdiklį.
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-networkingNorėdami įdiegti esamame VPC, tiesiog nurodykite savo potinklių ID, o eksctl nustatys patį VPC.
Norėdami užtikrinti, kad jūsų darbuotojų mazgai būtų įdiegti tik privačiame potinklyje, mazgų grupei turite nurodyti --node-private-networking.
2. Savo klasteryje įdiegiame vpc-valdiklį, kuris apdoros mūsų darbuotojų mazgus, skaičiuos nemokamų IP adresų skaičių, taip pat egzemplioriaus ENI skaičių, juos pridės ir pašalins.
eksctl utils install-vpc-controllers --name yyy --approve3. Sėkmingai paleidus sistemos konteinerius Linux darbuotojo mazge, įskaitant vpc valdiklį, belieka sukurti kitą mazgų grupę su Windows darbuotojais.
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-networkingKai mazgas sėkmingai prisijungė prie klasterio ir atrodo, kad viskas gerai, jo būsena yra parengta, bet ne.
Klaida vpc valdiklyje
Jei bandysime paleisti blokus „Windows Worker“ mazge, gausime klaidą:
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]Jei pažvelgsime giliau, pamatysime, kad mūsų pavyzdys AWS atrodo taip:
Ir turėtų būti taip:
Iš to aišku, kad vpc-valdiklis dėl kokių nors priežasčių neatliko savo dalies ir negalėjo prie egzemplioriaus pridėti naujų IP adresų, kad podai galėtų juos naudoti.
Pažvelkime į vpc-controller pod žurnalus ir štai ką matome:
kubectl žurnalas -n kube sistema
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.Paieškos „Google“ nieko nedavė, nes, matyt, tokios klaidos dar niekas nebuvo užfiksavęs arba nepaskelbė problemos, pirmiausia turėjau galvoti apie variantus. Pirmas dalykas, kuris atėjo į galvą, buvo tai, kad galbūt vpc valdiklis negali išspręsti ip-10-xxx.ap-xxx.compute.internal ir jo pasiekti, todėl atsiranda klaidų.
Taip, tikrai, VPC naudojame pasirinktinius DNS serverius ir iš esmės nenaudojame Amazon, todėl net persiuntimas nebuvo sukonfigūruotas šiam ap-xxx.compute.internal domenui. Išbandžiau šį variantą, ir jis nedavė rezultatų, galbūt testas nebuvo švarus, todėl toliau bendraudamas su technine pagalba pasidaviau jų idėjai.
Kadangi idėjų tikrai nebuvo, visas saugumo grupes kūrė pats eksctl, tad dėl jų aptarnavimo abejonių nekilo, maršrutų lentelės irgi buvo teisingos, nat, dns, interneto prieiga su worker mazgais taip pat buvo.
Be to, jei darbuotojo mazgą diegiate viešajame potinklyje nenaudodami —node-private-networking, šį mazgą iš karto atnaujino vpc valdiklis ir viskas veikė kaip laikrodis.
Buvo du variantai:
- Atsisakykite ir palaukite, kol kas nors aprašys šią AWS klaidą ir ją ištaisys, o tada galėsite saugiai naudoti AWS EKS Windows, nes jie ką tik išleisti GA (šio straipsnio rašymo metu praėjo 8 dienos), tikriausiai daugelis eik tuo pačiu keliu kaip aš.
- Parašykite AWS palaikymo tarnybai ir pasakykite jiems problemos esmę su daugybe žurnalų iš visur ir įrodykite, kad jų paslauga neveikia naudojant jūsų VPC ir potinklius, ne veltui turėjome verslo palaikymą, turėtumėte naudoti bent kartą :)
Bendravimas su AWS inžinieriais
Portale susikūręs bilietą, klaidingai pasirinkau atsakyti man per internetą – el. paštą arba pagalbos centrą, per šią parinktį jie gali jums atsakyti po kelių dienų, nepaisant to, kad mano biliete buvo sutrikęs sunkumas – sistema, kuri reiškė atsakymą per <12 valandų, o kadangi Verslo palaikymo plane yra 24/7 palaikymas, tikėjausi geriausio, bet išėjo kaip visada.
Mano bilietas liko nepriskirtas nuo penktadienio iki pirmadienio, tada nusprendžiau dar kartą jiems parašyti ir pasirinkau atsakymo į pokalbį variantą. Truputį palaukęs Harshadas Madhavas buvo paskirtas susitikti su manimi, ir tada prasidėjo...
Derinome su juo internete 3 valandas iš eilės, perkeldami žurnalus, diegdami tą patį klasterį AWS laboratorijoje, kad pamėgintume problemą, iš mano pusės kūrėme klasterį ir t. t., vienintelis dalykas, prie kurio priėjome, yra žurnaluose buvo aišku, kad resol neveikia AWS vidiniai domenų vardai, apie kuriuos rašiau aukščiau, o Harshad Madhav paprašė sukurti persiuntimą, tariamai mes naudojame pasirinktinį DNS ir tai gali būti problema.
Persiuntimas
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Štai kas buvo padaryta, diena baigėsi. Harshadas Madhavas atrašė, kad patikrintų ir turėtų veikti, bet ne, rezoliucija visiškai nepadėjo.
Tada buvo bendraujama su dar 2 inžinieriais, vienas tiesiog iškrito iš pokalbio, matyt, bijojo sudėtingo atvejo, antrasis vėl praleido visą dieną derindamas, siuntinėdamas žurnalus, kurdamas klasterius iš abiejų pusių, pabaiga jis tik pasakė gerai, man tai veikia, štai aš darau viską žingsnis po žingsnio oficialioje dokumentacijoje ir tau ir tau pavyks.
Į ką mandagiai paprašiau išeiti ir priskirti ką nors kitą prie mano bilieto, jei nežinai, kur ieškoti problemos.
Finalas
Trečią dieną man buvo paskirtas naujas inžinierius Arūnas B. ir nuo pat bendravimo su juo pradžios iš karto buvo aišku, kad tai ne 3 ankstesni inžinieriai. Jis perskaitė visą istoriją ir iš karto paprašė surinkti žurnalus naudodamas savo scenarijų ps1, kuris buvo jo github. Po to vėl sekė visos klasterių kūrimo, komandų rezultatų išvedimo, žurnalų rinkimo iteracijos, bet Arunas B. judėjo teisinga linkme, sprendžiant iš man užduodamų klausimų.
Kada jų vpc-valdiklyje įgalinome -stderrthreshold=debug ir kas nutiko toliau? žinoma, tai neveikia) blokas tiesiog neprasideda su šia parinktimi, veikia tik -stderrthreshold=info.
Baigėme čia ir Arūnas B. pasakė, kad bandys atkurti mano žingsnius, kad gautų tą pačią klaidą. Kitą dieną gaunu atsakymą iš Arūno B. jis neatsisakė šios bylos, bet paėmė jų vpc-valdiklio peržiūros kodą ir surado vietą, kur jis yra ir kodėl neveikia:
Taigi, jei naudojate pagrindinę maršruto lentelę savo VPC, tada pagal numatytuosius nustatymus ji neturi sąsajų su reikalingais potinkliais, kurie taip reikalingi vpc valdikliui, o viešo potinklio atveju jis turi pasirinktinę maršruto lentelę kuri turi asociaciją.
Rankiniu būdu pridedant asociacijas pagrindinei maršruto lentelei su reikalingais potinkliais ir iš naujo sukūrus mazgų grupę, viskas veikia puikiai.
Tikiuosi, kad Arunas B. tikrai praneš apie šią klaidą EKS kūrėjams ir pamatysime naują vpc-controller versiją, kurioje viskas veiks iš karto. Šiuo metu naujausia versija yra: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
turi šią problemą.
Dėkojame visiems, kurie perskaitė iki galo, prieš įdiegdami išbandykite viską, ką ketinate naudoti gamyboje.
Šaltinis: www.habr.com