Amazon EKS Windows í GA hefur galla, en er fljótastur

Góðan daginn, mig langar að deila með ykkur reynslu minni af því að setja upp og nota AWS EKS (Elastic Kubernetes Service) þjónustuna fyrir Windows gáma, eða réttara sagt um ómöguleikann á að nota hana, og villuna sem fannst í AWS kerfisílátinu, fyrir þá sem hafa áhuga á þessari þjónustu fyrir Windows gáma, vinsamlegast undir cat.

Ég veit að Windows gámar eru ekki vinsælt efni og fáir nota þá, en ég ákvað samt að skrifa þessa grein, þar sem það voru nokkrar greinar um Habré um kubernetes og Windows og það er enn til slíkt fólk.

Byrja

Þetta byrjaði allt þegar ákveðið var að flytja þjónustuna í fyrirtækinu okkar yfir í kubernetes, sem er 70% Windows og 30% Linux. Í þessu skyni var AWS EKS skýjaþjónustan talin vera einn af mögulegum valkostum. Þar til 8. október 2019 var AWS EKS Windows í Public Preview, ég byrjaði á því, gamla 1.11 útgáfan af kubernetes var notuð þar, en ég ákvað samt að athuga það og sjá á hvaða stigi þessi skýjaþjónusta væri, hvort hún virkaði yfirleitt, eins og það kom í ljós, nei, það var galli sem bætti við að fjarlægja belg, á meðan þeir gömlu hættu að svara í gegnum innri ip frá sama undirneti og Windows worker hnúturinn.

Þess vegna var ákveðið að hætta að nota AWS EKS í þágu okkar eigin klasa á kubernetes á sama EC2, aðeins við þyrftum að lýsa öllu jafnvægi og HA sjálf í gegnum CloudFormation.

Amazon EKS Windows gámastuðningur er nú almennt fáanlegur

eftir Martin Beeby | þann 08. OKT 2019

Áður en ég hafði tíma til að bæta við sniðmáti við CloudFormation fyrir minn eigin klasa, sá ég þessar fréttir Amazon EKS Windows gámastuðningur er nú almennt fáanlegur

Auðvitað lagði ég alla mína vinnu til hliðar og fór að kynna mér hvað þeir gerðu fyrir GA og hvernig allt breyttist með Public Preview. Já, AWS, vel gert, uppfærði myndirnar fyrir Windows Worker hnút í útgáfu 1.14, sem og þyrpingin sjálf, útgáfa 1.14 í EKS, styður nú Windows hnúta. Verkefni eftir Public Preview kl github Þeir hyldu það og sögðu nú nota opinberu skjölin hér: EKS Windows stuðningur

Að samþætta EKS klasa í núverandi VPC og undirnet

Í öllum heimildum, í hlekknum hér að ofan á tilkynningunni sem og í skjölunum, var lagt til að dreifa þyrpingunni annað hvort í gegnum einkarekna eksctl tólið eða í gegnum CloudFormation + kubectl eftir, aðeins með því að nota opinber undirnet í Amazon, auk þess að búa til aðskilið VPC fyrir nýjan klasa.

Þessi valkostur hentar ekki mörgum; í fyrsta lagi þýðir sérstakur VPC aukakostnað fyrir kostnaðinn + jafningumferð á núverandi VPC þinn. Hvað ættu þeir sem þegar eru með tilbúna innviði í AWS með sína eigin marga AWS reikninga, VPC, undirnet, leiðartöflur, flutningsgátt og svo framvegis að gera? Auðvitað, þú vilt ekki brjóta eða endurgera allt þetta, og þú þarft að samþætta nýja EKS þyrpinguna í núverandi netinnviði, nota núverandi VPC og, til aðskilnaðar, í mesta lagi búa til ný undirnet fyrir þyrpinguna.

Í mínu tilfelli var þessi leið valin, ég notaði núverandi VPC, bætti aðeins við 2 almennum undirnetum og 2 einka undirnetum fyrir nýja klasann, auðvitað var tekið tillit til allra reglna samkvæmt skjölunum Búðu til Amazon EKS Cluster VPC þinn.

Það var líka eitt skilyrði: Engir starfshnútar í opinberum undirnetum sem notuðu EIP.

eksctl vs CloudFormation

