Mirëdita, dua të ndaj me ju përvojën time në konfigurimin dhe përdorimin e shërbimit AWS EKS (Elastic Kubernetes Service) për kontejnerët e Windows, ose më saktë për pamundësinë e përdorimit të tij dhe defektin e gjetur në kontejnerin e sistemit AWS, për ata të cilët janë të interesuar për këtë shërbim për kontejnerët Windows, ju lutemi nën cat.
E di që kontejnerët e Windows nuk janë një temë popullore dhe pak njerëz i përdorin ato, por unë prapë vendosa të shkruaj këtë artikull, pasi kishte disa artikuj në Habré në kubernetes dhe Windows dhe ka ende njerëz të tillë.
Fillim
Gjithçka filloi kur u vendos që shërbimet në kompaninë tonë të migrojnë në kubernetes, që është 70% Windows dhe 30% Linux. Për këtë qëllim, shërbimi cloud AWS EKS u konsiderua si një nga opsionet e mundshme. Deri më 8 tetor 2019, AWS EKS Windows ishte në Parashikim Publik, fillova me të, aty përdorej versioni i vjetër 1.11 i kubernetes, por vendosa ta kontrolloja gjithsesi dhe të shihja në çfarë faze ishte ky shërbim cloud, nëse po funksiononte fare, siç doli, jo, ishte një gabim me shtimin e heqjes së pods, ndërsa të vjetrat pushuan së përgjigjuri përmes ip-së së brendshme nga e njëjta nënrrjet si nyja e punëtorit të Windows.
Prandaj, u vendos që të braktisim përdorimin e AWS EKS në favor të grupit tonë në kubernetes në të njëjtin EC2, vetëm ne do të na duhej të përshkruanim të gjithë balancimin dhe HA vetë përmes CloudFormation.
Mbështetja e kontejnerëve të Windows EKS të Amazon tani është përgjithësisht e disponueshme
nga Martin Beeby | më 08 TETOR 2019
Përpara se të kisha kohë për të shtuar një shabllon në CloudFormation për grupin tim, pashë këtë lajm
Natyrisht, e lashë të gjithë punën time mënjanë dhe fillova të studioja se çfarë bënë ata për GA, dhe se si gjithçka ndryshoi me Parashikimin Publik. Po, AWS, bravo, përditësoi imazhet për nyjen punëtore të Windows në versionin 1.14, si dhe vetë grupin, versioni 1.14 në EKS, tani mbështet nyjet e Windows. Projekti nga Parashikimi Publik në Ata e mbuluan dhe thanë tani përdorni dokumentacionin zyrtar këtu:
Integrimi i një grupi EKS në VPC-në dhe nënrrjetat aktuale
Në të gjitha burimet, në lidhjen e mësipërme në njoftim si dhe në dokumentacion, u propozua vendosja e grupit ose përmes programit të pronarit eksctl ose përmes CloudFormation + kubectl më pas, duke përdorur vetëm nënrrjetet publike në Amazon, si dhe krijimin e një VPC e ndarë për një grup të ri.
Ky opsion nuk është i përshtatshëm për shumë njerëz; së pari, një VPC e veçantë do të thotë kosto shtesë për koston e tij + trafikun kolegial në VPC-në tuaj aktuale. Çfarë duhet të bëjnë ata që tashmë kanë një infrastrukturë të gatshme në AWS me llogaritë e tyre të Shumëfishta AWS, VPC, nënrrjeta, tabelat e rrugëve, portën e tranzitit dhe kështu me radhë? Natyrisht, ju nuk dëshironi të prishni ose ribëni të gjitha këto dhe ju duhet të integroni grupin e ri EKS në infrastrukturën aktuale të rrjetit, duke përdorur VPC ekzistuese dhe, për ndarje, më së shumti të krijoni nënrrjeta të reja për grupin.
Në rastin tim u zgjodh kjo rrugë, përdora VPC-në ekzistuese, shtova vetëm 2 nënrrjete publike dhe 2 nënrrjeta private për grupin e ri, natyrisht, të gjitha rregullat u morën parasysh sipas dokumentacionit. .
Kishte gjithashtu një kusht: asnjë nyje punëtore në nënrrjetet publike duke përdorur EIP.
eksctl vs CloudFormation
Do të bëj një rezervim menjëherë se kam provuar të dyja metodat e vendosjes së një grupi, në të dyja rastet fotografia ishte e njëjtë.
Unë do të tregoj një shembull vetëm duke përdorur eksctl pasi kodi këtu do të jetë më i shkurtër. Duke përdorur eksctl, vendoseni grupin në 3 hapa:
1. Ne krijojmë vetë grupin + nyjen punëtore Linux, e cila më vonë do të presë kontejnerët e sistemit dhe të njëjtin kontrollues vpc fatkeq.
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-networkingPër t'u vendosur në një VPC ekzistuese, thjesht specifikoni ID-në e nënrrjetave tuaja dhe eksctl do të përcaktojë vetë VPC-në.
Për të siguruar që nyjet tuaja të punës të vendosen vetëm në një nënrrjet privat, ju duhet të specifikoni --node-private-networking për grupin e nyjeve.
2. Ne instalojmë vpc-controller në grupin tonë, i cili më pas do të përpunojë nyjet tona të punës, duke numëruar numrin e adresave IP të lira, si dhe numrin e ENI-ve në instancë, duke i shtuar dhe hequr ato.
eksctl utils install-vpc-controllers --name yyy --approve3. Pasi kontejnerët e sistemit tuaj të jenë nisur me sukses në nyjen tuaj të punës Linux, duke përfshirë kontrolluesin vpc, gjithçka që mbetet është të krijoni një grup tjetër nyje me punëtorët e 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-networkingPasi nyja juaj është lidhur me sukses me grupin tuaj dhe gjithçka duket se është në rregull, ajo është në statusin Gati, por jo.
Gabim në kontrolluesin vpc
Nëse përpiqemi të ekzekutojmë pods në një nyje pune të Windows, do të marrim gabimin:
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]Nëse shikojmë më thellë, shohim se shembulli ynë në AWS duket si ky:
Dhe duhet të jetë kështu:
Nga kjo është e qartë se kontrolluesi vpc nuk e përmbushi pjesën e tij për ndonjë arsye dhe nuk mund të shtonte adresa të reja IP në shembull, në mënyrë që pods t'i përdornin ato.
Le të shohim regjistrat e podit të kontrolluesit vpc dhe kjo është ajo që shohim:
kubectl log -n kube-sistem
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.Kërkimet në Google nuk çuan në asgjë, pasi me sa duket askush nuk e kishte kapur ende një gabim të tillë, ose nuk kishte postuar një problem në të, më duhej të mendoja vetë opsionet së pari. Gjëja e parë që më erdhi në mendje ishte se ndoshta kontrolluesi vpc nuk mund të zgjidhë ip-10-xxx.ap-xxx.compute.internal dhe ta arrijë atë dhe për këtë arsye ndodhin gabime.
Po, me të vërtetë, ne përdorim serverë të personalizuar DNS në VPC dhe, në parim, nuk përdorim ato të Amazon, kështu që edhe përcjellja nuk ishte konfiguruar për këtë domen ap-xxx.compute.internal. E testova këtë opsion dhe nuk solli rezultate, mbase testi nuk ishte i pastër, dhe për këtë arsye, më tej, kur komunikova me mbështetjen teknike, iu nënshtrova idesë së tyre.
Meqenëse në të vërtetë nuk kishte asnjë ide, të gjitha grupet e sigurisë u krijuan nga vetë eksctl, kështu që nuk kishte dyshim për shërbimin e tyre, tabelat e rrugëve ishin gjithashtu të sakta, nat, dns, qasja në internet me nyjet e punëtorëve ishte gjithashtu aty.
Për më tepër, nëse vendosni një nyje punëtore në një nën-rrjet publik pa përdorur —node-private-networking, kjo nyje u përditësua menjëherë nga kontrolluesi vpc dhe gjithçka funksionoi si me orë.
Kishte dy opsione:
- Hiqni dorë dhe prisni derisa dikush të përshkruajë këtë defekt në AWS dhe ta rregullojë atë, dhe më pas mund të përdorni me siguri AWS EKS Windows, sepse ata sapo u lëshuan në GA (kanë kaluar 8 ditë në kohën e shkrimit të këtij artikulli), me siguri shumë do ndiqni të njëjtën rrugë si unë.
- Shkruani në Mbështetjen AWS dhe tregojuni atyre thelbin e problemit me një grup të tërë regjistrash nga kudo dhe provoni atyre se shërbimi i tyre nuk funksionon kur përdorni VPC-në dhe nënrrjetet tuaja, nuk është për asgjë që kishim mbështetje për Biznesin, duhet të përdorni te pakten nje here :)
Komunikimi me inxhinierët AWS
Duke krijuar një biletë në portal, gabimisht zgjodha të më përgjigjem përmes postës elektronike të internetit ose qendrës mbështetëse, përmes këtij opsioni ata mund t'ju përgjigjen fare pas disa ditësh, pavarësisht se bileta ime kishte Ashpërsi - Sistemi i dëmtuar, i cili nënkuptonte një përgjigje brenda <12 orësh, dhe meqenëse plani i mbështetjes së biznesit ka mbështetje 24/7, shpresoja për më të mirën, por doli si gjithmonë.
Bileta ime mbeti e pacaktuar nga e premtja deri të hënën, më pas vendosa t'u shkruaj përsëri dhe zgjodha opsionin e përgjigjes në Chat. Pasi priti një kohë të shkurtër, Harshad Madhav u caktua të më takonte dhe më pas filloi...
Ne debuguam me të në internet për 3 orë rresht, duke transferuar regjistrat, duke vendosur të njëjtin grup në laboratorin AWS për të imituar problemin, duke rikrijuar grupin nga ana ime, e kështu me radhë, e vetmja gjë në të cilën arritëm është se nga regjistrat ishte e qartë se rezolucioni nuk po funksiononte emrat e brendshëm të domeneve AWS, për të cilat shkrova më lart, dhe Harshad Madhav më kërkoi të krijoja përcjellje, gjoja ne përdorim DNS të personalizuar dhe ky mund të jetë një problem.
Forwarding
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Kështu u bë, dita mbaroi. Harshad Madhav shkroi përsëri për ta kontrolluar dhe duhet të funksiononte, por jo, rezolucioni nuk ndihmoi aspak.
Më pas pati komunikim me 2 inxhinierë të tjerë, njëri thjesht u largua nga biseda, me sa duket kishte frikë nga një rast kompleks, i dyti e kaloi ditën time përsëri në një cikël të plotë korrigjimi, dërgimi të regjistrave, krijimit të grupimeve në të dyja anët, në fundi thjesht tha mire mua me funksionon ja ku jam bej cdo gje hap pas hapi ne dokumentacionin zyrtar dhe do ja dilni ju dhe ju.
Për të cilën me mirësjellje i kërkova të largohej dhe të caktonte dikë tjetër në biletën time nëse nuk dini ku ta kërkoni problemin.
finale
Ditën e tretë më caktuan një inxhinier të ri Arun B. dhe që në fillim të komunikimit me të u kuptua menjëherë se nuk ishin 3 inxhinierët e mëparshëm. Ai lexoi të gjithë historinë dhe kërkoi menjëherë të mblidhte regjistrat duke përdorur skriptin e tij në ps1, i cili ishte në github-in e tij. Kjo u pasua përsëri nga të gjitha përsëritjet e krijimit të grupimeve, nxjerrjes së rezultateve të komandave, mbledhjes së regjistrave, por Arun B. po lëvizte në drejtimin e duhur duke gjykuar nga pyetjet që më bëheshin.
Kur arritëm në pikën për të aktivizuar -stderrthreshold=debug në kontrolluesin e tyre vpc, dhe çfarë ndodhi më pas? sigurisht që nuk funksionon) pod thjesht nuk fillon me këtë opsion, funksionon vetëm -stderrthreshold=info.
Përfunduam këtu dhe Arun B. tha se do të përpiqej të riprodhonte hapat e mi për të marrë të njëjtin gabim. Të nesërmen mora një përgjigje nga Arun B. ai nuk e braktisi këtë rast, por mori kodin e rishikimit të vpc-kontrollerit të tyre dhe gjeti vendin ku është dhe pse nuk funksionon:
Kështu, nëse përdorni tabelën kryesore të rrugës në VPC-në tuaj, atëherë si parazgjedhje ajo nuk ka lidhje me nënrrjetat e nevojshme, të cilat janë aq të nevojshme për kontrolluesin vpc, në rastin e një nënrrjeti publik, ai ka një tabelë të personalizuar të rrugës. që ka një shoqatë.
Duke shtuar manualisht shoqatat për tabelën e rrugëve kryesore me nënrrjetat e nevojshme dhe duke rikrijuar grupin e nyjeve, gjithçka funksionon në mënyrë perfekte.
Shpresoj që Arun B. me të vërtetë do ta raportojë këtë problem te zhvilluesit e EKS dhe ne do të shohim një version të ri të kontrolluesit vpc ku gjithçka do të funksionojë jashtë kutisë. Aktualisht versioni më i fundit është: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
e ka këtë problem.
Faleminderit të gjithëve që lexojnë deri në fund, provoni gjithçka që do të përdorni në prodhim përpara zbatimit.
Burimi: www.habr.com