Bonu dopu meziornu, vogliu fà sparte cun voi a mo sperienza in l'installazione è l'usu di u serviziu AWS EKS (Elastic Kubernetes Service) per i cuntenituri di Windows, o piuttostu nantu à l'impossibilità di usà, è u bug trovu in u containeru di u sistema AWS, per quelli chì chì sò interessate in stu serviziu per i cuntenituri Windows, per piacè sottu cat.
Sapemu chì i cuntenituri di Windows ùn sò micca un tema populari, è pocu persone l'utilizanu, ma aghju sempre decisu di scrive stu articulu, postu chì ci era un paru d'articuli nantu à Habré nantu à kubernetes è Windows è ci sò sempre tali persone.
U principiu
Tuttu hà cuminciatu quandu hè statu decisu di migrà i servizii in a nostra cumpagnia à kubernetes, chì hè 70% Windows è 30% Linux. Per questu scopu, u serviziu di nuvola AWS EKS hè statu cunsideratu cum'è una di l'opzioni pussibuli. Finu à l'8 d'ottobre di u 2019, AWS EKS Windows era in Public Preview, aghju cuminciatu cun ellu, a vechja versione 1.11 di kubernetes hè stata aduprata quì, ma aghju decisu di verificà in ogni modu è vede in quale stadiu era stu serviziu di nuvola, s'ellu funzionava. in tuttu, cum'è risultava, no, ci era un bug cù l'aghjunzione di sguassate pods, mentre chì i vechji anu cessatu di risponde via ip internu da a listessa subnet cum'è u nodu di u Windows Worker.
Per quessa, hè statu decisu di abbandunà l'usu di AWS EKS in favore di u nostru propiu cluster in kubernetes nantu à u stessu EC2, solu avemu da discriverà tutti l'equilibriu è HA noi stessi via CloudFormation.
Amazon EKS Windows Container Support avà Generalmente Disponibile
di Martin Beeby | u 08 OCT 2019
Prima di avè u tempu di aghjunghje un mudellu à CloudFormation per u mo propiu cluster, aghju vistu sta nutizia
Di sicuru, aghju messu tuttu u mo travagliu da parte è hà cuminciatu à studià ciò chì anu fattu per GA, è cumu tuttu hà cambiatu cù Public Preview. Iè, AWS, ben fattu, hà aghjurnatu l'imaghjini per u nodu di Windows Worker à a versione 1.14, è ancu u cluster stessu, a versione 1.14 in EKS, supporta avà i nodi di Windows. Prughjettu da Public Preview at L'anu cupertu è dissenu avà aduprà a documentazione ufficiale quì:
Integrazione di un cluster EKS in l'attuale VPC è subnets
In tutte e fonti, in u ligame sopra à l'annunziu è ancu in a documentazione, hè stata pruposta di implementà u cluster sia per via di l'utilità eksctl patentata sia per CloudFormation + kubectl dopu, solu utilizendu subnets publichi in Amazon, è ancu di creà un VPC separatu per un novu cluster.
Questa opzione ùn hè micca adattata per parechji; prima, un VPC separatu significa costi supplementari per u so costu + trafficu di peering à u vostru VPC attuale. Chì duveranu fà quelli chì anu digià una infrastruttura pronta in AWS cù i so cunti Multiple AWS, VPC, subnets, tabelle di rotte, gateway di transitu è cusì? Di sicuru, ùn vulete micca rumpia o ripiglià tuttu questu, è avete bisognu di integrà u novu cluster EKS in l'infrastruttura di rete attuale, utilizendu a VPC esistente è, per a separazione, à u più di creà subnets novi per u cluster.
In u mo casu, sta strada hè stata scelta, aghju utilizatu u VPC esistente, aghjunghjite solu 2 subnets publichi è 2 subnets privati per u novu cluster, sicuru, tutte e regule sò state cunsiderate secondu a documentazione. .
Ci era ancu una cundizione: nisun nodu di travagliu in subnets publichi chì utilizanu EIP.
eksctl vs CloudFormation
Faraghju una riservazione subitu chì aghju pruvatu i dui metudi di implementà un cluster, in i dui casi a stampa era a stessa.
Mostraraghju un esempiu solu cù eksctl postu chì u codice quì serà più cortu. Utilizendu eksctl, implementate u cluster in 3 passi:
1. Creemu u cluster stessu + u nodu di u travagliu Linux, chì più tardi ospitu cuntenituri di u sistema è quellu stessu vpc-controller malati.
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-networkingPer implementà à un VPC esistente, basta à specificà l'id di i vostri subnets, è eksctl determinarà u VPC stessu.
Per assicurà chì i vostri nodi di u travagliu sò implementati solu in una subnet privata, avete bisognu di specificà --node-private-networking per nodegroup.
2. Installemu vpc-controller in u nostru cluster, chì poi processerà i nostri nodi di u travagliu, cuntendu u numeru di indirizzi IP gratuiti, è ancu u numeru di ENI nantu à l'istanza, aghjunghjendu è sguassà.
eksctl utils install-vpc-controllers --name yyy --approve3.Dopu chì i vostri cuntenituri di u sistema anu lanciatu cù successu in u vostru node di u travagliu Linux, cumpresu vpc-controller, tuttu ciò chì resta hè di creà un altru nodegroup cù i travagliadori 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-networkingDopu chì u vostru node hà cunnessu bè cù u vostru cluster è tuttu pare esse bè, hè in u statutu Ready, ma micca.
Errore in vpc-controller
Se pruvemu di eseguisce pods nantu à un nodu di Windows Worker, averemu l'errore:
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]Se guardemu più in fondu, vedemu chì a nostra istanza in AWS pare cusì:
È deve esse cusì:
Da questu hè chjaru chì u vpc-controller ùn hà micca rializatu a so parte per una certa ragione è ùn puderia micca aghjunghje novi indirizzi IP à l'istanza per chì i podi puderanu usà.
Fighjemu i logs di u pod di vpc-controller è questu hè ciò chì vedemu:
log kubectl -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.Ricerche in Google ùn anu purtatu à nunda, postu chì apparentemente nimu ùn avia micca pigliatu un tali bug, o ùn avia micca publicatu un prublema, aghju avutu à pensà à l'opzioni prima. A prima cosa chì hè vinutu in mente hè chì forsi u vpc-controller ùn pò micca risolve ip-10-xxx.ap-xxx.compute.internal è ghjunghje sin'à ellu è per quessa l'errori si sò.
Iè, daveru, usemu servitori DNS persunalizati in u VPC è, in principiu, ùn avemu micca usatu Amazon, perchè ancu l'inviu ùn era micca cunfiguratu per questu ap-xxx.compute.internal domain. Aghju pruvatu sta opzione, è ùn hà micca purtatu risultati, forsi a prova ùn era micca pulita, è per quessa, in più, quandu cumunicà cù u supportu tecnicu, aghju succorsu à a so idea.
Siccomu ùn ci era micca veramente idee, tutti i gruppi di securità sò stati creati da eksctl stessu, cusì ùn ci era micca dubbitu nantu à a so servibilità, i tavule di ruta eranu ancu curretti, nat, dns, accessu à Internet cù i nodi di u travagliu era ancu quì.
Inoltre, se implementate un nodu di u travagliu in una subnet publica senza aduprà -node-private-networking, stu node hè statu aghjurnatu immediatamente da u vpc-controller è tuttu hà travagliatu cum'è un clockwork.
Ci era dui opzioni:
- Rinuncia è aspettate finu à chì qualcunu descrive stu bug in AWS è u riparanu, è allora pudete aduprà AWS EKS Windows in modu sicuru, perchè sò appena liberati in GA (8 ghjorni sò passati à u mumentu di a scrittura di stu articulu), assai prubabilmente. seguite a stessa strada cum'è mè.
- Scrivite à AWS Support è dite l'essenza di u prublema cù un saccu di logs da ogni locu è dimustrà à elli chì u so serviziu ùn funziona micca quandu utilizate u vostru VPC è subnets, ùn hè micca per nunda chì avemu avutu un supportu cummerciale, duvete aduprà. almenu una volta :)
Comunicazione cù ingegneri AWS
Dopu avè creatu un bigliettu nantu à u portale, aghju sceltu per sbaglià per risponde à mè via Web - email o centru di supportu, attraversu questa opzione vi ponu risponde dopu à uni pochi di ghjorni à tutti, malgradu u fattu chì u mo bigliettu avia Severity - System impaired, chì significava una risposta in <12 ore, è postu chì u pianu di supportu di l'Affari hà un supportu 24/7, sperava per u megliu, ma resultò cum'è sempre.
U mo bigliettu hè statu lasciatu micca assignatu da u venneri finu à u luni, allora aghju decisu di scrive à elli di novu è hà sceltu l'opzione di risposta Chat. Dopu avè aspittatu per un pocu tempu, Harshad Madhav hè statu numinatu per vedemi, è dopu cuminciò ...
Avemu debugged cun ellu in linea per 3 ore in una fila, trasfirendu logs, implementendu u stessu cluster in u laboratoriu AWS per emulà u prublema, ricreendu u cluster da a mo parte, è cusì, l'unicu ciò chì avemu vinutu hè chì da i logs era chjaru chì u resolu ùn era micca travagliatu i nomi di duminiu internu AWS, chì aghju scrittu sopra sopra, è Harshad Madhav m'hà dumandatu di creà l'invio, presumibilmente avemu aduprà DNS persunalizati è questu puderia esse un prublema.
Trasmissione
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Hè ciò chì hè statu fattu, u ghjornu era finitu. Harshad Madhav hà scrittu torna per verificà è duverebbe travaglià, ma micca, a risoluzione ùn hà micca aiutu à tuttu.
Allora ci era una cumunicazione cù 2 ingegneri più, unu solu abbandunò da u chat, apparentemente avia paura di un casu cumplessu, u sicondu hà passatu u mo ghjornu di novu nantu à un ciclu sanu di debugging, mandendu logs, creendu clusters in i dui lati, in u fine hà dettu solu bè, travaglia per mè, eccu eccu facciu tuttu passu à passu in a ducumentazione ufficiale è voi è avete successu.
À quale l'aghju dumandatu educatamente di lascià è assignà qualcunu à u mo bigliettu se ùn sapete induve circà u prublema.
Finale
U terzu ghjornu, un novu ingegnere Arun B. hè statu attribuitu à mè, è da u principiu di a cumunicazione cun ellu era subitu chjaru chì questu ùn era micca l'ingegneri 3 previ. Hà lettu tutta a storia è hà dumandatu immediatamente di cullà i logs cù u so propiu script in ps1, chì era nantu à u so github. Questu hè statu seguitu novu da tutte l'iterazioni di creazione di clusters, outputting cumandamenti risultati, cullizzioni di logs, ma Arun B. si moveva in a direzzione ghjusta à ghjudicà da e dumande dumandatu à mè.
Quandu avemu ghjuntu à u puntu di attivà -stderrthreshold = debug in u so vpc-controller, è chì successe dopu? di sicuru ùn funziona micca) u pod simpricimenti ùn principia micca cù questa opzione, solu -stderrthreshold=info travaglia.
Avemu finitu quì è Arun B. hà dettu ch'ellu avissi da pruvà à ripruduce i mo passi per avè u listessu errore. U ghjornu dopu riceve una risposta da Arun B. ùn hà micca abbandunà stu casu, ma hà pigliatu u codice di rivisione di u so vpc-controller è hà trovu u locu induve hè è perchè ùn funziona micca:
Cusì, sè vo aduprate a tavola di rotta principale in u vostru VPC, in modu predeterminatu ùn hà micca associazioni cù i subnets necessarii, chì sò cusì necessarii per u vpc-controller, in u casu di una subnet publica, hà una tavola di rotta persunalizata. chì hà un associu.
Aghjunghjendu manualmente associazioni per a tavola di a strada principale cù i subnets necessarii, è ricreendu u nodegroup, tuttu funziona perfettamente.
Spergu chì Arun B. hà da veramente rapportà stu bug à i sviluppatori EKS è vedemu una nova versione di vpc-controller induve tuttu u travagliu fora di a scatula. Attualmente l'ultima versione hè: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
hà stu prublema.
Grazie à tutti quelli chì leghjenu finu à a fine, pruvate tuttu ciò chì avete da aduprà in a produzzione prima di l'implementazione.
Source: www.habr.com