Modernizzazione del control plane gestito

Puoi modernizzare le tue flotte Cloud Service Mesh dall'implementazione del control plane ISTIOD all'implementazione TRAFFIC_DIRECTOR in base alla tua pianificazione oppure lasciare che Google la pianifichi automaticamente.

Esistono due percorsi di modernizzazione, che puoi anche combinare:

  • Modernizzazione attivata dal cliente (self-service): avvii e controlli la tempistica esatta della modernizzazione del parco risorse utilizzando la Google Cloud CLI, indipendentemente dalle pianificazioni gestite da Google.
  • Modernizzazione basata su Google (impostazione predefinita): Google valuta la compatibilità del parco risorse e pianifica automaticamente la modernizzazione nell'organizzazione in base ai periodi di manutenzione e alle notifiche anticipate. Google attende che tutti i parchi risorse della tua organizzazione siano compatibili, quindi un singolo parco risorse incompatibile bloccherà la modernizzazione.

Indipendentemente dal percorso scelto, devi completare i seguenti passaggi principali per modernizzare il control plane:

  1. Verifica la compatibilità: attiva i controlli di compatibilità e scopri la compatibilità delle tue flotte con la modernizzazione.
  2. Pianifica e configura la modernizzazione: scegli il percorso, configura l'ordine di implementazione del cluster e del parco risorse o posticipa parchi risorse specifici.
  3. Risolvi i problemi di compatibilità: assicurati che le tue flotte soddisfino tutti i requisiti di compatibilità prima di avviare la modernizzazione.
  4. Avvia la modernizzazione: attiva la modernizzazione attivata dal cliente in base alla tua pianificazione o attendi la pianificazione basata su Google.
  5. Modernizzazione del cluster attivo: durante i periodi di manutenzione configurati, i due control plane vengono eseguiti contemporaneamente e i deployment (carichi di lavoro e gateway) vengono trasferiti automaticamente al nuovo control plane. Dovrai riavviare manualmente i carichi di lavoro StatefulSet e DaemonSet.
  6. Monitora lo stato, il periodo di rodaggio e finalizza: monitora l'avanzamento della condizione, risolvi eventuali blocchi, osserva i carichi di lavoro durante il periodo di rodaggio (almeno 6 giorni lavorativi), con supporto completo del rollback prima della finalizzazione a livello di flotta.

Controllare la compatibilità della flotta e colmare le lacune

Prima che un parco risorse possa essere modernizzato, sia in base all'attivazione da parte del cliente sia in base alla modernizzazione guidata da Google, deve essere verificata la compatibilità del parco risorse. Devi attivare i report di compatibilità per esaminare le potenziali condizioni di blocco e colmare le lacune di configurazione. Per maggiori dettagli, vedi Informazioni sulla compatibilità di Cloud Service Mesh.

  • Per la modernizzazione basata su Google: Google pianificherà solo le organizzazioni in cui tutte le flotte non differite sono compatibili.
  • Per l'ammodernamento attivato dal cliente: devi verificare che la flotta di destinazione segnali MODERNIZATION_COMPATIBLE prima di avviare l'ammodernamento.

I controlli di compatibilità valutano le configurazioni CRD di Istio del tuo parco risorse, le annotazioni dei pod, le dipendenze dell'infrastruttura (come Workload Identity) e i parametri di scalabilità.

Pianificare e configurare la modernizzazione

Crea un piano per la modernizzazione del tuo parco risorse o dei tuoi parchi risorse. Se non lo fai, la modernizzazione basata su Google viene applicata in modo predefinito. Devi intervenire per assicurarti che i tuoi parchi non di produzione vengano modernizzati per primi e che i parchi critici vengano modernizzati per ultimi. Inoltre, la modernizzazione guidata da Google non pianificherà la modernizzazione della tua organizzazione finché non sarà compatibile il 100% dei parchi dispositivi non posticipati dell'intera organizzazione, pertanto la modernizzazione potrebbe essere bloccata da incompatibilità locali.

Prima di iniziare la modernizzazione, esamina le opzioni e configura le impostazioni di implementazione nei parchi risorse e nei cluster della tua organizzazione.

Percorsi disponibili