Ég mun strax gera fyrirvara um að ég hafi prófað báðar aðferðirnar til að dreifa klasa, í báðum tilfellum var myndin sú sama.

Ég mun sýna dæmi með því að nota eksctl þar sem kóðinn hér verður styttri. Notaðu eksctl, dreifðu þyrpingunni í 3 skrefum:

1. Við búum til þyrpinguna sjálfa + Linux verkamannahnút, sem mun síðar hýsa kerfisílát og sama illa farna vpc-stýringuna.

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-networking

Til að dreifa á núverandi VPC skaltu bara tilgreina auðkenni undirnetanna þinna og eksctl mun ákvarða VPC sjálft.

Til að tryggja að starfshnútar þínir séu aðeins settir á einka undirnet, þarftu að tilgreina --node-private-networking fyrir hnútahóp.

2. Við setjum upp vpc-stýringu í þyrpingunni okkar, sem mun síðan vinna úr starfsmannahnútum okkar, telja fjölda ókeypis IP vistfanga, sem og fjölda ENIs á tilvikinu, bæta við og fjarlægja þær.

eksctl utils install-vpc-controllers --name yyy --approve

3.Eftir að kerfisgámarnir þínir hafa verið ræstir á Linux verkamannahnútinn þinn, þar á meðal vpc-stýringu, er allt sem eftir er að búa til annan hnútahóp með Windows starfsmönnum.

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-networking

Eftir að hnúturinn þinn hefur tengst þyrpingunni þinni og allt virðist vera í lagi, er hann í tilbúinn stöðu, en nei.

Villa í vpc-stýringu

Ef við reynum að keyra belg á Windows vinnuhnút fáum við villuna:

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]

Ef við skoðum dýpra sjáum við að tilvik okkar í AWS lítur svona út:

Og það ætti að vera svona:

Af þessu er ljóst að vpc-stjórnandinn uppfyllti ekki sinn hluta af einhverjum ástæðum og gat ekki bætt nýjum IP tölum við tilvikið svo að podarnir gætu notað þær.

Við skulum skoða annála vpc-stýringarbelgsins og þetta er það sem við sjáum:

kubectl log -n kúbe-kerfi

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.

Leit á Google leiddi ekki til neins, þar sem greinilega enginn hafði lent í slíkri villu ennþá, eða ekki sett inn mál á það, ég þurfti fyrst að hugsa um valkosti sjálfur. Það fyrsta sem kom upp í hugann var að ef til vill getur vpc-stjórnandinn ekki leyst ip-10-xxx.ap-xxx.compute.internal og náð því og því koma upp villur.

Já, sannarlega, við notum sérsniðna DNS netþjóna í VPC og í grundvallaratriðum notum við ekki Amazon, svo jafnvel áframsending var ekki stillt fyrir þetta ap-xxx.compute.internal lén. Ég prófaði þennan valmöguleika og það skilaði engum árangri, kannski var prófið ekki hreint, og þess vegna, þegar ég átti samskipti við tæknilega aðstoð, féll ég fyrir hugmynd þeirra.

Þar sem það voru í raun engar hugmyndir, voru allir öryggishópar búnir til af eksctl sjálfu, svo það var enginn vafi á nothæfi þeirra, leiðartöflurnar voru líka réttar, nat, dns, internetaðgangur með hnútum starfsmanna var líka til staðar.

Þar að auki, ef þú setur vinnuhnút á almennt undirnet án þess að nota —node-private-networking, var þessi hnút uppfærður strax af vpc-stýringunni og allt virkaði eins og smurt.

Það voru tveir valkostir:

1. Gefðu það upp og bíddu þangað til einhver lýsir þessari villu í AWS og hann lagar hana, og þá geturðu örugglega notað AWS EKS Windows, því þeir komu út í GA (8 dagar eru liðnir þegar þessi grein er skrifuð), margir munu líklega fara sömu leið og ég.
2. Skrifaðu til AWS Support og segðu þeim kjarna vandamálsins með fullt af annálum hvaðanæva að og sannaðu fyrir þeim að þjónusta þeirra virkar ekki þegar þú notar VPC og undirnetið þitt, það er ekki fyrir ekkert sem við höfðum viðskiptastuðning, þú ættir að nota það allavega einu sinni :)

Samskipti við AWS verkfræðinga

