Pianificare 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 gruppi di cluster di grandi dimensioni. Alcune funzionalità di GKE sono disponibili solo tramite un parco risorse.

La strategia di raggruppamento che utilizzi per creare i parchi risorse 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, mentre un'altra potrebbe raggrupparli per regione, ambiente o altri fattori pertinenti. A parità di condizioni, è conveniente avere il minor numero possibile di parchi risorse all'interno dell'organizzazione.

Questa guida è rivolta agli architetti cloud che vogliono iniziare a utilizzare i parchi risorse nelle loro organizzazioni. Fornisce alcune indicazioni pratiche sull'organizzazione dei 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 risorse. I parchi risorse sono flessibili e potresti decidere di utilizzare un pattern di raggruppamento diverso per i tuoi cluster.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

Limitazioni di parchi risorse e risorse

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

  • Un dato Google Cloud progetto può avere associato un solo parco risorse (o nessun parco risorse), anche se il parco risorse può 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.
  • Tutti i cluster di un determinato progetto devono trovarsi nello stesso parco risorse o in nessun parco risorse. Se un progetto contiene già membri del parco risorse, non puoi registrare un cluster di quel progetto in un altro parco risorse.
  • Il limite predefinito per il numero di cluster in un parco risorse è 250, ma puoi richiedere un limite superiore se necessario.

Per molti motivi, può essere conveniente inserire più cluster nello stesso progetto. Tuttavia, tieni presente i seguenti limiti quando pianifichi quali cluster inserire in un progetto:

Principi generali

