Pianifica le risorse del parco risorse

Come hai appreso nella panoramica della gestione dei parchi risorse, i parchi risorse sono un meccanismo di raggruppamento per gestire, configurare e proteggere i cluster Kubernetes su larga scala. I parchi risorse sono uno strumento potente che elimina la necessità di eseguire operazioni ripetute in un ambiente multi-cluster e fornisce coerenza e osservabilità completa su grandi gruppi di cluster. Alcune funzionalità di GKE Enterprise sono disponibili solo tramite un parco risorse.

La strategia di raggruppamento utilizzata per creare i parchi può variare a seconda delle esigenze tecniche e aziendali della tua organizzazione. Ad esempio, un'organizzazione potrebbe raggruppare i cluster in base al tipo di applicazioni in esecuzione al suo interno, mentre un'altra potrebbe raggrupparli per regione, ambiente o altri fattori pertinenti. A parità di condizioni, è conveniente avere il minor numero possibile di parchi all'interno della tua organizzazione.

Questa guida è rivolta ai Cloud Architect che vogliono iniziare a utilizzare i parchi risorse nelle loro organizzazioni. Fornisce alcune indicazioni pratiche su come organizzare i cluster in parchi risorse, tra cui:

  • Quando vuoi creare cluster completamente nuovi.
  • Quando vuoi creare parchi risorse con cluster esistenti.

I pattern descritti qui funzionano per molte organizzazioni, ma non sono l'unico modo per pianificare i parchi. I parchi risorse sono flessibili e puoi decidere di utilizzare un modello di raggruppamento diverso per i tuoi cluster.

Prima di leggere questa guida, dovresti acquisire familiarità con i concetti trattati nella nostra panoramica sulla gestione del parco risorse. Questa guida presuppone anche che tu abbia familiarità con i concetti di base di Kubernetes e con la gerarchia delle risorse di Google Cloud.

Limitazioni del parco risorse e delle risorse

Quando crei i parchi, si applicano le seguenti limitazioni generali:

  • A un determinato progetto Google Cloud può essere associato un solo parco risorse (o nessun parco risorse), sebbene possa includere cluster di più progetti. Il progetto associato a un parco risorse è noto come progetto host del parco risorse.
  • I cluster possono essere membri di un solo parco risorse alla volta.
  • Il limite predefinito per il numero di cluster in un parco risorse è 250, ma puoi richiedere un limite più alto, se necessario.

Può essere conveniente per molti motivi posizionare più cluster nello stesso progetto. Tuttavia, tieni presente i seguenti limiti quando pianifichi i cluster da riunire in un progetto:

Principi generali