Eftir að hafa búið til miða á gáttinni valdi ég ranglega að svara mér í gegnum vefinn - tölvupóst eða stuðningsmiðstöð, í gegnum þennan möguleika geta þeir svarað þér eftir nokkra daga, þrátt fyrir að miðinn minn hafi verið með alvarleika - kerfisskerðingu, sem þýddi svar innan <12 klukkustunda, og þar sem viðskiptastuðningsáætlunin er með 24/7 stuðning, vonaði ég það besta, en það reyndist eins og alltaf.

Miðinn minn var skilinn eftir óúthlutaður frá föstudegi til mánudags, þá ákvað ég að skrifa þeim aftur og valdi svarmöguleikann Spjall. Eftir að hafa beðið í stuttan tíma var Harshad Madhav skipaður til að hitta mig og þá byrjaði...

Við kemvuðum með það á netinu í 3 klukkustundir í röð, fluttum annála, settum upp sama klasa á AWS rannsóknarstofunni til að líkja eftir vandamálinu, endurgerðum klasann af minni hálfu og svo framvegis, það eina sem við komumst að er að frá kl. logs það var ljóst að resol virkaði ekki AWS innri lén, sem ég skrifaði um hér að ofan, og Harshad Madhav bað mig að búa til áframsendingu, að sögn notum við sérsniðið DNS og þetta gæti verið vandamál.

Áframsendingu

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

Það var það sem var gert, dagurinn var búinn. Harshad Madhav skrifaði til baka til að athuga það og það ætti að virka, en nei, upplausnin hjálpaði alls ekki.

Svo voru samskipti við 2 verkfræðinga í viðbót, annar datt einfaldlega út af spjallinu, greinilega var hann hræddur við flókið mál, sá síðari eyddi deginum mínum aftur í fulla lotu af villuleit, að senda logs, búa til klasa á báðum hliðum, í enda sagði hann bara vel, það virkar fyrir mig, hér er ég ég geri allt skref fyrir skref í opinberu skjölunum og þú og þú munt ná árangri.

Sem ég bað hann kurteislega um að fara og úthluta einhverjum öðrum á miðann minn ef þú veist ekki hvar þú átt að leita að vandamálinu.

Final

Á þriðja degi var nýr verkfræðingur Arun B. fenginn til mín og strax í upphafi samskipta við hann var strax ljóst að þetta voru ekki 3 fyrri verkfræðingarnir. Hann las alla söguna og bað umsvifalaust að safna loggunum með því að nota sitt eigið handrit á ps1, sem var á github hans. Þessu fylgdu aftur allar endurtekningarnar við að búa til klasa, gefa út stjórnunarniðurstöður, safna annálum, en Arun B. var að fara í rétta átt miðað við spurningarnar sem ég spurði.

Hvenær komumst við að því að virkja -stderrthreshold=debug í vpc-stýringunni þeirra og hvað gerðist næst? auðvitað virkar það ekki) podinn byrjar einfaldlega ekki með þessum valkosti, aðeins -stderrthreshold=info virkar.

Við kláruðum hér og Arun B. sagði að hann myndi reyna að endurskapa skrefin mín til að fá sömu villu. Daginn eftir fæ ég svar frá Arun B. hann hætti ekki við þetta mál, heldur tók upp endurskoðunarkóðann á vpc-stýringunni þeirra og fann staðinn þar sem hann er og hvers vegna hann virkar ekki:

Þannig, ef þú notar aðalleiðartöfluna í VPC þínum, þá hefur það sjálfgefið ekki tengsl við nauðsynleg undirnet, sem eru svo nauðsynleg fyrir vpc-stýringuna, ef um er að ræða almennt undirnet, þá hefur það sérsniðna leiðartöflu sem hefur samtök.

Með því að bæta handvirkt við tengingum fyrir aðalleiðartöfluna með nauðsynlegum undirnetum og endurskapa hnútahópinn, virkar allt fullkomlega.

Ég vona að Arun B. muni virkilega tilkynna þessa villu til EKS forritara og við munum sjá nýja útgáfu af vpc-stýringu þar sem allt mun ganga upp úr kassanum. Sem stendur er nýjasta útgáfan: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
er með þetta vandamál.

Takk allir sem lásu til enda, prófaðu allt sem þú ætlar að nota í framleiðslu fyrir innleiðingu.

Heimild: www.habr.com