Goeiemiddag, ek wil my ervaring met jou deel met die opstel en gebruik van die AWS EKS (Elastic Kubernetes Service) diens vir Windows-houers, of liewer, oor die onmoontlikheid om dit te gebruik, en die fout wat in die AWS-stelselhouer gevind is, die wat belangstel in hierdie diens vir Windows-houers, asseblief onder kat.
Ek weet dat vensterhouers nie 'n gewilde onderwerp is nie, en min mense gebruik dit, maar tog het ek besluit om hierdie artikel te skryf, aangesien daar 'n paar artikels oor kubernetes en vensters op Habré was, en daar is nog sulke mense.
Begin
Dit het alles begin met die feit dat die dienste in ons maatskappy besluit is om na kubernetes te migreer, dit is 70% vensters en 30% Linux. Hiervoor is die AWS EKS-wolkdiens as een van die moontlike opsies beskou. Tot 8 Oktober 2019 was AWS EKS Windows in Publieke Voorskou, ek het daarmee begin, die ou 1.11 weergawe van kubernetes is daar gebruik, maar ek het besluit om dit in elk geval na te gaan en te kyk in watter stadium hierdie wolkdiens enigsins werk, aangesien dit blyk dat daar 'n fout was met die byvoeging van die verwydering van peule, terwyl die oues opgehou het om op die interne ip te reageer vanaf dieselfde subnet as die Windows-werkernodus.
Daarom is daar besluit om die gebruik van AWS EKS te laat vaar ten gunste van ons eie groepering op kubernete op dieselfde EC2, net al die balansering en HA sal deur myself deur CloudFormation beskryf moet word.
Amazon EKS Windows Container-ondersteuning nou algemeen beskikbaar
deur Martin Beeby | op 08 Oktober 2019
Voordat ek tyd gehad het om 'n sjabloon by CloudFormation vir my eie cluster te voeg, het ek hierdie nuus gesien
Natuurlik het ek al my werk opsy gesit en begin bestudeer wat hulle vir GA gedoen het, en hoe dinge met die Openbare Voorskou verander het. Ja, goed gedoen AWS-bygewerkte beelde vir Windows-werker-nodus na weergawe 1.14 sowel as die groep self weergawe 1.14 in EKS nou met ondersteuning vir Windows-nodes. Projek deur Publieke Voorskou op hulle het toesmeer en gesê gebruik nou die amptelike dokumentasie hier:
Integrasie van die EKS-kluster in die huidige VPC en subnette
In alle bronne, in die skakel hierbo op die aankondiging sowel as in die dokumentasie, is voorgestel om die groepering óf deur die eie eksctl-nutsmiddel óf deur CloudFormation + kubectl daarna te ontplooi, slegs deur gebruik te maak van publieke subnette in Amazon, sowel as die skep van 'n aparte VPC vir 'n nuwe groepering.
Hierdie opsie is nie geskik vir baie nie, eerstens is 'n aparte VPC 'n bykomende koste vir sy koste + peering verkeer na jou huidige VPC. Wat om te doen vir diegene wat reeds 'n klaargemaakte infrastruktuur in AWS het met hul veelvuldige AWS-rekeninge, VPC, subnette, roetetabelle, transitopoort ensovoorts? Natuurlik wil jy nie dit alles breek of oordoen nie, en jy moet die nuwe EKS-groepering in die huidige netwerkinfrastruktuur integreer, deur die bestaande VPC te gebruik, en om 'n maksimum van nuwe subnette vir die groepering te skep om te skei.
In my geval is hierdie pad gekies, ek het die bestaande VPC gebruik, slegs 2 publieke subnette en 2 private subnette bygevoeg vir die nuwe cluster, natuurlik, al die reëls is in ag geneem volgens die dokumentasie .
Daar was ook een voorwaarde - geen werkernodus in openbare subnetwerke wat EIP gebruik nie.
eksctl vs CloudFormation
Ek sal dadelik 'n bespreking maak dat ek albei metodes probeer het om die cluster te ontplooi, in beide gevalle was die prentjie dieselfde.
Ek sal 'n voorbeeld wys wat slegs eksctl gebruik, aangesien die kode hier korter sal wees. Ontplooi groepering met eksctl in 3 stappe:
1. Ons skep die cluster self + Linux werker node, wat later stelselhouers en dieselfde noodlottige vpc-beheerder sal huisves.
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 na 'n bestaande VPC te ontplooi, is dit genoeg om die ID van jou subnette te spesifiseer, en eksctl sal die VPC self bepaal.
Om jou werkernodus slegs na die private subnet te ontplooi, moet jy --node-private-netwerking vir die nodegroep spesifiseer.
2. Installeer vpc-beheerder in ons cluster, wat dan ons werker nodusse sal verwerk, tel die aantal gratis IP-adresse, sowel as die aantal ENI op die instansie, wat hulle byvoeg en verwyder.
eksctl utils install-vpc-controllers --name yyy --approve3. Nadat jou stelselhouers suksesvol begin het op jou linux-werkernodus, insluitend vpc-beheerder, is al wat oorbly om nog 'n nodegroep met Windows-werkers te skep.
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-networkingNadat jou knoop suksesvol aan jou cluster gekoppel is en dit lyk of alles in orde is, is dit in die Gereed-status, maar nee.
Fout in vpc-beheerder
As ons pods op 'n Windows-werkernodus probeer laat loop, sal ons 'n fout kry:
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 ons dieper kyk, sien ons dat ons instansie in AWS so lyk:
En dit moet so wees:
Hieruit is dit duidelik dat die vpc-beheerder om een of ander rede nie sy deel uitgewerk het nie en nie nuwe ip-adresse by die instansie kon voeg sodat peule dit kon gebruik nie.
Ons klim om na die vpc-beheerder peul logs te kyk en dit is wat ons sien:
kubectl log -n kubus-stelsel
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.Google-soektogte het tot niks gelei nie, aangesien niemand klaarblyklik nog so 'n fout opgespoor het nie, wel, of nie 'n probleem daarop geplaas het nie, moes ek eers self aan die opsies dink. Die eerste ding wat by my opgekom het, was dat die vpc-beheerder miskien nie ip-10-xxx.ap-xxx.compute.internal kan oplos en dit kan bereik nie, en daarom word foute gegooi.
Ja, inderdaad, ons gebruik pasgemaakte dns-bedieners in die VPC en in beginsel gebruik ons nie Amazon-bedieners nie, so selfs aanstuur is nie vir hierdie ap-xxx.compute.internal-domein opgestel nie. Ek het hierdie opsie nagegaan, en dit het nie resultate gebring nie, miskien was die toets nie skoon nie, en daarom, toe ek met tegniese ondersteuning gekommunikeer het, het ek aan hul idee geswig.
Aangesien daar nie baie idees was nie, is alle sekuriteitsgroepe deur eksctl self geskep, so daar was geen twyfel dat hulle gewerk het nie, die roeteringstabelle was ook korrek, nat, dns, daar was ook internettoegang met werkersnodes.
Terselfdertyd, as jy 'n werkernodus na die publieke subnet ontplooi sonder om --node-private-networking te gebruik, is hierdie nodus onmiddellik deur vpc-beheerder opgedateer en alles het soos klokslag gewerk.
Daar was twee opsies:
- Om te score en te wag totdat iemand hierdie fout in AWS beskryf en hulle dit regmaak, en dan kan jy veilig AWS EKS Windows gebruik, want hulle is pas in GA vrygestel (8 dae het verloop ten tyde van hierdie skrywe), vir seker baie sal dieselfde pad as ek volg .
- Skryf aan AWS Ondersteuning en vertel hulle die essensie van die probleem met 'n hele klomp logs van oral en bewys aan hulle dat hulle diens nie werk wanneer hulle hul eie VPC en subnette gebruik nie, dit was nie verniet dat ons Besigheidsondersteuning gehad het nie, ons moet dit ten minste een keer gebruik 🙂
Kommunikasie met AWS-ingenieurs
Nadat ek 'n kaartjie op die portaal geskep het, het ek verkeerdelik gekies om my te antwoord via Web - e-pos of ondersteuningsentrum, deur hierdie opsie kan hulle jou enigsins na 'n paar dae antwoord, ten spyte van die feit dat my kaartjie Erns - Stelsel benadeel het, wat beteken het 'n reaksie binne <12 uur, en aangesien die Besigheidsondersteuningsplan 24/7 ondersteuning het, het ek vir die beste gehoop, maar dit het soos altyd uitgedraai.
My kaartjie was in Unassigned van Vrydag tot Ma, toe besluit ek om weer aan hulle te skryf en kies die Chat antwoord opsie. Na 'n kort wag is Harshad Madhav aan my toegewys, en toe begin dit ...
Ons het dit vir 3 uur in 'n ry aanlyn ontfout, logs oorgedra, dieselfde groepering in die AWS-laboratorium ontplooi om die probleem na te boots, die groepering van my kant af herskep, ensovoorts, die enigste ding waarmee ons vorendag gekom het, was dat die logs gewys het dat die resolusie nie interne AWS-domeinname werk nie, waaroor ek hierbo geskryf het, en Harshad Madhav het my gevra om 'n aanstuur te skep, vermoedelik gebruik ons pasgemaakte DNS en dit kan 'n probleem wees.
Aanstuur
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Wat gedoen is, die dag geëindig het Harshad Madhav het daardie tjek uitgeteken en dit behoort te werk, maar nee, die resolusie het nie gehelp nie.
Toe was daar kommunikasie met nog 2 ingenieurs, een het net van die klets afgeval, blykbaar was hy bang vir 'n komplekse saak, die tweede het my dag weer aan 'n volledige ontfoutingsiklus spandeer, logs gestuur, groepe aan beide kante geskep, op die ou end het hy net gesê goed, dit werk vir my, hier is ek amptelike dokumentasie doen alles stap vir stap doen dit en jy en jy sal slaag.
Waarop ek hom beleefd gevra het om weg te gaan, en nog een aan my kaartjie toe te wys, as jy nie weet waar om die probleem te soek nie.
finale
Op die derde dag is 'n nuwe ingenieur Arun B. aan my toegewys, en van die begin van kommunikasie met hom was dit dadelik duidelik dat dit nie 3 vorige ingenieurs was nie. Hy het die hele geskiedenis gelees en dadelik gevra om die logs te versamel met sy selfgeskrewe skrif op ps1, wat op sy github was. Dit is weer gevolg deur al die herhalings van die skep van groepe, die vertoon van die resultate van opdragte, die versameling van logs, maar Arun B. het in die regte rigting beweeg, te oordeel aan die vrae wat aan my gestel is.
Toe ons by die punt gekom het om -stderrthreshold=debug in hul vpc-beheerder te aktiveer, wat het volgende gebeur? dit werk natuurlik nie) die peul begin net nie met hierdie opsie nie, net -stderrthreshold=info werk.
Ons het hiermee klaargekom en Arun B. het gesê dat hy my stappe sal probeer weergee om dieselfde fout te kry. Die volgende dag kry ek 'n antwoord van Arun B. Hy het nie hierdie saak laat vaar nie, maar het die hersieningskode van sy vpc-beheerder opgeneem en dieselfde plek gevind waar dit is en hoekom dit nie werk nie:
Dus, as jy die hoofroetetabel in jou VPC gebruik, dan het dit by verstek nie assosiasies met die nodige subnette nie, so nodig vir die vpc-beheerder, in die geval van 'n publieke subnet, het dit 'n pasgemaakte roetetabel wat 'n vereniging.
Deur handmatig assosiasies by te voeg vir die hoofroetetabel met die nodige subnette, en die nodegroep te herskep, werk alles perfek.
Ek hoop dat Arun B. werklik hierdie fout aan die EKS-ontwikkelaars sal rapporteer en ons sal 'n nuwe weergawe van vpc-beheerder sien waar alles uit die boks sal werk. Tans nuutste weergawe: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
het hierdie probleem.
Dankie aan almal wat tot die einde gelees het, toets alles wat jy in produksie gaan gebruik voor implementering.
Bron: will.com