Bonan posttagmezon, mi volas konigi al vi mian sperton pri agordo kaj uzado de la servo AWS EKS (Elastic Kubernetes Service) por Vindozaj ujoj, aŭ pli ĝuste pri la neeblo uzi ĝin, kaj la cimon trovita en la AWS-sistema ujo, por tiuj. kiuj interesiĝas pri ĉi tiu servo por Vindozaj ujoj, bonvolu sub kato.
Mi scias, ke Vindozaj ujoj ne estas populara temo, kaj malmultaj homoj uzas ilin, sed mi tamen decidis skribi ĉi tiun artikolon, ĉar estis kelkaj artikoloj pri Habré pri kubernetes kaj Vindozo kaj ankoraŭ ekzistas tiaj homoj.
Начало
Ĉio komenciĝis kiam oni decidis migri la servojn en nia kompanio al kubernetes, kiu estas 70% Vindozo kaj 30% Linukso. Por ĉi tiu celo, la nuba servo de AWS EKS estis konsiderata kiel unu el la eblaj opcioj. Ĝis la 8-a de oktobro 2019, AWS EKS Windows estis en Publika Antaŭrigardo, mi komencis per ĝi, la malnova versio 1.11 de kubernetes estis uzata tie, sed mi decidis kontroli ĝin ĉiuokaze kaj vidi en kiu stadio estas ĉi tiu nuba servo, ĉu ĝi funkcias. tute, kiel montriĝis, ne, estis cimo kun la aldono de forigo de podoj, dum la malnovaj ĉesis respondi per interna ip de la sama subreto kiel la Windows Worker nodo.
Sekve, estis decidite forlasi la uzon de AWS EKS favore al nia propra cluster sur kubernetes sur la sama EC2, nur ni devus priskribi la tutan ekvilibron kaj HA mem per CloudFormation.
Amazon EKS Windows Container Support nun Ĝenerale Havebla
de Martin Beeby | la 08-an de oktobro 2019
Antaŭ ol mi havis tempon aldoni ŝablonon al CloudFormation por mia propra areto, mi vidis ĉi tiun novaĵon
Kompreneble, mi flankenmetis mian tutan laboron kaj komencis studi kion ili faris por GA, kaj kiel ĉio ŝanĝiĝis kun Public Preview. Jes, AWS, bone farita, ĝisdatigis la bildojn por Windows Worker-nodo al versio 1.14, same kiel la grapolo mem, versio 1.14 en EKS, nun subtenas Windows-nodojn. Projekto de Publika Antaŭrigardo ĉe Ili kovris ĝin kaj diris nun uzu la oficialan dokumentaron ĉi tie:
Integrante EKS-grupon en la nunajn VPC kaj subretojn
En ĉiuj fontoj, en la supra ligo pri la anonco kaj ankaŭ en la dokumentado, oni proponis disfaldi la areton aŭ per la propra eksctl-utilo aŭ per CloudFormation + kubectl poste, nur uzante publikajn subretojn en Amazono, kaj ankaŭ krei aparta VPC por nova areto.
Ĉi tiu opcio ne taŭgas por multaj; unue, aparta VPC signifas kromajn kostojn por sia kosto + peering trafiko al via nuna VPC. Kion devas fari tiuj, kiuj jam havas pretan infrastrukturon en AWS kun siaj propraj Multoblaj AWS-kontoj, VPC, subretoj, itinertabeloj, transitenirejo kaj tiel plu? Kompreneble, vi ne volas rompi aŭ refari ĉion ĉi, kaj vi devas integri la novan EKS-grupon en la nunan retan infrastrukturon, uzante la ekzistantan VPC kaj, por apartigo, maksimume krei novajn subretojn por la areto.
En mia kazo, ĉi tiu vojo estis elektita, mi uzis la ekzistantan VPC, aldonis nur 2 publikajn subretojn kaj 2 privatajn subretojn por la nova areto, kompreneble, ĉiuj reguloj estis konsiderataj laŭ la dokumentado. .
Estis ankaŭ unu kondiĉo: neniuj labornodoj en publikaj subretoj uzantaj EIP.
eksctl kontraŭ CloudFormation
Mi tuj rezervos, ke mi provis ambaŭ metodojn por disfaldi grapolon, en ambaŭ kazoj la bildo estis la sama.
Mi montros ekzemplon nur uzante eksctl ĉar la kodo ĉi tie estos pli mallonga. Uzante eksctl, disfaldi la areton en 3 paŝoj:
1. Ni kreas la areton mem + Linuksa laborista nodo, kiu poste gastigos sistemajn ujojn kaj tiun saman malbonŝancan vpc-regilon.
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-networkingPor deploji al ekzistanta VPC, simple specifu la identigilon de viaj subretoj, kaj eksctl determinos la VPC mem.
Por certigi, ke viaj labornodoj estas deplojitaj nur al privata subreto, vi devas specifi --node-private-networking por nodegroup.
2. Ni instalas vpc-controller en nia areto, kiu tiam prilaboros niajn laboristajn nodojn, kalkulante la nombron da senpagaj IP-adresoj, same kiel la nombron da ENIoj sur la petskribo, aldonante kaj forigante ilin.
eksctl utils install-vpc-controllers --name yyy --approve3.Post kiam viaj sistemaj ujoj sukcese lanĉiĝis sur via Linuksa laborista nodo, inkluzive de vpc-regilo, restas nur krei alian nodgrupon kun Windows-laboristoj.
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-networkingPost kiam via nodo sukcese konektiĝis al via areto kaj ĉio ŝajnas esti bona, ĝi estas en Preta statuso, sed ne.
Eraro en vpc-controller
Se ni provas ruli podojn sur nodo de Windows Worker, ni ricevos la eraron:
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]Se ni rigardas pli profunde, ni vidas, ke nia kazo en AWS aspektas jene:
Kaj ĝi devus esti tiel:
El tio estas klare, ke la vpc-regilo ne plenumis sian parton ial kaj ne povis aldoni novajn IP-adresojn al la petskribo por ke la podoj povu uzi ilin.
Ni rigardu la protokolojn de la vpc-controller pod kaj jen kion ni vidas:
kubectl log -n kube-sistemo
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.Serĉoj en Guglo ne kondukis al io ajn, ĉar ŝajne neniu ankoraŭ kaptis tian cimon aŭ ne afiŝis aferon pri ĝi, mi devis unue pensi pri opcioj. La unua afero, kiu venis en la menson, estis, ke eble la vpc-regilo ne povas solvi ip-10-xxx.ap-xxx.compute.internal kaj atingi ĝin kaj tial okazas eraroj.
Jes, efektive, ni uzas kutimajn DNS-servilojn en la VPC kaj, principe, ni ne uzas Amazon-ojn, do eĉ plusendado ne estis agordita por ĉi tiu ap-xxx.compute.internal domajno. Mi provis ĉi tiun opcion, kaj ĝi ne alportis rezultojn, eble la testo ne estis pura, kaj tial, plue, kiam mi komunikis kun teknika subteno, mi cedis al ilia ideo.
Ĉar vere ne estis ideoj, ĉiuj sekurecaj grupoj estis kreitaj de eksctl mem, do ne estis dubo pri ilia servado, ankaŭ la itinero-tabeloj estis ĝustaj, nat, dns, Interreta aliro kun laboristaj nodoj ankaŭ estis tie.
Krome, se vi deplojas laboristan nodon al publika subreto sen uzi —node-private-networking, ĉi tiu nodo tuj estis ĝisdatigita de la vpc-regilo kaj ĉio funkciis kiel horloĝo.
Estis du opcioj:
- Rezignu ĝin kaj atendu ĝis iu priskribas ĉi tiun cimon en AWS kaj ili riparos ĝin, kaj tiam vi povas sekure uzi AWS EKS Windows, ĉar ili ĵus eldonitaj en GA (8 tagoj pasis en la momento de verkado de ĉi tiu artikolo), multaj verŝajne faros. sekvu la saman vojon kiel mi.
- Skribu al AWS Support kaj diru al ili la esencon de la problemo kun tuta amaso da protokoloj de ĉie kaj pruvu al ili, ke ilia servo ne funkcias kiam vi uzas viajn VPC kaj subretojn, ne vane ni havis Komercan subtenon, vi devus uzi ĝi almenaŭ unufoje :)
Komunikado kun AWS-inĝenieroj
Kreinte bileton en la portalo, mi erare elektis respondi al mi per TTT - retpoŝto aŭ helpcentro, per ĉi tiu opcio ili povas respondi al vi entute post kelkaj tagoj, malgraŭ la fakto, ke mia bileto havis Gravecon - Sistemo difektita, kio signifis respondon ene de <12 horoj, kaj ĉar la Komerca subtena plano havas 24/7 subtenon, mi esperis la plej bonan, sed ĝi rezultis kiel ĉiam.
Mia bileto estis lasita neasignita de vendredo ĝis lundo, tiam mi decidis skribi al ili denove kaj elektis la Babilan respondopcion. Post atendado por mallonga tempo, Harshad Madhav estis nomumita por vidi min, kaj tiam ĝi komenciĝis...
Ni sencimigis per ĝi interrete dum 3 horoj sinsekve, translokigante protokolojn, disfaldante la saman areton en la AWS-laboratorio por kopii la problemon, rekreante la areton miaflanke, kaj tiel plu, la nura afero, al kiu ni venis, estas ke de la protokoloj estis klare, ke la rezolucio ne funkcias AWS internaj domajnaj nomoj, pri kiuj mi skribis supre, kaj Harshad Madhav petis min krei plusendon, supozeble ni uzas kutiman DNS kaj ĉi tio povus esti problemo.
Antaŭenigo
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Jen kio estis farita, la tago finiĝis.Harshad Madhav skribis reen por kontroli ĝin kaj ĝi devus funkcii, sed ne, la rezolucio tute ne helpis.
Tiam estis komunikado kun 2 pliaj inĝenieroj, unu simple eliris el la babilejo, ŝajne li timis kompleksan kazon, la dua pasigis mian tagon denove en plena ciklo de sencimigo, sendante protokolojn, kreante aretojn ambaŭflanke, en la fino li nur diris bone, ĝi funkcias por mi, jen mi mi faras ĉion paŝon post paŝo en la oficiala dokumentado kaj vi kaj vi sukcesos.
Al kio mi ĝentile petis lin foriri kaj atribui iun alian al mia bileto, se vi ne scias kie serĉi la problemon.
Fino
En la tria tago, nova inĝeniero Arun B. estis asignita al mi, kaj ekde la komenco de komunikado kun li tuj evidentiĝis, ke tio ne estas la 3 antaŭaj inĝenieroj. Li legis la tutan historion kaj tuj petis kolekti la protokolojn uzante sian propran skripton sur ps1, kiu estis sur lia github. Ĉi tio estis denove sekvita de ĉiuj ripetoj de kreado de aretoj, eligo de komandrezultoj, kolektado de protokoloj, sed Arun B. moviĝis en la ĝusta direkto juĝante laŭ la demandoj faritaj al mi.
Kiam ni atingis la punkton ebligi -stderrthreshold=debug en ilia vpc-controller, kaj kio okazis poste? kompreneble ĝi ne funkcias) la pod simple ne komenciĝas per ĉi tiu opcio, nur -stderrthreshold=info funkcias.
Ni finis ĉi tie kaj Arun B. diris, ke li provos reprodukti miajn paŝojn por ricevi la saman eraron. La sekvan tagon mi ricevas respondon de Arun B. li ne forlasis ĉi tiun kazon, sed prenis la revizian kodon de ilia vpc-regilo kaj trovis la lokon kie ĝi estas kaj kial ĝi ne funkcias:
Tiel, se vi uzas la ĉefan itineran tabelon en via VPC, tiam defaŭlte ĝi ne havas asociojn kun la necesaj subretoj, kiuj estas tiom necesaj por la vpc-regilo, en la kazo de publika subreto, ĝi havas kutiman itineran tabelon. kiu havas asocion.
Mane aldonante asociojn por la ĉefa itinertabelo kun la necesaj subretoj, kaj rekreante la nodgrupon, ĉio funkcias perfekte.
Mi esperas, ke Arun B. vere raportos ĉi tiun cimon al la EKS-programistoj kaj ni vidos novan version de vpc-controller kie ĉio funkcios el la skatolo. Nuntempe la plej nova versio estas: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
havas ĉi tiun problemon.
Dankon al ĉiuj, kiuj legas ĝis la fino, provu ĉion, kion vi uzos en produktado antaŭ efektivigo.
fonto: www.habr.com