Questo documento fornisce consigli su come eseguire lo sharding dell'utilizzo di Config Controller. Lo sharding è il processo di suddivisione delle risorse gestite da Config Controller Google Cloud 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 vengono interessati.
- Ti aiuta a gestire la sicurezza: ogni shard può avere configurazioni IAM e RBAC dedicate. Gli utenti malintenzionati che compromettono uno shard non possono accedere ad altri shard. Una configurazione errata in uno shard non può influire sugli altri shard.
- Migliore scalabilità: un singolo shard può avere colli di bottiglia di scalabilità, ad esempio il numero di oggetti gestiti o le quote API. L'utilizzo di più shard aumenta la scalabilità complessiva dell'utilizzo di Config Controller.
Utilizzare lo sharding con Config Controller
Esistono diversi modi per implementare lo sharding. L'approccio migliore per te dipenderà dalle tue esigenze e dai tuoi requisiti specifici.
Modelli di sharding
Esistono due modelli di sharding principali:
- Per linee di business o team di applicazioni: 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 per l'ambiente di controllo qualità e uno per l'ambiente di produzione.
Ridurre al minimo la necessità di riferimenti tra shard
Quando esegui lo sharding dell'utilizzo di Config Controller, devi ridurre al minimo la necessità di riferimenti tra shard. I riferimenti tra shard possono rendere la configurazione più complessa e difficile da gestire. Per ulteriori dettagli, consulta Riferimenti alle risorse tra le istanze.
Meccanismi di sharding
Esistono tre meccanismi di sharding principali:
- Per spazi dei nomi: puoi creare spazi dei nomi aggiuntivi e configurare Config Connector per gestire le risorse in questi spazi dei nomi.
- Per istanze di Config Controller: puoi creare più istanze di Config Controller in un Google Cloud progetto.
- Per progetti: puoi creare più istanze di Config Controller in più Google Cloud progetti. Questo meccanismo consente di risolvere i problemi relativi alle quote API se si verificano colli di bottiglia delle quote con un singolo progetto. Per ulteriori dettagli, consulta Suddividere le risorse in più progetti.
Avvertenze durante l'implementazione dello sharding
Quando implementi lo sharding per l'utilizzo di Config Controller, devi tenere presente alcuni potenziali problemi e pianificare la loro mitigazione.
Riferimenti alle risorse tra le istanze
Una delle sfide dello sharding di Config Controller è la gestione dei riferimenti alle risorse tra le istanze. Ad esempio, un team della piattaforma potrebbe creare progetti in un'istanza, mentre i team delle app potrebbero creare risorse che fanno riferimento a questi progetti in altre istanze. Questo può creare problemi come:
- Maggiore complessità: la gestione dei riferimenti alle risorse tra i cluster può rendere la configurazione più complessa e difficile da gestire.
- Aumento del rischio: se una risorsa viene eliminata in uno shard, può comunque essere referenziata da risorse in altri shard. Ciò può comportare un comportamento imprevisto e la perdita di dati.
- Degrado delle prestazioni: i riferimenti alle risorse tra i cluster possono aumentare la latenza delle modifiche alla configurazione.
Esistono alcuni modi per ovviare al problema dei riferimenti incrociati:
- Eseguire lo sharding in modo che non sia necessario alcun riferimento tra gli shard. Questa operazione può essere eseguita tramite lo sharding per ambienti o per team.
- Utilizzare riferimenti esterni. Ciò significa che l'oggetto a cui si fa riferimento non è effettivamente gestito da Config Controller. Questa può essere una buona opzione se l'oggetto non cambia di frequente.
- Avere lo stesso oggetto disponibile in tutti gli shard. Questa è un'opzione più complessa, ma può essere la migliore se l'oggetto cambia di frequente.
Gli oggetti devono condividere la stessa origine di verità per evitare conflitti di riconciliazione tra questi oggetti in shard diversi. Per questi oggetti devi impostare il
criterio di prevenzione dei conflitti
su
none.
Prima di scegliere un approccio, è importante valutare attentamente i vantaggi e gli svantaggi di ciascuno.
Quote API
Lo sharding potrebbe aumentare le quote API. Devi tenerne conto e pianificare di conseguenza. Per le best practice sulla gestione dei limiti delle quote API, consulta Gestire i limiti delle quote API.
Passaggi successivi
- Scopri di più sulla scalabilità di Config Controller