Labdien, es vÄlos dalÄ«ties ar jums savÄ pieredzÄ par pakalpojuma AWS EKS (Elastic Kubernetes Service) iestatÄ«Å”anu un lietoÅ”anu Windows konteineriem vai drÄ«zÄk par tÄ izmantoÅ”anas neiespÄjamÄ«bu un AWS sistÄmas konteinerÄ atrasto kļūdu tiem. kam interesÄ Å”is pakalpojums Windows konteineriem, lÅ«dzu zem kat.
Es zinu, ka Windows konteineri nav populÄra tÄma, un daži cilvÄki tos izmanto, taÄu es tomÄr nolÄmu uzrakstÄ«t Å”o rakstu, jo par kubernetes un Windows bija pÄris raksti par HabrĆ©, un joprojÄm ir tÄdi cilvÄki.
sÄkums
Viss sÄkÄs, kad tika nolemts mÅ«su uzÅÄmumÄ pakalpojumus migrÄt uz kubernetes, kas ir 70% Windows un 30% Linux. Å im nolÅ«kam kÄ viens no iespÄjamajiem variantiem tika izskatÄ«ts AWS EKS mÄkoÅpakalpojums. LÄ«dz 8. gada 2019. oktobrim AWS EKS Windows bija publiskajÄ priekÅ”skatÄ«jumÄ, sÄku ar to, tur tika izmantota vecÄ kubernetes 1.11 versija, bet nolÄmu tomÄr pÄrbaudÄ«t un paskatÄ«ties, kurÄ stadijÄ ir Å”is mÄkoÅpakalpojums, vai strÄdÄ. vispÄr, kÄ izrÄdÄ«jÄs, nÄ, tÄ bija kļūda, pievienojot noÅemÅ”anu podiem, savukÄrt vecie pÄrstÄja reaÄ£Ät caur iekÅ”Äjo ip no tÄ paÅ”a apakÅ”tÄ«kla, kur windows worker mezgls.
TÄpÄc tika nolemts atteikties no AWS EKS izmantoÅ”anas par labu mÅ«su paÅ”u klasterim uz kubernetes tajÄ paÅ”Ä EC2, tikai mums paÅ”iem bÅ«tu jÄapraksta visa balansÄÅ”ana un HA, izmantojot CloudFormation.
Amazon EKS Windows konteineru atbalsts tagad parasti ir pieejams
autors Martin Beeby | 08. gada 2019. oktobrī
Pirms man bija laiks pievienot CloudFormation veidni savam klasterim, es redzÄju Ŕīs ziÅas
Protams, es atliku visu savu darbu un sÄku pÄtÄ«t, ko viÅi darÄ«ja GA labÄ un kÄ viss mainÄ«jÄs ar publisko priekÅ”skatÄ«jumu. JÄ, AWS, labi darÄ«ts, atjauninÄja Windows Worker mezgla attÄlus uz versiju 1.14, kÄ arÄ« pats klasteris, EKS versija 1.14, tagad atbalsta Windows mezglus. Project by Public Preview plkst ViÅi to piesedza un teica, ka tagad izmantojiet oficiÄlo dokumentÄciju Å”eit:
EKS klastera integrÄÅ”ana paÅ”reizÄjÄ VPC un apakÅ”tÄ«klos
Visos avotos iepriekÅ” norÄdÄ«tajÄ saitÄ uz paziÅojumu, kÄ arÄ« dokumentÄcijÄ tika ierosinÄts izvietot klasteru, izmantojot patentÄto eksctl utilÄ«tu vai CloudFormation + kubectl after, tikai izmantojot publiskos apakÅ”tÄ«klus pakalpojumÄ Amazon, kÄ arÄ« izveidojot atseviŔķa VPC jaunam klasterim.
Å Ä« opcija nav piemÄrota daudziem; pirmkÄrt, atseviŔķs VPC nozÄ«mÄ papildu izmaksas par tÄ izmaksÄm + trafika savienoÅ”anu ar paÅ”reizÄjo VPC. Kas jÄdara tiem, kuriem jau ir gatava AWS infrastruktÅ«ra ar saviem vairÄkiem AWS kontiem, VPC, apakÅ”tÄ«kliem, marÅ”ruta tabulÄm, tranzÄ«ta vÄrteju un tÄ tÄlÄk? Protams, jÅ«s nevÄlaties to visu lauzt vai pÄrtaisÄ«t, un jaunais EKS klasteris ir jÄintegrÄ paÅ”reizÄjÄ tÄ«kla infrastruktÅ«rÄ, izmantojot esoÅ”o VPC un atdalÄ«Å”anai, ne vairÄk kÄ, izveidojot klasterim jaunus apakÅ”tÄ«klus.
ManÄ gadÄ«jumÄ tika izvÄlÄts Å”Äds ceļŔ, es izmantoju esoÅ”o VPC, pievienoju tikai 2 publiskos apakÅ”tÄ«klus un 2 privÄtos apakÅ”tÄ«klus jaunajam klasterim, protams, visi noteikumi tika Åemti vÄrÄ saskaÅÄ ar dokumentÄciju .
Bija arī viens nosacījums: publiskajos apakŔtīklos, kas izmanto EIP, nav darbinieku mezglu.
eksctl vs CloudFormation
Es uzreiz izdarÄ«Å”u atrunu, ka izmÄÄ£inÄju abas klastera izvietoÅ”anas metodes, abos gadÄ«jumos attÄls bija vienÄds.
Es parÄdÄ«Å”u piemÄru, izmantojot tikai eksctl, jo kods Å”eit bÅ«s Ä«sÄks. Izmantojot eksctl, izvietojiet klasteru trÄ«s darbÄ«bÄs:
1. MÄs izveidojam paÅ”u klasteru + Linux darbinieka mezglu, kas vÄlÄk uzÅems sistÄmas konteinerus un to paÅ”u neveiksmÄ«go vpc kontrolieri.
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-networkingLai izvietotu esoÅ”Ä VPC, vienkÄrÅ”i norÄdiet savu apakÅ”tÄ«klu ID, un eksctl noteiks paÅ”u VPC.
Lai nodroÅ”inÄtu, ka jÅ«su darbinieka mezgli tiek izvietoti tikai privÄtÄ apakÅ”tÄ«klÄ, mezglu grupai ir jÄnorÄda --node-private-networking.
2. MÄs savÄ klasterÄ« instalÄjam vpc-controller, kas pÄc tam apstrÄdÄs mÅ«su darbinieku mezglus, saskaitot brÄ«vo IP adreÅ”u skaitu, kÄ arÄ« ENI skaitu instancÄ, pievienojot un noÅemot tos.
eksctl utils install-vpc-controllers --name yyy --approve3.PÄc tam, kad jÅ«su sistÄmas konteineri ir veiksmÄ«gi palaisti jÅ«su Linux darbinieka mezglÄ, ieskaitot vpc kontrolieri, atliek tikai izveidot citu mezglu grupu ar Windows darbiniekiem.
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-networkingKad mezgls ir veiksmÄ«gi izveidojis savienojumu ar jÅ«su kopu un Ŕķiet, ka viss ir kÄrtÄ«bÄ, tas ir statusÄ Gatavs, bet nÄ.
Kļūda vpc kontrolierī
Ja mÄÄ£inÄsim palaist pods uz Windows Worker mezgla, mÄs saÅemsim kļūdu:
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]Ja skatÄmies dziļÄk, mÄs redzam, ka mÅ«su gadÄ«jums AWS izskatÄs Å”Ädi:
Un tam vajadzÄtu bÅ«t Å”Ädi:
No tÄ ir skaidrs, ka vpc kontrolieris kÄdu iemeslu dÄļ neizpildÄ«ja savu daļu un nevarÄja pievienot instancÄ jaunas IP adreses, lai podi varÄtu tÄs izmantot.
ApskatÄ«sim vpc-controller pod žurnÄlus, un tas ir tas, ko mÄs redzam:
kubectl žurnÄls -n kube-sistÄma
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.MeklÄÅ”ana Google ne pie kÄ nedeva, jo acÄ«mredzot neviens vÄl nebija pieÄ·Äris Å”Ädu kļūdu vai nebija publicÄjis problÄmu, vispirms nÄcÄs izdomÄt iespÄjas paÅ”am. PirmÄ lieta, kas ienÄca prÄtÄ, bija tÄda, ka, iespÄjams, vpc kontrolieris nevar atrisinÄt ip-10-xxx.ap-xxx.compute.internal un sasniegt to, un tÄpÄc rodas kļūdas.
JÄ, patieÅ”Äm, mÄs VPC izmantojam pielÄgotus DNS serverus un principÄ neizmantojam Amazon, tÄpÄc pat pÄrsÅ«tÄ«Å”ana netika konfigurÄta Å”im ap-xxx.compute.internal domÄnam. IzmÄÄ£inÄju Å”o variantu, un tas nedeva rezultÄtus, iespÄjams, tests nebija tÄ«rs, un tÄpÄc tÄlÄk, sazinoties ar tehnisko atbalstu, padevos viÅu idejai.
TÄ kÄ ideju Ä«sti nebija, visas droŔības grupas veidoja pats eksctl, tÄpÄc par to apkalpojamÄ«bu Å”aubu nebija, marÅ”ruta tabulas arÄ« bija pareizas, nat, dns, interneta pieeja ar worker node arÄ« bija.
TurklÄt, ja izvietojat darbinieka mezglu publiskajÄ apakÅ”tÄ«klÄ, neizmantojot ānode-private-networking, vpc kontrolieris nekavÄjoties atjauninÄja Å”o mezglu, un viss darbojÄs kÄ pulkstenis.
Bija divas iespÄjas:
- Atmet un pagaidi, kamÄr kÄds aprakstÄ«s Å”o kļūdu AWS un to izlabos, un tad vari droÅ”i lietot AWS EKS Windows, jo viÅi tikko izlaida GA (Ŕī raksta tapÅ”anas brÄ«dÄ« ir pagÄjuÅ”as 8 dienas), iespÄjams, daudzi to darÄ«s ej pa to paÅ”u ceļu kÄ es.
- Rakstiet AWS atbalsta dienestam un pastÄstiet viÅiem problÄmas bÅ«tÄ«bu ar veselu kaudzi žurnÄlu no jebkuras vietas un pierÄdiet viÅiem, ka viÅu pakalpojums nedarbojas, izmantojot jÅ«su VPC un apakÅ”tÄ«klus, ne velti mums bija biznesa atbalsts, jums vajadzÄtu izmantot tÄ vismaz vienu reizi :)
SaziÅa ar AWS inženieriem
Izveidojot biļeti portÄlÄ, es kļūdaini izvÄlÄjos atbildÄt man caur Web - e-pastu vai atbalsta centru, caur Å”o iespÄju viÅi var jums atbildÄt pÄc dažÄm dienÄm, neskatoties uz to, ka manai biļetei bija Smaguma pakÄpe - sistÄma ir traucÄta, nozÄ«mÄja atbildi <12 stundu laikÄ, un tÄ kÄ Biznesa atbalsta plÄnÄ ir 24/7 atbalsts, tad cerÄju uz to labÄko, bet sanÄca kÄ vienmÄr.
Mana biļete tika atstÄta nepieŔķirta no piektdienas lÄ«dz pirmdienai, tad nolÄmu viÅiem vÄlreiz uzrakstÄ«t un izvÄlÄjos atbildes opciju Chat. PÄc neilgas gaidÄ«Å”anas pie manis tika nozÄ«mÄts Harshads Madhavs, un tad sÄkÄs...
MÄs ar to atkļūdojÄm tieÅ”saistÄ 3 stundas pÄc kÄrtas, pÄrsÅ«tot žurnÄlus, izvietojot to paÅ”u klasteru AWS laboratorijÄ, lai emulÄtu problÄmu, no manas puses izveidojÄm klasteru no jauna utt., vienÄ«gais, pie kÄ nonÄcÄm, ir tas, ka no plkst. žurnÄlos bija skaidrs, ka resol nedarbojas AWS iekÅ”Äjie domÄna nosaukumi, par kuriem es rakstÄ«ju iepriekÅ”, un Harshad Madhav man lÅ«dza izveidot pÄrsÅ«tÄ«Å”anu, it kÄ mÄs izmantojam pielÄgotu DNS un tÄ varÄtu bÅ«t problÄma.
PÄrsÅ«tÄ«Å”ana
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Tas arÄ« tika izdarÄ«ts, diena bija beigusies. HarÅ”ads Madhavs atrakstÄ«ja, lai pÄrbaudÄ«tu, un tam vajadzÄtu darboties, bet nÄ, izŔķirtspÄja nepalÄ«dzÄja.
PÄc tam notika saziÅa ar vÄl 2 inženieriem, viens vienkÄrÅ”i izkrita no Äata, acÄ«mredzot baidÄ«jÄs no sarežģīta gadÄ«juma, otrs manu dienu atkal pavadÄ«ja pilnÄ atkļūdoÅ”anas ciklÄ, sÅ«tot žurnÄlus, veidojot klasterus abÄs pusÄs, beigas vins tikai teica labi, man tas der, te es esmu es daru visu soli pa solim oficiala dokumentaacija un tev un tev izdosies.
Uz ko es pieklÄjÄ«gi palÅ«dzu viÅam aiziet un pieŔķirt manai biļetei kÄdu citu, ja nezinÄt, kur meklÄt problÄmu.
FinÄls
TreÅ”ajÄ dienÄ pie manis tika norÄ«kots jauns inženieris Aruns B., un jau no komunikÄcijas sÄkuma ar viÅu uzreiz bija skaidrs, ka tie nav 3 iepriekÅ”Äjie inženieri. ViÅÅ” izlasÄ«ja visu vÄsturi un nekavÄjoties lÅ«dza savÄkt žurnÄlus, izmantojot viÅa paÅ”a ps1 skriptu, kas bija viÅa github. Tam atkal sekoja visas klasteru veidoÅ”anas, komandu rezultÄtu izvadÄ«Å”anas, žurnÄlu vÄkÅ”anas iterÄcijas, bet Aruns B., spriežot pÄc man uzdotajiem jautÄjumiem, virzÄ«jÄs pareizajÄ virzienÄ.
Kad mÄs nonÄcÄm lÄ«dz punktam -stderrthreshold=debug iespÄjoÅ”ana viÅu vpc-kontrolerÄ«, un kas notika tÄlÄk? protams, tas nedarbojas) pods vienkÄrÅ”i nesÄkas ar Å”o opciju, darbojas tikai -stderrthreshold=info.
MÄs pabeidzÄm Å”eit, un Aruns B. teica, ka viÅÅ” mÄÄ£inÄs atveidot manus soļus, lai iegÅ«tu tÄdu paÅ”u kļūdu. NÄkamajÄ dienÄ es saÅemu atbildi no Aruna B. viÅÅ” neatteicÄs no Ŕīs lietas, bet paÅÄma viÅu vpc kontroliera pÄrskata kodu un atrada vietu, kur tas atrodas un kÄpÄc tas nedarbojas:
TÄdÄjÄdi, ja izmantojat galveno marÅ”ruta tabulu savÄ VPC, tad pÄc noklusÄjuma tai nav saistÄ«bu ar nepiecieÅ”amajiem apakÅ”tÄ«kliem, kas ir tik nepiecieÅ”ami vpc-kontrolierim, publiska apakÅ”tÄ«kla gadÄ«jumÄ tai ir pielÄgota marÅ”ruta tabula. kam ir asociÄcija.
ManuÄli pievienojot asociÄcijas galvenajai marÅ”ruta tabulai ar nepiecieÅ”amajiem apakÅ”tÄ«kliem un no jauna izveidojot mezglu grupu, viss darbojas lieliski.
Ceru, ka Aruns B. tieÅ”Äm ziÅos par Å”o kļūdu EKS izstrÄdÄtÄjiem un mÄs redzÄsim jaunu vpc-controller versiju, kurÄ viss darbosies no kastes. PaÅ”laik jaunÄkÄ versija ir: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ir Ŕī problÄma.
Paldies visiem, kas izlasÄ«ja lÄ«dz galam, pirms ievieÅ”anas pÄrbaudiet visu, ko izmantosit ražoÅ”anÄ.
Avots: www.habr.com