Questo documento fornisce consigli su come partizionare l'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 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.
- Scalabilità migliore: un singolo shard può presentare colli di bottiglia di scalabilità, ad esempio il numero di oggetti gestiti o le quote API. La presenza 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 cross-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 partizionamento 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 Config Controller: puoi creare più istanze Config Controller in un unico progetto Google Cloud .
- Per progetti: puoi creare più istanze di Config Controller in più progetti. Google Cloud 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, vedi Dividere le risorse in più progetti.
Avvertenze per l'implementazione dello sharding
Quando implementi lo sharding per l'utilizzo di Config Controller, ci sono alcuni potenziali problemi di cui devi essere a conoscenza e che devi pianificare di mitigare.
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. Ciò può creare problemi come:
- Maggiore complessità: la gestione dei riferimenti alle risorse nei cluster può rendere la configurazione più complessa e difficile da gestire.
- Rischio maggiore: se una risorsa viene eliminata in uno shard, può comunque essere a cui fanno riferimento le risorse in altri shard. Ciò può comportare un comportamento inatteso e una perdita di dati.
- Degrado delle prestazioni: i riferimenti alle risorse nei cluster possono aumentare la latenza delle modifiche alla configurazione.
Esistono alcuni modi per ovviare al problema dei riferimenti incrociati:
- Lo sharding in modo che non sia necessario alcun riferimento tra gli shard. Ciò potrebbe essere fatto tramite 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 cambia di frequente.
- Avere lo stesso oggetto disponibile in tutti gli shard. Si tratta di un'opzione più complessa, ma può essere la migliore se l'oggetto cambia spesso.
Gli oggetti devono condividere la stessa origine attendibile 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. Consulta la sezione Gestire i limiti di quota API per le best practice sulla gestione dei limiti di quota API.
Passaggi successivi
- Scopri di più sulla scalabilità di Config Controller