Control plane gestito

Questo documento spiega le differenze architetturali tra l'implementazione del control plane ISTIOD ritirato e l'implementazione del control plane TRAFFIC_DIRECTOR moderno di Google e descrive i passaggi successivi se i tuoi cluster utilizzano ancora un control plane ritirato.

Panoramica del control plane

Nei service mesh, il control plane fornisce la gestione del traffico, la gestione dei proxy quando viene utilizzato il proxy Envoy e altre funzionalità di networking.

Cloud Service Mesh che utilizza le API Istio sui cluster GKE fornisce un'implementazione completamente supportata delle API Istio. Le API sono implementate e supportate dal piano di controllo TRAFFIC_DIRECTOR completamente gestito e integrato in Cloud Networking. In precedenza, erano supportate due implementazioni aggiuntive del piano di controllo:

  • L'implementazione ritirata gestita ISTIOD, che esegue un control plane dedicato a un singolo cluster.
  • L'implementazione ritirata di ISTIOD in-cluster, che esegue i componenti del control plane gestito dal cliente all'interno del cluster.

Caratteristiche operative del control plane TRAFFIC_DIRECTOR

Cloud Service Mesh con il control plane TRAFFIC_DIRECTOR utilizza l'infrastruttura di rete gestita di Google Cloudanziché le istanze del control plane per cluster.

Le API Istio (CRD) e la configurazione xDS inviata ai sidecar Envoy rimangono compatibili, ma devi aspettarti le seguenti caratteristiche operative:

  • Propagazione della configurazione del servizio e servizi:quando crei nuovi servizi o aggiorni le policy di routing e sicurezza, la configurazione viene convalidata e propagata nei sistemi Google Cloud prima di essere applicata ai sidecar. Di conseguenza, la propagazione iniziale di policy e servizi richiede più tempo rispetto ai control plane in-cluster o ISTIOD. Per indicazioni sull'ottimizzazione dei flussi di lavoro di deployment, consulta Propagazione della configurazione.
  • Scalabilità dei pod e aggiornamenti degli endpoint: le modifiche agli endpoint del workload, ad esempio i nuovi pod creati dalla scalabilità automatica orizzontale dei pod o i pod riavviati con nuovi indirizzi IP, vengono propagate direttamente dal control plane senza la latenza associata agli aggiornamenti dei criteri. I pod esistenti che recuperano la configurazione esistente vengono avviati senza ritardi.
  • Rilevamento degli endpoint multi-cluster: nelle mesh multi-cluster, i cluster condividono i propri endpoint direttamente tramite Google Cloud anziché sincronizzarli point-to-point tra ogni combinazione di cluster. In questo modo, lo stato dell'endpoint cross-cluster converge in modo più rapido e coerente man mano che la mesh viene scalata.

In che modo questo ti riguarda?

I passaggi successivi dipendono dall'implementazione del control plane di Cloud Service Mesh utilizzata dai tuoi cluster:

Modernizzazione del control plane per Cloud Service Mesh gestito con l'implementazione di ISTIOD

Tutte le flotte gestite che eseguono l'implementazione ISTIOD ritirata devono completare l'ammodernamento all'implementazione TRAFFIC_DIRECTOR prima della scadenza del termine di fine del supporto specificato nell'avviso di ritiro. Puoi modernizzare il tuo parco macchine utilizzando la modernizzazione attivata dal cliente (consigliata per il controllo per cluster e lo spostamento graduale del traffico) o la modernizzazione basata su Google (implementazioni automatiche per i parchi macchine idonei).

Per istruzioni passo passo, vedi Modernizzazione del control plane gestito.

Controllare la compatibilità del control plane

Per valutare il tuo parco risorse in base alle funzionalità supportate e identificare i blocchi di configurazione prima della modernizzazione, consulta:

Appendice: cronologia del lancio e del ritiro del control plane

La transizione dai control plane ISTIOD all'implementazione del control plane gestito TRAFFIC_DIRECTOR ha seguito questa cronologia:

  • 23 maggio 2024: Anthos Service Mesh e Traffic Director sono stati uniti in Cloud Service Mesh, introducendo l'implementazione del control plane TRAFFIC_DIRECTOR per le API Istio.
  • 1° luglio 2024: le nuove fleet di cui è stato eseguito l'onboarding a Cloud Service Mesh gestito hanno iniziato a ricevere l'implementazione di TRAFFIC_DIRECTOR per impostazione predefinita.
  • 8 settembre 2024: il provisioning dell'implementazione di ISTIOD per le nuove flotte è terminato per la disponibilità generale (con eccezioni temporanee per organizzazioni specifiche in una lista consentita).
  • 28 settembre 2026: annuncio del ritiro formale sia dell'implementazione del control plane gestito ISTIOD sia del control plane nel cluster su GKE.