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. Diverse funzionalità di GKE Enterprise sono disponibili solo tramite un parco risorse.

La strategia di raggruppamento utilizzata per creare i parchi può variare in base alle 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 all'interno della tua organizzazione.

Questa guida è rivolta ai Cloud Architect che vogliono iniziare a utilizzare i parchi nelle loro organizzazioni. Fornisce alcune indicazioni pratiche per 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, ti consigliamo di familiarizzare con i concetti trattati nella panoramica della gestione del parco risorse. Questa guida presuppone inoltre che tu abbia familiarità con i concetti di base di Kubernetes e con la gerarchia delle risorse di Google Cloud .

Limitazioni del parco risorse

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

  • Un determinato progetto Google Cloud può avere un solo parco risorse (o nessun parco risorse) associato, 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 far parte di un'unica flotta alla volta.
  • Tutti i cluster di un determinato progetto devono trovarsi nello stesso parco risorse o non in un 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 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 mutuamente attendibile) sulle risorse è fondamentale per garantire l'integrità del parco.

Pianificare i parchi risorse per i nuovi cluster

Questa sezione descrive come pianificare i parchi quando hai un insieme noto di applicazioni, ma puoi scegliere dove vengono implementate. Il motivo potrebbe essere 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 parco risorse, creare un parco risorse in ogni progetto e creare e registrare i cluster nel parco risorse previsto.

Controlla i tuoi 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.

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. In questo caso, ogni team IT federato potrebbe voler gestire i propri parchi. Utilizza parchi separati se i carichi di lavoro di due unità aziendali (ad esempio, auditing e trading in una banca) non possono comunicare tra loro per motivi normativi.

Separare 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, le modifiche all'applicazione vengono implementate progressivamente (o promosse) 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 blueprint dell'applicazione aziendale per un esempio in cui ogni ambiente ha un parco e come le applicazioni possono essere implementate progressivamente.

Combinare istanze di carico di lavoro ridondanti

Quando un'applicazione richiede un'alta disponibilità, un pattern è eseguirla in due o più regioni. Si tratta di due o più cluster che eseguono deployment configurati in modo molto simile e gestiti come un'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 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.

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 spostarli. Questi cluster potrebbero trovarsi 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 suddividere progressivamente l'insieme di applicazioni in sottoinsiemi fino a ottenere l'insieme minimo di raggruppamenti necessari. In questo modo potrai definire i parchi necessari.

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 genere, in questo caso partizioni l'insieme di cluster per unità aziendale. Un esempio è il caso in cui i carichi di lavoro di determinati reparti aziendali (ad esempio, auditing 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, valuta la possibilità 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

Identifica gli ambienti utilizzati nella tua organizzazione. I nomi di ambiente più comuni sono dev, non prod (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 il nuovo deployment delle applicazioni in cluster che contengono solo applicazioni appartenenti a un singolo ambiente logico.

Riduci al minimo il numero di proprietari di 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 amministratore con un team della piattaforma centrale che gestisce i parchi, non devono essere raggruppati in un parco.

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, ti consigliamo di organizzare i 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 dover avere determinati cluster 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 disponi di VPC condivisi con limitazioni e senza limitazioni, è buona prassi inserirli in parchi separati.

Se prevedi di utilizzare i perimetri dei Controlli di servizio VPC, in genere alcuni carichi di lavoro si trovano all'interno del perimetro e altri al di fuori. Dovresti prevedere 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 la produzione).

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

Passaggi successivi