Gudde Mëtteg, ech wëll mat Iech meng Erfahrung deelen beim AWS EKS (Elastic Kubernetes Service) Service fir Windows Container opzestellen an ze benotzen, oder éischter iwwer d'Onméiglechkeet et ze benotzen, an de Feeler am AWS System Container fonnt, fir déi déi an dësem Service fir Windows Container interesséiert sinn, weg ënner cat.
Ech weess datt Windows Container net e populär Thema sinn, a wéineg Leit benotzen se, awer ech hunn nach ëmmer decidéiert dësen Artikel ze schreiwen, well et e puer Artikelen iwwer Habré op kubernetes a Windows goufen an et sinn nach ëmmer esou Leit.
Den Ufank
Et huet alles ugefaang wéi et decidéiert gouf d'Servicer an eiser Firma op kubernetes ze migréieren, wat 70% Windows an 30% Linux ass. Fir dësen Zweck gouf den AWS EKS Cloud Service als eng vun de méiglechen Optiounen ugesinn. Bis den 8. Oktober 2019 war AWS EKS Windows an der Ëffentlecher Preview, ech hunn domat ugefaang, déi al 1.11 Versioun vu kubernetes gouf do benotzt, awer ech hu beschloss et iwwerhaapt z'iwwerpréiwen an ze kucken a wéi enger Etapp dëse Cloud Service war, ob et funktionnéiert iwwerhaapt, wéi et sech erausstellt, nee, et war e Käfer mat der Zousatz fir Pods ze läschen, während déi al gestoppt hunn iwwer intern IP aus dem selwechte Subnet wéi de Windows Worker Node ze reagéieren.
Dofir gouf decidéiert d'Benotzung vun AWS EKS zugonschte vun eisem eegene Stärekoup op kubernetes op der selwechter EC2 opzeginn, nëmme mir mussen all d'Balancen an HA selwer iwwer CloudFormation beschreiwen.
Amazon EKS Windows Container Support elo allgemeng verfügbar
vum Martin Beeby | den 08. Oktober 2019
Ier ech Zäit hat fir eng Schabloun op CloudFormation fir mäin eegene Cluster ze addéieren, hunn ech dës Neiegkeet gesinn
Natierlech hunn ech all meng Aarbecht op der Säit gesat an ugefaang ze studéieren wat se fir GA gemaach hunn, a wéi alles mam Public Preview geännert huet. Jo, AWS, gutt geschafft, huet d'Biller fir Windows Worker Node op Versioun 1.14 aktualiséiert, souwéi de Cluster selwer, Versioun 1.14 an EKS, ënnerstëtzt elo Windows Noden. Projet vun Ëffentlech Virschau um Si hunn et ofgedeckt a gesot elo benotzt déi offiziell Dokumentatioun hei:
Integratioun vun engem EKS-Cluster an den aktuellen VPC an Subnets
An alle Quellen, am Link hei uewen op der Ukënnegung wéi och an der Dokumentatioun, gouf proposéiert de Cluster entweder duerch de propriétaire eksctl Utility oder duerch CloudFormation + kubectl duerno z'installéieren, nëmmen ëffentlech Subnets an Amazon ze benotzen, souwéi eng Schafung vun engem separat VPC fir en neie Stärekoup.
Dës Optioun ass net gëeegent fir vill; éischtens, eng separat VPC bedeit zousätzlech Käschten fir seng Käschten + Peering Traffic op Ären aktuellen VPC. Wat sollen déi, déi schonn eng fäerdeg Infrastruktur an AWS mat hiren eegene Multiple AWS Konten, VPC, Subnets, Route Dëscher, Transit Gateway an sou weider maachen? Natierlech wëllt Dir dat alles net briechen oder nei maachen, an Dir musst den neien EKS-Cluster an déi aktuell Netzwierkinfrastruktur integréieren, andeems Dir déi existent VPC benotzt an, fir d'Trennung, héchstens nei Subnets fir de Cluster erstellen.
A mengem Fall gouf dëse Wee gewielt, ech hunn déi existent VPC benotzt, nëmmen 2 ëffentlech Subnets an 2 privat Subnets fir den neie Stärekoup bäigefüügt, natierlech goufen all d'Regele berücksichtegt no der Dokumentatioun .
Et war och eng Bedingung: keng Aarbechterknäppchen an ëffentlechen Ënnernetzer déi EIP benotzen.
eksctl vs CloudFormation
Ech reservéieren direkt datt ech béid Methoden probéiert hunn fir e Cluster z'installéieren, a béide Fäll war d'Bild d'selwecht.
Ech weisen e Beispill nëmme mat eksctl well de Code hei méi kuerz wäert sinn. Benotzt eksctl, deploy de Cluster an 3 Schrëtt:
1. Mir kreéieren de Cluster selwer + Linux Worker Node, dee spéider Systembehälter an dee selwechte schlechte vpc-Controller wäert hosten.
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-networkingFir op eng existent VPC z'installéieren, spezifizéiert just d'Id vun Ären Ënnernetzer, an eksctl wäert de VPC selwer bestëmmen.
Fir sécherzestellen datt Är Aarbechtsknäppchen nëmmen op e privaten Subnet ofgesat ginn, musst Dir --node-private-networking fir Nodegroup spezifizéieren.
2. Mir installéieren vpc-Controller an eisem Cluster, deen dann eis Aarbechternoden veraarbecht, d'Zuel vun de gratis IP Adressen zielen, wéi och d'Zuel vun den ENIs op der Instanz, addéieren an ewechhuelen.
eksctl utils install-vpc-controllers --name yyy --approve3.Nodeems Är Systembehälter erfollegräich op Ärem Linux Worker Node lancéiert hunn, inklusiv vpc-Controller, alles wat bleift ass eng aner Nodegroup mat Windows Aarbechter ze kreéieren.
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-networkingNodeems Ären Node erfollegräich mat Ärem Cluster verbonnen ass an alles schéngt gutt ze sinn, ass et am Ready Status, awer nee.
Feeler am vpc-Controller
Wa mir probéieren Pods op engem Windows Worker Node ze lafen, kréie mir de Feeler:
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]Wa mir méi déif kucken, gesi mir datt eis Instanz an AWS esou ausgesäit:
An et soll esou sinn:
Vun dësem ass et kloer datt de vpc-Controller aus irgendege Grënn säin Deel net erfëllt huet an net nei IP Adressen un d'Instanz konnt addéieren, sou datt d'Pods se benotze kënnen.
Loosst eis d'Logbicher vum vpc-Controller Pod kucken an dat ass wat mir gesinn:
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.Sichen op Google hunn zu näischt gefouert, well anscheinend nach keen esou e Käfer gefaangen hat, oder keen Thema drop gepost huet, hunn ech fir d'éischt selwer un Optiounen ze denken. Déi éischt Saach, déi am Kapp komm ass, war datt vläicht de vpc-Controller net ip-10-xxx.ap-xxx.compute.internal léisen kann an et erreechen an dofir Feeler geschéien.
Jo, tatsächlech, mir benotze personaliséiert DNS-Server am VPC a mir benotzen am Prinzip net Amazon, also war och d'Forwarding net fir dës ap-xxx.compute.internal Domain konfiguréiert. Ech hunn dës Optioun getest, an et huet keng Resultater bruecht, vläicht war den Test net propper, an dofir, weider, wann ech mat der technescher Ënnerstëtzung kommunizéieren, sinn ech op hir Iddi gefall.
Well et net wierklech Iddien waren, goufen all Sécherheetsgruppen vun eksctl selwer erstallt, sou datt et keen Zweifel iwwer hir Servicebarkeet war, d'Routetabelle waren och korrekt, nat, dns, Internetzougang mat Aarbechternoden war och do.
Ausserdeem, wann Dir en Aarbechter Node an en ëffentlechen Subnet ofsetzt ouni -Node-private-Networking ze benotzen, gouf dësen Node direkt vum vpc-Controller aktualiséiert an alles huet geschafft wéi Auerwierk.
Et waren zwou Méiglechkeeten:
- Gitt et op a waart bis een dëse Feeler an AWS beschreift a se fixéieren, an da kënnt Dir sécher AWS EKS Windows benotzen, well se just a GA verëffentlecht sinn (8 Deeg sinn vergaangen zum Zäitpunkt vum Schreiwen vun dësem Artikel), vill wäerten wahrscheinlech verfollegen dee selwechte Wee wéi ech.
- Schreift op AWS Support a sot hinnen d'Essenz vum Problem mat enger ganzer Rëtsch vu Logbicher vun iwwerall a beweist hinnen datt hire Service net funktionnéiert wann Dir Äre VPC an Subnets benotzt, et ass net fir näischt datt mir Business Support haten, Dir sollt benotzen op d'mannst eemol :)
Kommunikatioun mat AWS Ingenieuren
Nodeems ech en Ticket um Portal erstallt hunn, hunn ech falsch gewielt fir mech iwwer Web - E-Mail oder Supportcenter ze äntweren, duerch dës Optioun kënnen se Iech iwwerhaapt no e puer Deeg äntweren, trotz der Tatsaach datt mäi Ticket Schwéierkraaft - System behënnert huet, wat bedeit eng Äntwert bannent <12 Stonnen, a well de Business Support Plang 24/7 Ënnerstëtzung huet, hunn ech op dat Bescht gehofft, awer et huet sech erausgestallt wéi ëmmer.
Mäi Ticket gouf vu Freideg bis Méindes net zougewisen gelooss, dunn hunn ech decidéiert hinnen nach eng Kéier ze schreiwen an d'Chat-Äntwertoptioun gewielt. No enger kuerzer Zäit gewaart gouf den Harshad Madhav ernannt fir mech ze gesinn, an dunn huet et ugefaang ...
Mir hunn et online fir 3 Stonnen hannereneen debugged, Logbicher iwwerdroen, deeselwechte Cluster am AWS Laboratoire ofgesat fir de Problem ze emuléieren, de Cluster vu mengem Deel nei erstallt, an sou weider, dat eenzegt wat mir ukomm sinn ass datt vun d'Logbicher war et kloer datt d'Resol net funktionnéiert AWS intern Domain Nimm, iwwer déi ech uewen geschriwwen hunn, an den Harshad Madhav huet mech gefrot fir Forwarding ze kreéieren, angeblech benotze mir personaliséiert DNS an dëst kéint e Problem sinn.
Forwarding
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Dat ass wat gemaach gouf, den Dag war eriwwer.Harshad Madhav huet zréck geschriwwen fir et ze kontrolléieren an et sollt funktionnéieren, awer nee, d'Resolutioun huet guer net gehollef.
Duerno gouf et Kommunikatioun mat 2 weideren Ingenieuren, een ass einfach aus dem Chat gefall, anscheinend hat hien Angscht virun engem komplexe Fall, deen zweeten huet mäin Dag erëm op engem ganzen Zyklus vun Debugging verbruecht, Logbicher schécken, Cluster op béide Säiten erstallt, an der Enn sot hien just gutt, et Wierker fir mech, hei sinn ech maachen alles Schrëtt fir Schrëtt an der offizieller Dokumentatioun an Dir an Dir wäert gelengt.
Op déi ech héiflech gefrot him ze verloossen an een aneren op meng Ticket zouzeschreiwen wann Dir wësst net wou fir de Problem ze sichen.
Finale
Um drëtten Dag gouf mir en neien Ingenieur Arun B. zougewisen, a vun Ufank un vun der Kommunikatioun mat him war et direkt kloer datt dëst net déi 3 fréier Ingenieuren waren. Hien huet d'ganz Geschicht gelies an huet direkt gefrot d'Logbicher mat sengem eegene Skript op ps1 ze sammelen, deen op sengem Github war. Dëst gouf erëm gefollegt vun all Iteratiounen fir Cluster ze kreéieren, Kommando Resultater auszeginn, Logbicher ze sammelen, awer den Arun B. huet sech an déi richteg Richtung bewegt no de Froen déi mir gefrot goufen.
Wéini si mir op de Punkt komm fir -stderrthreshold = Debug an hirem vpc-Controller z'aktivéieren, a wat ass duerno geschitt? natierlech funktionnéiert et net) de Pod fänkt einfach net mat dëser Optioun un, nëmmen -stderrthreshold=info funktionnéiert.
Mir hunn hei fäerdeg gemaach an den Arun B. sot, hie géif probéieren meng Schrëtt ze reproduzéieren fir dee selwechte Feeler ze kréien. Den nächsten Dag kréien ech eng Äntwert vum Arun B. hien huet dëse Fall net opginn, awer den Iwwerpréiwungscode vun hirem vpc-Controller opgeholl an d'Plaz fonnt wou et ass a firwat et net funktionnéiert:
Also, wann Dir den Haaptroute-Tabelle an Ärem VPC benotzt, dann huet et par défaut keng Associatiounen mat den néidege Subnets, déi sou néideg sinn fir de vpc-Controller, am Fall vun engem ëffentlechen Subnet, huet et e personaliséierte Route-Tabelle dat huet eng Associatioun.
Andeems Dir manuell Associatiounen fir d'Haaptroute-Tabelle mat den néidege Subnets addéieren, an d'Nodegroup nei erstellen, funktionnéiert alles perfekt.
Ech hoffen, datt den Arun B. dëse Feeler wierklech un d'EKS Entwéckler bericht a mir wäerten eng nei Versioun vum vpc-Controller gesinn, wou alles aus der Këscht funktionnéiert. Momentan ass déi lescht Versioun: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
huet dëse Problem.
Merci un jiddereen deen bis zum Schluss gelies huet, test alles wat Dir an der Produktioun benotzt ier Dir implementéiert.
Source: will.com