Questa guida fornisce best practice, considerazioni pratiche e suggerimenti per l'implementazione dei parchi risorse nella tua organizzazione.
Prima di leggere questa guida, dovresti acquisire familiarità con i concetti descritti in Come funzionano i parchi risorse. Ti consigliamo di leggere questa guida prima di guardare i nostri esempi.
Requisiti dei componenti
Esistono alcune limitazioni da considerare durante l'implementazione dei parchi risorse in base ai componenti GKE Enterprise e Google Cloud sensibili al parco risorse che la tua organizzazione vuole utilizzare. Ad esempio, alcuni componenti potrebbero non supportare ancora l'utilizzo di cluster che non si trovano nel progetto host del parco risorse.
La seguente tabella mostra i requisiti e le limitazioni attuali di ciascun componente. La tabella elenca anche le funzionalità incluse in GKE Enterprise, ma che non sono configurate utilizzando l'API Fleet.
| Componente |
Tipi di cluster |
Requisiti del progetto |
Requisiti VPC |
|---|---|---|---|
| Config Sync | Tutti i cluster supportati da GKE Enterprise | Nessuna | Nessuna |
| Policy Controller | Tutti i cluster supportati da GKE Enterprise | Nessuna | Nessuna |
| Cloud Service Mesh | Vedi Piattaforme supportate | Il cluster deve essere registrato in un parco risorse e tutti i cluster nello stesso progetto devono essere registrati nello stesso parco risorse. Per maggiori informazioni, consulta Requisiti del parco risorse Cloud Service Mesh. | I cluster GKE devono trovarsi nella stessa rete VPC. |
| Ingress multi-cluster e gateway multi-cluster | Cluster GKE su Google Cloud | Le risorse Ingress/gateway, i cluster GKE e il parco risorse devono condividere lo stesso progetto. | Le risorse Ingress/Gateway e i cluster GKE devono trovarsi nella stessa rete VPC. |
| Pool di identità per i carichi di lavoro | Ottimizzato per GKE Enterprise, GKE su Google Cloud e Google Distributed Cloud on VMware. Con GKE Enterprise, sono supportati altri cluster Kubernetes, ma richiedono una configurazione manuale. | Nessuna | Nessuna |
| Autorizzazione binaria | Cluster GKE su Google Cloud, Google Distributed Cloud on VMware, Google Distributed Cloud on bare metal | Nessuna | Nessuna |
| Advanced Vulnerability Insights | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Strategia di sicurezza di GKE | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Strategia di sicurezza di GKE | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Postura di conformità | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Metriche di utilizzo delle risorse del parco risorse | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Logging del parco risorse | Tutti | Nessuna | Nessuna |
| connetti gateway | Tutti | Nessuna | Nessuna |
| Gestione dei team del parco risorse | Tutti | Nessuna | Nessuna |
| Criteri di rete FQDN pod | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Crittografia trasparente tra nodi | Cluster GKE su Google Cloud | Nessuna | Nessuna |
| Config Controller | Non applicabile | Nessuna | Nessuna |
| Sequenza di implementazione | Cluster GKE su Google Cloud | Nessuna | Nessuna |
Organizzazione di progetti e reti VPC per i parchi risorse
Quando crei l'architettura per i parchi risorse, devi tenere in considerazione due risorse fondamentali: i progetti Google Cloud e le reti Virtual Private Cloud (VPC).
Come indicato in Come funzionano i parchi risorse, ogni parco risorse viene creato all'interno di un singolo progetto. Tuttavia, con le limitazioni indicate nella tabella precedente, i parchi risorse sono destinati a funzionare con risorse sensibili al parco risorse del progetto host del parco risorse, di un altro progetto Google Cloud, di altri cloud provider o on-premise.
Anche se non è stato impedito esplicitamente nella maggior parte dei casi, consigliamo anche di aggiungere allo stesso parco risorse dedicate al parco risorse nello stesso progetto; non devono essere suddivise tra parchi risorse diversi. La suddivisione delle risorse dello stesso progetto tra i parchi risorse è considerata un anti-pattern, perché il confine del progetto fornisce una protezione più efficace per scopi di criteri e governance.
Al momento di decidere come collocare risorse sensibili al parco risorse in più progetti, prevediamo che molte organizzazioni avranno requisiti di tenancy diversi. Considera i seguenti due estremi:
- Alcune organizzazioni potrebbero scegliere di collocare tutte le risorse del parco risorse in una manciata di progetti controllati a livello centrale, allocando gli spazi dei nomi ai team.
- Altre organizzazioni potrebbero scegliere di assegnare ai team cluster dedicati all'interno dei propri progetti.
Al primo estremo, è più facile mantenere una governance centralizzata sulle risorse, ma potrebbe richiedere lavoro aggiuntivo per raggiungere l'isolamento desiderato. Al secondo estremo, questi compromessi sono invertiti. In alcuni casi complessi, la tua organizzazione potrebbe avere un mix di risorse di infrastruttura condivise e di risorse dedicate, isolate in progetti separati. Indipendentemente da dove arrivi, come illustrato nella nostra sezione di attendibilità elevata, il mantenimento della fiducia reciproca sulle risorse registrate in un parco risorse è importante per mantenere l'integrità del parco risorse.
Strettamente correlata all'organizzazione del progetto è l'organizzazione di rete. Diversi componenti del parco risorse, come indicato nella tabella dei requisiti dei componenti, richiedono una connettività specifica tra le risorse registrate nel parco risorse. Nel tempo, alcuni di questi requisiti potrebbero essere semplificati; tuttavia, ad esempio, oggi Ingress multi-cluster richiede che i pod siano nella stessa rete VPC, con i cluster stessi nello stesso progetto del parco risorse.
Quando i componenti possono allentare questi requisiti iniziali del progetto e della rete VPC, prevediamo che l'adozione di un modello VPC condiviso diventerà una best practice ogni volta che avrai bisogno di più progetti. In un modello di questo tipo, il parco risorse può essere identificato nel progetto host della rete VPC con risorse registrate dai rispettivi progetti di servizio. Se hai bisogno di più parchi risorse con un VPC condiviso, puoi nominare i progetti come progetto host del parco risorse.
Aggiunta/rimozione di risorse del parco risorse (cluster)
Le risorse esistenti sensibili al parco risorse possono essere aggiunte a un parco risorse, ma è necessario prestare particolare attenzione per garantire che i servizi non vengano interrotti in seguito all'aggiunta. In particolare, è importante garantire che le proprietà di uguaglianza e attendibilità vengano prese in considerazione prima di aggiungere la risorsa al parco risorse. L'amministratore del parco risorse deve prestare particolare attenzione al modo in cui i componenti attivi del parco risorse utilizzano lo stesso utilizzo. Ciò potrebbe richiedere la migrazione a pratiche di denominazione coerenti, la definizione della governance della risorsa o l'esecuzione potenzialmente di altre azioni prima di aggiungere la risorsa al parco risorse.
Anche la rimozione di risorse da un parco risorse richiede un'ulteriore attenzione. Ad esempio, saranno interessate le risorse che fanno attivamente parte di un mesh di servizi o che sono scelte come target come parte di un bilanciatore del carico multi-cluster. Per prepararti alla rimozione della risorsa, ti consigliamo di esaminare ogni componente abilitato nel tuo parco risorse e di adottare le misure necessarie per svuotare il traffico mesh di servizi attivo o il traffico esterno.
Man mano che i parchi risorse si evolvono, forniremo maggiori indicazioni sulla banda per l'aggiunta e la rimozione di risorse del parco risorse.
Abilitazione o riconfigurazione dei componenti del parco risorse
Anche l'abilitazione o la riconfigurazione dei componenti di Google Cloud o GKE Enterprise che utilizzano i parchi risorse richiede un'attenzione particolare. Quando abiliti nuovi componenti, presta attenzione ai potenziali effetti collaterali dell'attivazione del componente su tutti i cluster. Ad esempio, prima di abilitare Cloud Service Mesh, devi comprendere quali endpoint di servizio vengono uniti tra le risorse e assicurati che questo sia il risultato desiderato.
Forniremo ulteriori indicazioni in banda durante la configurazione di componenti abilitati per il parco risorse man mano che sviluppiamo il concetto di parco risorse.
Che cosa succede dopo?
- Per alcuni scenari ipotetici che illustrano le considerazioni descritte in questa guida, vedi Esempi del parco risorse.