Modernizzazione del control plane gestito

Devi modernizzare le tue flotte Cloud Service Mesh dall'implementazione del control plane ISTIOD ritirato all'implementazione TRAFFIC_DIRECTOR prima della scadenza del termine di fine del supporto. Puoi avviare la modernizzazione in base alla tua programmazione oppure lasciare che Google la pianifichi automaticamente una volta che la tua organizzazione è compatibile.

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 di base per modernizzare il control plane:

  1. Controlla 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 in parallelo 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 la finalizzazione: 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 che la modernizzazione sia attivata dal cliente o da Google, il parco risorse deve essere verificato come compatibile. Devi attivare i report sulla compatibilità per esaminare le potenziali condizioni di blocco e correggere le lacune di configurazione. Per ulteriori dettagli, consulta la sezione 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 la modernizzazione attivata dal cliente: devi verificare che la flotta di destinazione segnali MODERNIZATION_COMPATIBLE prima di avviare la modernizzazione.

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à.

Gestione delle funzionalità non supportate

Nell'ambito del ritiro del control plane ISTIOD, Google Cloud termina il supporto per le funzionalità incompatibili con l'implementazione del control plane TRAFFIC_DIRECTOR. Visualizza i dettagli del supporto API.

Se utilizzi funzionalità non supportate, devi intraprendere una delle seguenti azioni prima della fine del supporto (vedi Ritiri):

  • Rifattorizza la configurazione (consigliato): rimuovi i campi non supportati o sostituiscili con alternative Cloud Service Mesh supportate in modo che il tuo parco risorse riporti MODERNIZATION_COMPATIBLE, quindi esegui l'upgrade all'implementazione del control plane TRAFFIC_DIRECTOR.
  • Esegui la migrazione a Istio open source (OSS): se i tuoi carichi di lavoro richiedono rigorosamente funzionalità non supportate da Cloud Service Mesh gestito con TRAFFIC_DIRECTOR, non puoi modernizzare questi cluster a TRAFFIC_DIRECTOR. Devi eseguire la migrazione di questi carichi di lavoro a Istio open source autogestito.
  • Disinstalla Cloud Service Mesh: puoi disinstallare Cloud Service Mesh gestito.

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 risorse non di produzione vengano modernizzati per primi e che i parchi risorse 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 della tempistica 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 cronologia.
  • Consenti a Google di modernizzare le flotte rimanenti: tutte le flotte compatibili e non rinviate 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 dispositivi, 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.

L'impostazione --modernization-strategy deferred è il modo consigliato per:

  • Escludi flotte specifiche dalla pianificazione basata su Google perché intendi modernizzarle in base alla tua tempistica utilizzando la modernizzazione attivata dal cliente.
  • Rimanda temporaneamente la modernizzazione dei parchi risorse complessi o critici mentre correggi le dipendenze, consentendo ad altri parchi risorse compatibili della tua organizzazione di procedere con la pianificazione basata su Google.

Tieni presente che l'etichetta del progetto precedente mesh-modernization-mode=manual rimane rispettata, ma è consigliabile utilizzare --modernization-strategy deferred. Gli altri parchi risorse non posticipati della tua organizzazione rimangono idonei alla pianificazione basata su Google una volta che sono tutti 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 risorse contiene più cluster, puoi controllare l'ordine in cui i cluster vengono modernizzati applicando l'etichetta mesh-modernization-order a ogni 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 una delle seguenti opzioni:

  • 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 basato su Google)

Nelle organizzazioni con più parchi risorse sottoposti a 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 Google Cloud organizzazioni, 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 l'ammodernamento 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 la modernizzazione in tutta l'organizzazione in modo automatico.

Pianificazione a livello di organizzazione

Google monitora costantemente i tuoi parchi risorse. Quando tutte le flotte abilitate alla mesh nella tua organizzazione (escluse quelle posticipate) sono compatibili con l'ammodernamento, Google pianifica l'ammodernamento della tua organizzazione.

Notifiche anticipate e pianificazione

Google fornisce due livelli di preavviso prima di iniziare l'ammodernamento:

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 guidata da Google 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 della modernizzazione possibile è 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 soak (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.

Modernizzare 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 dispongono di proxy Cloud Service Mesh vengono riavviati, in modo che si riconnettano al nuovo control plane.
    • I pod vengono riavviati in wave progressivamente più grandi con un tempo di attesa dopo ogni wave per il monitoraggio.

  3. Riavvii manuali dei workload per i non deployment (è richiesta l'azione del 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 rimangono connessi al control plane Istiod legacy di cui è pianificato il deprovisioning.
    • Riavvia i carichi di lavoro utilizzando 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 rodaggio 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 l'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 un'operazione di 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 passerà 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à dell'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 blocchi (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 esaminare il problema e decidere se eseguire una correzione 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 dei servizi 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 alle 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 rodaggio.
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 alle condizioni a livello di cluster

Condizione Descrizione
MODERNIZATION_SCHEDULED L'ammodernamento del cluster è pianificato per la data specificata nella condizione o per una data successiva. 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 È abilitata la nuova implementazione del control plane. La migrazione del workload non è ancora stata avviata.
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 È in corso il rollback del cluster.
MODERNIZATION_ABORTED È stato eseguito il rollback del cluster al control plane precedente. Segnalato per un breve periodo di tempo.