Bună ziua, vreau să vă împărtășesc experiența mea în configurarea și utilizarea serviciului AWS EKS (Elastic Kubernetes Service) pentru containerele Windows, sau mai degrabă despre imposibilitatea utilizării acestuia și despre bug-ul găsit în containerul de sistem AWS, pentru cei care sunt interesați de acest serviciu pentru containere Windows, vă rugăm sub cat.
Știu că containerele Windows nu sunt un subiect popular și puțini oameni le folosesc, dar tot am decis să scriu acest articol, deoarece au existat câteva articole despre Habré pe kubernetes și Windows și există încă astfel de oameni.
Home
Totul a început când s-a decis migrarea serviciilor din compania noastră către kubernetes, care este 70% Windows și 30% Linux. În acest scop, serviciul cloud AWS EKS a fost considerat una dintre opțiunile posibile. Până pe 8 octombrie 2019, AWS EKS Windows era în Public Preview, am început cu el, acolo era folosită vechea versiune 1.11 de kubernetes, dar am decis să o verific oricum și să văd în ce stadiu se afla acest serviciu cloud, dacă funcționează deloc, după cum sa dovedit, nu, a existat o eroare cu adăugarea de eliminare a podurilor, în timp ce cele vechi au încetat să răspundă prin ip intern din aceeași subrețea ca și nodul Windows Worker.
Prin urmare, s-a decis să renunțăm la utilizarea AWS EKS în favoarea propriului cluster pe kubernetes pe același EC2, doar că ar trebui să descriem noi înșine toată echilibrarea și HA prin CloudFormation.
Suport pentru containere Amazon EKS Windows acum disponibil în general
de Martin Beeby | pe 08 octombrie 2019
Înainte să am timp să adaug un șablon la CloudFormation pentru propriul meu cluster, am văzut această știre
Desigur, mi-am lăsat toată munca deoparte și am început să studiez ce au făcut pentru GA și cum s-a schimbat totul cu Public Preview. Da, AWS, bine făcut, a actualizat imaginile pentru nodul Windows Worker la versiunea 1.14, precum și clusterul în sine, versiunea 1.14 în EKS, acum acceptă noduri Windows. Proiect de Public Preview la Au acoperit-o și au spus că acum folosiți documentația oficială aici:
Integrarea unui cluster EKS în VPC-ul și subrețelele actuale
În toate sursele, în linkul de mai sus de pe anunț, precum și în documentație, s-a propus implementarea clusterului fie prin utilitarul proprietar eksctl, fie prin CloudFormation + kubectl după, numai folosind subrețele publice în Amazon, precum și crearea unui VPC separat pentru un cluster nou.
Această opțiune nu este potrivită pentru mulți; în primul rând, un VPC separat înseamnă costuri suplimentare pentru costul său + trafic de peering la VPC-ul actual. Ce ar trebui să facă cei care au deja o infrastructură gata făcută în AWS cu propriile conturi AWS multiple, VPC, subrețele, tabele de rute, gateway de tranzit și așa mai departe? Desigur, nu doriți să rupeți sau să refaceți toate acestea și trebuie să integrați noul cluster EKS în infrastructura de rețea actuală, folosind VPC-ul existent și, pentru separare, cel mult să creați noi subrețele pentru cluster.
În cazul meu, a fost aleasă această cale, am folosit VPC-ul existent, am adăugat doar 2 subrețele publice și 2 subrețele private pentru noul cluster, bineînțeles, toate regulile au fost luate în considerare conform documentației .
De asemenea, a existat o condiție: nu există noduri de lucru în subrețele publice care utilizează EIP.
eksctl vs CloudFormation
Voi face imediat o rezervare că am încercat ambele metode de implementare a unui cluster, în ambele cazuri imaginea a fost aceeași.
Voi arăta un exemplu numai folosind eksctl, deoarece codul de aici va fi mai scurt. Folosind eksctl, implementați clusterul în 3 pași:
1. Creăm clusterul în sine + nodul de lucru Linux, care mai târziu va găzdui containere de sistem și același vpc-controller nefericit.
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-networkingPentru a fi implementat pe un VPC existent, trebuie doar să specificați id-ul subrețelelor dvs. și eksctl va determina VPC-ul însuși.
Pentru a vă asigura că nodurile dvs. de lucru sunt implementate numai într-o subrețea privată, trebuie să specificați --node-private-networking pentru nodegroup.
2. Instalăm vpc-controller în clusterul nostru, care va procesa apoi nodurile noastre de lucru, numărând numărul de adrese IP libere, precum și numărul de ENI de pe instanță, adăugându-le și eliminându-le.
eksctl utils install-vpc-controllers --name yyy --approve3. După ce containerele dvs. de sistem s-au lansat cu succes pe nodul dvs. de lucru Linux, inclusiv vpc-controller, tot ce rămâne este să creați un alt grup de noduri cu lucrători Windows.
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-networkingDupă ce nodul dvs. s-a conectat cu succes la cluster și totul pare să fie în regulă, este în starea Gata, dar nu.
Eroare la vpc-controller
Dacă încercăm să rulăm pod-uri pe un nod Windows Worker, vom primi eroarea:
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]Dacă ne uităm mai profund, vedem că instanța noastră din AWS arată astfel:
Și ar trebui să fie așa:
Din aceasta, este clar că vpc-controller nu și-a îndeplinit rolul din anumite motive și nu a putut adăuga noi adrese IP la instanță, astfel încât pod-urile să le poată folosi.
Să ne uităm la jurnalele podului vpc-controller și asta este ceea ce vedem:
jurnal kubectl -n sistem-cub
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.Căutările pe Google nu au dus la nimic, deoarece se pare că nimeni nu a prins încă o astfel de eroare sau nu a postat o problemă pe el, a trebuit să mă gândesc mai întâi la opțiuni. Primul lucru care mi-a venit în minte a fost că, probabil, vpc-controller nu poate rezolva ip-10-xxx.ap-xxx.compute.internal și nu poate ajunge la el și, prin urmare, apar erori.
Da, într-adevăr, folosim servere DNS personalizate în VPC și, în principiu, nu le folosim pe cele Amazon, așa că nici măcar redirecționarea nu a fost configurată pentru acest domeniu ap-xxx.compute.internal. Am testat această opțiune și nu a dat rezultate, poate că testul nu a fost curat și, prin urmare, în continuare, când am comunicat cu suportul tehnic, am cedat ideii lor.
Deoarece nu existau cu adevărat idei, toate grupurile de securitate au fost create de eksctl în sine, așa că nu exista nicio îndoială cu privire la funcționalitatea lor, tabelele de rute erau de asemenea corecte, nat, dns, acces la Internet cu noduri de lucru era și acolo.
Mai mult, dacă implementați un nod de lucru într-o subrețea publică fără a utiliza —node-private-networking, acest nod a fost actualizat imediat de controlerul vpc și totul a funcționat ca un ceas.
Au existat două opțiuni:
- Renunță la asta și așteaptă până când cineva descrie acest bug în AWS și îl remediază, iar apoi poți folosi AWS EKS Windows în siguranță, deoarece tocmai au fost lansate în GA (au trecut 8 zile în momentul scrierii acestui articol), probabil că mulți vor urmeaza aceeasi cale ca mine.
- Scrieți la AWS Support și spuneți-le esența problemei cu o grămadă de jurnale de peste tot și dovediți-le că serviciul lor nu funcționează atunci când vă folosiți VPC-ul și subrețelele, nu degeaba am avut asistență pentru afaceri, ar trebui să utilizați macar o data :)
Comunicarea cu inginerii AWS
După ce am creat un bilet pe portal, am ales din greșeală să îmi răspund prin Web - e-mail sau centru de asistență, prin această opțiune vă pot răspunde după câteva zile, în ciuda faptului că biletul meu avea Severitate - Sistem defect, ceea ce a însemnat un răspuns în <12 ore și, deoarece planul de asistență pentru afaceri are asistență 24/7, am sperat să fie mai bun, dar a ieșit ca întotdeauna.
Biletul meu a fost lăsat nealocat de vineri până luni, apoi am decis să le scriu din nou și am ales opțiunea de răspuns la chat. După o scurtă așteptare, Harshad Madhav a fost numit să mă vadă și apoi a început...
Am depanat cu el online timp de 3 ore la rând, transferând jurnalele, implementând același cluster în laboratorul AWS pentru a emula problema, recreând clusterul din partea mea și așa mai departe, singurul lucru la care am ajuns este că de la jurnalele era clar că rezoluția nu funcționează cu numele de domenii interne AWS, despre care am scris mai sus, iar Harshad Madhav mi-a cerut să creez redirecționare, se presupune că folosim DNS personalizat și asta ar putea fi o problemă.
Transmiterea
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Asta s-a făcut, ziua s-a terminat. Harshad Madhav a scris înapoi pentru a verifica și ar trebui să funcționeze, dar nu, rezoluția nu a ajutat deloc.
Apoi a existat comunicarea cu încă 2 ingineri, unul a ieșit pur și simplu din chat, se pare că i-a fost frică de un caz complex, al doilea și-a petrecut ziua din nou într-un ciclu complet de depanare, trimițând jurnalele, creând clustere pe ambele părți, în sfarsit tocmai a spus bine, la mine merge, iata-ma fac totul pas cu pas in documentatia oficiala si tu si tu vei reusi.
La care l-am rugat politicos să plece și să atribuie pe altcineva biletul meu dacă nu știi unde să cauți problema.
final
În a treia zi, mi-a fost repartizat un nou inginer Arun B. și de la începutul comunicării cu el a fost imediat clar că nu era vorba de cei 3 ingineri anteriori. A citit întregul istoric și a cerut imediat să colecteze jurnalele folosind propriul script pe ps1, care era pe github-ul său. Au urmat din nou toate iterațiile de a crea clustere, de a scoate rezultatele comenzilor, de a colecta jurnalele, dar Arun B. se mișca în direcția corectă judecând după întrebările care mi-au fost adresate.
Când am ajuns la punctul de a activa -stderrthreshold=debug în vpc-controller-ul lor și ce s-a întâmplat mai departe? desigur că nu funcționează) podul pur și simplu nu începe cu această opțiune, funcționează doar -stderrthreshold=info.
Am terminat aici și Arun B. a spus că va încerca să reproducă pașii mei pentru a obține aceeași eroare. A doua zi primesc un răspuns de la Arun B. el nu a abandonat acest caz, ci a preluat codul de revizuire al controlerului lor vpc și a găsit locul unde se află și de ce nu funcționează:
Astfel, dacă utilizați tabelul de rute principal în VPC-ul dvs., atunci implicit nu are asocieri cu subrețelele necesare, care sunt atât de necesare pentru vpc-controller, în cazul unei subrețele publice, acesta are un tabel de rute personalizat care are o asociere.
Adăugând manual asocieri pentru tabelul principal de rute cu subrețelele necesare și recreând grupul de noduri, totul funcționează perfect.
Sper că Arun B. va raporta cu adevărat această eroare dezvoltatorilor EKS și vom vedea o nouă versiune de vpc-controller în care totul va funcționa imediat. În prezent, cea mai recentă versiune este: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
are aceasta problema.
Mulțumim tuturor celor care au citit până la sfârșit, testați tot ce veți folosi în producție înainte de implementare.
Sursa: www.habr.com