Modernizzazione del control plane gestito

Devi modernizzare i tuoi parchi risorse Cloud Service Mesh dall'implementazione del control plane ISTIOD deprecata all'implementazione TRAFFIC_DIRECTOR prima della scadenza del supporto. Puoi avviare la modernizzazione in base alla tua pianificazione o 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): È possibile avviare e controllare autonomamente la tempistica esatta della modernizzazione del parco risorse utilizzando Google Cloud CLI, indipendentemente dalle pianificazioni gestite da Google.
• Modernizzazione guidata da Google (predefinita): Google valuta la compatibilità del parco risorse e pianifica automaticamente la modernizzazione nella tua 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à dei tuoi parchi risorse con la modernizzazione.
2. Pianifica e configura la modernizzazione: scegli il percorso, configura l'ordine di implementazione di cluster e parchi risorse o posticipa parchi risorse specifici.
3. Correggi le lacune di compatibilità: assicurati che i tuoi parchi risorse soddisfino tutti i requisiti di compatibilità prima di avviare la modernizzazione.
4. Avvia la modernizzazione: attiva la modernizzazione avviata dal cliente in base alla tua pianificazione o attendi la pianificazione guidata da Google.
5. Modernizzazione dei cluster attivi: durante i periodi di manutenzione configurati, i control plane doppi vengono eseguiti in parallelo e i deployment (workload e gateway) passano automaticamente al nuovo control plane. Dovrai riavviare manualmente i workload StatefulSet e DaemonSet.
6. Monitora lo stato, esegui il soak e finalizza: monitora l'avanzamento delle condizioni, risolvi eventuali blocchi, osserva i workload durante il periodo di soak (almeno 6 giorni lavorativi), con supporto completo del rollback prima della finalizzazione a livello di parco risorse.

Verifica la compatibilità del parco risorse e correggi le lacune

Prima che un parco risorse possa essere modernizzato, sia che la modernizzazione venga attivata dal cliente o da Google, è necessario verificare che il parco risorse sia compatibile. Devi attivare i report sulla compatibilità per esaminare le potenziali condizioni di blocco e correggere le lacune di configurazione. Per maggiori dettagli, consulta Informazioni sulla compatibilità di Cloud Service Mesh.

• Per la modernizzazione basata su Google: Google pianificherà solo le organizzazioni in cui tutti i parchi risorse non differiti sono compatibili.
• Per la modernizzazione attivata dal cliente: devi verificare che il parco risorse di destinazione segnali MODERNIZATION_COMPATIBLE prima di avviare la modernizzazione.

I controlli di compatibilità valutano le configurazioni CRD 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 sta terminando il supporto delle funzionalità incompatibili con l'implementazione del control plane TRAFFIC_DIRECTOR. Visualizza i dettagli del supporto dell'API.

Se utilizzi funzionalità non supportate, devi intraprendere una delle seguenti azioni prima del termine del supporto (consulta Deprecazioni):

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

Pianifica e configura la modernizzazione

Crea un piano per la modernizzazione dei tuoi parchi risorse. In caso contrario, la modernizzazione basata su Google viene applicata in modo predefinito. Devi intervenire per assicurarti che i parchi risorse non di produzione vengano modernizzati per primi e quelli critici per ultimi. Inoltre, la modernizzazione guidata da Google non pianificherà la modernizzazione della tua organizzazione finché il 100% dei parchi risorse non differiti nell'intera organizzazione non sarà compatibile, pertanto la modernizzazione potrebbe essere bloccata da incompatibilità locali.

Prima di avviare la modernizzazione, esamina le opzioni e configura le impostazioni di implementazione per i parchi risorse e i cluster della tua organizzazione.

Percorsi disponibili

Gestione di più parchi risorse in un'organizzazione

Se la tua Google Cloud organizzazione gestisce più parchi risorse, non è necessario scegliere un unico approccio per tutti. Puoi combinare le strategie, ad esempio:

• Rimanda i parchi risorse complessi o critici: blocca parchi risorse specifici nell'implementazione legacy utilizzando --modernization-strategy deferred in modo che vengano esclusi dalla pianificazione gestita da Google mentre correggi le dipendenze o pianifichi l'esecuzione attivata dal cliente.
• Inizia con la modernizzazione attivata dal cliente su parchi risorse selezionati: modernizza prima i parchi risorse di test, sviluppo o valutazione per convalidare il comportamento in base alla tua cronologia.
• Consenti a Google di modernizzare i parchi istanze rimanenti: tutti i parchi istanze compatibili e non differiti rimangono attivi per la pianificazione basata su Google.

Rinvio della modernizzazione del parco risorse (disattivazione)

Per disattivare la modernizzazione basata su Google per un singolo parco risorse, imposta la relativa 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:

• Escludere parchi risorse specifici dalla pianificazione basata su Google perché intendi modernizzarli in base alla tua cronologia utilizzando la modernizzazione attivata dal cliente.
• Sospendi temporaneamente la modernizzazione di parchi risorse complessi o critici mentre correggi le dipendenze, consentendo ad altri parchi risorse compatibili della tua organizzazione di procedere con la pianificazione guidata da Google.

