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 garantisce coerenza e osservabilità completa su grandi gruppi di cluster. Diverse funzionalità di GKE sono disponibili solo tramite un parco progetti.

La strategia di raggruppamento utilizzata per creare le flotte 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 flotte all'interno dell'organizzazione.

Questa guida è rivolta agli architetti cloud che vogliono iniziare a utilizzare i fleet nella loro organizzazione. Fornisce alcune indicazioni pratiche sull'organizzazione dei cluster in parchi risorse, tra cui:

  • Quando vuoi creare cluster completamente nuovi.
  • Quando vuoi creare flotte con cluster esistenti.

I pattern descritti qui funzionano per molte organizzazioni, ma non sono l'unico modo per pianificare le flotte. 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 avere familiarità con i seguenti concetti:

Limitazioni del parco risorse e delle risorse

Quando crei flotte, si applicano le seguenti limitazioni generali:

  • A un determinato progetto Google Cloud può essere associato un solo parco risorse (o nessuno), 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 una sola flotta 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, anche se 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 raggruppare in un progetto:

Principi generali

Di seguito sono riportate le domande generali da porsi quando si decide se raggruppare i cluster in una flotta. Vedremo in dettaglio come vengono applicati nelle sezioni seguenti.

  • 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 il controllo unificato (o almeno reciprocamente attendibile) delle risorse è fondamentale per garantire l'integrità del parco auto.

Pianificare i parchi risorse per i nuovi cluster

Questa sezione descrive come pianificare le flotte quando hai un insieme noto di applicazioni, ma sei flessibile in merito alla posizione in cui vengono eseguito il deployment. Questo potrebbe essere dovuto al fatto che non hai ancora sviluppato queste applicazioni o le stai eseguendo la migrazione da un'altra piattaforma di container. In alternativa, potresti avere già applicazioni in esecuzione in cluster esistenti, ma essere disposto a spostarle in nuovi cluster per ottenere un'architettura preferita.

Una volta identificati 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 carichi di lavoro Kubernetes (ad esempio i deployment) che vuoi eseguire il deployment. Non deve essere un elenco letterale, ma solo un'idea dei carichi di lavoro di cui avrai bisogno. Poi, segui i passaggi nel resto di questa sezione per dividere progressivamente questo insieme di applicazioni in sottoinsiemi fino a ottenere il set minimo di raggruppamenti necessario. In questo modo, definirai le flotte e i cluster di cui hai bisogno.

Considera 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 le proprie flotte. Utilizza flotte separate 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 carichi di lavoro 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. Le modifiche all'applicazione vengono in genere implementate in modo progressivo (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. Consulta il blueprint delle basi aziendali per un esempio di come creare ambienti nella tua organizzazione.

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

Combinare istanze di workload ridondanti

Quando un'applicazione richiede un'alta disponibilità, 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 hanno un bilanciatore del carico che copre le istanze dell'applicazione in tutti i cluster o utilizzano 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 necessario 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 carichi di lavoro in esecuzione su cluster esistenti e non prevedi di trasferirli. Questi cluster potrebbero trovarsi all'interno o all'esterno di Google Cloud. In questo scenario, l'obiettivo è creare un insieme di flotte all'interno della tua organizzazione e assegnare loro i cluster esistenti.

Una volta identificati 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 del cluster Kubernetes nella tua organizzazione.

Puoi quindi seguire i passaggi nel resto di questa sezione per dividere progressivamente questo insieme di applicazioni in sottoinsiemi fino a ottenere il set minimo di raggruppamenti necessario. In questo modo, potrai definire le flotte di cui hai bisogno.

Considera 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, il set di cluster viene partizionato in base all'unità aziendale. Un esempio è quando i carichi di lavoro 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 a fini di contabilità dei costi, ma utilizzano un team IT comune, valuta la possibilità di combinare i cluster in un'unica flotta, soprattutto se esistono dipendenze significative tra i servizi delle unità aziendali.

Raggruppa i cluster per ambiente

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

Se ogni cluster si trova chiaramente in uno solo dei tuoi ambienti, separa l'elenco dei 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 si combinano progetti esistenti in un parco risorse, potrebbero esserci diversi gruppi di utenti autorizzati ad agire come amministratori su questi cluster, considerando sia i criteri IAM (container.admin) sia RBAC (ClusterRoleBinding amministrativo). Se prevedi di utilizzare funzionalità che richiedono l'identità, l'obiettivo dovrebbe essere quello di fare in modo che tutti i cluster abbiano lo stesso insieme di amministratori e che ci sia 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 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 amministrative con un team della piattaforma centrale che gestisce i parchi auto, non devono essere raggruppati in un parco auto.

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

Considera le funzionalità del parco risorse

Indipendentemente dal fatto che tu stia lavorando con cluster nuovi o esistenti, le funzionalità del parco veicoli che scegli possono influire anche sull'organizzazione ottimale del parco veicoli. Ad esempio, se scegli di utilizzare la federazione delle identità per i carichi di lavoro 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 carichi di lavoro 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 un singolo VPC per flotta.

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

Considera 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 su un VPC condiviso con Controlli di servizio VPC) possono trovarsi insieme in un parco risorse. Se hai VPC condivisi con limitazioni e senza limitazioni, una buona pratica è inserirli in flotte separate.

Se prevedi di utilizzare i perimetri di Controlli di servizio VPC, in genere alcuni carichi di lavoro si trovano all'interno del perimetro e altri all'esterno. Ti consigliamo di pianificare di avere versioni di ogni parco risorse con e senza Controlli di servizio VPC in ogni ambiente (o almeno in produzione e nell'ambiente immediatamente precedente alla produzione).

Quando pianifichi i fleet con i VPC, tieni presente che alcune funzionalità dei fleet hanno requisiti VPC specifici, ad esempio richiedono che tutti i cluster che le utilizzano si trovino all'interno della stessa rete VPC.

Passaggi successivi