Maayong hapon, gusto nako nga ipaambit kanimo ang akong kasinatian sa pag-set up ug paggamit sa serbisyo sa AWS EKS (Elastic Kubernetes Service) para sa mga sudlanan sa Windows, o labi pa bahin sa imposible sa paggamit niini, ug ang bug nga nakit-an sa sulud sa sistema sa AWS, alang sa mga kinsa interesado niini nga serbisyo para sa mga sudlanan sa Windows, palihog ubos sa iring.
Nahibal-an ko nga ang mga sudlanan sa Windows dili usa ka popular nga hilisgutan, ug pipila ka mga tawo ang naggamit niini, apan nakahukom gihapon ako nga isulat kini nga artikulo, tungod kay adunay usa ka magtiayon nga mga artikulo sa Habré sa kubernetes ug Windows ug adunay ingon nga mga tawo.
Начало
Nagsugod ang tanan sa dihang nakahukom nga ibalhin ang mga serbisyo sa among kompanya sa mga kubernetes, nga mao ang 70% Windows ug 30% Linux. Alang niini nga katuyoan, ang serbisyo sa panganod sa AWS EKS giisip nga usa sa mga posible nga kapilian. Hangtud sa Oktubre 8, 2019, ang AWS EKS Windows naa sa Public Preview, gisugdan nako kini, ang daan nga 1.11 nga bersyon sa mga kubernetes gigamit didto, apan nakahukom ko nga susihon kini ug tan-awon kung unsang yugto kini nga serbisyo sa panganod, kung nagtrabaho ba kini. sa tanan, ingon nga kini nahimo, dili, kini adunay usa ka bug nga adunay pagdugang sa pagtangtang sa mga pod, samtang ang mga tigulang mihunong sa pagtubag pinaagi sa internal nga ip gikan sa parehas nga subnet sama sa windows worker node.
Busa, nakahukom nga biyaan ang paggamit sa AWS EKS pabor sa atong kaugalingong cluster sa mga kubernetes sa samang EC2, kinahanglan lang natong ihulagway ang tanan nga pagbalanse ug HA sa atong kaugalingon pinaagi sa CloudFormation.
Ang Suporta sa Amazon EKS Windows Container karon Kasagaran nga Anaa
ni Martin Beeby | sa 08 OKT 2019
Sa wala pa ako adunay panahon sa pagdugang usa ka template sa CloudFormation alang sa akong kaugalingon nga cluster, nakita nako kini nga balita
Siyempre, gisalikway nako ang tanan nakong trabaho ug nagsugod sa pagtuon kung unsa ang ilang gibuhat para sa GA, ug kung giunsa ang pagbag-o sa tanan sa Public Preview. Oo, AWS, maayong pagkabuhat, gi-update ang mga imahe alang sa windows worker node sa bersyon 1.14, ingon man ang cluster mismo, bersyon 1.14 sa EKS, karon nagsuporta sa mga node sa windows. Proyekto pinaagi sa Public Preview sa Gitabonan nila kini ug giingon nga gamiton karon ang opisyal nga dokumentasyon dinhi:
Pag-integrate sa EKS cluster sa kasamtangang VPC ug mga subnet
Sa tanan nga mga gigikanan, sa link sa ibabaw sa pahibalo ingon man sa dokumentasyon, gisugyot nga ipakaylap ang cluster pinaagi sa proprietary eksctl utility o pinaagi sa CloudFormation + kubectl pagkahuman, gamit lamang ang mga pampublikong subnet sa Amazon, ingon man paghimo og usa ka bulag nga VPC para sa bag-ong cluster.
Kini nga opsyon dili angay alang sa kadaghanan; una, ang usa ka bulag nga VPC nagpasabut nga dugang nga mga gasto alang sa gasto + sa pagtan-aw sa trapiko sa imong karon nga VPC. Unsa man ang kinahanglan buhaton sa mga adunay andam na nga imprastraktura sa AWS nga adunay ilang kaugalingon nga Multiple AWS account, VPC, subnets, mga lamesa sa ruta, agianan sa transit ug uban pa? Siyempre, dili nimo gusto nga bungkagon o usbon kining tanan, ug kinahanglan nimo nga i-integrate ang bag-ong EKS cluster ngadto sa kasamtangan nga imprastraktura sa network, gamit ang kasamtangan nga VPC ug, alang sa pagbulag, sa kadaghanan paghimo og bag-ong mga subnet alang sa cluster.
Sa akong kaso, gipili kini nga dalan, gigamit nako ang kasamtangan nga VPC, gidugang lamang ang 2 nga mga pampublikong subnet ug 2 nga mga pribadong subnet alang sa bag-ong cluster, siyempre, ang tanan nga mga lagda gikonsiderar sumala sa dokumentasyon. .
Adunay usab usa ka kondisyon: walay worker node sa mga pampublikong subnet gamit ang EIP.
eksctl batok sa CloudFormation
Maghimo ako usa ka reserbasyon dayon nga akong gisulayan ang duha nga mga pamaagi sa pag-deploy sa usa ka kumpol, sa parehas nga mga kaso parehas ang litrato.
Magpakita ako usa ka pananglitan gamit lamang ang eksctl tungod kay ang code dinhi mas mubo. Gamit ang eksctl, i-deploy ang cluster sa 3 ka lakang:
1. Among gimugna ang cluster mismo + Linux worker node, nga sa ulahi mag-host sa mga sudlanan sa sistema ug sa samang dili maayo nga 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-networkingAron ma-deploy sa usa ka kasamtangan nga VPC, itakda lang ang id sa imong mga subnet, ug ang eksctl ang magdeterminar sa VPC mismo.
Aron masiguro nga ang imong mga worker node na-deploy lamang sa usa ka pribado nga subnet, kinahanglan nimo nga ipiho ang --node-private-networking para sa nodegroup.
2. Gi-install namo ang vpc-controller sa among cluster, nga magproseso unya sa among mga worker node, pag-ihap sa gidaghanon sa mga libreng IP address, ingon man sa gidaghanon sa ENI sa pananglitan, pagdugang ug pagtangtang niini.
eksctl utils install-vpc-controllers --name yyy --approve3.Human ang imong mga sudlanan sa sistema malampuson nga gilunsad sa imong Linux worker node, lakip ang vpc-controller, ang nahabilin mao ang paghimo og laing nodegroup nga adunay mga trabahante sa bintana.
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-networkingHuman ang imong node malampuson nga konektado sa imong cluster ug ang tanan ingon og maayo, kini anaa sa Ready status, apan dili.
Sayop sa vpc-controller
Kung sulayan namon ang pagpadagan sa mga pod sa usa ka windows worker node, makuha namon ang sayup:
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]Kung atong tan-awon ang mas lawom, atong makita nga ang atong instance sa AWS ingon niini:
Ug kini kinahanglan nga ingon niini:
Gikan niini klaro nga ang vpc-controller wala makatuman sa iyang bahin sa usa ka rason ug dili makadugang sa bag-ong mga IP address sa pananglitan aron ang mga pod makagamit niini.
Atong tan-awon ang mga log sa vpc-controller pod ug mao kini ang atong makita:
kubectl log -n kube-system
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.Ang mga pagpangita sa Google wala magdala sa bisan unsa, tungod kay dayag nga wala'y usa nga nakadakop sa ingon nga bug, o wala pa mag-post og isyu niini, kinahanglan nakong hunahunaon una ang mga kapilian sa akong kaugalingon. Ang una nga butang nga naa sa hunahuna mao nga tingali ang vpc-controller dili makasulbad sa ip-10-xxx.ap-xxx.compute.internal ug maabot kini ug busa adunay mga sayup.
Oo, sa tinuud, gigamit namon ang mga kostumbre nga DNS server sa VPC ug, sa prinsipyo, wala kami mogamit sa mga Amazon, mao nga bisan ang pagpasa wala ma-configure alang niining ap-xxx.compute.internal nga domain. Gisulayan nako kini nga kapilian, ug wala kini magdala og mga resulta, tingali ang pagsulay dili limpyo, ug busa, dugang pa, sa dihang nakigsulti sa teknikal nga suporta, midaog ako sa ilang ideya.
Tungod kay wala'y bisan unsa nga mga ideya, ang tanan nga mga grupo sa seguridad gimugna sa eksctl mismo, mao nga walay pagduhaduha mahitungod sa ilang serbisyo, ang mga lamesa sa ruta husto usab, nat, dns, Internet access nga adunay mga worker node anaa usab.
Dugang pa, kung imong i-deploy ang usa ka worker node sa usa ka publiko nga subnet nga wala mogamit —node-private-networking, kini nga node gi-update dayon sa vpc-controller ug ang tanan nagtrabaho sama sa orasan.
Adunay duha nga kapilian:
- Ihatag kini ug paghulat hangtud nga adunay usa nga naghulagway niini nga bug sa AWS ug ila kining ayohon, ug unya luwas nga magamit nimo ang AWS EKS Windows, tungod kay bag-o lang silang gipagawas sa GA (8 ka adlaw ang milabay sa panahon sa pagsulat niini nga artikulo), daghan tingali ang subay sa akong dalan .
- Pagsulat sa Suporta sa AWS ug sultihi sila sa esensya sa problema sa usa ka bug-os nga hugpong sa mga troso gikan sa bisan diin ug pamatud-i kanila nga ang ilang serbisyo dili molihok kung gigamit ang imong VPC ug mga subnet, wala’y hinungdan nga kami adunay suporta sa Negosyo, kinahanglan nimo gamiton labing menos kausa :)
Komunikasyon sa mga inhenyero sa AWS
Ang paghimo og tiket sa portal, nasayop ko nga mipili sa pagtubag kanako pinaagi sa Web - email o support center, pinaagi niini nga opsyon sila makatubag kanimo human sa pipila ka adlaw, bisan pa sa kamatuoran nga ang akong tiket adunay Severity - System impaired, nga nagpasabot og tubag sulod sa <12 ka oras, ug tungod kay ang plano sa suporta sa Negosyo adunay 24/7 nga suporta, ako naglaum alang sa labing maayo, apan kini nahimo sama sa kanunay.
Ang akong tiket wala ma-assign gikan sa Biyernes hangtod sa Lunes, unya nakahukom ko nga sulatan sila pag-usab ug gipili ang opsyon sa pagtubag sa Chat. Human sa paghulat sa mubo nga panahon, si Harshad Madhav gitudlo nga makigkita kanako, ug dayon nagsugod kini...
Gi-debug namon kini online sulod sa 3 ka oras nga sunud-sunod, pagbalhin sa mga troso, pag-deploy sa parehas nga cluster sa laboratoryo sa AWS aron masundog ang problema, paghimo pag-usab sa cluster sa akong bahin, ug uban pa, ang bugtong butang nga among naabut mao nga gikan sa ang mga troso tin-aw nga ang resol wala nagtrabaho sa AWS internal nga mga ngalan sa domain, nga akong gisulat mahitungod sa ibabaw, ug gihangyo ako ni Harshad Madhav sa paghimo sa pagpasa, giingong naggamit kami og custom DNS ug kini mahimong usa ka problema.
Pagpadayon
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Mao kana ang nahimo, nahuman na ang adlaw. Si Harshad Madhav misulat og balik aron susihon kini ug kini kinahanglan nga molihok, apan dili, ang resolusyon wala gayud makatabang.
Pagkahuman adunay komunikasyon sa 2 pa nga mga inhenyero, ang usa nahulog gikan sa chat, dayag nga nahadlok siya sa usa ka komplikado nga kaso, ang ikaduha migahin sa akong adlaw pag-usab sa usa ka bug-os nga siklo sa pag-debug, pagpadala sa mga troso, paghimo og mga pungpong sa duha ka kilid, sa katapusan maayo ra ang giingon niya, kini nagtrabaho alang kanako, ania ako buhaton ang tanan nga lakang sa lakang sa opisyal nga dokumentasyon ug ikaw ug ikaw magmalampuson.
Nga matinahuron ko nga gihangyo siya nga mobiya ug mag-assign og lain sa akong tiket kung wala ka mahibal-an kung asa pangitaon ang problema.
Kataposan
Sa ikatulo nga adlaw, usa ka bag-ong inhenyero nga si Arun B. ang gi-assign kanako, ug gikan sa sinugdanan sa komunikasyon uban kaniya klaro dayon nga dili kini ang 3 nga nauna nga mga inhenyero. Gibasa niya ang tibuuk nga kasaysayan ug gihangyo dayon nga kolektahon ang mga troso gamit ang iyang kaugalingon nga script sa ps1, nga naa sa iyang github. Gisundan kini pag-usab sa tanan nga mga pag-usab sa paghimo og mga pungpong, pag-output sa mga resulta sa command, pagkolekta og mga troso, apan si Arun B. naglihok sa husto nga direksyon sa paghukom sa mga pangutana nga gipangutana kanako.
Kanus-a kami nakaabot sa punto nga makapahimo -stderrthreshold=debug sa ilang vpc-controller, ug unsa ang sunod nga nahitabo? siyempre dili kini molihok) ang pod wala magsugod sa kini nga kapilian, lamang -stderrthreshold=info ang nagtrabaho.
Nahuman mi diri ug niingon si Arun B. nga sulayan niya nga i-reproduce ang akong mga lakang aron makuha ang parehas nga sayup. Pagkasunod adlaw nakadawat ko og tubag gikan ni Arun B. wala niya gibiyaan kini nga kaso, apan gikuha ang review code sa ilang vpc-controller ug nakit-an ang lugar kung asa kini ug ngano nga wala kini molihok:
Busa, kung imong gigamit ang main nga ruta nga lamesa sa imong VPC, nan pinaagi sa default wala kini mga asosasyon sa kinahanglan nga mga subnet, nga kinahanglanon kaayo alang sa vpc-controller, sa kaso sa usa ka publiko nga subnet, kini adunay usa ka naandan nga lamesa sa ruta. nga adunay asosasyon.
Pinaagi sa mano-mano nga pagdugang mga asosasyon alang sa main nga ruta nga lamesa nga adunay kinahanglan nga mga subnet, ug paghimo pag-usab sa nodegroup, ang tanan molihok nga hingpit.
Nanghinaut ko nga i-report gyud ni Arun B. kini nga bug sa mga developer sa EKS ug makakita kami usa ka bag-ong bersyon sa vpc-controller diin ang tanan molihok sa gawas sa kahon. Sa pagkakaron ang pinakabag-o nga bersyon mao ang: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
adunay kini nga problema.
Salamat sa tanan nga nagbasa hangtod sa katapusan, sulayi ang tanan nga imong gamiton sa produksiyon sa wala pa ipatuman.
Source: www.habr.com