Best practice per gli upgrade dei cluster Google Distributed Cloud

Questo documento descrive le best practice e le considerazioni per l'upgrade di Google Distributed Cloud. Scopri come prepararti agli upgrade del cluster e le best practice da seguire prima dell'upgrade. Queste best practice aiutano a ridurre i rischi associati agli upgrade dei cluster.

Se hai più ambienti, ad esempio test, sviluppo e produzione, ti consigliamo di iniziare con l'ambiente meno critico, ad esempio test, e verificare la funzionalità di upgrade. Dopo aver verificato che l'upgrade sia stato eseguito correttamente, passa all'ambiente successivo. Ripeti questa procedura finché non esegui l'upgrade degli ambienti di produzione. Questo approccio ti consente di passare da un punto critico all'altro e verificare che l'upgrade e i tuoi workload vengano eseguiti correttamente.

Elenco di controllo per l'upgrade

Per rendere il processo di upgrade il più semplice possibile, esamina e completa i seguenti controlli prima di iniziare l'upgrade dei cluster:

Pianifica l'upgrade

Gli aggiornamenti possono essere interrotti. Prima di iniziare l'upgrade, pianifica con attenzione per assicurarti che l'ambiente e le applicazioni siano pronti e preparati. Potresti anche dover pianificare l'upgrade dopo il normale orario di lavoro, quando il traffico è meno intenso.

Stima l'impegno di tempo e pianifica un periodo di manutenzione

Per impostazione predefinita, tutti i pool di nodi vengono sottoposti ad upgrade in parallelo. Tuttavia, all'interno di ogni pool di nodi, i nodi vengono sottoposti a upgrade in sequenza perché ogni nodo deve essere svuotato e ricreato. Pertanto, il tempo totale per un upgrade dipende dal numero di nodi nel pool di nodi più grande. Per calcolare una stima approssimativa del tempo di upgrade, moltiplica 15 minuti per il numero di nodi nel pool di nodi più grande. Ad esempio, se hai 10 nodi nel pool più grande, il tempo totale di upgrade sarà di circa 15 * 10 = 150 minuti o 2,5 ore.

Ecco alcuni modi per ridurre i tempi di upgrade e semplificare la pianificazione e la programmazione degli upgrade:

  • Nella versione 1.28 e successive, puoi accelerare un upgrade impostando il valore di maxSurge per i singoli pool di nodi. Quando esegui l'upgrade dei nodi con maxSurge, più nodi vengono aggiornati nello stesso tempo necessario per aggiornare un singolo nodo.

  • Se i tuoi cluster hanno la versione 1.16 o successive, puoi saltare una versione secondaria quando esegui l'upgrade dei node pool. L'esecuzione di un upgrade con salto di versione dimezza il tempo necessario per eseguire l'upgrade sequenziale dei pool di nodi di due versioni. Inoltre, gli upgrade con salto di versione ti consentono di aumentare il tempo tra gli upgrade necessari per rimanere su una versione supportata. La riduzione del numero di upgrade riduce le interruzioni del workload e il tempo di verifica. Per saperne di più, consulta Salta una versione durante l'upgrade dei pool di nodi.

  • Puoi eseguire l'upgrade del control plane di un cluster utente separatamente dai node pool. Questa flessibilità può aiutarti a pianificare più periodi di manutenzione brevi anziché un unico periodo di manutenzione lungo per eseguire l'upgrade dell'intero cluster. Per maggiori dettagli, vedi Eseguire l'upgrade dei pool di nodi.

Esegui il backup del cluster utente e di amministrazione

Prima di iniziare un upgrade, esegui il backup dei cluster utente e di amministrazione.

Un backup del cluster utente è uno snapshot dell'archivio etcd del cluster utente. Il datastore etcd contiene tutti gli oggetti Kubernetes e gli oggetti personalizzati necessari per gestire lo stato del cluster. Lo snapshot contiene i dati necessari per ricreare i componenti e i carichi di lavoro del cluster. Per ulteriori informazioni, scopri come eseguire il backup di un cluster di utenti.

