‘Imansible connettersi al Net / http: TLS timeout del timeout’ – Perché Kubectl non può connettersi al server Azure Kubernetes? (AKS)

La mia domanda (a SM ea chiunque altro) è: perché questo problema si verifica e quali sono le soluzioni che possono essere implementate dagli utenti / clienti stessi rispetto al supporto Microsoft?

Ci sono state ovviamente alcune “altre” domande su questo problema:

  1. Errore di connessione di Azure Kubernetes gestito
  2. Imansible contattare il nostro Azure-AKS Kube – timeout dell’handshake TLS
  3. Azure Kubernetes: timeout dell’handshake TLS (questo ha qualche riscontro da Microsoft)

E più problemi di GitHub pubblicati sul repository AKS:

  1. https://github.com/Azure/AKS/issues/112
  2. https://github.com/Azure/AKS/issues/124
  3. https://github.com/Azure/AKS/issues/164
  4. https://github.com/Azure/AKS/issues/177
  5. https://github.com/Azure/AKS/issues/324

Più alcuni thread su Twitter:

  1. https://twitter.com/ternel/status/955871839305261057

TL; DR

Passa a soluzioni alternative in Risposte qui sotto .

La migliore soluzione attuale è pubblicare un ticket di assistenza – e attendere – o ricreare il tuo cluster AKS (forse più di una volta, incrocia le dita, vedi sotto …) ma dovrebbe esserci qualcosa di meglio. Almeno, per favore concedi la possibilità di consentire ad AKS di visualizzare l’anteprima dei clienti, indipendentemente dal livello di supporto, aggiornare la severità della richiesta di supporto per questo specifico problema.

Puoi anche provare a ridimensionare il tuo Cluster (supponendo che non si rompa la tua app).

Che mi dici di GitHub?

Molti dei problemi sopra GitHub sono stati chiusi come risolti ma il problema persiste. Precedentemente c’era un documento di annunci relativo al problema ma attualmente non sono disponibili aggiornamenti di questo tipo, anche se il problema continua a presentarsi:

  1. https://github.com/Azure/AKS/tree/master/annoucements

Sto postando questo perché ho alcune novità che non ho visto altrove e mi chiedo se qualcuno ha idee per quanto riguarda altre potenziali opzioni per aggirare il problema.

Utilizzo della risorsa VM / nodo interessato

Il primo pezzo che non ho visto menzionato altrove è l’utilizzo delle risorse sui nodes / vms / istanze che sono stati interessati dal suddetto problema di Kubectl “Imansible connettersi al server: net / http: TLS handshake timeout”.

Utilizzo del nodo di produzione

Il nodo (i) sul mio cluster interessato assomiglia a questo:

net / http: timeout handshake TLS

Il calo dell’utilizzo e della rete io è strettamente correlato sia all’aumento dell’utilizzo del disco sia al periodo di tempo in cui abbiamo iniziato a riscontrare il problema.

L’utilizzo complessivo di Node / VM è generalmente piatto prima di questo grafico per i precedenti 30 giorni con alcuni dossi relativi al traffico del sito di produzione / push di aggiornamento, ecc.

Metriche dopo la riduzione dei problemi (aggiunta postmortem)

Al punto precedente, qui ci sono le metriche dello stesso Node dopo il Ridimensionamento e poi indietro (che è successo per alleviare il nostro problema, ma non sempre funziona – vedere le risposte in fondo):

inserisci la descrizione dell'immagine qui

Si noti il ​​”Dip” nella CPU e nella rete? È qui che il problema Net / http: TLS ha avuto un impatto su di noi e quando il server AKS non era raggiungibile da Kubectl. Sembra che non stesse parlando con VM / Node oltre a non rispondere alle nostre richieste.

