Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Failover dei pod Kubernetes tramite disconnessioni di rete
Iniziamo con una revisione dei concetti chiave, dei componenti e delle impostazioni che influenzano il comportamento di Kubernetes durante le disconnessioni di rete tra i nodi e il piano di controllo di Kubernetes. EKS è conforme a Kubernetes a monte, quindi tutti i concetti, i componenti e le impostazioni Kubernetes descritti qui si applicano alle implementazioni EKS ed EKS Hybrid Nodes.
Per ulteriori informazioni sul comportamento di failover del pod Kubernetes a monte durante le disconnessioni di rete, consulta i problemi #131294 e #131481 nel repository Kubernetes upstream. GitHub https://github.com/kubernetes/kubernetes/pull/131294
Concetti
Colori e tolleranze: i contaminanti e le tolleranze vengono utilizzati in Kubernetes per controllare la pianificazione dei pod sui nodi. I taint vengono impostati dal node-lifecycle-controller per indicare che i nodi non sono idonei alla pianificazione o che i pod su tali nodi devono essere eliminati. Quando i nodi non sono raggiungibili a causa di una disconnessione dalla rete, il node-lifecycle-controller applica node.kubernetes. io/unreachable contaminare con un effetto e con un effetto se vengono soddisfatte determinate condizioni. NoSchedule NoExecute Il node.kubernetes. io/unreachable La macchia corrisponde al fatto che Ready è Unknown. NodeCondition Gli utenti possono specificare le tolleranze per i contaminanti a livello di applicazione in. PodSpec
-
NoSchedule: Non sono programmati nuovi Pod sul nodo contaminato a meno che non abbiano una tolleranza corrispondente. I pod già in esecuzione sul nodo non vengono eliminati.
-
NoExecute: I pod che non tollerano la contaminazione vengono sfrattati immediatamente. I pod che tollerano la contaminazione (senza specificare TolerationSeconds) rimangono vincolati per sempre. I pod che tollerano la contaminazione con un valore di tolleranza specificato rimangono vincolati per il tempo specificato. Trascorso questo tempo, il controller del ciclo di vita del nodo rimuove i Pod dal nodo.
Node Leases: Kubernetes utilizza l'API Lease per comunicare gli heartbeat del nodo Kubelet al server API Kubernetes. Per ogni nodo, esiste un oggetto Lease con un nome corrispondente. Internamente, ogni kubelet heartbeat aggiorna il campo SPEC.renewTime dell'oggetto Lease. Il piano di controllo di Kubernetes utilizza il timestamp di questo campo per determinare la disponibilità dei nodi. Se i nodi vengono disconnessi dal piano di controllo di Kubernetes, non possono aggiornare Spec.RenewTime per il loro Lease e il piano di controllo lo interpreta come Ready come Unknown. NodeCondition
Componenti
| Componente | Sub-component | Description |
|---|---|---|
|
Piano di controllo Kubernetes |
server kube-api |
Il server API è un componente principale del piano di controllo Kubernetes che espone l'API Kubernetes. |
|
Piano di controllo Kubernetes |
node-lifecycle-controller |
Uno dei controller eseguiti dal kube-controller-manager. È responsabile del rilevamento e della risposta ai problemi dei nodi. |
|
Piano di controllo Kubernetes |
kube-scheduler |
Un componente del piano di controllo che controlla i Pod appena creati senza alcun nodo assegnato e seleziona un nodo su cui eseguirli. |
|
Nodi Kubernetes |
kubelet |
Un agente che viene eseguito su ogni nodo del cluster. Il kubelet controlla PodSpecs e garantisce che i contenitori in essi descritti PodSpecs siano funzionanti e integri. |
Impostazioni di configurazione
| Componente | Impostazione | Description | L'impostazione predefinita di K8 | EKS predefinito | Configurabile in EKS |
|---|---|---|---|---|---|
|
server kube-api |
secondi di tolleranza non raggiungibili di default |
Indica la tolleranza |
300 |
300 |
No |
|
node-lifecycle-controller |
node-monitor-grace-period |
Il periodo di tempo in cui un nodo può non rispondere prima di essere contrassegnato come non integro. Deve essere N volte superiore a quello di kubelet |
40 |
40 |
No |
|
node-lifecycle-controller |
soglia di grandi dimensioni del cluster |
Il numero di nodi in cui il node-lifecycle-controller considera il cluster come grande per la logica di eliminazione. |
50 |
100.000 |
No |
|
node-lifecycle-controller |
soglia di zona non salutare |
La percentuale di nodi in una zona che deve essere non pronta perché tale zona venga considerata non integra. |
55% |
55% |
No |
|
kubelet |
frequenza di aggiornamento dello stato del nodo |
Con quale frequenza il kubelet invia lo stato del nodo al piano di controllo. Deve essere compatibile con in |
10 |
10 |
Sì |
|
kubelet |
etichette di nodo |
Etichette da aggiungere durante la registrazione del nodo nel cluster. L'etichetta |
Nessuno |
Nessuno |
Sì |
Failover del pod Kubernetes tramite disconnessioni di rete
Il comportamento qui descritto presuppone che i pod vengano eseguiti come Kubernetes Deployments con impostazioni predefinite e che EKS sia utilizzato come provider Kubernetes. Il comportamento effettivo potrebbe variare in base all'ambiente, al tipo di disconnessione della rete, alle applicazioni, alle dipendenze e alla configurazione del cluster. Il contenuto di questa guida è stato convalidato utilizzando un'applicazione specifica, una configurazione del cluster e un sottoinsieme di plug-in. Si consiglia vivamente di testare il comportamento nel proprio ambiente e con le proprie applicazioni prima di passare alla produzione.
In caso di disconnessioni di rete tra i nodi e il piano di controllo di Kubernetes, il kubelet su ciascun nodo disconnesso non può comunicare con il piano di controllo di Kubernetes. Di conseguenza, il kubelet non può rimuovere i pod su quei nodi finché la connessione non viene ripristinata. Ciò significa che i pod in esecuzione su quei nodi prima della disconnessione dalla rete continuano a funzionare durante la disconnessione, supponendo che non siano stati causati da altri guasti. In sintesi, è possibile raggiungere la stabilità statica durante le disconnessioni di rete tra i nodi e il piano di controllo di Kubernetes, ma non è possibile eseguire operazioni di mutazione sui nodi o sui carichi di lavoro finché la connessione non viene ripristinata.
Esistono cinque scenari principali che producono diversi comportamenti di failover del pod in base alla natura della disconnessione dalla rete. In tutti gli scenari, il cluster torna a funzionare senza l'intervento dell'operatore una volta che i nodi si riconnetteranno al piano di controllo di Kubernetes. Gli scenari seguenti delineano i risultati attesi in base alle nostre osservazioni, ma questi risultati potrebbero non essere applicabili a tutte le possibili configurazioni di applicazioni e cluster.
Scenario 1: interruzione completa del cluster
Risultato previsto: i pod sui nodi irraggiungibili non vengono eliminati e continuano a funzionare su tali nodi.
Un'interruzione completa del cluster significa che tutti i nodi del cluster vengono disconnessi dal piano di controllo di Kubernetes. In questo scenario, il node-lifecycle-controller sul piano di controllo rileva che tutti i nodi del cluster sono irraggiungibili e annulla qualsiasi rimozione dei pod.
Gli amministratori del cluster vedranno tutti i nodi con stato durante la disconnessione. Not Ready Lo stato del pod non cambia e non vengono pianificati nuovi pod su nessun nodo durante la disconnessione e la successiva riconnessione.
Scenario 2: interruzione dell'intera zona
Risultato previsto: il comportamento dipende dal fatto che la zona interessata sia l'unica zona del cluster.
Un'interruzione completa della zona significa che tutti i nodi della zona sono disconnessi dal piano di controllo di Kubernetes.
Single-zone cluster (o cluster in cui i nodi non hanno l'topology.kubernetes.io/zoneetichetta): quando la zona interessata è l'unica zona del cluster, un'interruzione dell'intera zona equivale a un'interruzione completa del cluster (Scenario 1). Il node-lifecycle-controller entra in «modalità master disruption» perché ogni zona ha zero nodi Ready e annulla tutte le eliminazioni dei pod. I pod continuano a funzionare su nodi irraggiungibili.
Multi-zone cluster: quando un cluster ha nodi in più zone e una zona è completamente inattiva, le zone rimanenti hanno ancora nodi Ready. In questo caso, gli sfratti procedono normalmente: i pod sui nodi non raggiungibili nella zona guasta vengono eliminati dopo default-unreachable-toleration-seconds (5 minuti) e node-monitor-grace-period (40 secondi) e i nuovi pod vengono programmati sui nodi integri nelle zone rimanenti. Per maggiori dettagli su questo comportamento, vedi Comprendere l'eliminazione dei pod durante le interruzioni zonali. https://docs.aws.amazon.com/prescriptive-guidance/latest/ha-resiliency-amazon-eks-apps/pod-eviction.html
Nota
I nodi senza topology.kubernetes.io/zone etichetta sono raggruppati in un'unica zona implicita. Se tutti i nodi di un cluster Multi-AZ non hanno questa etichetta, il cluster si comporta come se avesse una sola zona e un'interruzione completa della zona innesca il comportamento dello Scenario 1 indipendentemente dal numero di zone di disponibilità fisiche.
Scenario 3: interruzione della maggior parte delle zone
Risultato previsto: i pod sui nodi irraggiungibili non vengono eliminati e continuano a funzionare su tali nodi.
Un'interruzione della maggior parte delle zone significa che la maggior parte dei nodi in una determinata zona sono disconnessi dal piano di controllo di Kubernetes. Le zone in Kubernetes sono definite da nodi con la stessa etichetta. topology.kubernetes.io/zone Se non è definita alcuna zona nel cluster, un'interruzione di maggioranza significa che la maggior parte dei nodi dell'intero cluster è disconnessa. Per impostazione predefinita, la maggioranza è definita dai node-lifecycle-controller, che sono impostati al 55% sia in unhealthy-zone-threshold Kubernetes che in EKS. Poiché large-cluster-size-threshold è impostato su 100.000 in EKS, se il 55% o più dei nodi in una zona è irraggiungibile, gli sfratti dei pod vengono annullati (dato che la maggior parte dei cluster è molto più piccola di 100.000 nodi).
Gli amministratori del cluster vedranno la maggior parte dei nodi nella zona con stato Not Ready durante la disconnessione, ma lo stato dei pod non cambierà e non verranno riprogrammati su altri nodi.
Nota che il comportamento sopra riportato si applica solo ai cluster più grandi di tre nodi. Nei cluster di tre nodi o meno, i pod su nodi non raggiungibili sono pianificati per l'eliminazione e i nuovi pod sono programmati su nodi integri.
Durante i test, abbiamo osservato occasionalmente che i pod venivano rimossi esattamente da un nodo irraggiungibile durante le disconnessioni di rete, anche quando la maggior parte dei nodi della zona era irraggiungibile. Si tratta di un comportamento noto (vedi #131481unreachable:NoExecute prima che venga raggiunto il unhealthy-zone-threshold (55%), tale contaminazione non viene rimossa una volta superata la soglia e la riduzione del tasso di sfratti ha effetto. I pod su quel nodo già contaminato vengono comunque sfrattati di per sé. tolerationSeconds
Scenario 4: interruzione delle zone minoritarie
Risultato previsto: i pod vengono rimossi dai nodi non raggiungibili e i nuovi pod vengono programmati sui nodi disponibili e idonei.
Un'interruzione di minoranza significa che una percentuale minore di nodi in una zona viene disconnessa dal piano di controllo di Kubernetes. Se nel cluster non è definita alcuna zona, un'interruzione di minoranza significa che la minoranza dei nodi dell'intero cluster è disconnessa. Come indicato, la minoranza è definita dall'impostazione di node-lifecycle-controller, che per unhealthy-zone-threshold impostazione predefinita è del 55%. In questo scenario, se la disconnessione dalla rete dura più di default-unreachable-toleration-seconds (5 minuti) e node-monitor-grace-period (40 secondi) e meno del 55% dei nodi di una zona è irraggiungibile, i nuovi pod vengono pianificati sui nodi integri mentre i pod sui nodi non raggiungibili sono contrassegnati per l'eliminazione.
Gli amministratori del cluster vedranno i nuovi pod creati su nodi integri e i pod sui nodi disconnessi verranno visualizzati come. Terminating Ricorda che, anche se i pod sui nodi disconnessi hanno uno Terminating status, non vengono completamente eliminati finché il nodo non si riconnette al piano di controllo di Kubernetes.
Scenario 5: riavvio del nodo durante un'interruzione della rete
Risultato previsto: i pod sui nodi irraggiungibili non vengono avviati finché i nodi non si riconnettono al piano di controllo di Kubernetes. Il failover dei pod segue la logica descritta negli Scenari 1—3, a seconda del numero di nodi irraggiungibili.
Il riavvio di un nodo durante un'interruzione della rete significa che si è verificato un altro errore (ad esempio un ciclo di alimentazione, un evento di esaurimento della memoria o altro problema) su un nodo contemporaneamente a una disconnessione dalla rete. I pod che erano in esecuzione su quel nodo all'inizio della disconnessione dalla rete non vengono riavviati automaticamente durante la disconnessione se anche il kubelet è stato riavviato. Il kubelet interroga il server API Kubernetes durante l'avvio per sapere quali pod deve essere eseguito. Se il kubelet non riesce a raggiungere il server API a causa di una disconnessione dalla rete, non può recuperare le informazioni necessarie per avviare i pod.
In questo scenario, gli strumenti locali di risoluzione dei problemi, come la crictl CLI, non possono essere utilizzati per avviare i pod manualmente come misura preventiva. Kubernetes in genere rimuove i pod guasti e ne crea di nuovi anziché riavviare i pod esistenti (vedi #10213 nel repository containerd per i dettagli). https://github.com/containerd/containerd/pull/10213
