Linee guida per lo sharding di Config Controller

Questo documento fornisce consigli su come suddividere 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 sono interessati.
  • Ti aiuta a gestire la sicurezza: ogni shard può avere IAM e RBAC dedicati configurazioni. Gli utenti malintenzionati che compromettono uno shard non possono accedere agli altri shard. La configurazione errata di uno shard non può influire sugli altri.
  • Migliore scalabilità: un singolo shard può avere colli di bottiglia della scalabilità quali come il numero di oggetti gestiti o le quote API. Avere 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 suddivisione 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 generalmente utilizzato quando Config Controller viene utilizzato in diversi ambienti. Ad esempio, potrebbe avere uno shard per l'ambiente di sviluppo, uno shard per il 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, devi ridurre al minimo i riferimenti incrociati. I riferimenti tra shard 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:

Limitazioni dell'implementazione dello sharding

Quando implementi lo sharding per l'utilizzo di Config Controller, ci sono alcune dei potenziali problemi di cui dovresti essere a conoscenza e che prevedi di risolvere.

Riferimenti delle risorse tra le istanze

Una delle sfide dello sharding di Config Controller è gestire i riferimenti alle risorse tra le istanze. Ad esempio, un team della piattaforma potrebbe creare progetti in un caso, i team dedicati alle app potrebbero creare risorse che fanno riferimento Progetti in altre istanze. Ciò può creare problemi come:

  • Maggiore complessità: la gestione dei riferimenti alle risorse tra i cluster può aumentare la complessità e la difficoltà di gestione della configurazione.
  • Rischio maggiore: se una risorsa viene eliminata in uno shard, può comunque essere richiamata dalle risorse in altri shard. Ciò può comportare comportamenti imprevisti e perdita di dati.
  • Degradamento delle prestazioni: i riferimenti alle risorse tra i 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 suddividendo gli ambienti o i team.
  • Utilizzo di riferimenti esterni. Ciò significa che l'oggetto a cui viene fatto riferimento non è effettivamente gestito da Config Controller. Può essere un un'opzione valida se l'oggetto non viene modificato di frequente.
  • Avere lo stesso oggetto disponibile in tutti gli shard. Questo è un processo più complesso ma può essere l'opzione migliore se l'oggetto cambia spesso. Gli oggetti devono condividere la stessa fonte di dati per evitare la riconciliazione combattimenti tra questi oggetti in shard diversi. Devi impostare criterio di prevenzione dei conflitti a 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: Gestire i limiti di quota delle API per le best practice sulla gestione dei limiti di quota delle API.

Passaggi successivi