Con Google Distributed Cloud versione 1.8 e successive, puoi configurare il backup automatico con clusterBackup.datastore nel file di configurazione del cluster di amministrazione. Per attivare questa funzionalità in un cluster esistente, modifica il file di configurazione del cluster di amministrazione e aggiungi il campo clusterBackup.datastore, poi esegui gkectl update admin.

Dopo l'attivazione di clusterBackup.datastore, il cluster di amministrazione viene automaticamente eseguito il backup in etcd nell'archivio vSphere configurato. Questa procedura di backup viene ripetuta ogni volta che viene apportata una modifica al cluster di amministrazione. Quando avvii un upgrade del cluster, viene eseguita un'attività di backup prima dell'upgrade del cluster.

Per ripristinare un cluster di amministrazione dal backup in caso di problemi, consulta Backup e ripristino di un cluster di amministrazione con gkectl.

Esaminare l'utilizzo di PodDisruptionBudgets

In Kubernetes, i PodDisruptionBudgets (PDB) possono contribuire a evitare tempi di inattività o interruzioni indesiderati delle applicazioni. I PDB indicano allo scheduler di mantenere sempre in esecuzione un numero di pod mentre altri pod potrebbero non funzionare. Questo comportamento è un modo utile per garantire la disponibilità dell'applicazione.

  1. Per controllare quali PDB sono configurati nel tuo cluster, utilizza il comando kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il nome del file kubeconfig.

    L'output di esempio seguente mostra i PDB denominati istio-ingress, istiod e kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Nella tabella precedente, ogni PDB specifica che deve essere sempre disponibile almeno un pod. Questa disponibilità diventa fondamentale durante gli upgrade quando i nodi vengono svuotati.

Controlla se sono presenti PDB che non possono essere soddisfatti. Ad esempio, puoi impostare una disponibilità minima di 1 quando il deployment include una sola replica. In questo esempio, l'operazione di svuotamento viene interrotta perché il PDB non può essere soddisfatto dal controller delle risorse.

Per assicurarti che i PDB non interferiscano con la procedura di upgrade, controlla tutti i PDB su un determinato cluster prima di iniziare l'upgrade. Potrebbe essere necessario coordinarsi con i team di sviluppo e i proprietari delle applicazioni per modificare o disattivare temporaneamente i PDB durante l'upgrade di un cluster.

Google Distributed Cloud esegue un controllo preflight durante la procedura di upgrade per avvisare in merito ai PDB. Tuttavia, devi anche verificare manualmente i PDB per garantire un'esperienza di upgrade senza problemi. Per scoprire di più sui budget di interruzione dei pod, consulta Specifica di un budget di interruzione per l'applicazione.

Esamina gli indirizzi IP disponibili

Le seguenti considerazioni sull'indirizzo IP si applicano agli upgrade dei cluster utente e dei cluster di amministrazione non HA (ovvero i cluster di amministrazione che non sono ad alta disponibilità):

  • Il processo di upgrade del cluster crea un nuovo nodo e svuota le risorse prima di eliminare il nodo precedente. Ti consigliamo di avere sempre N+1 indirizzi IP per il cluster, dove N è il numero di nodi nel cluster. Questo consiglio si applica solo ai cluster di amministrazione non HA (che hanno solo un nodo del control plane) e ai cluster utente.

  • Quando utilizzi indirizzi IP statici, gli indirizzi IP richiesti devono essere elencati nei file del blocco IP.

    • Quando esegui l'upgrade dei cluster di amministrazione non HA, aggiungi l'indirizzo IP aggiuntivo nel file di blocco IP utilizzato dal cluster di amministrazione. Il percorso di questo file deve essere specificato nel campo network.ipMode.ipBlockFilePath del file di configurazione del cluster di amministrazione.
    • Quando esegui l'upgrade dei cluster utente, aggiungi l'indirizzo IP aggiuntivo nel file di blocco IP utilizzato dal cluster utente. Il percorso di questo file deve essere specificato nel campo network.ipMode.ipBlockFilePath del file di configurazione del cluster utente.

  • Se utilizzi DHCP, assicurati che le nuove VM possano ottenere ulteriori lease IP nella subnet applicabile durante un upgrade.

    Se devi aggiungere indirizzi IP, aggiorna il file del blocco IP, quindi esegui il comando gkectl update. Per saperne di più, consulta Pianificare gli indirizzi IP.

  • Se utilizzi indirizzi IP statici e vuoi velocizzare il processo di upgrade del cluster utente, elenca un numero sufficiente di indirizzi IP nel file del blocco IP in modo che ogni pool di nodi possa avere un indirizzo IP aggiuntivo disponibile. Questo approccio consente al processo di velocizzare la procedura di aggiunta e rimozione delle VM, poiché viene eseguita in base al pool di nodi.

    Sebbene questo approccio sia una buona opzione per velocizzare gli upgrade dei cluster utente, valuta la disponibilità di risorse e prestazioni del tuo ambiente vSphere prima di procedere.

  • Se è presente un solo IP di riserva per l'intero cluster utente, questa limitazione rallenta la procedura di upgrade a una sola VM alla volta, anche quando vengono utilizzati più pool di nodi.