Tieni presente che l'etichetta del progetto legacy mesh-modernization-mode=manual rimane rispettata, ma è consigliato --modernization-strategy deferred. Le altre parchi risorse non differite della tua organizzazione rimangono idonee alla programmazione gestita da Google una volta che sono tutte compatibili.

Configurazione dell'ordine di implementazione

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

Ordine di implementazione dei 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 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 località 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 gestito da Google)

Nelle organizzazioni con più parchi risorse sottoposti a modernizzazione guidata da Google, puoi controllare l'ordine in cui Google modernizza i 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: il parco risorse viene modernizzato nella prima ondata di modernizzazione.
• default: il parco risorse viene modernizzato nella seconda ondata di modernizzazione.
• late: il parco risorse viene modernizzato nella terza e ultima ondata di modernizzazione.

Google completa la modernizzazione di ogni livello del parco risorse prima di iniziare con il successivo: Early, poi Default (e senza etichetta), infine Late. I parchi risorse contrassegnati come differiti non sono inclusi in questo ordine.

Ad esempio, puoi impostare i tuoi parchi risorse non di produzione su early, un parco risorse particolarmente critico su late e lasciare gli altri sul valore predefinito.

Se non utilizzi le organizzazioni Google Cloud , i tuoi parchi verranno pianificati e modernizzati in modo indipendente e non potrai controllare l'ordine.

Modernizzazione attivata dal cliente (self-service)

La modernizzazione attivata dal cliente ti offre il controllo diretto su quando inizia la modernizzazione per un singolo parco risorse.

Attivazione della modernizzazione del parco risorse

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 configurati per il cluster. La modernizzazione del cluster inizia durante il periodo di manutenzione aperto successivo del cluster.
• Ordinamento dei cluster: se hai configurato le etichette mesh-modernization-order sui tuoi cluster, Google rispetta questo ordinamento.

Monitora l'avanzamento

Segui le istruzioni riportate in Controlla lo stato della modernizzazione per monitorare l'avanzamento della modernizzazione del parco risorse e dei cluster. Controlla il monitoraggio dell'applicazione per determinare se è necessario un rollback, soprattutto durante gli stati MODERNIZATION_PREPARING e MODERNIZATION_MIGRATING_WORKLOADS.

Rollback di una modernizzazione attivata dal cliente

Se rilevi problemi durante la modernizzazione attiva del cluster o durante il periodo di soaking 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 risorse rimarrà nello stato posticipato, ovvero non verrà preso in considerazione per la modernizzazione guidata da Google. Quando è tutto pronto per riprovare la modernizzazione, esegui nuovamente il comando per attivare la modernizzazione del parco risorse.

Modernizzazione guidata da 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 tutti i fleet abilitati per il mesh nella tua organizzazione (esclusi i fleet con upgrade posticipato) sono compatibili con la modernizzazione (MODERNIZATION_COMPATIBLE) e supportano la modernizzazione gestita da Google, Google pianifica la modernizzazione per la tua organizzazione.

Supporto per la modernizzazione guidata da Google

Alcune condizioni bloccano la modernizzazione gestita da Google e richiedono la modernizzazione attivata dal cliente per un parco risorse. Viene visualizzata una condizione a livello di parco risorse di MODERNIZATION_REQUIRES_CUSTOMER_TRIGGER e ulteriori dettagli in altre condizioni a livello di parco risorse o di cluster.

Questa condizione blocca la pianificazione a livello di organizzazione per la modernizzazione gestita da Google finché non modernizzi il parco risorse utilizzando la modernizzazione attivata dal cliente o non rimandi il parco risorse.

Notifiche e pianificazione avanzate

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

Notifica a livello di parco risorse

Innanzitutto, riceverai una notifica quando i tuoi parchi risorse saranno stati identificati come compatibili con la modernizzazione e selezionati per la modernizzazione guidata da Google che avverrà in futuro.

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

• Riceverai una notifica contemporaneamente per ogni parco risorse della tua organizzazione (esclusi quelli che hai posticipato). Questa notifica è disponibile nelle condizioni dello stato funzionalità a livello di parco risorse (MODERNIZATION_WILL_BE_SCHEDULED).

Notifica a livello di cluster

Riceverai una notifica, a livello di cluster, della data di inizio stimata per la modernizzazione del cluster guidata da Google, almeno 1 giorno (24 ore) prima dell'inizio della modernizzazione del cluster.

In questo modo, dopo la notifica a livello di parco risorse, avrai una tempistica molto più precisa per la modernizzazione dei singoli cluster. Questa notifica è disponibile nelle condizioni dello stato funzionalità a livello di cluster (MODERNIZATION_SCHEDULED).

Richiesta di rollback per la modernizzazione guidata da Google

Se si verificano problemi durante la modernizzazione attiva o il soaking su un parco risorse di modernizzazione gestito 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 di parchi risorse e cluster.

Modernizzazione dei parchi risorse

Per ogni parco risorse in fase di modernizzazione (gestita da Google o attivata dal cliente), attiviamo la nuova implementazione del control plane per tutti i cluster in base all'ordine (anticipato → predefinito → ritardato).

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 (anticipato → predefinito → ritardato).