Approccio Descrizione Ideali per Ambito Prerequisiti Preavviso Funzionalità di rollback
Modernizzazione attivata dal cliente Avvii la modernizzazione flotta per flotta in base alla tua pianificazione. Controllo granulare dei tempi di modernizzazione del parco risorse (decidi quando avviare e quando eseguire il rollback a livello di parco risorse). Sfruttare il monitoraggio delle applicazioni esistente per avvisarti se è necessario un rollback. Flotta per flotta (FLEET_PROJECT_ID). La flotta di destinazione deve essere compatibile con l'ammodernamento. N/D. Rollback self-service immediato utilizzando Google Cloud CLI.
Modernizzazione basata su Google (impostazione predefinita) Google pianifica automaticamente la modernizzazione in tutta l'organizzazione. Modernizzazione automatica una volta che tutti i parchi risorse della tua organizzazione sono compatibili. Intera Google Cloud organizzazione (tutti i parchi risorse non rinviati). Tutte le flotte non rinviate dell'organizzazione devono essere compatibili con l'ammodernamento. Notifica del parco risorse di 14 giorni o più + notifica del cluster di 24 ore o più prima dell'inizio. Google eseguirà il rollback se il monitoraggio standardizzato mostra un errore. Se il monitoraggio dell'applicazione mostra un errore, devi contattare l'assistenza clienti Google Cloud.

Gestione di più parchi risorse in un'organizzazione

Se la tua Google Cloud organizzazione gestisce più flotte, non devi scegliere un unico approccio per tutte. Puoi combinare le strategie, ad esempio:

  • Rimanda le flotte complesse o critiche: blocca flotte specifiche nell'implementazione legacy utilizzando --modernization-strategy deferred in modo che vengano escluse dalla pianificazione basata su Google mentre risolvi le dipendenze o pianifichi l'esecuzione attivata dal cliente.
  • Inizia con la modernizzazione attivata dal cliente sulle flotte selezionate: modernizza prima le flotte di test, sviluppo o valutazione per convalidare il comportamento nella tua sequenza temporale.
  • Consenti a Google di modernizzare le flotte rimanenti: le flotte compatibili e non posticipate rimangono attive nella pianificazione basata su Google.

Posticipare la modernizzazione del parco risorse (disattivazione)

Per disattivare la modernizzazione basata su Google per un singolo parco risorse (ad esempio, per eseguire la modernizzazione attivata dal cliente in un secondo momento o per risolvere dipendenze complesse), imposta la strategia su DEFERRED:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse.

Tieni presente che l'etichetta del progetto precedente mesh-modernization-mode=manual rimane rispettata, ma è consigliata --modernization-strategy deferred. Le altre flotte non rinviate della tua organizzazione rimangono idonee alla pianificazione basata su Google una volta che sono tutte compatibili.

Configurazione dell'ordine di implementazione

Puoi controllare l'ordine di implementazione sequenziale nei cluster e nelle flotte utilizzando l'etichetta mesh-modernization-order (early, default o late).

Ordine di implementazione del cluster (si applica a entrambi i percorsi)

Se un parco veicoli contiene più cluster, puoi controllare l'ordine in cui i cluster vengono modernizzati applicando l'etichetta mesh-modernization-order a ciascun cluster. Quando tu o Google attivate la modernizzazione di un parco risorse, ogni gruppo di cluster viene modernizzato in sequenza, attendendo il completamento dei passaggi di modernizzazione automatica sul gruppo corrente prima di iniziare il successivo:

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

Sostituisci CLUSTER_NAME con il nome del cluster, LOCATION con la posizione del cluster e VALUE con uno dei seguenti valori:

  • early: Il cluster viene modernizzato nella prima ondata di modernizzazione.
  • default: il cluster viene modernizzato nella seconda ondata di modernizzazione.
  • late: Il cluster viene modernizzato nella terza e ultima ondata di modernizzazione.

Ordine di implementazione del parco risorse (solo Google)

Nelle organizzazioni con più parchi risorse in fase di modernizzazione guidata da Google, puoi controllare l'ordine in cui Google modernizza i tuoi parchi risorse impostando l'etichetta a livello di progetto nel progetto host del parco risorse:

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-order=VALUE"

Sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse e VALUE con uno dei seguenti valori:

  • early: La flotta viene modernizzata nella prima ondata di modernizzazione.
  • default: il parco risorse viene modernizzato nella seconda ondata di modernizzazione.
  • late: La flotta viene modernizzata nella terza e ultima ondata di modernizzazione.