Di seguito sono riportate alcune domande generali che dovresti porti quando decidi se raggruppare i cluster in un parco. Analizzeremo più in dettaglio come vengono applicati nelle sezioni seguenti.

  • Le risorse sono correlate tra loro?
    • Le risorse con un volume elevato di comunicazioni tra servizi traggono il massimo vantaggio dalla gestione collettiva in un parco risorse.
    • Le risorse nello stesso ambiente di implementazione (ad esempio l'ambiente di produzione) devono essere gestite insieme in un parco risorse.
  • Chi amministra le risorse?
    • Avere un controllo unificato (o almeno reciprocamente affidabile) sulle risorse è fondamentale per garantire l'integrità del parco risorse.

Pianificare i parchi risorse per i nuovi cluster

Questa sezione descrive come pianificare i parchi risorse se disponi di un set noto di applicazioni, ma sei flessibile su dove viene eseguito il deployment di queste applicazioni. Ciò potrebbe essere dovuto al fatto che non hai ancora sviluppato queste applicazioni o che stai eseguendo la migrazione da una piattaforma di contenitori diversa. In alternativa, potresti avere già applicazioni in esecuzione in cluster esistenti, ma essere disponibile a spostarle in nuovi cluster per ottenere un'architettura preferita.

Dopo aver identificato i parchi risorse, puoi creare un nuovo progetto per ogni parco risorse, creare un parco risorse in ogni progetto e creare e registrare i cluster nel parco risorse previsto.

Controllare i carichi di lavoro

Inizia con un elenco di tutti i carichi di lavoro Kubernetes (ad esempio i deployment) che vuoi eseguire. Non deve essere un elenco letterale; può essere solo un'idea dei carichi di lavoro di cui avrai bisogno. Poi, segui i passaggi nel resto di questa sezione per suddividere progressivamente l'insieme di applicazioni in sottoinsiemi fino a ottenere l'insieme minimo di raggruppamenti necessari. In questo modo, potrai definire i parchi e i cluster di cui hai bisogno.

Valuta le unità aziendali

La tua organizzazione potrebbe avere una struttura IT federata, con un team IT centrale per l'organizzazione e team IT separati per ogni unità aziendale. In questo caso, ogni team IT federato potrebbe voler gestire i propri parchi risorse. Utilizza parchi separati se i carichi di lavoro di due unità aziendali (ad esempio, audit e trading in una banca) non possono comunicare tra loro per motivi normativi.

Separa i carichi di lavoro in base all'ambiente

Un pattern comune che funziona per molte organizzazioni è raggruppare i cluster per ambiente. Una configurazione tipica prevede tre ambienti principali: sviluppo, non produzione (o gestione temporanea) e produzione. In genere, il deployment delle modifiche alle applicazioni viene eseguito in modo progressivo (o promosso) in ogni ambiente nell'elenco. Per questo motivo, hai implementazioni separate in ogni ambiente per la stessa applicazione sottostante, ad esempio lo stesso nome dell'immagine del contenitore di base. Consulta il blueprint Enterprise Foundations per un esempio di come creare ambienti nella tua organizzazione.

Un parco risorse deve contenere solo cluster di un ambiente. Tre ambienti, con un parco in ogni ambiente, potrebbero essere sufficienti per molte organizzazioni. Consulta il progetto dell'applicazione aziendale per un esempio in cui ogni ambiente ha un parco risorse e come è possibile eseguire il deployment progressivo delle applicazioni.

Combinare istanze di carico di lavoro ridondanti

Quando un'applicazione richiede un'elevata disponibilità, un pattern è eseguirla in due o più regioni. Sono coinvolti due o più cluster che eseguono deployment configurati in modo molto simile e gestiti come un'unità. Spesso avranno un bilanciatore del carico che copre le istanze delle applicazioni in tutti i cluster o utilizzeranno il bilanciamento del carico DNS.

In questi scenari, inserisci tutti i cluster nello stesso parco risorse. In genere, i cluster in regioni diverse non devono essere in parchi risorse distinti, a meno che non sia richiesto per motivi normativi o di altro tipo.

Pianifica i parchi risorse con cluster esistenti

Questa sezione descrive come pianificare i parchi risorse quando hai carichi di lavoro in esecuzione su cluster esistenti e non prevedi di spostarli. Questi cluster potrebbero essere all'interno o all'esterno di Google Cloud. In questo scenario, l'obiettivo è creare un insieme di parchi risorse all'interno della tua organizzazione e assegnarvi i cluster esistenti.

Dopo aver identificato i parchi risorse, puoi creare un nuovo progetto per parco risorse, creare un parco risorse in ogni progetto e registrare i cluster nel parco risorse previsto.

Controllare i cluster

Inizia con un elenco di tutti i cluster Kubernetes della tua organizzazione. Cloud Asset Inventory è un modo per cercare risorse del cluster Kubernetes nella tua organizzazione.

Puoi quindi seguire i passaggi nel resto di questa sezione per dividere progressivamente l'insieme di applicazioni in sottoinsiemi fino a ottenere il numero minimo di raggruppamenti necessario. Questo determinerà i parchi risorse di cui hai bisogno.

Prendi in considerazione le unità aziendali

La tua organizzazione potrebbe avere una struttura IT federata, con un team IT centrale per l'organizzazione e team IT separati per ogni unità aziendale. Questi team IT per unità di business potrebbero aver creato i cluster esistenti. In questo caso, in genere, si esegue la partizione dell'insieme di cluster per unità aziendale. Un esempio è il ruolo di alcune unità aziendali carichi di lavoro (ad esempio, audit e trading in una banca) non possono comunicare tra loro per motivi normativi.

Se le unità aziendali esistono solo a fini di contabilità dei costi, ma utilizzano un team IT comune, ti consigliamo di combinare i relativi cluster in un unico parco risorse, soprattutto se esistono dipendenze interservizio significative tra le unità aziendali.

Raggruppa i cluster per ambiente

Identificare quali ambienti vengono utilizzati nella tua organizzazione. I nomi di ambiente tipici sono sviluppo, non produzione (o gestione temporanea) e produzione.

Se ogni cluster si trova chiaramente in uno solo dei tuoi ambienti, separa l'elenco di cluster per ambiente. Tuttavia, se alcuni cluster contengono carichi di lavoro che appartengono logicamente a ambienti diversi, ti consigliamo di eseguire nuovamente il deployment delle applicazioni in cluster che contengono solo applicazioni appartenenti a un singolo ambiente logico.

Riduci al minimo il numero di proprietari del cluster

Quando combini progetti esistenti in un parco risorse, potrebbero esserci diversi gruppi di utenti autorizzati ad agire come amministratori su questi cluster, tenendo conto sia dei criteri IAM (container.admin) sia del RBAC (ClusterRoleBinding amministrativo). Se prevedi di utilizzare funzionalità che richiedono uniformità, l'obiettivo dovrebbe essere quello di avere tutti i cluster con lo stesso insieme di amministratori e un numero ridotto di amministratori per il parco. Se i cluster devono avere amministratori diversi e l'obiettivo è utilizzare le funzionalità che richiedono identità, probabilmente non appartengono alla stessa flotta.

Ad esempio, se i cluster C1 e C2 hanno amministratori diversi che non si fidano reciprocamente e non sono disposti a condividere le autorizzazioni di amministrazione con un team centrale della piattaforma che gestisce i parchi risorse, questi ultimi non devono essere raggruppati in un parco risorse.

Puoi scoprire di più sull'identità e sulle funzionalità che la richiedono in Come funzionano i parchi risorse.

Valuta le funzionalità del parco risorse

Indipendentemente dal fatto che tu stia lavorando con cluster nuovi o esistenti, le funzionalità del parco risorse che scegli possono influire anche sull'organizzazione ottimale del parco risorse. Ad esempio, se scegli di utilizzare la federazione delle identità per i carichi di lavoro a livello di parco risorse, potresti voler organizzare i tuoi parchi risorse in modo da ridurre al minimo i rischi durante la configurazione dell'autenticazione dei carichi di lavoro a livello di parco risorse oppure, se vuoi utilizzare Cloud Service Mesh, potresti aver bisogno che alcuni cluster siano nello stesso parco risorse. Se utilizzi Virtual Private Cloud (VPC), alcune funzionalità richiedono l'utilizzo di un unico VPC per ogni parco.

Per scoprire di più sull'adozione delle funzionalità di gestione del parco veicoli, sui relativi requisiti e limitazioni, consulta la prossima guida di questa serie, Pianificare le funzionalità di gestione del parco veicoli.

Prendi in considerazione i perimetri VPC

Un altro problema da considerare per i cluster nuovi ed esistenti è se hai scelto o vuoi creare le tue reti private su Google Cloud con Virtual Private Cloud (VPC). I cluster all'interno di un perimetro VPC (ad esempio in un VPC condiviso con Controlli di servizio VPC) possono essere inclusi in un parco insieme. Se hai VPC condivisi limitati e non, è buona norma suddividerli in parchi risorse separati.

Se prevedi di utilizzare i perimetri Controlli di servizio VPC, in genere alcuni carichi di lavoro si trovano nel perimetro e altri all'esterno. Dovresti pianificare di avere le versioni dei Controlli di servizio VPC e non dei Controlli di servizio VPC di ogni parco risorse in ciascun ambiente (o almeno di produzione e dell'ambiente immediatamente prima della produzione).

Quando pianifichi i parchi risorse con VPC, tieni presente che alcune funzionalità del parco risorse hanno requisiti VPC specifici, ad esempio richiedono che tutti i cluster che li utilizzano siano all'interno della stessa rete VPC.

Passaggi successivi