Questa guida fornisce best practice, considerazioni pratiche e consigli 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 esaminare 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 non presenti nel progetto host del parco risorse.
La tabella seguente 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 | Nessun valore | Nessun valore |
| Policy Controller | Tutti i cluster supportati da GKE Enterprise | Nessun valore | Nessun valore |
| Anthos Service Mesh | Vedi Piattaforme supportate | Il cluster deve essere registrato in un parco risorse e tutti i cluster che si trovano nello stesso progetto devono essere registrati nello stesso parco risorse. Per maggiori informazioni, consulta i requisiti del parco risorse Anthos Service Mesh. | I cluster GKE devono trovarsi nella stessa rete VPC. |
| Gateway multi-cluster e Ingress 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 Workload Identity | Ottimizzato per GKE Enterprise, GKE su Google Cloud e GKE su VMware. Con GKE Enterprise, sono supportati altri cluster Kubernetes, ma richiedono operazioni di configurazione manuale. | Nessun valore | Nessun valore |
| Autorizzazione binaria | Cluster GKE su Google Cloud, GKE su Bare Metal, GKE su VMware | Nessun valore | Nessun valore |
| Advanced Vulnerability Insights | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Strategia di sicurezza di GKE | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Strategia di sicurezza di GKE | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Postura di conformità | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Metriche di utilizzo delle risorse del parco risorse | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Logging del parco risorse | Tutte | Nessun valore | Nessun valore |
| connetti gateway | Tutte | Nessun valore | Nessun valore |
| Gestione dei team del parco risorse | Tutte | Nessun valore | Nessun valore |
| Criteri di rete del nome di dominio completo dei pod | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Crittografia trasparente tra nodi | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
| Config Controller | Non applicabile | Nessun valore | Nessun valore |
| Sequenza di implementazione | Cluster GKE su Google Cloud | Nessun valore | Nessun valore |
Organizzazione di progetti e reti VPC per i parchi risorse
Quando progetti l'architettura per i parchi risorse, devi prendere 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.
Sebbene non sia evitato esplicitamente nella maggior parte dei casi, consigliamo anche di aggiungere allo stesso parco risorse cloud-aware nello stesso progetto; non devono essere suddivise tra diversi parchi risorse. La suddivisione delle risorse nello stesso progetto tra i parchi risorse è considerata un anti-pattern perché i confini del progetto forniscono protezioni più efficaci per scopi di criteri e governance.
Quando decidi come inserire risorse sensibili al parco risorse in più progetti, prevediamo che molte organizzazioni abbiano 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 centralmente, allocando gli spazi dei nomi ai team.
- Altre organizzazioni potrebbero scegliere di assegnare ai team cluster dedicati all'interno dei progetti dei propri team.
Al primo livello, è più facile mantenere una governance centralizzata delle risorse, ma potrebbe richiedere un lavoro aggiuntivo per raggiungere l'isolamento desiderato. Nel secondo estremo, questi compromessi sono invertiti. In alcuni casi complessi, la tua organizzazione potrebbe avere una combinazione di risorse di infrastruttura condivise e risorse dedicate, isolate in progetti separati. A prescindere da dove giudichi, come illustrato nella nostra sezione Fiducia elevata, mantenere la fiducia reciproca sulle risorse registrate in un parco risorse è importante per mantenere l'integrità del parco risorse.
Strettamente correlato 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 allentati. Tuttavia, ad esempio, oggi Ingress multi-cluster richiede che i pod si trovino nella stessa rete VPC e che i cluster stessi siano 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 istruito 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 designare i progetti come progetto host del parco risorse.
Aggiunta/rimozione delle risorse del parco risorse (cluster)
Le risorse relative al parco risorse esistenti possono essere aggiunte a un parco risorse, ma è necessario prestare particolare attenzione per garantire che i servizi non vengano interrotti a seguito dell'aggiunta. In particolare, è importante assicurarsi che vengano prese in considerazione le proprietà di identità e attendibilità 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 l'identicità. Ciò potrebbe richiedere la migrazione a pratiche di denominazione coerenti, stabilire la governance della risorsa o eseguire potenzialmente altre azioni prima di aggiungere la risorsa al parco risorse.
La rimozione delle risorse da un parco risorse richiede anche un'ulteriore attenzione. Ad esempio, saranno interessate le risorse che fanno parte attivamente di un mesh di servizi o hanno come target 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 del 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 delle risorse del parco risorse.
Abilitazione o riconfigurazione dei componenti del parco risorse
Anche l'abilitazione o la riconfigurazione dei componenti 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'abilitazione del componente su tutti i cluster. Ad esempio, prima di attivare Anthos Service Mesh, scopri quali endpoint di servizio vengono uniti tra le risorse e assicurati che questo sia il risultato desiderato.
Forniremo ulteriori indicazioni sulla banda durante la configurazione dei componenti abilitati per il parco risorse man mano che sviluppiamo il concetto del parco risorse.
Che cosa succede dopo?
- Per alcuni scenari ipotetici che illustrano le considerazioni descritte in questa guida, vedi Esempi del parco risorse.