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ù namespace, 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 frammento può avere configurazioni IAM e RBAC dedicate. Gli utenti malintenzionati che compromettono uno shard non possono accedere agli altri shard. La configurazione errata di uno shard non può influire sugli altri shard.
  • Maggiore scalabilità: un singolo shard può avere colli di bottiglia di scalabilità come 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 suddivisione in parti

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 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 QA e uno per l'ambiente di produzione.

Riduci 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 la sezione Riferimenti alle risorse tra istanze.

Meccanismi di sharding

Esistono tre meccanismi di suddivisione principali:

Limitazioni dell'implementazione dello sharding

Quando implementi lo sharding per l'utilizzo di Config Controller, devi essere a conoscenza di alcuni potenziali problemi e pianificare come mitigarli.

Riferimenti alle risorse tra 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'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 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 il problema dei riferimenti incrociati:

  • Eseguire lo sharding in modo che non sia necessario alcun riferimento tra i vari 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. 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 di frequente. 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.

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

Quote API

Lo sharding potrebbe aumentare le quote API. Devi essere consapevole di questo e pianificare di conseguenza. Consulta Gestire i limiti di quota API per le best practice sulla gestione dei limiti di quota API.

Passaggi successivi