Linee guida per lo sharding di Config Controller

Questo documento fornisce suggerimenti su come eseguire lo sharding dell'utilizzo di Config Controller. Lo sharding è il processo di suddivisione delle risorse Google Cloud gestite da Config Controller in più spazi dei nomi, cluster o progetti.

Lo sharding offre i seguenti vantaggi:

  • Riduce l'impatto delle modifiche: se un singolo shard smette di funzionare, gli altri shard non sono interessati.
  • Ti aiuta a gestire la sicurezza: ogni shard può avere configurazioni IAM e RBAC dedicate. Gli utenti malintenzionati malintenzionati che compromettono uno shard non possono accedere ad altri shard. La configurazione errata in uno shard non può interessare altri shard.
  • Migliore scalabilità: un singolo shard può avere colli di bottiglia della scalabilità come il numero di oggetti gestiti o le quote delle API. Avere più shard aumenta la scalabilità complessiva dell'utilizzo di Config Controller.

Utilizza lo sharding con Config Controller

Esistono diversi modi per implementare lo sharding. L'approccio migliore per te dipende dalle tue esigenze e requisiti specifici.

Modelli di sharding

Esistono due principali modelli dello sharding:

  • Per linee aziendali o team applicativi: questo modello viene in genere utilizzato quando Config Controller viene utilizzato da team diversi. In questo modello, ogni team ha il proprio shard.
  • Per ambiente: questo modello viene in genere utilizzato quando Config Controller viene utilizzato in ambienti diversi. Ad esempio, potresti avere uno shard per l'ambiente di sviluppo, uno shard per l'ambiente di QA e uno shard per l'ambiente di produzione.

Riduci al minimo la necessità di riferimenti incrociati

Quando esegui lo sharding dell'utilizzo di Config Controller, dovresti ridurre al minimo la necessità di riferimenti incrociati. I riferimenti incrociati possono rendere la configurazione più complessa e difficile da gestire. Consulta Riferimenti delle risorse tra le istanze per ulteriori dettagli.

Meccanismi di sharding

Esistono tre principali meccanismi di sharding:

  • Per spazi dei nomi: puoi creare spazi dei nomi aggiuntivi e configurare Config Connector per gestire le risorse al loro interno.
  • Da istanze di Config Controller: puoi creare più istanze di Config Controller in un progetto Google Cloud.
  • Per progetti: puoi creare più istanze Config Controller in più progetti Google Cloud. Questo meccanismo consente di risolvere i problemi di quota dell'API se si verificano colli di bottiglia delle quote in un singolo progetto. Per ulteriori dettagli, consulta Suddividere le risorse in più progetti.

Avvertenze per l'implementazione dello sharding

Durante l'implementazione dello sharding per l'utilizzo di Config Controller, esistono alcuni potenziali problemi di cui dovresti essere a conoscenza e pianificare di mitigarli.

Riferimenti delle risorse tra le istanze

Una delle sfide dello sharding per Config Controller riguarda la gestione dei riferimenti alle risorse tra le istanze. Ad esempio, un team della piattaforma potrebbe creare progetti in un'istanza e poi i team dedicati alle app potrebbero creare risorse che fanno riferimento a questi progetti in altre istanze. Ciò può creare problemi quali:

  • Maggiore complessità: la gestione dei riferimenti alle risorse tra cluster può rendere la configurazione più complessa e difficile da gestire.
  • Maggiore rischio: se una risorsa viene eliminata in uno shard, può comunque essere menzionata dalle risorse in altri shard. Ciò può causare comportamenti inaspettati e perdita di dati.
  • Riduzione delle prestazioni: i riferimenti alle risorse nei vari cluster possono aumentare la latenza delle modifiche alla configurazione.

Esistono alcuni modi per aggirare la sfida del controllo incrociato:

  • Eseguire lo sharding in modo che non sia necessario alcun riferimento tra gli shard. Questo potrebbe essere fatto mediante lo sharding per ambienti o per team.
  • Utilizzo di riferimenti esterni. Ciò significa che l'oggetto a cui viene fatto riferimento non è effettivamente gestito da Config Controller. Questa può essere una buona opzione se l'oggetto non viene modificato di frequente.
  • Avere lo stesso oggetto disponibile in tutti gli shard. Si tratta di un'opzione più complessa, ma può essere l'opzione migliore se l'oggetto cambia spesso. Gli oggetti devono condividere la stessa fonte di dati per evitare combattimenti di riconciliazione tra questi oggetti in shard diversi. Devi impostare il criterio di prevenzione dei conflitti su none per questi oggetti.

È importante valutare attentamente i vantaggi e gli svantaggi di ciascun approccio prima di sceglierne uno.

Quote API

Lo sharding potrebbe aumentare le tue quote API. Devi tenerne conto e pianificare di conseguenza. Consulta Gestione dei limiti di quota API per le best practice sulla gestione dei limiti di quota API.

Passaggi successivi