Consulta Controlla lo stato di modernizzazione del parco risorse per verificare lo stato attuale.

Periodo di attesa del parco risorse

Una volta spostato il traffico per tutti i cluster, il parco risorse entra in un periodo di soaking. 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 per tutto il periodo di soak. Una volta finalizzata la modernizzazione, il rollback non è più possibile e i componenti ISTIOD potrebbero essere sottoposti a deprovisioning.

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 presenti i seguenti dettagli:
   • Per abilitare il controllo di integrità, viene creato il DaemonSet snk nello spazio dei nomi kube-system del cluster e viene creata una regola firewall per cluster.
   • Per abilitare l'importazione dei gruppi di endpoint di rete (NEG), l'annotazione cloud.google.com/neg viene aggiunta a tutti i servizi Kubernetes.
   • Nel cluster vengono create nuove risorse Google Cloud , come mesh, route, servizi di backend e controlli di integrità.
   • Alcune delle nuove risorse sono soggette a quote. Puoi visualizzare le quote e richiederne altre, se necessario.
   • Il cluster viene monitorato durante il tempo di soak prima di passare al passaggio successivo.
2. Shift il traffico alla nuova implementazione del control plane. Se hai configurato periodi di manutenzione per il tuo cluster, questo passaggio inizierà durante un periodo di manutenzione e continuerà fino al completamento. Tieni presenti 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 wave progressivamente più grandi con un tempo di soak dopo ogni wave per il monitoraggio.

3. Riavvio manuale dei workload per i non deployment (è richiesta l'azione del cliente).

   • Google riavvia automaticamente i workload gestiti dai deployment Kubernetes. I workload gestiti da altri tipi di risorse Kubernetes, come StatefulSet o DaemonSet, devono essere riavviati manualmente. Se un cluster contiene questi workload, segnala la condizione MODERNIZATION_REQUIRES_MANUAL_WORKLOAD_RESTART e il parco risorse segnala la condizione MODERNIZATION_REQUIRES_CUSTOMER_TRIGGER.
   • Durante la modernizzazione attiva del cluster, dopo il riavvio dei workload Deployment, segnaliamo una condizione a livello di cluster di MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART (insieme a MODERNIZATION_MIGRATING_WORKLOADS).
   • A questo punto, devi riavviare manualmente i workload rimanenti in modo che i relativi proxy si connettano all'implementazione del control plane TRAFFIC_DIRECTOR.
   • Google attende almeno 60 giorni per consentirti di riavviare tutti i workload prima di procedere con i cluster successivi (in un parco risorse multi-cluster) o di avviare il periodo di soak del parco risorse. I workload che rimangono connessi a ISTIOD non saranno più supportati.
   • Per verificare quali proxy sono ancora connessi a ISTIOD, esegui il comando gcloud beta container fleet mesh debug proxy-status, come descritto in Visualizza lo stato del control plane. I proxy con un ID istanza Istiod nella colonna ISTIOD dell'output comando si connettono ancora a ISTIOD e richiedono un riavvio manuale.
   • Dopo che tutti i workload del mesh nel cluster si sono connessi a TRAFFIC_DIRECTOR, le condizioni MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART e MODERNIZATION_REQUIRES_MANUAL_WORKLOAD_RESTART vengono cancellate automaticamente e lo stato del cluster passa a MODERNIZATION_COMPLETED.

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

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

Controlla lo stato della modernizzazione e passa all'azione

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 della 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 una modernizzazione del parco risorse riuscita, lo stato del parco risorse inizierà come MODERNIZATION_MODERNIZING.

Ogni cluster passa quindi attraverso i seguenti stati:

• MODERNIZATION_SCHEDULED
• MODERNIZATION_PREPARING
• MODERNIZATION_PREPARED
• MODERNIZATION_MIGRATING_WORKLOADS
• (facoltativamente) MODERNIZATION_MIGRATING_WORKLOADS con MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART
• MODERNIZATION_COMPLETED

Una volta che tutti i cluster del parco risorse hanno completato la modernizzazione, il parco risorse passerà attraverso i seguenti stati:

• MODERNIZATION_MODERNIZED
• MODERNIZATION_FINALIZED

Rollback

La modernizzazione basata su Google monitora l'idoneità e l'integrità del deployment durante tutto 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 visualizzato temporaneamente lo stato MODERNIZATION_ABORTED.

Gestione di errori e blocchi (solo se 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à i rollback per la modernizzazione attivata dal cliente. Devi valutare il problema e decidere se applicare una correzione o attivare un rollback.

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

Errori risolvibili dall'utente

Se rileviamo una configurazione mesh o cluster incompatibile, interromperemo la modernizzazione. Assicurati che i report sulla compatibilità siano abilitati ed esamina le condizioni a livello di parco risorse e di cluster per individuare eventuali lacune, come descritto in Informazioni sulla compatibilità di Cloud Service Mesh.

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

Errori interni

I problemi relativi ai servizi Google interni 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 è bloccata per 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 workload di produzione sono interessati.

Riferimento per le condizioni a livello di parco risorse

Riferimento alle condizioni a livello di cluster