Goeiemiddei, ik wol myn ûnderfining mei jo diele yn it opsetten en brûken fan de AWS EKS (Elastic Kubernetes Service) tsjinst foar Windows-konteners, of leaver oer de ûnmooglikheid om it te brûken, en de brek fûn yn 'e AWS-systeemcontainer, foar dyjingen dy't ynteressearre binne yn dizze tsjinst foar Windows-konteners, asjebleaft ûnder kat.
Ik wit dat Windows-konteners net in populêr ûnderwerp binne, en in pear minsken brûke se, mar ik besleat dochs dit artikel te skriuwen, om't d'r in pear artikels wiene oer Habré op kubernetes en Windows en d'r binne noch sokke minsken.
Thús
It begon allegear doe't it waard besletten om de tsjinsten yn ús bedriuw te migrearjen nei kubernetes, dat is 70% Windows en 30% Linux. Foar dit doel waard de AWS EKS-wolktsjinst beskôge as ien fan 'e mooglike opsjes. Oant 8 oktober 2019 wie AWS EKS Windows yn Public Preview, ik begon dermei, de âlde 1.11 ferzje fan kubernetes waard dêr brûkt, mar ik besleat it dochs te kontrolearjen en te sjen yn hokker stadium dizze wolktsjinst wie, oft it wurke at all, sa die bliken út, nee, it wie der in brek mei de tafoeging fan it fuortheljen fan pods, wylst de âlde stoppe te reagearjen fia ynterne ip út deselde subnet as de finsters arbeider node.
Dêrom waard besletten om it gebrûk fan AWS EKS te ferlitten yn it foardiel fan ús eigen kluster op kubernetes op deselde EC2, allinich soene wy alle balânsjen en HA sels moatte beskriuwe fia CloudFormation.
Amazon EKS Windows Container Support no algemien beskikber
by Martin Beeby | op 08 oktober 2019
Foardat ik tiid hie om in sjabloan ta te foegjen oan CloudFormation foar myn eigen kluster, seach ik dit nijs
Fansels sette ik al myn wurk oan 'e kant en begon te studearjen wat se diene foar GA, en hoe't alles feroare mei Public Preview. Ja, AWS, goed dien, bywurke de ôfbyldings foar Windows Worker Node nei ferzje 1.14, lykas it kluster sels, ferzje 1.14 yn EKS, stipet no Windows-knooppunten. Projekt troch Public Preview at Se besloegen it en seine no brûk de offisjele dokumintaasje hjir:
Yntegrearje fan in EKS-kluster yn 'e hjoeddeistige VPC en subnetten
Yn alle boarnen, yn 'e keppeling hjirboppe op' e oankundiging as yn 'e dokumintaasje, waard foarsteld om it kluster yn te setten fia it proprietêre eksctl-hulpprogramma of fia CloudFormation + kubectl nei, allinich mei gebrûk fan iepenbiere subnets yn Amazon, en ek it meitsjen fan in aparte VPC foar in nij kluster.
Dizze opsje is net geskikt foar in protte, earst, in aparte VPC betsjut ekstra kosten foar syn kosten + peeringferkear nei jo hjoeddeistige VPC. Wat moatte dejingen dy't al in klearmakke ynfrastruktuer hawwe yn AWS mei har eigen Meardere AWS-akkounts, VPC, subnets, rûtetabellen, transitgateway ensafuorthinne? Fansels wolle jo dit alles net brekke of opnij meitsje, en jo moatte it nije EKS-kluster yntegrearje yn 'e hjoeddeistige netwurkynfrastruktuer, mei de besteande VPC en, foar skieding, op syn heechst nije subnetten meitsje foar it kluster.
Yn myn gefal waard dit paad keazen, ik brûkte de besteande VPC, tafoege allinich 2 iepenbiere subnets en 2 privee subnets foar it nije kluster, fansels, alle regels waarden rekken holden neffens de dokumintaasje .
D'r wie ek ien betingst: gjin arbeidersknooppunten yn iepenbiere subnetten dy't EIP brûke.
eksctl vs CloudFormation
Ik sil fuortdaliks reservearje dat ik beide metoaden foar it ynsetten fan in kluster besocht, yn beide gefallen wie it byld itselde.
Ik sil in foarbyld sjen litte allinich mei eksctl, om't de koade hjir koarter sil wêze. Mei eksctl, ynset it kluster yn 3 stappen:
1. Wy meitsje it kluster sels + Linux-wurkerknooppunt, dy't letter systeemkonteners sil hostje en dy selde ûngelokkige vpc-controller.
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-networkingOm te ynsetten nei in besteande VPC, spesifisearje gewoan de id fan jo subnets, en eksctl sil de VPC sels bepale.
Om derfoar te soargjen dat jo wurkknooppunten allinich wurde ynset op in privee subnet, moatte jo --node-private-netwurking foar nodegroup spesifisearje.
2. Wy ynstallearje vpc-controller yn ús kluster, dy't dan ús arbeidersknooppunten ferwurkje, it oantal fergese IP-adressen telle, lykas it oantal ENI's op it eksimplaar, tafoegje en fuortsmite.
eksctl utils install-vpc-controllers --name yyy --approve3. Neidat jo systeemkonteners mei súkses lansearre binne op jo Linux-wurkerknooppunt, ynklusyf vpc-controller, alles wat bliuwt is om in oare knooppuntgroep te meitsjen mei Windows-wurkers.
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-networkingNei't jo knooppunt mei súkses ferbûn is mei jo kluster en alles liket goed te wêzen, is it yn Ready-status, mar nee.
Flater yn vpc-controller
As wy besykje pods út te fieren op in Windows-wurkerknooppunt, krije wy de flater:
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]As wy djipper sjogge, sjogge wy dat ús eksimplaar yn AWS der sa útsjocht:
En it moat sa wêze:
Dêrút is it dúdlik dat de vpc-controller har diel om ien of oare reden net foldie en koe gjin nije IP-adressen tafoegje oan it eksimplaar, sadat de pods se kinne brûke.
Litte wy nei de logs fan 'e vpc-controller pod sjen en dit is wat wy sjogge:
kubectl log -n kubussysteem
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.Sykopdrachten op Google leine net ta neat, om't blykber noch gjinien sa'n brek fongen hie, of der gjin probleem op pleatst hie, moast ik earst sels oan opsjes betinke. It earste ding dat yn 't sin kaam wie dat miskien de vpc-controller ip-10-xxx.ap-xxx.compute.internal net oplosse kin en it berikke en dêrom foarkomme flaters.
Ja, yndie, wy brûke oanpaste DNS-tsjinners yn 'e VPC en, yn prinsipe, brûke wy gjin Amazon, dus sels trochstjoeren waard net konfigureare foar dit ap-xxx.compute.internal domein. Ik hifke dizze opsje, en it brocht gjin resultaten, miskien de test wie net skjin, en dêrom, fierder, doe't kommunikaasje mei technyske stipe, ik bezweken oan harren idee.
Sûnt der wiene net echt gjin ideeën, alle feiligens groepen waarden makke troch eksctl sels, dus der wie gjin twifel oer harren tsjinstability, de rûte tabellen wiene ek korrekt, nat, dns, Ynternet tagong mei wurker knopen wie der ek.
Boppedat, as jo in arbeidersknooppunt ynsette nei in iepenbier subnet sûnder —node-private-netwurking te brûken, waard dit knooppunt fuortendaliks bywurke troch de vpc-controller en alles wurke as in klok.
Der wiene twa opsjes:
- Jou it op en wachtsje oant immen dizze brek yn AWS beskriuwt en se reparearje, en dan kinne jo AWS EKS Windows feilich brûke, om't se krekt yn GA frijlitten binne (8 dagen binne ferrûn op it momint fan it skriuwen fan dit artikel), in protte sille wierskynlik folgje itselde paad as my.
- Skriuw nei AWS Support en fertel har de essinsje fan it probleem mei in hiele bosk logs fan oeral en bewize har dat har tsjinst net wurket by it brûken fan jo VPC en subnets, it is net foar neat dat wy saaklike stipe hiene, jo moatte brûke it op syn minst ien kear :)
Kommunikaasje mei AWS-yngenieurs
Nei't ik in kaartsje makke op it portaal, keas ik foar fersin om my te reagearjen fia it web - e-post of stipesintrum, fia dizze opsje kinne se jo nei in pear dagen hielendal antwurdzje, nettsjinsteande it feit dat myn kaartsje Severity - System impaired hie, wat betsjutte in antwurd binnen <12 oeren, en sûnt de Business stipe plan hat 24/7 stipe, Ik hope foar it bêste, mar it die bliken as altyd.
Myn kaartsje waard fan freed oant moandei net tawiisd, doe besleat ik har nochris te skriuwen en keas de opsje Chat-antwurd. Nei in koarte tiid te wachtsjen, waard Harshad Madhav beneamd om my te sjen, en doe begon it ...
Wy hawwe der 3 oeren efterinoar online mei debuggen, logboeken oerbrocht, itselde kluster yn it AWS-laboratoarium ynset om it probleem te emulearjen, it kluster fan myn kant opnij oan te meitsjen, ensafuorthinne, it iennichste wêr't wy oan kamen is dat fan de logs wie it dúdlik dat de resol net wurke AWS ynterne domeinnammen, dêr't ik skreau oer boppe, en Harshad Madhav frege my te meitsjen trochstjoere, allegedly wy brûke oanpaste DNS en dit kin in probleem.
Ferwidering
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Dat is wat dien wie, de dei wie foarby Harshad Madhav skreau werom om it te kontrolearjen en it soe wurkje moatte, mar nee, de resolúsje holp hielendal net.
Doe wie der kommunikaasje mei 2 mear yngenieurs, ien foel gewoan út it petear, blykber wie hy bang foar in komplekse saak, de twadde brocht myn dei wer troch oan in folsleine syklus fan debuggen, ferstjoeren fan logs, it meitsjen fan klusters oan beide kanten, yn 'e ein hy krekt sei goed, it wurket foar my, hjir bin ik doch alles stap foar stap yn 'e offisjele dokumintaasje en do en do silst slagje.
Dêr't ik beleefd frege him te ferlitten en tawize immen oars oan myn kaartsje as jo net witte wêr't te sykjen foar it probleem.
Finale
Op de tredde dei waard my in nije yngenieur Arun B. tawiisd, en fan it begjin fan 'e kommunikaasje mei him wie it fuortendaliks dúdlik dat dit net de 3 eardere yngenieurs wiene. Hy lies de hiele skiednis en frege fuortendaliks om de logs te sammeljen mei syn eigen skript op ps1, dat wie op syn github. Dit waard wer folge troch alle iteraasjes fan it oanmeitsjen fan klusters, it útfieren fan kommando-resultaten, it sammeljen fan logs, mar Arun B. beweecht yn 'e goede rjochting te beoardieljen troch de fragen dy't my steld binne.
Wannear kamen wy op it punt om -stderrthreshold = debug yn har vpc-controller yn te skeakeljen, en wat barde dernei? fansels wurket it net) de pod begjint gewoan net mei dizze opsje, allinich -stderrthreshold=ynfo wurket.
Wy binne hjir klear en Arun B. sei dat hy soe besykje myn stappen te reprodusearjen om deselde flater te krijen. De oare deis krij ik in antwurd fan Arun B. hy hat dizze saak net ferlitten, mar naam de resinsjekoade fan har vpc-controller op en fûn it plak wêr't it is en wêrom it net wurket:
Dus, as jo de haadrûtetabel yn jo VPC brûke, dan hat it standert gjin assosjaasjes mei de nedige subnets, dy't sa nedich binne foar de vpc-controller, yn it gefal fan in iepenbier subnet, hat it in oanpaste rûtetabel dat hat in feriening.
Troch it manuell tafoegjen fan assosjaasjes foar de haadrûtetafel mei de nedige subnetten, en de nodegroep opnij oanmeitsje, wurket alles perfekt.
Ik hoopje dat Arun B. dizze brek echt rapportearje sil oan de EKS-ûntwikkelders en wy sille in nije ferzje fan vpc-controller sjen wêr't alles út 'e doaze sil wurkje. Op it stuit is de lêste ferzje: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
hat dit probleem.
Mei tank oan elkenien dy't lêze oant it ein, test alles wat jo sille brûke yn produksje foar ymplemintaasje.
Boarne: www.habr.com