Google completa la modernizzazione di ogni livello del parco risorse prima di iniziare il successivo: prima quello iniziale, poi quello predefinito (e senza etichetta) e infine quello tardivo. Le flotte contrassegnate come posticipate non sono incluse in questo ordine.

Ad esempio, puoi impostare le flotte non di produzione su early, una flotta particolarmente critica su late e lasciare le altre al valore predefinito.

Se non utilizzi le organizzazioni Google Cloud , le tue flotte verranno pianificate e modernizzate in modo indipendente e non potrai controllare l'ordine.

Modernizzazione attivata dal cliente (self-service)

La modernizzazione attivata dal cliente ti consente di controllare direttamente quando inizia la modernizzazione per un singolo parco risorse.

Attivazione della modernizzazione della flotta

Una volta che il parco risorse di destinazione segnala MODERNIZATION_COMPATIBLE, attiva la modernizzazione utilizzando il seguente comando:

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

Sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse.

  • Periodi di manutenzione: Google rispetta i periodi di manutenzione e le esclusioni del cluster configurati. La modernizzazione del cluster inizia durante il successivo periodo di manutenzione aperto del cluster.
  • Ordine dei cluster: se hai configurato le etichette mesh-modernization-order sui cluster, Google rispetta l'ordine.

Monitorare l'avanzamento

Segui le istruzioni riportate in Controllare lo stato della modernizzazione per monitorare l'avanzamento della modernizzazione del parco risorse e del cluster.

Eseguire il rollback di una modernizzazione attivata dal cliente

Se rilevi problemi durante la modernizzazione attiva del cluster o durante il periodo di test del parco risorse (prima della finalizzazione a livello di parco risorse), puoi attivare un rollback immediato:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse.

In questo modo, il tuo parco dispositivi rimarrà nello stato posticipato, ovvero non verrà preso in considerazione per la modernizzazione basata su Google. Quando è tutto pronto per riprovare la modernizzazione, esegui nuovamente il comando per attivare la modernizzazione del parco dispositivi.

Modernizzazione basata su Google (impostazione predefinita automatica)

Se non avvii la modernizzazione attivata dal cliente, Google gestisce automaticamente la modernizzazione in tutta l'organizzazione.

Pianificazione a livello di organizzazione

Google monitora costantemente i tuoi parchi risorse. Dopo che tutte le flotte abilitate alla mesh nella tua organizzazione (escluse quelle posticipate) sono compatibili con la modernizzazione, Google pianifica la modernizzazione della tua organizzazione.

Notifiche anticipate e pianificazione

Google fornisce due livelli di preavviso prima di iniziare la modernizzazione:

Notifica a livello di flotta

Innanzitutto, riceverai una notifica quando le tue flotte sono state identificate come compatibili con la modernizzazione e selezionate per la modernizzazione basata su Google che avrà luogo in futuro.

  • L'ammodernamento del cluster può iniziare già 14 giorni dopo il primo giorno lavorativo del mese successivo alla notifica negli Stati Uniti. Ad esempio, se Google stabilisce che la tua organizzazione è pronta il 10 gennaio 2027, ti comunicheremo entro il 31 gennaio 2027 che la prima data di inizio possibile per l'ammodernamento è il 15 febbraio 2027.

  • Riceverai una notifica simultanea per ogni flotta della tua organizzazione (escluse quelle che hai posticipato). Questa notifica è disponibile nelle condizioni di stato delle funzionalità a livello di parco risorse (MODERNIZATION_WILL_BE_SCHEDULED).

Notifica a livello di cluster

A livello di cluster, riceverai una notifica della data di inizio stimata per la modernizzazione del cluster basata su Google, almeno 1 giorno (24 ore) prima dell'inizio della modernizzazione del cluster.

Dopo la notifica a livello di parco risorse, questo ti offre una tempistica molto più precisa dell'ammodernamento dei singoli cluster. Questa notifica è disponibile nelle condizioni dello stato delle funzionalità a livello di cluster (MODERNIZATION_SCHEDULED).

Richiesta di rollback per la modernizzazione basata su Google

Se si verificano problemi durante la modernizzazione attiva o il periodo di stabilizzazione su una flotta di modernizzazione gestita da Google, contatta l'assistenza clienti Google Cloud per richiedere un rollback.

Cosa succede durante la modernizzazione attiva

Questa sezione descrive cosa succede durante la modernizzazione attiva dei parchi risorse e dei cluster.

