Buon pomeriggio, voglio condividere con voi la mia esperienza nella configurazione e nell'utilizzo del servizio AWS EKS (Elastic Kubernetes Service) per container Windows, ovvero sull'impossibilità di utilizzarlo, e sul bug riscontrato nel container del sistema AWS, per quelli che sono interessati a questo servizio per i contenitori Windows, si prega di consultare la cat.
So che i contenitori Windows non sono un argomento popolare e poche persone li usano, ma ho comunque deciso di scrivere questo articolo, poiché c'erano un paio di articoli su Habré su Kubernetes e Windows e ci sono ancora persone del genere.
Inizio
Tutto è iniziato quando abbiamo deciso di migrare i servizi della nostra azienda su Kubernetes, che è al 70% Windows e al 30% Linux. A questo scopo, il servizio cloud AWS EKS è stato considerato una delle possibili opzioni. Fino all'8 ottobre 2019 AWS EKS Windows era in anteprima pubblica, ho iniziato con quello, lì veniva utilizzata la vecchia versione 1.11 di Kubernetes, ma ho deciso comunque di controllarlo e vedere a che punto era questo servizio cloud, se funzionava affatto, come si è scoperto, no, c'era un bug con l'aggiunta della rimozione dei pod, mentre quelli vecchi smettevano di rispondere tramite IP interno dalla stessa sottorete del nodo di lavoro di Windows.
Pertanto si è deciso di abbandonare l'uso di AWS EKS a favore del nostro cluster su Kubernetes sullo stesso EC2, solo che avremmo dovuto descrivere noi stessi tutto il bilanciamento e l'HA tramite CloudFormation.
Il supporto per i contenitori Windows Amazon EKS è ora disponibile a livello generale
di Martin Beeby | il 08 OTT 2019
Prima di avere il tempo di aggiungere un modello a CloudFormation per il mio cluster, ho visto questa notizia
Ovviamente ho messo da parte tutto il mio lavoro e ho iniziato a studiare cosa hanno fatto per GA e come tutto è cambiato con Public Preview. Sì, AWS, ben fatto, ha aggiornato le immagini per il nodo Windows Worker alla versione 1.14, così come il cluster stesso, versione 1.14 in EKS, ora supporta i nodi Windows. Progetto di Anteprima pubblica su Lo hanno nascosto e hanno detto che ora usa la documentazione ufficiale qui:
Integrazione di un cluster EKS nel VPC e nelle sottoreti correnti
In tutte le fonti, nel collegamento riportato sopra nell'annuncio e nella documentazione, è stato proposto di implementare il cluster tramite l'utilità proprietaria eksctl o successivamente tramite CloudFormation + kubectl, utilizzando solo sottoreti pubbliche in Amazon, oltre a creare un VPC separato per un nuovo cluster.
Questa opzione non è adatta a molti; in primo luogo, un VPC separato significa costi aggiuntivi per il suo costo + traffico in peering al tuo VPC attuale. Cosa dovrebbe fare chi ha già un'infrastruttura già pronta in AWS con i propri account AWS multipli, VPC, sottoreti, tabelle di routing, transit gateway e così via? Naturalmente, non vuoi interrompere o rifare tutto questo, ma devi integrare il nuovo cluster EKS nell'attuale infrastruttura di rete, utilizzando il VPC esistente e, per la separazione, creare al massimo nuove sottoreti per il cluster.
Nel mio caso è stato scelto questo percorso, ho utilizzato il VPC esistente, ho aggiunto solo 2 sottoreti pubbliche e 2 sottoreti private per il nuovo cluster, ovviamente tutte le regole sono state prese in considerazione secondo la documentazione .
C'era anche una condizione: nessun nodo di lavoro nelle sottoreti pubbliche che utilizzavano EIP.
eksctl contro CloudFormation
Faccio subito una prenotazione per aver provato entrambi i metodi di distribuzione del cluster, in entrambi i casi l'immagine era la stessa.
Mostrerò un esempio solo utilizzando eksctl poiché il codice qui sarà più breve. Utilizzando eksctl, distribuisci il cluster in 3 passaggi:
1. Creiamo il cluster stesso + il nodo di lavoro Linux, che in seguito ospiterà i contenitori di sistema e lo stesso sfortunato controller vpc.
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 eseguire la distribuzione su un VPC esistente, specifica semplicemente l'ID delle tue sottoreti ed eksctl determinerà il VPC stesso.
Per assicurarti che i tuoi nodi di lavoro siano distribuiti solo su una sottorete privata, devi specificare --node-private-networking per nodegroup.
2. Installiamo vpc-controller nel nostro cluster, che poi elaborerà i nostri nodi di lavoro, contando il numero di indirizzi IP liberi, nonché il numero di ENI sull'istanza, aggiungendoli e rimuovendoli.
eksctl utils install-vpc-controllers --name yyy --approve3.Dopo che i contenitori di sistema sono stati avviati con successo sul tuo nodo di lavoro Linux, incluso vpc-controller, non resta che creare un altro gruppo di nodi con Windows Worker.
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-networkingDopo che il tuo nodo si è connesso con successo al tuo cluster e tutto sembra andare bene, è nello stato Pronto, ma no.
Errore nel controller vpc
Se proviamo a eseguire i pod su un nodo Windows Worker, otterremo 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 guardiamo più in profondità, vediamo che la nostra istanza in AWS assomiglia a questa:
E dovrebbe essere così:
Da ciò è chiaro che il controller vpc non ha svolto la sua parte per qualche motivo e non ha potuto aggiungere nuovi indirizzi IP all'istanza in modo che i pod potessero utilizzarli.
Diamo un'occhiata ai log del pod vpc-controller e questo è ciò che vediamo:
registro kubectl -n sistema kube
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.Le ricerche su Google non hanno portato a nulla, poiché apparentemente nessuno aveva ancora rilevato un bug del genere o non aveva pubblicato un problema al riguardo, ho dovuto prima pensare io stesso alle opzioni. La prima cosa che mi è venuta in mente è che forse il controller vpc non riesce a risolvere ip-10-xxx.ap-xxx.compute.internal e a raggiungerlo e quindi si verificano errori.
Sì, infatti, utilizziamo server DNS personalizzati nel VPC e, in linea di principio, non utilizziamo quelli di Amazon, quindi anche l'inoltro non è stato configurato per questo dominio ap-xxx.compute.internal. Ho testato questa opzione e non ha portato risultati, forse il test non è stato pulito e quindi, inoltre, quando ho comunicato con il supporto tecnico, ho ceduto alla loro idea.
Dato che non c'erano davvero idee, tutti i gruppi di sicurezza sono stati creati da eksctl stesso, quindi non c'erano dubbi sulla loro funzionalità, anche le tabelle di routing erano corrette, c'erano anche nat, dns, accesso a Internet con nodi di lavoro.
Inoltre, se distribuisci un nodo di lavoro su una sottorete pubblica senza utilizzare —node-private-networking, questo nodo è stato immediatamente aggiornato dal controller vpc e tutto ha funzionato come un orologio.
C'erano due opzioni:
- Lascia perdere e aspetta finché qualcuno descrive questo bug in AWS e lo risolve, quindi puoi tranquillamente utilizzare AWS EKS Windows, perché sono appena stati rilasciati in GA (sono passati 8 giorni al momento della stesura di questo articolo), molti probabilmente lo faranno segui la mia stessa strada.
- Scrivi ad AWS Support e spiega loro l'essenza del problema con un sacco di log da ogni parte e dimostra loro che il loro servizio non funziona quando usi il tuo VPC e le sottoreti, non per niente abbiamo avuto il supporto aziendale, dovresti usare almeno una volta :)
Comunicazione con gli ingegneri AWS
Avendo creato un ticket sul portale, ho erroneamente scelto di rispondermi tramite Web - email o centro di supporto, tramite questa opzione possono risponderti dopo pochi giorni, nonostante il mio ticket avesse Severity - System alterato, il che significava una risposta entro meno di 12 ore e, poiché il piano di supporto Business prevede un supporto 24 ore su 7, XNUMX giorni su XNUMX, speravo per il meglio, ma è andata come sempre.
Il mio ticket è rimasto non assegnato da venerdì a lunedì, poi ho deciso di scrivere nuovamente e ho scelto l'opzione di risposta via chat. Dopo aver aspettato per un po', Harshad Madhav venne incaricato di vedermi, e poi cominciò...
Abbiamo eseguito il debug online per 3 ore di seguito, trasferendo i log, distribuendo lo stesso cluster nel laboratorio AWS per emulare il problema, ricreando il cluster da parte mia e così via, l'unica cosa a cui siamo arrivati è che da dai log era chiaro che il resol non funzionava sui nomi di dominio interni di AWS, di cui ho scritto sopra, e Harshad Madhav mi ha chiesto di creare l'inoltro, presumibilmente utilizziamo DNS personalizzati e questo potrebbe essere un problema.
Spedizione
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Questo è quello che è stato fatto, la giornata è finita, Harshad Madhav ha risposto per verificare e dovrebbe funzionare, ma no, la risoluzione non è stata di alcun aiuto.
Poi c'è stata una comunicazione con altri 2 ingegneri, uno ha semplicemente abbandonato la chat, a quanto pare aveva paura di un caso complesso, il secondo ha trascorso di nuovo la mia giornata in un ciclo completo di debug, invio di registri, creazione di cluster su entrambi i lati, nel fine ha appena detto bene, per me funziona, eccomi qui faccio tutto passo dopo passo nella documentazione ufficiale e tu e tu ci riuscirai.
Al che gli ho gentilmente chiesto di andarsene e di assegnare qualcun altro al mio biglietto se non sai dove cercare il problema.
Finale
Il terzo giorno mi è stato assegnato un nuovo ingegnere Arun B. e fin dall'inizio della comunicazione con lui è stato subito chiaro che non si trattava dei 3 ingegneri precedenti. Ha letto l'intera cronologia e ha immediatamente chiesto di raccogliere i log utilizzando il proprio script su PS1, che era sul suo github. Questo è stato seguito nuovamente da tutte le iterazioni di creazione di cluster, output dei risultati dei comandi, raccolta di log, ma Arun B. si stava muovendo nella giusta direzione a giudicare dalle domande che mi venivano poste.
Quando siamo arrivati al punto di abilitare -stderrthreshold=debug nel loro controller vpc e cosa è successo dopo? ovviamente non funziona) il pod semplicemente non si avvia con questa opzione, funziona solo -stderrthreshold=info.
Abbiamo finito qui e Arun B. ha detto che avrebbe provato a riprodurre i miei passi per ottenere lo stesso errore. Il giorno successivo ricevo una risposta da Arun B. non ha abbandonato questo caso, ma ha preso il codice di revisione del loro controller vpc e ha trovato il posto in cui si trova e perché non funziona:
Pertanto, se utilizzi la tabella di routing principale nel tuo VPC, per impostazione predefinita non ha associazioni con le sottoreti necessarie, che sono così necessarie per il controller vpc, nel caso di una sottorete pubblica, ha una tabella di routing personalizzata che ha un'associazione.
Aggiungendo manualmente le associazioni per la tabella di routing principale con le sottoreti necessarie e ricreando il gruppo di nodi, tutto funziona perfettamente.
Spero che Arun B. segnali davvero questo bug agli sviluppatori EKS e vedremo una nuova versione di vpc-controller in cui tutto funzionerà immediatamente. Attualmente l'ultima versione è: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ha questo problema.
Grazie a tutti coloro che hanno letto fino alla fine, prova tutto ciò che utilizzerai in produzione prima dell'implementazione.
Fonte: habr.com