I cluster di amministrazione HA non richiedono N+1 indirizzi IP per gli upgrade. I tre nodi del control plane in un cluster di amministrazione ad alta disponibilità vengono ricreati uno alla volta, garantendo che non siano necessari indirizzi IP aggiuntivi.

Controllare l'utilizzo del cluster

Assicurati che i pod possano essere evacuati quando il nodo viene svuotato e che nel cluster in fase di upgrade ci siano risorse sufficienti per gestire l'upgrade. Per controllare l'utilizzo attuale delle risorse del cluster, puoi utilizzare dashboard personalizzate in Google Cloud Observability o direttamente sul cluster utilizzando comandi come kubectl top nodes.

I comandi che esegui sul cluster mostrano uno snapshot dell'utilizzo attuale delle risorse del cluster. Le dashboard possono fornire una visualizzazione più dettagliata delle risorse consumate nel tempo. Questi dati sull'utilizzo delle risorse possono aiutarti a capire quando un upgrade causerebbe meno interruzioni, ad esempio durante i fine settimana o le serate, a seconda del carico di lavoro in esecuzione e dei casi d'uso.

La tempistica per l'upgrade del cluster di amministrazione potrebbe essere meno critica rispetto a quella per i cluster utente, perché un upgrade del cluster di amministrazione di solito non introduce tempi di inattività dell'applicazione. Tuttavia, è comunque importante verificare la disponibilità di risorse gratuite in vSphere prima di iniziare l'upgrade del cluster di amministrazione. Inoltre, l'upgrade del cluster di amministrazione potrebbe comportare alcuni rischi e pertanto potrebbe essere consigliato durante i periodi di utilizzo meno attivi, quando l'accesso di gestione al cluster è meno critico.

Per saperne di più, vedi quali servizi sono interessati durante l'upgrade di un cluster.

Controllare l'utilizzo di vSphere

Verifica che ci siano risorse sufficienti nell'infrastruttura vSphere sottostante. Per controllare l'utilizzo di questa risorsa, seleziona un cluster in vCenter e esamina la scheda Riepilogo.

La scheda Riepilogo mostra il consumo complessivo di memoria, CPU e spazio di archiviazione dell'intero cluster. Poiché gli upgrade di Google Distributed Cloud richiedono risorse aggiuntive, devi anche verificare se il cluster è in grado di gestire queste richieste di risorse aggiuntive.

Come regola generale, il cluster vSphere deve essere in grado di supportare le seguenti risorse aggiuntive:

  • +1 VM per l'upgrade del cluster di amministrazione
  • +1 VM per pool di nodi per upgrade del cluster utente

Ad esempio, supponiamo che un cluster utente abbia 3 pool di nodi in cui ogni pool di nodi ha nodi che utilizzano 8 vCPU e 32 GB o più di RAM. Poiché l'upgrade viene eseguito in parallelo per i tre pool di nodi per impostazione predefinita, la procedura di upgrade utilizza le seguenti risorse aggiuntive per i tre nodi di picco aggiuntivi:

  • 24 vCPU
  • 96 GB di RAM
  • Spazio su disco della VM + 96 GB di vSwap

