Sviluppo e collaudo di app per garantirne la resilienza

Scopri come Red Hat OpenShift on IBM Cloud gestisce la manutenzione del piano di controllo, in che modo gli aggiornamenti di manutenzione influiscono sui carichi di lavoro in esecuzione e come testare e progettare le tue applicazioni per garantire un’elevata resilienza.

Panoramica sull'architettura dei cluster e sulle responsabilità

Red Hat OpenShift on IBM Cloud è un servizio gestito di tipo " Kubernetes ". In ogni cluster, l'architettura è suddivisa in due livelli con [responsabilità di gestione distinte](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service):

Piano di controllo
Gestito da IBM. Include il server API di Kubernetes, etcd, il gestore dei controller e lo scheduler.
Piano dati
Gestito da te. Comprende nodi di lavoro, pod applicativi, configurazioni di archiviazione e componenti aggiuntivi di rete.
Responsabilità relative alla proprietà del piano di controllo e del piano dati del cluster
Aereo Gestito da Componenti
Piano di controllo IBM Server API, etcd, gestore dei controller, scheduler
Piano dati Tu Nodi di lavoro, pod delle applicazioni, archiviazione, componenti aggiuntivi di rete

IBM applica regolarmente gli aggiornamenti delle versioni delle patch al piano di controllo. Queste patch risolvono le vulnerabilità di sicurezza, applicano correzioni di bug critiche e garantiscono che i cluster rimangano conformi ai requisiti di sicurezza di IBM. Comprendere come vengono applicate queste patch ti aiuta a prendere decisioni consapevoli riguardo all'architettura della tua applicazione.

Le applicazioni in esecuzione in ambienti cloud sono soggette a condizioni dinamiche, tra cui interruzioni transitorie della rete, interventi di manutenzione dell'infrastruttura di hosting e latenza dei servizi di terze parti. La progettazione e il collaudo finalizzati a garantire la resilienza in ogni circostanza assicurano l'affidabilità dei carichi di lavoro di produzione.

Come " IBM " applica le patch al piano di controllo

I componenti del piano di controllo di ogni cluster Red Hat OpenShift on IBM Cloud funzionano in una configurazione ad alta disponibilità (HA). Vengono distribuite più repliche di ciascun componente in zone di disponibilità indipendenti, in modo che non esista alcun singolo punto di guasto all’interno del piano di controllo.

Quando viene applicato un aggiornamento tramite patch, IBM utilizza una strategia di ricreazione progressiva. Le repliche vengono aggiornate in ordine sequenziale:

  • Il server API di Kubernetes rimane accessibile per tutta la durata dell'aggiornamento.
  • Le operazioni relative al cluster, quali la pianificazione, il ridimensionamento automatico e i controlli di integrità, proseguono senza interruzioni.
  • IBM garantisce un tempo di attesa per lo spegnimento graduale, in modo da consentire il completamento delle connessioni in corso prima della rimozione di un pod.

Gli aggiornamenti delle patch del piano di controllo sono progettati in modo tale da non avere alcun impatto sulle applicazioni degli utenti in esecuzione nel piano dati. I tuoi pod, servizi e carichi di lavoro continuano a funzionare normalmente sui nodi di lavoro per tutta la durata del processo.

Impatto sul carico di lavoro durante gli aggiornamenti del piano di controllo

Poiché il piano dati è gestito dall'utente, le patch del piano di controllo di IBM non riavviano, non riprogrammano né modificano i nodi di lavoro o i pod delle applicazioni in esecuzione.

Tuttavia, le applicazioni o gli strumenti che effettuano chiamate dirette e frequenti all'API " Kubernetes " (come controller personalizzati, operatori, pipeline CI/CD o agenti di monitoraggio che controllano lo stato del cluster) devono gestire in modo corretto gli errori transitori dell'API. Seguire le migliori pratiche generali relative all' Kubernetes:

  • Implementare una logica di riprova con back-off esponenziale per tutte le chiamate API.
  • Evitare di fare affidamento su connessioni aperte persistenti al server API senza una logica di riconnessione.

Simulazione di scenari per verificare la resilienza delle applicazioni

Per garantire la resilienza delle applicazioni, è opportuno simulare le condizioni di guasto in un ambiente non di produzione prima che si verifichino interventi di manutenzione programmata o interruzioni impreviste.

Durante qualsiasi simulazione, monitora le tue applicazioni per individuare eventuali segnali di malfunzionamento: riavvii imprevisti dei pod, picchi nei log degli errori, tempi di risposta rallentati o richieste dei client non elaborate. Utilizza queste osservazioni per perfezionare la logica dei tentativi di riprova, ottimizzare i test di integrità o adeguare la topologia delle repliche.

L'esecuzione dei comandi di gestione del cluster (come l'aggiornamento del master o il ridimensionamento del pool di worker) richiede l'accesso alla piattaforma con ruolo di Amministratore o Operatore e le autorizzazioni relative al servizio di gestione del cluster. Se sei uno sviluppatore di applicazioni e non hai accesso all'infrastruttura del cluster, mettiti d'accordo con l'amministratore del cluster per eseguire queste simulazioni.

Simulazione di una patch del piano di controllo con un aggiornamento del piano di controllo

