Tere pärastlõunal, tahan teiega jagada oma kogemusi teenuse AWS EKS (Elastic Kubernetes Service) seadistamisel ja kasutamisel Windowsi konteinerite jaoks või õigemini selle kasutamise võimatuse ja AWS-i süsteemikonteineris leitud vea kohta. kes on huvitatud sellest Windowsi konteinerite teenusest, palun kat.
Ma tean, et Windowsi konteinerid pole populaarne teema ja vähesed inimesed kasutavad neid, kuid otsustasin siiski selle artikli kirjutada, kuna Habré kohta oli paar artiklit kubernetes ja Windowsis ning selliseid inimesi on ikka veel.
Algus
Kõik sai alguse sellest, et meie ettevõttes otsustati teenused migreerida kubernetesesse, mis on 70% Windows ja 30% Linux. Selleks kaaluti ühe võimaliku variandina pilveteenust AWS EKS. Kuni 8. oktoobrini 2019 oli AWS EKS Windows avalikus eelvaates, alustasin sellega, seal oli kasutusel kubernetese vana 1.11 versioon, aga otsustasin selle siiski üle vaadata ja vaadata, mis faasis see pilveteenus on, kas töötab. üldse, nagu selgus, ei, see oli viga, mis hõlmas kabude eemaldamist, samas kui vanad lakkasid reageerimast sisemise ip kaudu samast alamvõrgust, kus Windows Worker sõlm.
Seetõttu otsustati AWS EKS-i kasutamisest loobuda meie enda klastri kasuks kubernetes samal EC2 peal, ainult kogu tasakaalustamise ja HA peaksime ise CloudFormationi kaudu kirjeldama.
Amazon EKS Windowsi konteinerite tugi on nüüd üldiselt saadaval
autor Martin Beeby | 08. oktoobril 2019
Enne kui mul oli aega oma klastri jaoks CloudFormationi malli lisada, nägin seda uudist
Loomulikult jätsin ma kogu oma töö kõrvale ja hakkasin uurima, mida nad GA heaks tegid ja kuidas kõik avaliku eelvaatega muutus. Jah, AWS, hästi tehtud, värskendas Windows Worker sõlme pildid versioonile 1.14, aga ka klastri enda, EKS-i versioon 1.14, toetab nüüd Windowsi sõlme. Projekt avaliku eelvaate kaudu aadressil Nad varjasid selle ja ütlesid, et kasutage nüüd ametlikku dokumentatsiooni siin:
EKS-i klastri integreerimine praegusesse VPC-sse ja alamvõrkudesse
Kõigis allikates, nii teadaande ülaltoodud lingil kui ka dokumentatsioonis, tehti ettepanek juurutada klaster kas utiliidi eksctl kaudu või CloudFormation + kubectl after kaudu, kasutades ainult Amazoni avalikke alamvõrke ja luues eraldi VPC uue klastri jaoks.
See valik ei sobi paljudele; esiteks tähendab eraldiseisev VPC lisakulusid oma kuludele + liikluse suunamine teie praegusesse VPC-sse. Mida peaksid tegema need, kellel on juba AWS-is valmis infrastruktuur koos oma mitme AWS-i kontoga, VPC-ga, alamvõrkudega, marsruuditabelitega, transiidilüüsiga ja muuga? Loomulikult ei taha te seda kõike lõhkuda ega ümber teha ning peate integreerima uue EKS-i klastri praeguse võrguinfrastruktuuriga, kasutades olemasolevat VPC-d ja eraldamiseks looma klastri jaoks maksimaalselt uued alamvõrgud.
Minu puhul valiti see tee, kasutasin olemasolevat VPC-d, lisasin uue klastri jaoks ainult 2 avalikku alamvõrku ja 2 privaatset alamvõrku, loomulikult võeti arvesse kõiki reegleid vastavalt dokumentatsioonile .
Samuti oli üks tingimus: EIP-d kasutavates avalikes alamvõrkudes ei olnud töötajaid.
eksctl vs CloudFormation
Teen kohe broneeringu, et proovisin mõlemat klastri juurutamise meetodit, mõlemal juhul oli pilt sama.
Näitan näidet ainult eksctli kasutamisest, kuna siinne kood on lühem. Kasutades eksctl, juurutage klaster kolmes etapis:
1. Loome klastri enda + Linuxi töötaja sõlme, mis hiljem majutab süsteemikonteinereid ja seda sama õnnetut vpc-kontrollerit.
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-networkingOlemasolevale VPC-le juurutamiseks määrake lihtsalt oma alamvõrkude ID ja eksctl määrab VPC ise.
Tagamaks, et teie töötaja sõlmed juurutatakse ainult privaatsesse alamvõrku, peate sõlmerühma jaoks määrama --node-private-networking.
2. Installime oma klastris vpc-kontrolleri, mis seejärel töötleb meie töötajate sõlme, loendab vabade IP-aadresside arvu, samuti eksemplari ENI-de arvu, lisab ja eemaldab need.
eksctl utils install-vpc-controllers --name yyy --approve3. Pärast seda, kui teie süsteemikonteinerid on teie Linuxi töötaja sõlmes, sealhulgas vpc-kontrolleris, edukalt käivitatud, jääb üle vaid luua Windowsi töötajatega uus sõlmerühm.
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-networkingKui sõlm on klastriga edukalt ühenduse loonud ja kõik näib olevat korras, on see olekus Valmis, kuid mitte.
Viga vpc-kontrolleris
Kui proovime Windows Worker sõlmes podeid käivitada, kuvatakse tõrketeade:
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]Kui vaatame sügavamalt, näeme, et meie eksemplar AWS-is näeb välja selline:
Ja see peaks olema selline:
Sellest on selge, et vpc-kontroller ei täitnud mingil põhjusel oma osa ja ei saanud eksemplarile uusi IP-aadresse lisada, et podid saaksid neid kasutada.
Vaatame vpc-kontrolleri podi logisid ja näeme seda:
kubectl logi -n kube-süsteem
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.Google'is tehtud otsingud ei viinud millegini, kuna ilmselt polnud keegi veel sellist viga tabanud või ei olnud selle kohta teemat postitanud, siis pidin esmalt ise võimalusi välja mõtlema. Esimese asjana meenus, et vpc-kontroller ei suuda ehk lahendada faili ip-10-xxx.ap-xxx.compute.internal ja seda saavutada ning seetõttu tekivad vead.
Jah, tõepoolest, me kasutame VPC-s kohandatud DNS-servereid ja põhimõtteliselt me Amazoni servereid ei kasuta, nii et isegi edastamist polnud selle ap-xxx.compute.internal domeeni jaoks seadistatud. Testisin seda võimalust ja see ei andnud tulemusi, võib-olla ei olnud test puhas ja seetõttu alistusin tehnilise toega suheldes nende ideele.
Kuna ideid tegelikult ei olnud, siis kõik turvagrupid lõi eksctl ise, nii et nende hooldatavuses polnud kahtlust, marsruuditabelid olid ka õiged, nat, dns, tööliste sõlmedega internet oli ka olemas.
Veelgi enam, kui juurutate töötaja sõlme avalikku alamvõrku ilma funktsiooni —node-private-networking kasutamata, värskendas vpc-kontroller seda sõlme kohe ja kõik töötas nagu kellavärk.
Seal oli kaks võimalust:
- Loobuge ja oodake, kuni keegi seda viga AWS-is kirjeldab ja selle parandab, ning siis võite julgelt kasutada AWS EKS Windowsi, kuna need just GA-s välja antud (selle artikli kirjutamise ajaks on möödunud 8 päeva), ilmselt paljud käi minuga sama rada.
- Kirjutage AWS-i toele ja rääkige neile probleemi olemusest terve hunniku logidega kõikjalt ja tõestage neile, et nende teenus ei tööta teie VPC ja alamvõrkude kasutamisel. Pole asjata, et meil oli äritugi, peaksite kasutama seda vähemalt korra :)
Suhtlemine AWS-i inseneridega
Olles portaalis pileti loonud, valisin ekslikult vastata mulle veebi - meili või tugikeskuse kaudu, selle valiku kaudu saavad nad teile mõne päeva pärast üldse vastata, hoolimata sellest, et mu piletil oli raskusaste – süsteem häiritud, mis tähendas vastust <12 tunni jooksul ja kuna Ettevõtluse tugiplaanil on 24/7 tugi, siis lootsin parimat, aga läks nagu alati.
Minu pilet jäi reedest esmaspäevani määramata, siis otsustasin neile uuesti kirjutada ja valisin vestluse vastuse võimaluse. Pärast lühikest ootamist määrati Harshad Madhav minu juurde ja siis algas...
Silusime sellega võrgus 3 tundi järjest, teisaldades logisid, juurutades sama klastri AWS-i laboris, et probleem emuleerida, luua minu poolt klastri uuesti ja nii edasi. Ainus asi, milleni jõudsime on see, et logides oli selge, et resol ei tööta AWS-i sisemiste domeeninimedega, millest ma eespool kirjutasin, ja Harshad Madhav palus mul luua edasisuunamine, väidetavalt kasutame kohandatud DNS-i ja see võib olla probleem.
Edastamine
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Seda tehtigi, päev oli läbi. Harshad Madhav kirjutas tagasi, et kontrollida ja see peaks toimima, aga ei, resolutsioon ei aidanud üldse.
Seejärel suheldi veel 2 inseneriga, üks langes lihtsalt vestlusest välja, ilmselt kartis keerulist juhtumit, teine veetis mu päeva taas täistsükli silumisel, logide saatmisel, mõlemal pool klastrite loomisel, lõppu ta lihtsalt ütles hästi, see töötab minu jaoks, siin ma olen, ma teen kõik samm-sammult ametlikus dokumentatsioonis ja teil ja teil õnnestub.
Mille peale palusin tal viisakalt lahkuda ja määrata keegi teine minu piletile, kui te ei tea, kust probleemi otsida.
Lõplik
Kolmandal päeval määrati mulle uus insener Arun B., kellega suhtlemise algusest peale oli kohe selge, et tegemist ei olnud 3 eelmise inseneriga. Ta luges kogu ajaloo läbi ja palus kohe logid koguda, kasutades tema enda ps1 skripti, mis oli tema githubis. Sellele järgnesid taas kõik klastrite loomise iteratsioonid, käsutulemuste väljastamine, logide kogumine, kuid Arun B. liikus mulle esitatud küsimuste põhjal õiges suunas.
Millal jõudsime nende vpc-kontrolleris funktsiooni -stderrthreshold=debug lubamiseni ja mis edasi sai? muidugi see ei tööta) pod lihtsalt ei käivitu selle valikuga, töötab ainult -stderrthreshold=info.
Lõpetasime siin ja Arun B. ütles, et proovib sama vea saamiseks minu samme reprodutseerida. Järgmisel päeval saan vastuse Arun B-lt. Ta ei loobunud sellest juhtumist, vaid võttis üles nende vpc-kontrolleri ülevaatekoodi ja leidis koha, kus see asub ja miks see ei tööta:
Seega, kui kasutate oma VPC-s peamist marsruudi tabelit, siis vaikimisi pole sellel seoseid vajalike alamvõrkudega, mis on vpc-kontrolleri jaoks nii vajalikud, avaliku alamvõrgu puhul on sellel kohandatud marsruuditabel millel on ühendus.
Lisades käsitsi seoseid peamise marsruudi tabeli jaoks vajalike alamvõrkudega ja luues uuesti sõlmerühma, töötab kõik ideaalselt.
Loodan, et Arun B. tõesti teatab sellest veast EKS-i arendajatele ja me näeme vpc-kontrolleri uut versiooni, kus kõik töötab karbist välja. Praegu on uusim versioon: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
on see probleem.
Aitäh kõigile, kes lugesid lõpuni, testige enne juurutamist kõike, mida tootmises kasutama hakkate.
Allikas: www.habr.com