La procedura di upgrade crea VM utilizzando l'operazione di clonazione di vSphere. La clonazione di più VM da un modello può introdurre stress nel sistema di archiviazione sottostante sotto forma di aumento delle operazioni di I/O. L'upgrade può essere rallentato notevolmente se il sottosistema di archiviazione sottostante non è in grado di fornire prestazioni sufficienti durante un upgrade.

Sebbene vSphere sia progettato per l'utilizzo simultaneo delle risorse e disponga di meccanismi per fornire risorse, anche in caso di overcommit, ti consigliamo vivamente di non eseguire l'overcommit della memoria della VM. L'overcommitment della memoria può comportare gravi impatti sulle prestazioni che interessano l'intero cluster, in quanto vSphere fornisce la "RAM mancante" scambiando le pagine con il datastore. Questo comportamento può causare problemi durante l'upgrade di un cluster e influire sulle prestazioni di altre VM in esecuzione nel cluster vSphere.

Se le risorse disponibili sono già scarse, spegni le VM non necessarie per soddisfare questi requisiti aggiuntivi ed evitare un potenziale calo delle prestazioni.

Controlla lo stato e la configurazione del cluster

Esegui i seguenti strumenti su tutti i cluster prima dell'upgrade:

  • Il comando gkectl diagnose: gkectl diagnose garantisce che tutti i cluster siano integri. Il comando esegue controlli avanzati, ad esempio per identificare i nodi che non sono configurati correttamente o che hanno pod in uno stato bloccato. Se il comando gkectl diagnose mostra un avviso Cluster unhealthy, risolvi i problemi prima di tentare un upgrade. Per saperne di più, vedi Diagnosticare i problemi del cluster.

  • Lo strumento pre-upgrade: oltre a controllare l'integrità e la configurazione del cluster, lo strumento pre-upgrade verifica la presenza di potenziali problemi noti che potrebbero verificarsi durante un upgrade del cluster.

Inoltre, quando esegui l'upgrade dei cluster utente alla versione 1.29 e successive, ti consigliamo di eseguire il comando gkectl upgrade cluster con il flag --dry-run. Il flag --dry-run esegue controlli preflight ma non avvia la procedura di upgrade. Sebbene le versioni precedenti di Google Distributed Cloud eseguano controlli preliminari, non possono essere eseguiti separatamente dall'upgrade. Aggiungendo il flag --dry-run, puoi trovare e risolvere eventuali problemi che i controlli preflight rilevano nel cluster utente prima dell'upgrade.

Utilizzare i deployment per ridurre al minimo le interruzioni dell'applicazione

Poiché i nodi devono essere svuotati durante gli aggiornamenti, gli upgrade del cluster possono causare interruzioni delle applicazioni. Lo svuotamento dei nodi comporta l'arresto e il riavvio di tutti i pod in esecuzione sui nodi rimanenti nel cluster.

Se possibile, le tue applicazioni devono utilizzare i deployment. Con questo approccio, le applicazioni sono progettate per gestire le interruzioni. L'impatto dovrebbe essere minimo per i deployment con più repliche. Puoi comunque eseguire l'upgrade del cluster se le applicazioni non utilizzano i deployment.

Esistono anche regole per i deployment per assicurarsi che un numero prestabilito di repliche sia sempre in esecuzione. Queste regole sono note come PodDisruptionBudgets (PDB). I PDB ti consentono di limitare l'interruzione di un workload quando i relativi pod devono essere riprogrammati per qualche motivo, ad esempio upgrade o manutenzione dei nodi del cluster, e sono importanti da controllare prima di un upgrade.

Utilizza una coppia di bilanciatori del carico ad alta disponibilità

Se utilizzi Seesaw come bilanciatore del carico su un cluster, i bilanciatori del carico vengono aggiornati automaticamente quando esegui l'upgrade del cluster. Questo upgrade può causare un'interruzione del servizio. Per ridurre l'impatto di un upgrade e di un eventuale errore del bilanciamento del carico, puoi utilizzare una coppia ad alta disponibilità. In questa configurazione, il sistema crea e configura due VM del bilanciatore del carico in modo che possa verificarsi un failover all'altro peer.