Di seguito sono riportate le domande generali che devi porti quando decidi se raggruppare i cluster in un parco risorse. Nelle sezioni seguenti esamineremo in dettaglio come si applicano.

  • Le risorse sono correlate tra loro?
    • Le risorse che hanno grandi quantità di comunicazione tra servizi traggono il massimo vantaggio dalla gestione congiunta in un parco risorse.
    • Le risorse nello stesso ambiente di deployment (ad esempio, l'ambiente di produzione) devono essere gestite insieme in un parco risorse.
  • Chi amministra le risorse?
    • Avere un controllo unificato (o almeno di fiducia reciproca) 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 quando hai un insieme noto di applicazioni, ma sei flessibile in merito alla posizione in cui vengono eseguite. Questo potrebbe essere dovuto al fatto che non hai ancora sviluppato queste applicazioni o le stai eseguendo la migrazione da una piattaforma container diversa. In alternativa, potresti già avere applicazioni in esecuzione nei cluster esistenti, ma sei disposto 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 workload

Inizia con un elenco di tutti i workload Kubernetes (ad esempio i deployment) di cui vuoi eseguire il deployment. Non deve essere un elenco letterale, ma solo un'idea dei workload di cui avrai bisogno. Poi, segui i passaggi riportati nel resto di questa sezione per dividere progressivamente l'insieme di applicazioni in sottoinsiemi fino a ottenere l'insieme minimo di raggruppamenti necessari. In questo modo definirai i parchi risorse e i cluster di cui hai bisogno.

Considerare le unità aziendali

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

Separare i workload per ambiente

Un pattern comune che funziona per molte organizzazioni è raggruppare i cluster per ambiente. Una configurazione tipica prevede tre ambienti principali: sviluppo, non di produzione (o gestione temporanea) e produzione. In genere, le modifiche alle applicazioni vengono eseguite il deployment progressivamente (o promosse) in ogni ambiente dell'elenco. Per questo motivo, hai deployment separati in ogni ambiente per la stessa applicazione sottostante, ad esempio lo stesso nome dell'immagine container di base. Per un esempio di come creare ambienti nella tua organizzazione, consulta il progetto di base aziendale.

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

Combinare le istanze di workload ridondanti

Quando un'applicazione richiede un'alta affidabilità, un pattern consiste nell'eseguirla in due o più regioni. Ciò comporta l'esecuzione di due o più cluster con deployment configurati in modo molto simile e gestiti come un'unica unità. Spesso avranno un bilanciatore del carico che copre le istanze dell'applicazione in tutti i cluster o utilizzeranno il bilanciamento del carico DNS.

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

Pianificare i parchi risorse con i cluster esistenti

Questa sezione descrive come pianificare i parchi risorse quando hai workload in esecuzione su cluster esistenti e non prevedi di spostarli. Questi cluster potrebbero trovarsi su o al di fuori di Google Cloud. In questo scenario, l'obiettivo è creare un insieme di parchi risorse all'interno dell'organizzazione e assegnarvi i cluster esistenti.

Dopo aver identificato i parchi risorse, puoi creare un nuovo progetto per ogni 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 le risorse dei cluster Kubernetes nella tua organizzazione.

Poi, segui i passaggi riportati nel resto di questa sezione per dividere progressivamente l'insieme di applicazioni in sottoinsiemi fino a ottenere l'insieme minimo di raggruppamenti necessari. In questo modo definirai i parchi risorse di cui hai bisogno.

Considerare le unità aziendali

La tua organizzazione potrebbe avere una struttura IT federata, in cui è presente un team IT centrale per l'organizzazione, nonché team IT separati per ogni unità aziendale. Questi team IT per unità aziendale potrebbero aver creato i cluster esistenti. In genere, in questo caso, la partizione dell'insieme di cluster viene eseguita per unità aziendale. Un esempio è quando i workload di determinate unità aziendali (ad esempio, audit e trading in una banca) non possono comunicare tra loro per motivi normativi.

Se le unità aziendali esistono esclusivamente per scopi di contabilità dei costi, ma utilizzano un team IT comune, valuta la possibilità di combinare i cluster in un unico parco risorse, soprattutto se esistono dipendenze interservizi significative tra le unità aziendali.

Raggruppare i cluster per ambiente

Identifica gli ambienti utilizzati nella tua organizzazione. I nomi degli ambienti tipici sono dev, non di produzione (o gestione temporanea) e prod.

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

Ridurre al minimo il numero di proprietari dei cluster

Quando combini i progetti esistenti in un parco risorse, potrebbero esistere diversi insiemi di utenti autorizzati ad agire come amministratori su questi cluster, tenendo conto sia delle policy IAM (container.admin) sia di RBAC (ClusterRoleBinding admin). Se prevedi di utilizzare funzionalità che richiedono l'uguaglianza, l'obiettivo dovrebbe essere che tutti i cluster abbiano lo stesso insieme di amministratori e che esista un piccolo insieme di amministratori per il parco risorse. Se i cluster devono avere amministratori diversi e l'obiettivo è utilizzare le funzionalità che richiedono l'uguaglianza, probabilmente non appartengono allo stesso parco risorse.

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 amministratore con un team di piattaforma centrale che gestisce i parchi risorse, non devono essere raggruppati in un parco risorse.

Per scoprire di più sull'uguaglianza e sulle funzionalità che la richiedono, consulta la sezione Come funzionano i parchi risorse.

Considerare 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 anche influire sull'organizzazione ottimale del parco risorse. Ad esempio, se scegli di utilizzare la federazione delle identità per i workload a livello di parco risorse, potresti voler organizzare i parchi risorse in modo da ridurre al minimo il rischio durante la configurazione dell'autenticazione dei workload a livello di parco risorse oppure, se vuoi utilizzare Cloud Service Mesh, potresti aver bisogno che determinati cluster si trovino nello stesso parco risorse. Se utilizzi Virtual Private Cloud (VPC), alcune funzionalità richiedono l'utilizzo di una singola VPC per parco risorse.

Puoi scoprire di più sull'adozione delle funzionalità del parco risorse e sui relativi requisiti e limitazioni nella guida successiva di questa serie, Pianificare le funzionalità del parco risorse.

Considerare i perimetri VPC

Un altro aspetto 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 su una VPC condiviso con Controlli di servizio VPC) possono trovarsi insieme in un parco risorse. Se hai VPC condivise con restrizioni e senza restrizioni, una buona pratica è inserirle in parchi risorse separati.

Se prevedi di utilizzare i perimetri dei Controlli di servizio VPC, in genere alcuni workload si trovano all'interno del perimetro e altri all'esterno. Dovresti pianificare di avere versioni dei Controlli di servizio VPC e non dei Controlli di servizio VPC di ogni parco risorse in ogni ambiente (o almeno in prod e nell'ambiente immediatamente precedente a prod).

Quando pianifichi i parchi risorse con le VPC, tieni presente che alcune funzionalità del parco risorse hanno requisiti VPC specifici, ad esempio richiedono che tutti i cluster che le utilizzano si trovino nella stessa rete VPC.

Passaggi successivi