Non appena siamo tornati indietro (scalato i nodes # di uno, e retrocesso – vedi le risposte per soluzione alternativa) le metriche (CPU ecc.) Sono tornate alla normalità e potremmo connetterci da Kubectl. Ciò significa che probabilmente possiamo creare un allarme da questo comportamento (e ho un problema nel chiedere informazioni su questo lato di Azure DevOps: https://github.com/Azure/AKS/issues/416 )

La dimensione del nodo influisce potenzialmente sulla frequenza di emissione

Zimmergren su GitHub indica che ha meno problemi con le istanze più grandi di quanto non abbia fatto con nodes più piccoli. Questo ha senso per me e potrebbe indicare che il modo in cui i server AKS divulano il carico di lavoro (vedi la prossima sezione) potrebbe essere basato sulla dimensione delle istanze.

“La dimensione dei nodes (ad es. D2, A4, ecc.) 🙂 Ho sperimentato che, quando si esegue A4 e versioni successive, il mio cluster è più sano che se si esegue A2, ad esempio. (E ne ho più di una dozzina di simili esperienze con combinazioni di dimensioni e guasti del cluster, sfortunatamente). ” ( https://github.com/Azure/AKS/issues/268#issuecomment-375715435 )

Altri riferimenti all’impatto sulla dimensione del cluster:

  1. giorgited ( https://github.com/Azure/AKS/issues/268#issuecomment-376390692 )

Un server AKS responsabile di cluster più piccoli potrebbe essere colpito più spesso?

Esistenza di “server” di gestione AKS multipli in una regione di Az

La prossima cosa che non ho visto menzionato altrove è il fatto che puoi avere più Cluster che corrono fianco a fianco nella stessa Regione dove un Cluster (produzione per noi in questo caso) viene colpito con ‘timeout handshake net / http: TLS’ e l’altro funziona bene e può essere collegato normalmente tramite Kubectl (per noi questo è il nostro ambiente di staging identico).

Il fatto che gli utenti (Zimmergren ecc. Sopra) sembrino ritenere che la dimensione del nodo influenzi la probabilità che questo problema abbia un impatto su di te sembra anche indicare che la dimensione del nodo può riguardare il modo in cui le responsabilità della sottoregione vengono assegnate all’AKS subregionale server di gestione.

Ciò potrebbe significare che ricreare il tuo cluster con una diversa dimensione del Cluster avrebbe più probabilità di metterti su un server di gestione diverso – alleviando il problema e riducendo la probabilità che sarebbero necessarie più ri-creazioni.

Utilizzo del cluster di gestione temporanea

Entrambi i nostri cluster AKS sono situati negli Stati Uniti orientali. Come riferimento alle metriche del Cluster “Produzione” di cui sopra, il nostro utilizzo delle risorse “Staging” Cluster (anche negli Stati Uniti orientali) non ha il forte calo di CPU / rete IO – E non ha l’aumento del disco ecc. Nello stesso periodo:

net / http: l'istanza di staging del timeout del handshake TLS è raggiungibile tramite kubectl.

Gli ambienti identici vengono influenzati in modo diverso

Entrambi i nostri cluster eseguono identici ingressi, servizi, pod, contenitori, quindi è anche improbabile che tutto ciò che un utente sta facendo causa questo problema.

La ri-creazione è A VOLTE SUCCESSIVAMENTE riuscita

La suddetta esistenza di molteplici responsabilità sub-regionali del server di gestione AKS ha senso con il comportamento descritto da altri utenti su github ( https://github.com/Azure/AKS/issues/112 ) in cui alcuni utenti sono in grado di ricreare un cluster (che può quindi essere contattato) mentre altri lo ricreano e hanno ancora problemi.

Emergenza potrebbe = Ricreazioni multiple

In caso di emergenza (cioè il tuo sito di produzione … come il nostro … deve essere gestito) puoi PROBABILMENTE solo ricreare fino a quando non ottieni un cluster funzionante che si trova in una diversa istanza del server di gestione AKS (uno che non è impattato) ma sappiate che questo potrebbe non accadere al primo tentativo – la ricostruzione del cluster AKS non è esattamente istantanea.

Detto ciò…

Le risorse sui nodes impattati continuano a funzionare

Tutti i contenitori / ingressi / risorse della nostra VM interessata sembrano funzionare bene e non ho alcun allarme che si triggers per il monitoraggio di uptime / risorse (oltre alle stranezze di utilizzo sopra elencate nei grafici)

Voglio sapere perché questo problema si sta verificando e quali sono le soluzioni che possono essere implementate dagli utenti stessi anziché dal supporto Microsoft (attualmente hanno un ticket in). Se hai un’idea, fammelo sapere.

Potenziali suggerimenti per la causa

  1. https://github.com/Azure/AKS/issues/164#issuecomment-363613110
  2. https://github.com/Azure/AKS/issues/164#issuecomment-365389154

Perché nessun GKE?

Comprendo che Azure AKS è in anteprima e che molte persone si sono trasferite a GKE a causa di questo problema (). Ciò detto, la mia esperienza su Azure è stata finora nient’altro che positiva e preferirei contribuire con una soluzione se ansible.

E inoltre … GKE affronta occasionalmente qualcosa di simile:

  1. Timeout handshake TLS con kubernetes in GKE

Sarei interessato a vedere se scalare i nodes su GKE risolva anche il problema laggiù.

Soluzione alternativa 1 (Potrebbe non funzionare per tutti)

Una soluzione interessante (ha funzionato per me) per testare è ridimensionare il numero di nodes nel cluster, e quindi tornare indietro …

inserisci la descrizione dell'immagine qui

  1. Accedere a Console di Azure: il blade del servizio di Kubernetes.
  2. Ridimensiona il tuo cluster di 1 nodo.
  3. Attendi il completamento della scala e prova a connetterti (dovresti essere in grado di).
  4. Ridimensionare il cluster alla dimensione normale per evitare aumenti dei costi.

In alternativa puoi (forse) farlo dalla riga di comando:

az aks scale --name --node-count --resource-group

Dal momento che si tratta di un problema complesso e ho usato l’interfaccia web non sono sicuro se quanto sopra è identico o funzionerebbe.

Tempo totale mi ci sono voluti ~ 2 minuti – per la mia situazione che è MOLTO meglio di ricreare / configurare un Cluster (potenzialmente più volte …)

Detto ciò….

Zimmergren mostra alcuni punti positivi che Scaling non è una vera soluzione:

“Ha funzionato a volte, in cui il cluster ha auto-ripristinato un periodo dopo il ridimensionamento, ma a volte ha fallito con gli stessi errori. Non considero il ridimensionamento di una soluzione a questo problema, poiché questo causa altre sfide a seconda di come sono impostate le cose. Non mi fido di quella routine per un carico di lavoro di GA, questo è sicuro: nell’attuale anteprima, è un po ‘selvaggio west (e atteso), e sono felice di far saltare il cluster e crearne uno nuovo quando questo non riesce continuamente. ” ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )

Feedback di supporto di Azure

Poiché avevo un ticket di supporto aperto al momento in cui mi sono imbattuto nella soluzione di scalabilità sopra riportata, sono stato in grado di ottenere un feedback (o meglio un’ipotesi) su ciò che potrebbe funzionare in precedenza, ecco una risposta parafrasata:

“So che il ridimensionamento del cluster può a volte aiutare se si entra in uno stato in cui il numero di nodes non corrisponde tra” az aks show “e” kubectl get nodes “. Potrebbe essere simile.”

Riferimenti per soluzioni temporanee:

  1. Utente GitHub Scalare i nodes dalla console e risolvere il problema: https://github.com/Azure/AKS/issues/268#issuecomment-375722317

Soluzione alternativa non ha funzionato?

Se questo non funziona per te, ti preghiamo di postare un commento qui sotto perché cercherò di mantenere un elenco aggiornato della frequenza con cui il problema si verifica, se si risolve da solo e se questa soluzione funziona tra gli utenti Azure AKS (aspetto come se non funzionasse per tutti).

Utenti scalabili su / giù NON FUNZIONANO per:

  1. omgargo ( https://github.com/Azure/AKS/issues/112#issuecomment-395231681 )
  2. Zimmergren ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )
  3. operazione di scala sercand – non riuscita – non sicuro se avrebbe avuto un impatto sulla connettibilità ( https://github.com/Azure/AKS/issues/268#issuecomment-395301296 )

Scalare su / giù il lavoro DID per:

  1. Me
  2. LohithChanda ( https://github.com/Azure/AKS/issues/268#issuecomment-395207716 )
  3. Zimmergren ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )

Soluzione 2 Ricreare il cluster (piuttosto ovvio)

Aggiungo questo perché ci sono alcuni dettagli da tenere a mente e anche se l’ho toccato nella mia domanda iniziale, quella cosa è durata molto, quindi aggiungo dettagli specifici sulla ricreazione qui.

La ri-creazione del cluster non funziona sempre

Per quanto sopra nella mia domanda originale ci sono più istanze di AKS Server che dividono le responsabilità per una determinata area di Azure (pensiamo). Alcuni, o tutti, di questi possono essere influenzati da questo bug che risulta nel non essere raggiungibile tramite Kubectl.

Ciò significa che se crei nuovamente il Cluster e se atterra sullo stesso server AKS, probabilmente quel nuovo Cluster non sarà raggiungibile anche richiedendo …

Ulteriori tentativi di ri-creazione

Probabilmente ricreando più volte, il tuo nuovo Cluster verrà scaricato su uno degli altri server AKS (che funziona correttamente). Per quanto posso dire, non vedo alcuna indicazione che TUTTI i server AKS vengano colpiti con questo problema di tanto in tanto (se mai).

Diversa dimensione del nodo del cluster

Se sei in difficoltà e vuoi la massima probabilità ansible ( non lo abbiamo confermato ) che la tua ri-creazione atterra su un server di gestione AKS diverso, scegli una diversa dimensione del nodo quando crei il tuo nuovo Cluster (vedi la sezione Dimensione del nodo di la domanda iniziale sopra).

Ho aperto questo ticket chiedendo a Azure DevOps se la dimensione del nodo è EFFETTIVAMENTE correlata alla decisione su quali cluster sono amministrati da quali server di gestione AKS: https://github.com/Azure/AKS/issues/416

Support Fix di ticket vs. Self Healing

Poiché ci sono molti utenti che indicano che il problema occasionalmente si risolve da solo e va via, penso che sia ragionevole supporre che il supporto risolva effettivamente il server AKS incriminato (che potrebbe comportare la correzione di altri utenti con i Cluster – Self Self ‘) in contrasto con la correzione del Cluster del singolo utente.

Creazione di ticket di supporto

Per me quanto sopra significherebbe probabilmente che creare un Ticket è probabilmente una buona cosa dato che risolverebbe altri Cluster di utenti che hanno riscontrato lo stesso problema – potrebbe anche essere un argomento per consentire l’escalation della gravità del problema di supporto per questo specifico problema.

Penso che questo sia anche un indicatore decente che forse il supporto di Azure non ha ancora capito come allarmare completamente il problema, nel qual caso anche la creazione di un ticket di supporto serve a tale scopo.

Ho anche chiesto a Azure DevOps se Allarme per il problema (in base alla mia esperienza visualizzava facilmente il problema in base alle modifiche delle metriche della CPU e della rete IO) dalla loro parte: https://github.com/Azure/AKS/issues/416

Se NOT ( non si è sentito indietro ) allora ha senso creare un ticket ANCHE SE si pianifica di ricreare il proprio cluster poiché tale ticket renderebbe Azure DevOps consapevole del problema risultante in una correzione per gli altri utenti su quella gestione del Cluster server.

Cose per rendere più facile la Ri-creazione del cluster

Aggiungerò a questo (feedback / idee sono apprezzati) ma in cima alla mia testa:

  1. Sii diligente (ovvio) sul modo in cui archivi tutti i file YAML usati per creare il tuo Cluster (anche se non lo ri-distribuisci spesso per la tua app in base alla progettazione).
  2. Script le tue modifiche DNS per accelerare il puntamento alla nuova istanza – Se hai un’applicazione / servizio pubblico che utilizza DNS (forse qualcosa come questo esempio per Google Domains ?: https://gist.github.com/cyrusboadway/ 5a7b715665f33c237996 , Documenti completi qui: https://cloud.google.com/dns/api/v1/ )