Per aumentare la disponibilità del servizio (ovvero del server API Kubernetes), ti consigliamo di utilizzare sempre una coppia HA davanti al cluster di amministrazione. Per saperne di più su Seesaw e sulla sua configurazione HA, consulta la documentazione della versione 1.16 Bilanciamento del carico in bundle con Seesaw.

Per evitare un'interruzione del servizio durante un upgrade con una coppia HA, il cluster avvia un failover prima di creare la nuova VM del bilanciatore del carico. Se un cluster utente utilizza una sola istanza del bilanciatore del carico, si verifica un'interruzione del servizio finché l'upgrade del bilanciatore del carico non viene completato.

Ti consigliamo di avere una coppia di bilanciatori del carico HA se anche il cluster utente è configurato per essere ad alta disponibilità. Questa serie di best practice presuppone che un cluster utente HA utilizzi una coppia di bilanciatori del carico HA.

Se utilizzi MetalLB come bilanciatore del carico in bundle, non è necessaria alcuna configurazione pre-upgrade. Il bilanciatore del carico viene aggiornato durante il processo di upgrade del cluster.

Decidi come eseguire l'upgrade di ogni cluster utente

Nella versione 1.14 e successive, puoi scegliere di eseguire l'upgrade di un cluster utente nel suo complesso (ovvero puoi eseguire l'upgrade del control plane e di tutti i pool di nodi nel cluster) oppure puoi eseguire l'upgrade del control plane del cluster utente e lasciare i pool di nodi alla versione attuale. Per informazioni sul motivo per cui potresti voler eseguire l'upgrade del control plane separatamente, consulta Upgrade dei cluster utente.

In un ambiente multi-cluster, tieni traccia dei cluster utente che sono stati aggiornati e registra il numero di versione. Se decidi di eseguire l'upgrade del control plane e dei node pool separatamente, registra la versione del control plane e di ogni pool di nodi in ogni cluster.

Controllare le versioni dei cluster utente e di amministrazione

gkectl

  • Per controllare la versione dei cluster utente:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il cluster di amministrazione.

  • Per controllare la versione dei cluster di amministrazione:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Interfaccia a riga di comando gcloud

Per i cluster registrati nell'API GKE On-Prem, puoi utilizzare la gcloud CLI per ottenere le versioni dei cluster utente, dei pool di nodi sul cluster utente e dei cluster di amministrazione.

  1. Assicurati di avere l'ultima versione di gcloud CLI. Aggiorna i componenti di gcloud CLI, se necessario:

    gcloud components update

  2. Esegui i seguenti comandi per controllare le versioni:

  • Per controllare la versione dei cluster utente:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Sostituisci PROJECT_ID con l'ID progetto del tuo progetto host del parco veicoli.

    Quando imposti --location=-, significa elencare tutti i cluster in tutte le regioni. Se devi ridurre l'ambito dell'elenco, imposta --location sulla regione che hai specificato al momento della registrazione del cluster.

    L'output del comando include la versione del cluster.

  • Per controllare la versione dei cluster di amministrazione:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Controlla la versione dei nodi del cluster:

Puoi utilizzare kubectl per ottenere la versione dei nodi del cluster, ma kubectl restituisce la versione di Kubernetes. Per ottenere la versione di Google Distributed Cloud corrispondente a una versione di Kubernetes, consulta la sezione Controllo delle versioni.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il cluster utente.

Controlla se è necessario ruotare i certificati CA

Durante un upgrade, i certificati foglia vengono ruotati, ma i certificati CA no. Devi ruotare manualmente i certificati CA almeno una volta ogni cinque anni. Per saperne di più, vedi Rotazione delle autorità di certificazione dei cluster utente e Rotazione dei certificati CA del cluster di amministrazione.

Differenze tra i tipi di cluster

Esistono due tipi diversi di cluster:

  • Cluster utente
  • Cluster di amministrazione

A seconda di come crei un cluster utente, potrebbe contenere sia nodi worker sia nodi del control plane (Controlplane V2) o solo nodi worker (kubeception). Con kubeception, il control plane per un cluster utente viene eseguito su uno o più nodi in un cluster di amministrazione. In entrambi i casi, nella versione 1.14 e successive, puoi eseguire l'upgrade del control plane di un cluster utente separatamente dai pool di nodi che eseguono i tuoi carichi di lavoro.