Modernizzazione delle flotte

Per ogni parco risorse in fase di modernizzazione (che sia guidata da Google o attivata dal cliente), abilitiamo la nuova implementazione del control plane per tutti i cluster in base all'ordine (early → default → late).

Una volta abilitato il control plane per tutti i cluster, spostiamo il traffico alla nuova implementazione del control plane per tutti i cluster in base all'ordine (early → default → late).

Consulta Controllare lo stato di modernizzazione della flotta per verificare lo stato attuale.

Periodo di attesa per il parco risorse

Una volta spostato il traffico per tutti i cluster, il parco risorse entra in un periodo di assestamento. Il parco risorse rimane nel periodo di sospensione (MODERNIZATION_MODERNIZED) per almeno 6 giorni lavorativi dopo che tutti i cluster hanno completato la modernizzazione prima di passare a MODERNIZATION_FINALIZED. La funzionalità di rollback completo viene mantenuta durante il periodo di test. Una volta completata la modernizzazione, il rollback non è più possibile e i componenti ISTIOD potrebbero essere deprovisionati.

Modernizzazione di un cluster

Durante la modernizzazione attiva di un cluster, entrambe le implementazioni del control plane vengono eseguite temporaneamente in parallelo e, in modo sicuro e controllato, vengono elaborate le seguenti attività:

  1. Abilita la nuova implementazione del control plane. Se hai configurato i periodi di manutenzione per il cluster, questo passaggio inizierà durante un periodo di manutenzione e continuerà fino al completamento. Tieni presente i seguenti dettagli:
  2. Shift il traffico alla nuova implementazione del control plane. Se hai configurato periodi di manutenzione per il cluster, questo passaggio inizierà durante un periodo di manutenzione e continuerà fino al completamento. Tieni presente i seguenti dettagli:
    • I pod gestiti dal deployment Kubernetes che hanno proxy Cloud Service Mesh vengono riavviati, in modo che si riconnettano al nuovo control plane.
    • I pod vengono riavviati in ondate progressivamente più grandi con un tempo di attesa dopo ogni ondata per il monitoraggio.

  3. Riavvii manuali dei workload per i non deployment (azione richiesta dal cliente).

    • Google riavvia automaticamente i carichi di lavoro gestiti dai deployment Kubernetes. I carichi di lavoro gestiti da altri tipi di risorse Kubernetes, come StatefulSet e DaemonSet, devono essere riavviati manualmente.
    • Riavvia questi workload dopo che lo stato del cluster segnala MODERNIZATION_COMPLETED (ovvero quando il cluster è nel periodo di rodaggio).
    • Devi riavviare questi workload prima che la modernizzazione del parco macchine venga finalizzata, altrimenti questi proxy rimarranno connessi al control plane Istiod legacy di cui è prevista la deprovisioning.
    • Riavvia i carichi di lavoro utilizzando gli approcci Kubernetes standard, ad esempio kubectl rollout restart ...

  4. Una volta eseguita la transizione di tutti i workload in un cluster, il cluster attende il periodo di assorbimento del parco risorse.

Per monitorare lo stato di modernizzazione attivo dei tuoi cluster, consulta Controllare lo stato di modernizzazione.

Controllare lo stato della modernizzazione e intervenire

Puoi monitorare lo stato di avanzamento della modernizzazione dei tuoi parchi risorse e cluster utilizzando Google Cloud CLI:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Sostituisci FLEET_PROJECT_ID con l'ID del progetto host del parco risorse.

L'output è simile al seguente:

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/docs/...
        severity: INFO

Lo stato di modernizzazione viene riportato nei campi state.servicemesh.conditions (a livello di parco risorse) e membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (a livello di cluster):

Stato di una modernizzazione del parco risorse riuscita

In un'operazione di modernizzazione del parco risorse riuscita, lo stato del parco risorse inizierà con MODERNIZATION_MODERNIZING.

Ogni cluster passerebbe quindi attraverso gli stati:

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • MODERNIZATION_COMPLETED

Una volta completata la modernizzazione di tutti i cluster nel parco risorse, il parco risorse passerà attraverso i seguenti stati:

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

Rollback

La modernizzazione basata su Google monitora la preparazione e l'integrità della tua implementazione durante il processo di modernizzazione e attiveremo automaticamente un rollback se rileviamo problemi. Se rilevi un problema, contatta l'assistenza clienti Google Cloud per richiedere un rollback.

