Dobar dan, želim s vama podijeliti svoje iskustvo u postavljanju i korištenju servisa AWS EKS (Elastic Kubernetes Service) za Windows kontejnere, odnosno o nemogućnosti korištenja i pronađenom bugu u kontejneru AWS sustava, za one koji su zainteresirani za ovu uslugu za Windows kontejnere, molimo pod kat.
Znam da Windows kontejneri nisu popularna tema i da ih malo ljudi koristi, ali sam ipak odlučio napisati ovaj članak, jer je bilo par članaka na Habréu o kubernetesu i Windowsima i još uvijek ima takvih ljudi.
početak
Sve je počelo kada je odlučeno migrirati usluge u našoj tvrtki na kubernetes koji je 70% Windows i 30% Linux. U tu svrhu kao jedna od mogućih opcija razmatrana je usluga u oblaku AWS EKS. Do 8. listopada 2019. AWS EKS Windows je bio u Public Previewu, krenuo sam s njim, tamo se koristila stara 1.11 verzija kubernetesa, ali sam ipak odlučio provjeriti i vidjeti u kojoj je fazi taj cloud servis, radi li uopće, kako se pokazalo, ne, bio je tu bug s dodatkom uklanjanja podova, dok su stari prestali odgovarati preko internog ip-a iz iste podmreže kao i windows worker node.
Stoga je odlučeno napustiti korištenje AWS EKS-a u korist vlastitog klastera na kubernetesu na istom EC2, samo što bismo morali sami opisati sva balansiranja i HA putem CloudFormation-a.
Podrška za Amazon EKS Windows kontejner sada je općenito dostupna
napisao Martin Beeby | dana 08. listopada 2019
Prije nego što sam stigao dodati predložak u CloudFormation za vlastiti klaster, vidio sam ovu vijest
Naravno, ostavio sam sav svoj posao po strani i počeo proučavati što su učinili za GA i kako se sve promijenilo s Javnim pregledom. Da, AWS, bravo, ažurirao slike za windows worker node na verziju 1.14, kao i sam klaster, verzija 1.14 u EKS-u, sada podržava windows čvorove. Projekt za javni pregled na Zataškali su to i rekli da sada koristite službenu dokumentaciju ovdje:
Integracija EKS klastera u trenutni VPC i podmreže
U svim izvorima, u gornjoj poveznici u objavi kao iu dokumentaciji, predloženo je da se klaster postavi ili putem vlasničkog uslužnog programa eksctl ili putem CloudFormation + kubectl nakon toga, samo koristeći javne podmreže u Amazonu, kao i stvaranje odvojeni VPC za novi klaster.
Ova opcija nije prikladna za mnoge; prvo, zasebni VPC znači dodatne troškove za svoj trošak + peering promet na vaš trenutni VPC. Što trebaju učiniti oni koji već imaju gotovu infrastrukturu u AWS-u s vlastitim višestrukim AWS računima, VPC-om, podmrežama, tablicama ruta, tranzitnim pristupnikom i tako dalje? Naravno, ne želite sve ovo slomiti ili ponoviti, a trebate integrirati novi EKS klaster u trenutnu mrežnu infrastrukturu, koristeći postojeći VPC i, za odvajanje, najviše stvoriti nove podmreže za klaster.
U mom slučaju odabran je ovaj put, koristio sam postojeći VPC, dodao samo 2 javne podmreže i 2 privatne podmreže za novi klaster, naravno, uzeta su u obzir sva pravila prema dokumentaciji .
Postojao je i jedan uvjet: nema radnih čvorova u javnim podmrežama koje koriste EIP.
eksctl protiv CloudFormation
Odmah ću rezervirati da sam isprobao obje metode postavljanja klastera, u oba slučaja slika je bila ista.
Pokazat ću primjer samo koristeći eksctl jer će kod ovdje biti kraći. Koristeći eksctl, implementirajte klaster u 3 koraka:
1. Kreiramo sam klaster + Linux radni čvor, koji će kasnije ugostiti sistemske spremnike i taj isti zlosretni vpc-kontroler.
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-networkingKako biste implementirali na postojeći VPC, samo navedite ID svojih podmreža, a eksctl će sam odrediti VPC.
Kako biste osigurali da su vaši radnički čvorovi raspoređeni samo na privatnu podmrežu, trebate navesti --node-private-networking za grupu čvorova.
2. Instaliramo vpc-kontroler u naš klaster, koji će zatim obraditi naše radne čvorove, brojeći broj slobodnih IP adresa, kao i broj ENI-ova na instanci, dodajući ih i uklanjajući ih.
eksctl utils install-vpc-controllers --name yyy --approve3. Nakon što se spremnici vašeg sustava uspješno pokrenu na vašem Linux radnom čvoru, uključujući vpc-kontroler, sve što preostaje je stvoriti drugu grupu čvorova s Windows radnicima.
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-networkingNakon što se vaš čvor uspješno povezao s vašim klasterom i čini se da je sve u redu, on je u statusu Ready, ali ne.
Pogreška u vpc-kontroleru
Ako pokušamo pokrenuti podove na Windows Worker čvoru, dobit ćemo pogrešku:
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]Ako pogledamo dublje, vidimo da naša instanca u AWS-u izgleda ovako:
I trebalo bi biti ovako:
Iz ovoga je jasno da vpc-kontroler iz nekog razloga nije ispunio svoju ulogu i nije mogao dodati nove IP adrese instanci kako bi ih podovi mogli koristiti.
Pogledajmo zapisnike vpc-controller pod-a i vidimo ovo:
kubectl log -n kube-sustav
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.Pretrage na Googleu nisu dovele do ničega, budući da očito još nitko nije uhvatio takvu grešku ili nije objavio problem na njemu, morao sam prvo sam smisliti opcije. Prvo što mi je palo na pamet je da možda vpc-kontroler ne može razriješiti ip-10-xxx.ap-xxx.compute.internal i doći do njega i stoga dolazi do grešaka.
Da, doista, koristimo prilagođene DNS poslužitelje u VPC-u, a u principu ne koristimo Amazonove, tako da ni prosljeđivanje nije konfigurirano za ovu ap-xxx.compute.internal domenu. Testirao sam ovu opciju i nije donijela rezultate, možda test nije bio čist i stoga sam, dalje, u komunikaciji s tehničkom podrškom, podlegao njihovoj ideji.
Kako baš i nije bilo ideja, sve sigurnosne grupe je kreirao sam eksctl, tako da nije bilo sumnje u njihovu ispravnost, tablice ruta su također bile ispravne, nat, dns, pristup Internetu sa radnim čvorovima je također bio tu.
Štoviše, ako implementirate radni čvor u javnu podmrežu bez korištenja —node-private-networking, ovaj čvor je odmah ažuriran od strane vpc-kontrolera i sve je radilo kao sat.
Postojale su dvije opcije:
- Odustanite i pričekajte dok netko ne opiše ovu grešku u AWS-u i popravi je, a onda možete sigurno koristiti AWS EKS Windows, jer su upravo pušteni u GA (prošlo je 8 dana u trenutku pisanja ovog članka), mnogi će vjerojatno slijedite isti put kao i ja.
- Pišite AWS Podršci i recite im suštinu problema sa hrpom logova sa svih strana i dokažite im da njihov servis ne radi kada koristite Vaš VPC i podmreže, nismo uzalud imali Poslovnu podršku, trebali biste koristiti bar jednom :)
Komunikacija s AWS inženjerima
Kreirajući tiket na portalu, greškom sam odabrao da mi se odgovori putem Web - e-maila ili centra za podršku, preko te opcije vam mogu odgovoriti nakon par dana uopće, unatoč tome što je moj tiket imao Severity - System impaired, što značilo je odgovor u roku <12 sati, a budući da Business support plan ima podršku 24/7, nadao sam se najboljem, ali ispalo je kao i uvijek.
Moja je karta ostala nedodijeljena od petka do ponedjeljka, a onda sam im odlučio ponovno pisati i odabrao opciju odgovora putem chata. Nakon kratkog čekanja, Harshad Madhav je imenovan da me vidi, a onda je počelo...
Otklanjali smo pogreške s njim online 3 sata zaredom, prenosili zapisnike, postavljali isti klaster u AWS laboratoriju da emuliramo problem, ponovno stvarali klaster s moje strane, i tako dalje, jedino do čega smo došli je da od zapisima je bilo jasno da resol ne radi s internim imenima AWS domena, o čemu sam gore pisao, a Harshad Madhav me zamolio da kreiram prosljeđivanje, navodno koristimo prilagođeni DNS i to bi mogao biti problem.
prosljeđivanje
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)To je učinjeno, dan je završio. Harshad Madhav je odgovorio da provjeri i trebalo bi raditi, ali ne, rješenje nije nimalo pomoglo.
Zatim je došlo do komunikacije s još 2 inženjera, jedan je jednostavno odustao od chata, očito se bojao složenog slučaja, drugi je opet proveo moj dan na punom ciklusu ispravljanja pogrešaka, slanja zapisa, stvaranja klastera s obje strane, u na kraju je samo rekao dobro, meni radi, evo radim sve korak po korak u službenoj dokumentaciji i uspjet ćeš ti i ti.
Na što sam ga pristojno zamolio da ode i dodijeli nekom drugom moju kartu ako ne znaš gdje tražiti problem.
finale
Trećeg dana dodijeljen mi je novi inženjer Arun B. i od samog početka komunikacije s njim bilo je odmah jasno da se ne radi o prethodna 3 inženjera. Pročitao je cijelu povijest i odmah zatražio prikupljanje zapisa pomoću vlastite skripte na ps1, koja je bila na njegovom githubu. Uslijedile su opet sve iteracije stvaranja klastera, ispisivanja rezultata naredbi, prikupljanja logova, ali Arun B. se kretao u dobrom smjeru sudeći po pitanjima koja su mi postavljena.
Kada smo došli do točke omogućavanja -stderrthreshold=debug u njihovom vpc-kontroleru i što se zatim dogodilo? naravno da ne radi) pod jednostavno se ne pokreće s ovom opcijom, radi samo -stderrthreshold=info.
Ovdje smo završili i Arun B. je rekao da će pokušati reproducirati moje korake da dobije istu pogrešku. Sljedećeg dana dobivam odgovor od Aruna B. on nije odustao od ovog slučaja, već je preuzeo kod za pregled njihovog vpc-kontrolera i pronašao mjesto gdje se nalazi i zašto ne radi:
Stoga, ako koristite glavnu tablicu ruta u svom VPC-u, tada prema zadanim postavkama nema asocijacija s potrebnim podmrežama, koje su toliko potrebne vpc-kontroleru, u slučaju javne podmreže, ima prilagođenu tablicu ruta koji ima asocijaciju.
Ručnim dodavanjem asocijacija za glavnu tablicu ruta s potrebnim podmrežama i ponovnim stvaranjem grupe čvorova, sve radi savršeno.
Nadam se da će Arun B. stvarno prijaviti ovaj bug programerima EKS-a i da ćemo vidjeti novu verziju vpc-controllera gdje će sve raditi izvan kutije. Trenutno najnovija verzija je: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ima ovaj problem.
Hvala svima koji ste pročitali do kraja, prije implementacije testirajte sve što ćete koristiti u proizvodnji.
Izvor: www.habr.com