Roj baş, ez dixwazim ezmûna xwe ya di sazkirin û karanîna karûbarê AWS EKS (Xizmeta Elastic Kubernetes) ji bo konteynerên Windows-ê, an bêtir li ser nemimkûniya karanîna wê, û xeletiya ku di konteynera pergala AWS de hatî dîtin, bi we re parve bikim. yên ku ji bo konteynerên Windows-ê bi vê karûbarê re eleqedar dibin, ji kerema xwe li binê pisîkê.
Ez dizanim ku konteynerên Windows-ê ne mijarek populer in, û hindik kes wan bikar tînin, lê dîsa jî min biryar da ku vê gotarê binivîsim, ji ber ku li ser Habré li ser kubernetes û Windows-ê çend gotar hebûn û hîn jî kesên weha hene.
Destpêka
Hemî gava ku biryar hat dayîn ku karûbarên di pargîdaniya me de koçberî kubernetes, ku 70% Windows û 30% Linux ye, dest pê kir. Ji bo vê armancê, karûbarê cloudê AWS EKS wekî yek ji vebijarkên gengaz hate hesibandin. Heya 8ê Cotmeha 2019-an, AWS EKS Windows di Pêşniyara Giştî de bû, min pê re dest pê kir, guhertoya kevn a 1.11 ya kubernetes li wir hate bikar anîn, lê min biryar da ku wê her weha kontrol bikim û bibînim ka ev karûbarê ewr di kîjan qonaxê de ye, gelo ew dixebite qet nebe, wek ku derket, na, ew bi lêzêdekirina rakirina potan re xeletiyek hebû, dema ku yên kevin bi riya ip-ya hundurîn a ji heman subtorê wekî girêka xebatkarê windows-ê bersiv sekinîn.
Ji ber vê yekê, biryar hate dayîn ku em dev ji karanîna AWS EKS berdin di berjewendiya koma xwe ya li ser kubernetes de li ser heman EC2-ê, tenê em neçar in ku hemî hevseng û HA-ya xwe bi navgîniya CloudFormation vebêjin.
Piştgiriya konteynerê ya Amazon EKS Windows Naha Bi gelemperî Berdest e
ji hêla Martin Beeby | di 08 OCT 2019 de
Berî ku min wext hebe ku ji bo koma xwe şablonek li CloudFormation zêde bikim, min ev nûçe dît
Bê guman, min hemî karê xwe danî aliyekî û dest bi lêkolînê kir ku wan ji bo GA çi kir, û çawa her tişt bi Pêşniyara Giştî re guherî. Erê, AWS, baş kir, wêneyên ji bo girêka xebatkarê Windows-ê nûve kir guhertoya 1.14, û hem jî komê bixwe, guhertoya 1.14 di EKS de, naha girêkên windows piştgirî dike. Projeya ji hêla Pêşniyara Giştî ve li Wan ew veşart û got naha belgeya fermî li vir bikar bînin:
Yekkirina komek EKS di nav VPC û subnetên heyî de
Di hemî çavkaniyan de, di zencîreya jorîn a li ser ragihandinê de û hem jî di belgeyê de, hate pêşniyar kirin ku komê bi navgîniya kargêriya xwedan eksctl an jî bi navgîniya CloudFormation + kubectl ve were bicîh kirin, tenê bi karanîna jêrtorên gelemperî li Amazon-ê, û her weha afirandina a VPC ji bo komek nû veqetînin.
Ev vebijark ji bo pir kesan ne maqûl e; yekem, VPC-yek cihêreng tê wateya lêçûnên zêde ji bo lêçûna wê + seyrûsefera hevberdanê ya li VPC-ya weya heyî. Yên ku berê xwedan binesaziyek amadekirî di AWS-ê de bi hesabên xwe yên Pirjimar AWS, VPC, subnets, tabloyên rêgezê, deriyê derbasbûnê û hwd re divê çi bikin? Bê guman, hûn nexwazin van hemîyan bişkînin an ji nû ve bikin, û hûn hewce ne ku koma nû ya EKS-ê di binesaziya torê ya heyî de yek bikin, VPC-ya heyî bikar bînin û, ji bo veqetandinê, herî zêde ji bo komê jêrtorokên nû biafirînin.
Di doza min de, ev rê hate bijartin, min VPC-ya heyî bikar anî, ji bo koma nû tenê 2 jêrtorên giştî û 2 jêrtorên taybet lê zêde kirin, bê guman, hemî qaîdeyên li gorî belgeyan hatin girtin. .
Di heman demê de yek şertek jî hebû: di jêrtorên gelemperî de girêkên karker ên ku EIP bikar tînin tune.
eksctl vs CloudFormation
Ez ê tavilê rezervasyonek bikim ku min her du awayên bicîhkirina komê ceriband, di her du rewşan de jî wêne yek bû.
Ez ê mînakek tenê bi karanîna eksctl nîşan bidim ji ber ku koda li vir dê kurttir be. Bi karanîna eksctl, komê di 3 gavan de bicîh bikin:
1. Em komê bi xwe + girêka xebatkarê Linuxê diafirînin, ku paşê dê konteynerên pergalê û heman vpc-kontrolkerê nexweş bihewîne.
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-networkingJi bo ku hûn li VPC-ya heyî bicîh bikin, tenê id-ya jêr-torayên xwe diyar bikin, û eksctl dê VPC-ê bixwe diyar bike.
Ji bo ku pê ewle bin ku girêkên we yên karker tenê li ser jêrtorek taybetî têne bicîh kirin, hûn hewce ne ku ji bo nodegroup -node-private-networking diyar bikin.
2. Em di koma xwe de vpc-kontroller saz dikin, ku wê dûv re girêkên me yên xebatkar bişopîne, hejmara navnîşanên IP-ya belaş, û her weha hejmara ENI-yên li ser nimûneyê bijmêre, wan zêde bike û jê rake.
eksctl utils install-vpc-controllers --name yyy --approve3.Piştî ku konteynerên pergala we bi serfirazî li ser girêka weya xebatkarê Linux-ê, tevî vpc-kontroller, dest pê kirin, ya ku dimîne ev e ku hûn bi xebatkarên windows re komeke din ava bikin.
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-networkingPiştî ku girêka we bi serfirazî bi koma we ve hat girêdan û her tişt baş xuya dike, ew di statûya Amade ye, lê na.
Di vpc-kontroller de çewtî
Ger em hewl bidin ku pod li ser girêkek xebatkarê Windows-ê bimeşînin, em ê xeletiyê bistînin:
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]Ger em kûr binihêrin, em dibînin ku mînaka me di AWS de wiha xuya dike:
Û divê wisa be:
Ji vê yekê diyar e ku vpc-kontroller ji ber hin sedeman beşa xwe pêk neaniye û nekariye navnîşanên IP-ya nû li nimûneyê zêde bike da ku pod bikaribe wan bikar bîne.
Ka em li têketinên vpc-kontroller pod binêrin û tiştê ku em dibînin ev e:
kubectl têketin -n kube-sîstema
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.Lêgerînên li ser Google-ê negihîştin tiştek, ji ber ku xuya ye ku hêj kesek xeletiyek wusa negirtiye, an pirsgirêkek li ser nekiriye, min neçar ma ku pêşî li vebijarkan bifikirim. Yekem tiştê ku hat bîra min ev bû ku dibe ku vpc-kontroller nikaribe ip-10-xxx.ap-xxx.compute.internal çareser bike û bigihîje wê û ji ber vê yekê xeletî çêdibin.
Erê, bi rastî, em di VPC-ê de serverên DNS-ya xwerû bikar tînin û, di prensîbê de, em yên Amazon-ê bikar neynin, ji ber vê yekê jî şandin ji bo vê domaina ap-xxx.compute.internal nehat mîheng kirin. Min ev vebijark ceriband, û ew encam negirt, dibe ku ceribandin ne paqij bû, û ji ber vê yekê, bêtir, dema ku bi piştgiriya teknîkî re danûstendinê, ez ketim ber ramana wan.
Ji ber ku bi rastî ti raman tune bûn, hemî komên ewlehiyê ji hêla eksctl bixwe ve hatine afirandin, ji ber vê yekê guman di karûbarê wan de tune bû, tabloyên rêgezê jî rast bûn, nat, dns, gihandina înternetê ya bi girêkên karkeran jî hebû.
Wekî din, heke hûn bêyî karanîna -node-taybet-tora girêkek xebatkar li jêrtorek gelemperî bicîh bikin, ev girê tavilê ji hêla vpc-kontrolker ve hate nûve kirin û her tişt mîna demjimêrê xebitî.
Du vebijark hebûn:
- Dev jê berdin û li bendê bin heya ku kesek vê xeletiyê di AWS-ê de diyar bike û ew wê rast bike, û dûv re hûn dikarin bi ewlehî AWS EKS Windows-ê bikar bînin, ji ber ku ew nû di GA-yê de berdan (8 roj di dema nivîsandina vê gotarê de derbas bûne), dibe ku pir kes bi min re heman rê bişopîne.
- Ji Piştgiriya AWS-ê re binivîsin û bi komek têketin ji her deverê re bingeha pirsgirêkê ji wan re vebêjin û ji wan re îspat bikin ku dema ku hûn VPC û subnetên we bikar tînin karûbarê wan naxebite, ne ji bo tiştek e ku me piştgirîya Karsaziyê hebû, divê hûn bikar bînin. bi kêmanî carekê :)
Têkilî bi endezyarên AWS re
Dema ku bilêtek li ser portalê çêkir, min bi xeletî hilbijart ku ez bi riya Web - e-name an navenda piştgiriyê bersivê bidim min, bi vê vebijarkê ew dikarin piştî çend rojan bi tevahî bersivê bidin we, tevî ku bilêta min Zêdetir bû - Pergal xera bû, ku tê wateya bersivek di nav <12 demjimêran de, û ji ber ku plana Piştgiriya Karsaziyê 24/7 piştgirî heye, min hêviya çêtirîn kir, lê ew wekî her gav derket.
Bilêta min ji Îniyê heta Duşemê bê tayîn hişt, dûv re min biryar da ku ez dîsa ji wan re binivîsim û vebijarka bersiva Chat hilbijartim. Piştî ku demek kurt li bendê ma, Harshad Madhav hat tayîn kirin ku min bibîne, û dûv re dest pê kir ...
Me 3 saetan li pey hev bi wê re serhêl debug kir, têketin veguhezand, heman komê di laboratûara AWS-ê de bicîh kir da ku pirsgirêkê bişopîne, ji hêla min ve komê ji nû ve afirand, û hwd, tenê tiştê ku em gihîştinê ev e ku ji têketin eşkere bû ku çareserî navên domaina navxweyî ya AWS-ê naxebite, yên ku min li jor nivîsand, û Harshad Madhav ji min xwest ku ez şandinê biafirînim, qaşo em DNS-ya xwerû bikar tînin û ev dikare bibe pirsgirêk.
Forwarding
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Ya ku hat kirin ev bû, roj bi dawî bû. Harshad Madhav vegerî nivîsand da ku wê kontrol bike û divê ew bixebite, lê na, çareserî bi tu awayî ne alîkar bû.
Dûv re bi 2 endezyarên din re pêwendiyek çêbû, yek bi tenê dev ji sohbetê berda, xuya ye ku ew ji dozek tevlihev ditirse, ya duyemîn roja min dîsa li ser çerxek bêkêmasî ya xeletkirinê, şandina têketin, çêkirina koman li her du aliyan, li dawiya wî tenê got baş e, ew ji min re dixebite, li vir ez im ez her tiştî gav bi gav di belgeyên fermî de dikim û hûn û hûn ê biserkevin.
Li ser vê yekê min bi nermî jê pirsî ku ger hûn nizanin li ku derê li pirsgirêkê bigerin, derkeve û yekî din li bilêta min bide.
Dawîn
Di roja sisiyan de endezyarekî nû Arun B. ji min re hat tayînkirin û ji destpêka pêwendiya bi wî re yekser diyar bû ku ev ne 3 endezyarên berê ne. Wî tevahiya dîrok xwend û tavilê xwest ku bi karanîna nivîsara xwe ya li ser ps1, ku li ser github-a wî bû, têketin berhev bike. Dûv re dîsa hemî dubareyên çêkirina koman, derxistina encamên fermanê, berhevkirina têketin peyda bû, lê Arun B. li gorî pirsên ku ji min hatin kirin dadbar di rêça rast de diçû.
Kengî em gihîştin nuqteya çalakkirina -stderrthreshold=debug di vpc-kontrolkerê wan de, û paşê çi qewimî? bê guman ew naxebite) pod bi vê vebijarkê dest pê nake, tenê -stderrthreshold=info dixebite.
Me li vir qedand û Arun B. got ku ew ê hewl bide ku gavên min dubare bike da ku heman xeletiyê bigire. Dotira rojê ez bersivek ji Arun B. distînim, wî dev ji vê dozê berneda, lê koda vekolînê ya vpc-kontrolerê wan girt û cîhê ku ew lê ye û çima naxebite dît:
Ji ber vê yekê, heke hûn di VPC-ya xwe de tabloya rêça sereke bikar bînin, wê hingê ew bi xwerû bi jêrtorên pêwîst re, yên ku ji bo vpc-kontrolker ew qas hewce ne re têkildar in, di doza jêrtorek gelemperî de, wê tabloyek rêgezek xwerû heye. ku komeleyek heye.
Bi lêzêdekirina bi destan komeleyên ji bo tabloya rêça sereke bi jêrtorêkên pêwîst re, û ji nû ve avakirina koma node, her tişt bêkêmasî dixebite.
Ez hêvî dikim ku Arun B. bi rastî dê vê xeletiyê ji pêşdebirên EKS re ragihîne û em ê guhertoyek nû ya vpc-kontrollerê bibînin ku dê her tişt ji qutiyê bixebite. Niha guhertoya herî dawî ev e: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ev pirsgirêk heye.
Spas ji her kesê ku heya dawiyê dixwîne, berî bicîhkirinê her tiştê ku hûn ê di hilberînê de bikar bînin ceribandin.
Source: www.habr.com