Diversi effetti degli upgrade del cluster utente rispetto a quelli del cluster di amministrazione

La procedura di upgrade di Google Distributed Cloud prevede un processo di svuotamento dei nodi che rimuove tutti i pod da un nodo. Il processo crea una nuova VM per ogni nodo di lavoro svuotato e la aggiunge al cluster. I nodi worker svuotati vengono poi rimossi dall'inventario di VMware. Durante questa procedura, qualsiasi workload in esecuzione su questi nodi viene arrestato e riavviato su altri nodi disponibili nel cluster.

A seconda dell'architettura scelta per il carico di lavoro, questa procedura potrebbe influire sulla disponibilità di un'applicazione. Per evitare un carico eccessivo sulle capacità delle risorse del cluster, Google Distributed Cloud esegue l'upgrade di un nodo alla volta.

Interruzione del cluster utente

La seguente tabella descrive l'impatto di un upgrade in loco del cluster di utenti:

Funzione Cluster di amministrazione Cluster utente non HA Cluster utente ad alta disponibilità
Accesso all'API Kubernetes Non interessato Non interessato Non interessato
Workload utente Non interessato Non interessato Non interessato
PodDisruptionBudgets* Non interessato Non interessato Non interessato
Nodo del control plane Non interessato Interessato Non interessato
Gestore della scalabilità automatica pod (VMware) Non interessato Non interessato Non interessato
Riparazione automatica Non interessato Non interessato Non interessato
Scalabilità automatica dei nodi (VMware) Non interessato Non interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • * : i PDB potrebbero causare l'esito negativo o l'interruzione dell'upgrade.
  • Interessato: un'interruzione del servizio durante l'upgrade è evidente fino al completamento dell'upgrade.
  • Non interessato: potrebbe verificarsi un'interruzione del servizio per un periodo di tempo molto breve, ma è quasi impercettibile.

I nodi del control plane del cluster utente, che vengano eseguiti sul cluster di amministrazione (kubeception) o sul cluster utente stesso (control plane v2), non eseguono alcun carico di lavoro utente. Durante un upgrade, questi nodi del control plane vengono svuotati e poi aggiornati di conseguenza.

Negli ambienti con piani di controllo ad alta disponibilità, l'upgrade del piano di controllo di un cluster utente non interrompe i carichi di lavoro degli utenti. In un ambiente HA, l'upgrade di un cluster di amministrazione non interrompe i carichi di lavoro degli utenti. Per i cluster utente che utilizzano Controlplane V2, l'upgrade del solo control plane non interrompe i carichi di lavoro utente.

Durante un upgrade in un ambiente del control plane non ad alta disponibilità, il control plane non può controllare le azioni di scalabilità, ripristino o deployment dei pod. Durante la breve interruzione del control plane durante l'upgrade, i carichi di lavoro utente possono essere interessati se si trovano in uno stato di scalabilità, deployment o ripristino. Ciò significa che le implementazioni non andranno a buon fine durante un upgrade in un ambiente non ad alta disponibilità.

Per migliorare la disponibilità e ridurre le interruzioni dei cluster utente di produzione durante gli upgrade, ti consigliamo di utilizzare tre nodi del control plane (modalità ad alta disponibilità).

Interruzione del cluster di amministrazione

La tabella seguente descrive l'impatto di un upgrade del cluster di amministrazione in loco:

Funzione Cluster di amministrazione Cluster utente non HA Cluster utente ad alta disponibilità
Accesso all'API Kubernetes Interessato Interessato Non interessato
Workload utente Non interessato Non interessato Non interessato
Nodo del control plane Interessato Interessato Non interessato
Gestore della scalabilità automatica dei pod Interessato Interessato Non interessato
Autofficina Interessato Interessato Non interessato
Scalabilità automatica dei nodi Interessato Interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • Interessato: un'interruzione del servizio durante l'upgrade è evidente fino al completamento dell'upgrade.
  • Non interessato: potrebbe verificarsi un'interruzione del servizio per un periodo di tempo molto breve, ma è quasi impercettibile.

Passaggi successivi