Per la modernizzazione attivata dal cliente, puoi attivare un rollback in qualsiasi momento.

Durante un rollback, il parco risorse mostra lo stato MODERNIZATION_ROLLING_BACK_FLEET e il cluster mostra lo stato MODERNIZATION_ROLLING_BACK_CLUSTER.

Una volta completato il rollback di un cluster, viene temporaneamente visualizzato lo stato MODERNIZATION_ABORTED.

Gestione di errori e stalli (solo attivati dal cliente)

Durante la modernizzazione attivata dal cliente, se un cluster riscontra un problema che impedisce l'avanzamento, la sua condizione passa a MODERNIZATION_STALLED. Google non attiverà rollback per la modernizzazione attivata dal cliente. Devi valutare il problema e decidere se risolverlo o attivare un rollback.

Quando un cluster segnala MODERNIZATION_STALLED, esamina i dettagli della condizione per un link diretto alla sezione degli errori pertinente:

Errori che richiedono l'intervento dell'utente

Se rileviamo una configurazione di mesh o cluster incompatibile, interromperemo l'ammodernamento. Assicurati che la generazione di report sulla compatibilità sia abilitata e controlla le condizioni a livello di parco risorse e cluster per individuare eventuali lacune, come descritto in Informazioni sulla compatibilità di Cloud Service Mesh.

  • Riprova immediata: non appena il blocco viene risolto, rileviamo la modifica e riprendiamo immediatamente la modernizzazione, senza attendere il successivo periodo di manutenzione.

Errori interni

I problemi interni del servizio Google vengono esaminati dagli ingegneri di Google, che riprenderanno la modernizzazione, se possibile. Tieni presente che la modernizzazione potrebbe riprendere al di fuori di un periodo di manutenzione, proprio come per gli errori che richiedono l'intervento dell'utente. Per evitare questo problema, puoi attivare un rollback.

Se la modernizzazione è in stallo da più di 24 ore e non sono presenti lacune di compatibilità, contatta l'assistenza clienti Google Cloud per maggiori dettagli o attiva un rollback se i carichi di lavoro di produzione sono interessati.

Riferimento per le condizioni a livello di parco risorse

Condizione Descrizione
MODERNIZATION_COMPATIBLE Il parco risorse è compatibile con la nuova implementazione del control plane.
MODERNIZATION_WILL_BE_SCHEDULED Modernizzazione basata su Google: tutte le flotte non posticipate dell'organizzazione sono compatibili e sono state messe in coda per la pianificazione.
MODERNIZATION_MODERNIZING La modernizzazione è in corso per uno o più cluster nel parco risorse.
MODERNIZATION_MODERNIZED Tutti i cluster hanno completato la modernizzazione attiva. Il parco risorse è nel periodo di test.
MODERNIZATION_FINALIZED La modernizzazione è stata completata e finalizzata. I componenti Istiod legacy verranno rimossi. Il rollback non è più possibile.
MODERNIZATION_ROLLING_BACK_FLEET È in corso un rollback a livello di flotta.

Riferimento per le condizioni a livello di cluster

Condizione Descrizione
MODERNIZATION_SCHEDULED L'ammodernamento del cluster è pianificato a partire dalla data specificata nella condizione. Se per il cluster sono configurati periodi di manutenzione/esclusioni, la data indica il periodo di manutenzione di destinazione.
MODERNIZATION_PREPARING Abilitazione della nuova implementazione del control plane.
MODERNIZATION_PREPARED La nuova implementazione del control plane è abilitata. La migrazione del carico di lavoro non è ancora iniziata.
MODERNIZATION_MIGRATING_WORKLOADS Il cluster sta eseguendo la migrazione attiva dei workload alla nuova implementazione del control plane.
MODERNIZATION_COMPLETED Il cluster ha completato la modernizzazione e si trova nel periodo di rodaggio.
MODERNIZATION_STALLED La modernizzazione è in fase di stallo a causa di un errore (solo attivato dal cliente). Per la risoluzione, consulta i dettagli della condizione.
MODERNIZATION_ROLLING_BACK_CLUSTER Il cluster è in fase di rollback.
MODERNIZATION_ABORTED È stato eseguito il rollback del cluster al control plane precedente. Segnalato per un breve periodo di tempo.