L'attivazione di un aggiornamento del piano di controllo avvia il processo di aggiornamento graduale utilizzato da IBM durante gli aggiornamenti delle patch. Questo test verifica che l'applicazione e gli strumenti gestiscano senza intoppi le transizioni delle repliche del piano di controllo.

  1. Avvia un aggiornamento del piano di controllo sul tuo cluster.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

  2. Verificate che le vostre applicazioni continuino a gestire il traffico senza interruzioni e che gli endpoint rivolti ai clienti rimangano reattivi.

Simulazione degli aggiornamenti di routing della rete tramite l'aggiunta e la rimozione di nodi di lavoro

L'aggiunta e la rimozione di nodi di lavoro inducono l' Kubernetes e ad aggiornare la logica di routing di rete interna in tutto il cluster, simulando le condizioni che si verificano quando i nodi vengono riavviati durante la manutenzione dell'infrastruttura.

  1. Modifica le dimensioni del tuo pool di worker per aggiungere un nodo worker temporaneo.

    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE

  2. Monitora i log dell'applicazione e la latenza di risposta mentre il nuovo nodo worker si inizializza e si collega alla rete del cluster.

  3. Una volta completato il test, rimuovere il nodo di lavoro di test.

    Per rimuovere in modo mirato il nodo worker specifico creato al punto 1:

    1. Isolare e svuotare il nodo di lavoro prima di eliminarlo, per garantire che i carichi di lavoro vengano riprogrammati in modo corretto.
       oc cordon NODE_NAME
   oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. Elimina il nodo di lavoro dal cluster.
       ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. Ripristina la capacità originale del pool di worker utilizzando il comando ibmcloud oc worker-pool resize con il valore originale di --size-per-zone .

    In alternativa, con un approccio meno mirato, è possibile semplicemente riportare il pool di worker alle dimensioni originali utilizzando il comando ibmcloud oc worker-pool resize del passaggio 1, senza eliminare esplicitamente un nodo specifico.

Pratiche consigliate per la resilienza del carico di lavoro

La resilienza della vostra applicazione durante gli eventi relativi al cluster dipende da come sono progettati e configurati i vostri carichi di lavoro. Applica le seguenti best practice alle specifiche del tuo carico di lavoro Kubernetes:

Eseguire più repliche per ogni carico di lavoro

Un'implementazione a replica singola non può tollerare alcuna interruzione. Impostare spec.replicas su un valore pari almeno a 2 (preferibilmente 3 o superiore per i carichi di lavoro di produzione), in modo che la perdita o la riprogrammazione di un singolo pod non causi tempi di inattività.

Distribuire le repliche tra le zone e i nodi di lavoro

Configura le regole di anti-affinità per " topologySpreadConstraints " o per i pod nella configurazione della tua distribuzione. La distribuzione dei pod su più zone di disponibilità e nodi di lavoro impedisce che un’interruzione in una singola zona o un intervento di manutenzione su un singolo nodo provochi il blocco simultaneo di tutte le repliche.

Configurare i Pod Disruption Budget (PDB)

Una risorsa " PodDisruptionBudget " specifica il numero minimo o la percentuale minima di pod che devono rimanere disponibili durante le interruzioni volontarie, quali lo svuotamento dei nodi o gli aggiornamenti del cluster. Definire un PDB per ogni carico di lavoro critico, al fine di impedire che le operazioni amministrative eliminino un numero di pod superiore a quello che l'applicazione è in grado di tollerare.

Definire i test di prontezza e di funzionamento

Configura i test di disponibilità e integrità nelle specifiche dei tuoi container:

  • Probe di prontezza: assicurarsi che Kubernetes indirizzi il traffico solo ai pod che sono stati inizializzati e sono pronti a gestire le richieste.
  • Probe di integrità: abilita la funzione “ Kubernetes ” per riavviare automaticamente i container che entrano in uno stato di deadlock o di malfunzionamento.

Impostare richieste e limiti adeguati per le risorse

Specificare requisiti e limiti realistici relativi alla CPU e alla memoria per ciascun container. Le richieste garantiscono che lo scheduler Kubernetes collochi i pod su nodi con capacità sufficiente. I limiti impediscono che un singolo container consumi risorse eccessive e comprometta le prestazioni dei carichi di lavoro collocati sullo stesso nodo di lavoro.

Implementare una gestione corretta dello spegnimento

Quando un pod viene terminato, Kubernetes invia un segnale “ SIGTERM ” prima di inviare “ SIGKILL ”. Progetta la tua applicazione in modo che rilevi un' SIGTERM, smetta di accettare nuove connessioni, porti a termine le transazioni in corso e si chiuda in modo corretto. Imposta un valore adeguato per il parametro terminationGracePeriodSeconds nella specifica del tuo pod, in modo da garantire all'applicazione il tempo necessario per smaltire il traffico.

Evita di fare affidamento su connessioni di lunga durata al server API

Kubernetes Le richieste di monitoraggio e le connessioni di streaming (come oc exec, i port forwarding o i monitoraggi personalizzati tramite client API) si collegano direttamente a una specifica replica del piano di controllo. Quando quella replica esegue un ciclo durante l'aggiornamento di una patch, la connessione si interrompe. I carichi di lavoro e gli strumenti devono implementare una logica di riconnnessione automatica con back-off esponenziale.

Utilizzare la logica di riprova e i circuit breaker

Quando la tua applicazione interagisce con l'API Kubernetes, con database esterni o con microservizi a valle, implementa una logica di riprova con back-off esponenziale e jitter. Utilizzare modelli di interruttori automatici per prevenire guasti a cascata quando una dipendenza a monte o a valle risulta temporaneamente indisponibile.

Passi successivi