Questa guida fornisce best practice, considerazioni pratiche e e suggerimenti per l'implementazione dei parchi risorse nella tua organizzazione.
Prima di leggere questa guida, dovresti conoscere i concetti trattati in Come funzionano i parchi risorse. I nostri suggerimenti leggere questa guida prima di esaminare il nostro esempi.
Requisiti dei componenti
Ci sono alcune limitazioni da considerare quando implementi i parchi risorse sui componenti GKE Enterprise e Google Cloud consapevoli del parco risorse che l'organizzazione vuole usare. Ad esempio, alcuni componenti potrebbero non supportare ancora lavorare con cluster che non fanno parte del 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 | Nessuno | Nessuno |
| Policy Controller | Tutti i cluster supportati da GKE Enterprise | Nessuno | Nessuno |
| 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 ulteriori informazioni, vedi 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 sulla 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, altri servizi Kubernetes sono supportati, ma richiedono una configurazione manuale. | Nessuno | Nessuno |
| Autorizzazione binaria | cluster GKE su Google Cloud, Google Distributed Cloud on VMware, Google Distributed Cloud on bare metal | Nessuno | Nessuno |
| Advanced Vulnerability Insights | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Strategia di sicurezza di GKE | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Strategia di sicurezza di GKE | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Postura di conformità | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Metriche di utilizzo delle risorse del parco risorse | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Logging del parco risorse | Tutti | Nessuno | Nessuno |
| connetti gateway | Tutti | Nessuno | Nessuno |
| Gestione dei team del parco risorse | Tutti | Nessuno | Nessuno |
| Criteri di rete FQDN pod | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Crittografia trasparente tra nodi | Cluster GKE su Google Cloud | Nessuno | Nessuno |
| Config Controller | Non applicabile | Nessuno | Nessuno |
| Sequenza di implementazione | Cluster GKE su Google Cloud | Nessuno | Nessuno |
Organizzazione di progetti e reti VPC per i parchi risorse
Al momento di progettare l'architettura per i parchi risorse, devi considerare due risorse fondamentali: Progetti Google Cloud e 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 limiti indicati nella tabella precedente), i parchi risorse sono pensati per lavorare risorse sensibili al parco risorse dal progetto host del parco risorse, da un altro progetto Google Cloud da altri cloud provider o on-premise.
Sebbene non impedisca esplicitamente la maggior parte dei casi, raccomandiamo anche di utilizzare le risorse sensibili al parco risorse nello stesso progetto verranno aggiunti allo stesso parco risorse. non dovrebbero esserlo divisi tra flotte diverse. Suddivisione delle risorse nello stesso progetto tra parchi risorse è considerato un anti-pattern perché il confine del progetto fornisce protezioni più forti ai fini delle politiche e della governance.
Al momento di decidere come collocare risorse sensibili al parco risorse in più progetti, anticipare 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 a progetti controllati centralmente, allocando spazi dei nomi ai team.
- Altre organizzazioni potrebbero scegliere di assegnare ai team cluster dedicati all'interno progetti personalizzati.
Al primo estremo, risulta più facile mantenere una governance centralizzata ma potrebbe richiedere ulteriori operazioni per raggiungere l'isolamento desiderato. Al secondo estremo, questi compromessi sono invertiti. In alcuni casi complessi, di un'organizzazione potrebbe utilizzare sia risorse di infrastruttura condivise e quelli dedicati, isolati in progetti separati. Non importa dove andrai a finire, dato che di cui parleremo nel nostro Sezione Affidabilità 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. Varie flotta come indicato nella tabella dei requisiti dei componenti, richiedono connettività tra le risorse registrate nel parco risorse. Nel tempo, alcune questi requisiti potrebbero essere più flessibili; tuttavia, ad esempio, oggi Ingress multi-cluster richiede che i pod siano nella stessa rete VPC, nello stesso progetto del parco risorse.
Quando i componenti possono allentare il progetto iniziale e la rete VPC requisiti, prevediamo che l'adozione di Il modello VPC condiviso diventerà una best practice ogni volta che hai bisogno di più progetti. In questo modello, il parco risorse può essere creata un'istanza nel progetto host della rete VPC con risorse registrati dai rispettivi progetti di servizio. Se hai bisogno di più parchi risorse con un VPC condiviso, puoi nominare i progetti come parco risorse progetto host.
Aggiunta/rimozione di risorse del parco risorse (cluster)
Le risorse esistenti sensibili al parco risorse possono essere aggiunte a un parco risorse, ma con molta attenzione per garantire che i servizi non subiscano interruzioni in seguito alla aggiunto. In particolare, è importante garantire che la uguaglianza e la fiducia vengono prese in considerazione prima di aggiungere la risorsa al parco risorse. Il parco risorse amministratore deve prestare particolare attenzione all'utilizzo dei componenti attivi del parco risorse somiglianza. Potrebbe essere necessario eseguire 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.
Anche la rimozione di risorse da un parco risorse richiede un'ulteriore attenzione. Per Ad esempio, le risorse che fanno attivamente parte di un mesh di servizi o sono scelte come target di un bilanciatore del carico multi-cluster. Per prepararti alla rimozione risorsa, ti consigliamo di esaminare ogni componente che hai abilitato nel tuo parco risorse e adottando le misure necessarie per svuotare il traffico mesh di servizi attivi o per il traffico esterno.
Man mano che i parchi risorse si evolvono, forniremo più indicazioni in banda quando aggiungi e rimuovendo le risorse del parco risorse.
Abilitazione o riconfigurazione dei componenti del parco risorse
Abilitazione o riconfigurazione dei componenti di Google Cloud o GKE Enterprise che utilizzano flotte richiede anche una certa attenzione. Quando attivi nuovi componenti, paga ai potenziali effetti collaterali dell'attivazione del componente su tutte cluster. Ad esempio, prima di abilitare Cloud Service Mesh, devi capire quale servizio vengano uniti tra le risorse, e assicurarsi che sia il o il risultato finale.
Forniremo ulteriori indicazioni sulla banda durante la configurazione di un parco risorse abilitato per lo sviluppo del concetto di parco risorse.
Passaggi successivi
- Per alcuni scenari ipotetici che illustrano le considerazioni descritte di questa guida, vedi Esempi del parco risorse.