Dobar dan, želim da sa vama podelim svoje iskustvo u postavljanju i korišćenju AWS EKS (Elastic Kubernetes Service) servisa za Windows kontejnere, odnosno o nemogućnosti njegovog korišćenja i grešci pronađenoj u kontejneru AWS sistema, za one koji su zainteresovani za ovu uslugu za Windows kontejnere, molimo pod kat.
Znam da Windows kontejneri nisu popularna tema i malo ih ljudi koristi, ali sam se ipak odlučio da napišem ovaj članak, pošto je bilo par članaka na Habré-u o kubernetes-u i Windows-u i još uvijek ima takvih ljudi.
Начало
Sve je počelo kada je odlučeno da se servisi u našoj kompaniji migriraju na kubernetes, koji je 70% Windows i 30% Linux. U tu svrhu, AWS EKS cloud servis je razmatran kao jedna od mogućih opcija. Do 8 AWS EKS Windows je bio u javnom pregledu, počeo sam sa njim, tamo je korišćena stara verzija kubernetesa 2019, ali sam ipak odlučio da to proverim i vidim u kojoj je fazi ovaj cloud servis, da li radi uopšte, kako se ispostavilo, ne, tu je bila greška sa dodatkom uklanjanja podova, dok su stari prestali da reaguju preko internog ip-a iz iste podmreže kao i windows worker čvor.
Stoga je odlučeno da se odustane od korištenja AWS EKS-a u korist vlastitog klastera na kubernetes-u na istom EC2, samo što bismo sve balansiranje i HA morali sami opisati preko CloudFormation-a.
Podrška za Amazon EKS Windows Container je sada generalno dostupna
by Martin Beeby | dana 08
Prije nego što sam imao vremena da dodam šablon u CloudFormation za svoj vlastiti klaster, vidio sam ovu vijest
Naravno, ostavio sam sav svoj posao po strani i počeo da proučavam šta su uradili za GA i kako se sve promenilo sa Public Preview-om. Da, AWS, bravo, ažurira slike za windows worker node na verziju 1.14, kao i sam klaster, verzija 1.14 u EKS-u, sada podržava windows čvorove. Projekat od javnog pregleda 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, na linku iznad u najavi kao iu dokumentaciji, predloženo je da se klaster implementira ili preko vlasničkog eksctl uslužnog programa ili preko CloudFormation + kubectl nakon, koristeći samo javne podmreže u Amazonu, kao i kreiranje odvojeni VPC za novi klaster.
Ova opcija nije pogodna za mnoge; prvo, odvojeni VPC znači dodatne troškove za njegovu cijenu + peering promet na vaš trenutni VPC. Šta bi trebalo da rade oni koji već imaju gotovu infrastrukturu u AWS-u sa sopstvenim višestrukim AWS nalozima, VPC-om, podmrežama, tabelama ruta, tranzitnim gateway-om i tako dalje? Naravno, ne želite sve ovo da razbijete ili ponovite, i potrebno je da integrišete novi EKS klaster u trenutnu mrežnu infrastrukturu, koristeći postojeći VPC i, za razdvajanje, kreirate najviše nove podmreže za klaster.
U mom slučaju je izabran ovaj put, koristio sam postojeći VPC, dodao samo 2 javne podmreže i 2 privatne podmreže za novi klaster, naravno, sva pravila su uzeta u obzir prema dokumentaciji .
Postojao je i jedan uslov: nema radnih čvorova u javnim podmrežama koje koriste EIP.
eksctl vs CloudFormation
Odmah ću rezervisati da sam isprobao oba načina 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, rasporedite klaster u 3 koraka:
1. Kreiramo sam klaster + Linux radni čvor, koji će kasnije ugostiti sistemske kontejnere i taj isti nesrećni 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-networkingDa biste se implementirali na postojeći VPC, samo navedite id vaše podmreže, a eksctl će odrediti sam VPC.
Da biste osigurali da su vaši radnički čvorovi raspoređeni samo na privatnu podmrežu, morate navesti --node-private-networking za grupu čvorova.
2. Instaliramo vpc-kontroler u naš klaster, koji će zatim obraditi naše radne čvorove, računajuć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 vaši sistemski kontejneri uspješno pokrenu na vašem Linux radnom čvoru, uključujući vpc-kontroler, sve što ostaje je da kreirate drugu grupu čvorova sa 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 poveže s vašim klasterom i čini se da je sve u redu, on je u statusu Ready, ali ne.
Greška u vpc-kontroleru
Ako pokušamo pokrenuti podove na čvoru Windows Worker, dobićemo greš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:
A trebalo bi da bude ovako:
Iz ovoga je jasno da vpc-kontroler iz nekog razloga nije ispunio svoj dio i nije mogao dodati nove IP adrese instanci kako bi ih podovi mogli koristiti.
Pogledajmo logove vpc-controller pod i evo šta vidimo:
kubectl log -n kube-sistem
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 Guglu nisu dovele do ničega, pošto očigledno niko još nije uhvatio takvu grešku, ili nije objavio problem na njoj, morao sam prvo sam da smislim opcije. Prvo što mi je palo na pamet je da možda vpc-kontroler ne može riješiti ip-10-xxx.ap-xxx.compute.internal i doći do njega i stoga dolazi do grešaka.
Da, zaista, mi koristimo prilagođene DNS servere u VPC-u i, u principu, ne koristimo Amazonove, tako da čak ni prosljeđivanje nije konfigurirano za ovaj ap-xxx.compute.internal domen. Testirao sam ovu opciju, i nije dala rezultate, možda test nije bio čist, pa sam dalje, u komunikaciji sa tehničkom podrškom, podlegao njihovoj ideji.
S obzirom da nije bilo baš nikakvih ideja, sve sigurnosne grupe je kreirao sam eksctl, tako da nije bilo sumnje u njihovu upotrebljivost, tabele ruta su također bile ispravne, nat, dns, pristup Internetu sa radničkim čvorovima je također bio tu.
Štaviše, ako rasporedite radni čvor na javnu podmrežu bez korištenja —node-private-networking, vpc-kontroler je odmah ažurirao ovaj čvor i sve je radilo kao sat.
Postojale su dvije opcije:
- Odustanite i sačekajte da vam neko opiše ovu grešku u AWS-u i da je popravi, a onda možete bezbedno da koristite AWS EKS Windows, jer su tek izašli u GA (prošlo je 8 dana u trenutku pisanja ovog članka), mnogi će verovatno prati isti put kao ja.
- Pišite AWS podršci i recite im suštinu problema sa čitavom gomilom log-ova sa svih strana i dokažite im da njihov servis ne radi kada koristite vaš VPC i podmreže, nije uzalud imali poslovnu podršku, trebalo bi da koristite bar jednom :)
Komunikacija sa AWS inženjerima
Nakon što sam kreirao tiket na portalu, greškom sam odabrao da mi odgovorim putem weba - e-maila ili centra za podršku, preko ove opcije mogu vam odgovoriti i nakon nekoliko dana, uprkos činjenici da je moja karta imala ozbiljnost - oštećenje sistema, što značio odgovor u roku od <12 sati, a pošto plan poslovne podrške ima podršku 24/7, nadao sam se najboljem, ali ispalo je kao i uvijek.
Moja karta je ostala nedodijeljena od petka do ponedjeljka, a onda sam odlučio da im ponovo pišem i odabrao opciju Chat odgovora. Nakon kratkog čekanja, Harshad Madhav je bio određen da me primi, a onda je počelo...
Ispravljali smo greške na mreži 3 sata zaredom, prenosili evidencije, postavljali isti klaster u AWS laboratoriju da oponašamo problem, ponovo kreirali klaster s moje strane, i tako dalje, jedino do čega smo došli je da od u logovima je bilo jasno da resol ne radi AWS interna imena domena, o čemu sam pisao gore, a Harshad Madhav me zamolio da kreiram prosljeđivanje, navodno koristimo prilagođeni DNS i to bi mogao biti problem.
forwarding
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)To je ono što je urađeno, dan je prošao. Harshad Madhav je pisao da to provjeri i trebalo bi da radi, ali ne, rezolucija uopšte nije pomogla.
Zatim je došlo do komunikacije sa još 2 inženjera, jedan je jednostavno ispao iz chata, očigledno se bojao složenog slučaja, drugi je ponovo proveo dan na punom ciklusu otklanjanja grešaka, slanju dnevnika, kreiranju klastera na obje strane, u kraj samo je rekao dobro, meni radi, evo ja radim sve korak po korak u službenoj dokumentaciji i uspjet ćete i vi i vi.
Na šta sam ga ljubazno zamolio da ode i dodijeli nekog drugog na moju kartu ako ne znaš gdje potražiti problem.
Finale
Trećeg dana mi je dodijeljen novi inžinjer Arun B. i od samog početka komunikacije s njim odmah je bilo jasno da to nisu prethodna 3 inženjera. Pročitao je cijelu historiju i odmah zatražio da prikupi dnevnike koristeći svoju vlastitu skriptu na ps1, koja je bila na njegovom githubu. Ponovo su uslijedile sve iteracije kreiranja klastera, izlaza rezultata komandi, prikupljanja logova, ali Arun B. se kretao u pravom smjeru sudeći po pitanjima koja su mi postavljena.
Kada smo došli do tačke omogućavanja -stderrthreshold=debug u njihovom vpc-kontroleru i šta se dalje dogodilo? naravno da ne radi) pod jednostavno ne počinje s ovom opcijom, radi samo -stderrthreshold=info.
Završili smo ovdje i Arun B. je rekao da će pokušati ponoviti moje korake da dobije istu grešku. Sljedećeg dana dobijam odgovor od Aruna B. nije napustio ovaj slučaj, već je preuzeo pregled kod njihovog vpc-kontrolera i pronašao mjesto gdje se nalazi i zašto ne radi:
Dakle, ako koristite glavnu tabelu ruta u vašem VPC-u, tada ona po defaultu nema asocijacije sa potrebnim podmrežama, koje su toliko neophodne za vpc-kontroler, u slučaju javne podmreže, ima prilagođenu tabelu ruta koja ima asocijaciju.
Ručnim dodavanjem asocijacija za glavnu tabelu ruta sa potrebnim podmrežama i ponovnim kreiranjem grupe čvorova, sve radi savršeno.
Nadam se da će Arun B. zaista prijaviti ovu grešku EKS programerima i da ćemo vidjeti novu verziju vpc-kontrolera gdje će sve raditi iz 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 su pročitali do kraja, testirajte sve što ćete koristiti u produkciji prije implementacije.
izvor: www.habr.com