Questa sezione descrive i controlli utilizzati nella piattaforma per gli sviluppatori.
Identità, ruoli e gruppi della piattaforma
L'accesso ai Google Cloud servizi richiede Google Cloud identità. Il blueprint utilizza la federazione delle identità per i carichi di lavoro del parco per GKE per mappare gli account di servizio Kubernetes utilizzati come identità per i pod agliGoogle Cloud account di servizio che controllano l'accesso ai Google Cloudservizi. Per proteggerti dalle riassegnazioni tra ambienti, ogni ambiente ha un pool di identità separato (noto come insieme di provider di identità attendibili) per i propri account Workload Identity Federation for GKE.
Profili della piattaforma
Quando esegui il deployment del blueprint, crei tre tipi di gruppi di utenti: un team della piattaforma per sviluppatori, un team dell'applicazione (un team per applicazione) e un team di operazioni di sicurezza.
Il team della piattaforma per gli sviluppatori è responsabile dello sviluppo e della gestione della piattaforma per gli sviluppatori. I membri di questo team sono:
- Sviluppatori di piattaforme per sviluppatori:questi membri del team estendono il blueprint e lo integrano nei sistemi esistenti. Questo team crea anche nuovi modelli di applicazioni.
- Amministratore della piattaforma per sviluppatori: questo team è responsabile di quanto segue:
- Approvazione della creazione di nuovi team di tenant.
- Eseguire attività pianificate e non pianificate che interessano più tenant, tra cui:
- Approvazione della promozione delle applicazioni nell'ambiente non di produzione e nell'ambiente di produzione.
- Coordinamento degli aggiornamenti dell'infrastruttura.
- Creare piani di capacità a livello di piattaforma.
Un tenant della piattaforma per sviluppatori è un singolo team di sviluppo software e gli incaricati del funzionamento del software. Il team del tenant è composto da due gruppi: sviluppatori di applicazioni e operatori di applicazioni. I compiti dei due gruppi del team del tenant sono i seguenti:
- Sviluppatori di applicazioni:questo team scrive e esegue il debug del codice dell'applicazione. A volte vengono anche chiamati software engineer o sviluppatori full-stack. Le loro responsabilità includono quanto segue:
- Eseguire test e controllo qualità su un componente dell'applicazione quando viene eseguito il deployment nell'ambiente di sviluppo.
- Gestione delle risorse cloud di proprietà dell'applicazione (ad esempio database e bucket di archiviazione) nell'ambiente di sviluppo.
- Progettazione di schemi di database o di archiviazione da utilizzare dalle applicazioni.
- Operatori delle applicazioni o SRE (Site Reliability Engineer): questo team gestisce l'affidabilità delle applicazioni in esecuzione negli ambienti di produzione e l'avanzamento sicuro delle modifiche apportate dagli sviluppatori delle applicazioni in produzione. A volte vengono chiamati operatori di servizi,
sistemisti o amministratori di sistema. Le loro responsabilità includono quanto segue:
- Pianificare le esigenze di capacità a livello di applicazione.
- Creazione di criteri di avviso e impostazione di obiettivi del livello di servizio (SLO) per i servizi.
- Diagnostica dei problemi di servizio utilizzando log e metriche specifici per l'applicazione.
- Rispondere ad avvisi e pagine, ad esempio quando un servizio non soddisfa i suoi SLO.
- Collaborazione con un gruppo o più gruppi di sviluppatori di applicazioni.
- Approvazione del deployment delle nuove versioni in produzione.
- Gestione delle risorse cloud di proprietà dell'applicazione negli ambienti di produzione e non di produzione (ad esempio, backup e aggiornamenti dello schema).
Struttura organizzativa della piattaforma
Il progetto dell'applicazione aziendale utilizza la struttura dell'organizzazione fornita dal progetto della piattaforma aziendale. Il seguente diagramma mostra come i progetti di blueprint delle applicazioni aziendali si inseriscono nella struttura del blueprint di base.
Progetti della piattaforma
La tabella seguente descrive i progetti aggiuntivi, oltre a quelli forniti dal blueprint di base, di cui il blueprint dell'applicazione ha bisogno per il deployment di risorse, configurazioni e applicazioni.
| Cartella | Progetto | Descrizione |
|---|---|---|
|
|
Contiene la pipeline dell'infrastruttura multi-tenant per il deployment dell'infrastruttura del tenant. |
|
Contiene la factory di applicazioni , che viene utilizzata per creare l'architettura delle applicazioni monotenant e le pipeline di integrazione e deployment continui (CI/CD). Questo progetto contiene anche Config Sync, che viene utilizzato per la configurazione del cluster GKE. |
|
|
Contiene le pipeline CI/CD dell'applicazione, che si trovano in progetti indipendenti per consentire la separazione tra i team di sviluppo. Esiste una pipeline per ogni applicazione. |
|
|
|
Contiene i cluster GKE per la piattaforma per sviluppatori e la logica impiegata per registrare i cluster per la gestione del parco risorse. |
( |
Contiene tutti i servizi di applicazioni monoutente, come database o altri servizi gestiti, utilizzati da un team di applicazioni. |
Architettura del cluster della piattaforma
Il blueprint esegue il deployment delle applicazioni in tre ambienti: sviluppo, non di produzione e di produzione. Ogni ambiente è associato a un parco. In questo blueprint, un parco risorse è un progetto che include uno o più cluster. Tuttavia, i parchi risorse possono anche raggruppare più progetti. Un parco risorse fornisce un confine di sicurezza logico per il controllo amministrativo. Un parco risorse fornisce un modo per raggruppare e normalizzare logicamente i cluster Kubernetes e semplifica l'amministrazione dell'infrastruttura.
Il seguente diagramma mostra due cluster GKE, creati in ogni ambiente per eseguire il deployment delle applicazioni. I due cluster si comportano come cluster GKE identici in due diverse regioni per garantire la resilienza su più regioni. Per beneficiare delle funzionalità del parco risorse, il blueprint utilizza il concetto di identicità tra oggetti, servizi e identità dello spazio dei nomi.
Il blueprint dell'applicazione aziendale utilizza i cluster GKE con spazi privati abilitati tramite l'accesso Private Service Connect al piano di controllo e i pool di nodi privati per rimuovere potenziali superfici di attacco da internet. Né i nodi del cluster né il piano di controllo hanno un endpoint pubblico. I nodi del cluster eseguono un sistema operativo ottimizzato per i container per limitare la loro superficie di attacco e utilizzano i nodi GKE protetti per limitare la capacità di un malintenzionato di rubare l'identità di un nodo.
L'accesso amministrativo ai cluster GKE è abilitato tramite il gateway Connect. Nell'ambito del deployment del blueprint, viene utilizzata un'istanza Cloud NAT per ogni ambiente per fornire ai pod e a Config Sync un meccanismo per accedere alle risorse su internet, come GitHub. L'accesso ai cluster GKE è controllato dall'autorizzazione RBAC di Kubernetes basata su Google Gruppi per GKE. I gruppi ti consentono di controllare le identità utilizzando un sistema di gestione delle identità centralizzato controllato dagli amministratori delle identità.
Componenti della piattaforma GKE Enterprise
La piattaforma per sviluppatori utilizza i componenti di GKE Enterprise per consentirti di creare, pubblicare e gestire il ciclo di vita delle tue applicazioni. I componenti GKE Enterprise utilizzati nel deployment del blueprint sono i seguenti:
- GKE per la gestione dei container
- Policy Controller per la gestione e l'applicazione dei criteri
- Cloud Service Mesh per la gestione dei servizi
- Autorizzazione binaria per la verifica delle immagini container
- GKE Gateway Controller per il controller gateway multi-cluster per i cluster GKE
Gestione del parco risorse della piattaforma
I parchi risorse ti consentono di gestire più cluster GKE in un unico modo unificato. La gestione dei team nel parco risorse consente agli amministratori della piattaforma di eseguire più facilmente il provisioning e la gestione delle risorse di infrastruttura per gli utenti della piattaforma per sviluppatori. Gli utenti hanno il controllo con ambito delle risorse all'interno del proprio spazio dei nomi, incluse le applicazioni, i log e le metriche.
Per eseguire il provisioning di sottoinsiemi di risorse del parco risorse in base al team, gli amministratori possono utilizzare gli ambiti dei team. Gli ambiti dei team consentono di definire sottoinsiemi di risorse del parco risorse per ogni team, con ogni ambito del team associato a uno o più cluster di membri del parco risorse.
Gli spazi dei nomi del parco risorse consentono di controllare chi ha accesso a spazi dei nomi specifici all'interno del parco risorse. L'applicazione utilizza due cluster GKE di cui è stato eseguito il deployment su un parco risorse, con tre ambiti di team e ogni ambito con uno spazio dei nomi del parco risorse.
Il seguente diagramma mostra le risorse del parco risorse e dell'ambito che corrispondono ai cluster di esempio in un ambiente, come implementato dal blueprint.
Networking della piattaforma
Per la rete, i cluster GKE vengono di solito implementati in una VPC condivisa creata nell'ambito del progetto di fondazione dell'azienda. I cluster GKE richiedono di assegnare più intervalli di indirizzi IP negli ambienti di sviluppo, non di produzione e di produzione. Ogni cluster GKE utilizzato dal blueprint necessita di intervalli di indirizzi IP separati allocati per i nodi, i pod, i servizi e il piano di controllo. Le istanze AlloyDB per PostgreSQL richiedono anche intervalli di indirizzi IP distinti.
La tabella seguente descrive le subnet VPC e gli intervalli di indirizzi IP utilizzati nei diversi ambienti per eseguire il deployment dei cluster di blueprint. Per l'ambiente di sviluppo nella regione del cluster GKE dell'applicazione 2, il blueprint esegue il deployment di un solo spazio indirizzi IP, anche se è allocato uno spazio indirizzi IP per due cluster GKE di sviluppo.
| Risorsa | Tipo di intervallo di indirizzi IP | Sviluppo | Non di produzione | Produzione |
|---|---|---|---|---|
Regione del cluster GKE dell'applicazione 1 |
Intervallo di indirizzi IP principale |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Intervallo di indirizzi IP pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Intervallo di indirizzi IP di servizio |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
Intervallo di indirizzi IP del control plane GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
Regione del cluster GKE dell'applicazione 2 |
Intervallo di indirizzi IP principale |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Intervallo di indirizzi IP pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Intervallo di indirizzi IP di servizio |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
Intervallo di indirizzi IP del control plane GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB per PostgreSQL |
Intervallo di indirizzi IP del database |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
Se devi progettare il tuo schema di allocazione degli indirizzi IP, consulta la sezione Gestione degli indirizzi IP in GKE e Pianificazione degli indirizzi IPv4 di GKE.
DNS della piattaforma
Il blueprint utilizza Cloud DNS per GKE per fornire la risoluzione DNS per i pod e i servizi Kubernetes. Cloud DNS per GKE è un DNS gestito che non richiede un provider DNS ospitato in un cluster.
Nel blueprint, Cloud DNS è configurato per l'ambito VPC. L'ambito VPC consente ai servizi di tutti i cluster GKE di un progetto di condividere una singola zona DNS. Una singola zona DNS consente di risolvere i servizi in più cluster e le VM o i pod esterni al cluster possono risolvere i servizi all'interno del cluster.
Firewall della piattaforma
GKE crea automaticamente regole firewall durante la creazione di cluster GKE, servizi GKE, firewall gateway GKE e firewall di ingresso GKE che consentono ai cluster di operare nei tuoi ambienti. La priorità di tutte le regole firewall create automaticamente è 1000. Queste regole sono necessarie perché il blueprint della base dell'azienda ha una regola predefinita per bloccare il traffico nella VPC condivisa.
Accesso della piattaforma ai servizi Google Cloud
Poiché le applicazioni di blueprint utilizzano cluster privati, Accesso privato Google fornisce l'accesso ai servizi Google Cloud .
Alta disponibilità della piattaforma
Il progetto è stato progettato per essere resiliente alle interruzioni sia delle zone che delle regioni. Le risorse necessarie per mantenere in esecuzione le applicazioni sono distribuite su due regioni. Seleziona le regioni in cui vuoi eseguire il deployment del blueprint. Le risorse che non fanno parte del percorso critico per la pubblicazione e la risposta al carico si trovano in una sola regione o sono globali. La tabella seguente descrive le risorse e dove vengono eseguite.
Località |
Regione 1 |
Regione 2 |
Globale |
|---|---|---|---|
Ambienti con risorse in questa posizione |
|
|
|
Progetti con risorse in questa località |
|
|
|
Tipi di risorse in questa località |
|
|
|
La seguente tabella riassume in che modo i diversi componenti reagiscono a un'interruzione di servizio in una regione o in una zona e come puoi mitigare questi effetti.
Ambito dell'errore |
Effetti dei servizi esterni |
Effetti del database | Crea ed esegui il deployment degli effetti | Effetti delle pipeline Terraform |
|---|---|---|---|---|
Una zona della Regione 1 |
Disponibile. |
Disponibile. L'istanza di standby diventa attiva con un RPO pari a zero. |
Disponibile, potrebbe essere necessaria una modifica manuale. Potresti dover riavviare qualsiasi
|
Disponibile, potrebbe essere necessaria una modifica manuale. Potresti dover riavviare qualsiasi
|
Una zona della Regione 2 |
Disponibile. |
Disponibile. |
Disponibile. |
Disponibile, potrebbe essere necessaria una modifica manuale. Potresti dover riavviare qualsiasi
|
Regione 1 |
Disponibile. |
È necessaria una modifica manuale. Un operatore deve promuovere manualmente il cluster secondario. |
Non disponibile. |
Non disponibile. |
Regione 2 |
Disponibile. |
Disponibile. |
Disponibile, potrebbe essere necessaria una modifica manuale Le build rimangono disponibili. Potresti dover eseguire il deployment delle nuove build manualmente. Le build esistenti potrebbero non essere completate correttamente. |
Disponibile. |
Le interruzioni del servizio del provider cloud sono solo una delle cause di downtime. L'alta disponibilità dipende anche da processi e operazioni che contribuiscono a ridurre la probabilità di errori. La tabella seguente descrive tutte le decisioni prese nel blueprint relative all'alta disponibilità e i relativi motivi.
| Decisione relativa al progetto base | Impatto sulla disponibilità |
|---|---|
Gestione dei cambiamenti |
|
Utilizza GitOps e IaC. |
Supporta la revisione tra pari delle modifiche e consente di ripristinare rapidamente le configurazioni precedenti. |
Apporta le modifiche gradualmente negli ambienti. |
Riduce l'impatto degli errori di software e configurazione. |
Rendi simili gli ambienti di produzione e non di produzione. |
Garantisce che le differenze non ritardino il rilevamento di un errore. Entrambi gli ambienti sono a due regioni. |
Modificare le risorse replicate una regione alla volta all'interno di un ambiente. |
Garantisce che i problemi non rilevati dalla promozione graduale riguardino solo la metà dell'infrastruttura di runtime. |
Modificare un servizio in una regione alla volta all'interno di un ambiente. |
Garantisce che i problemi non rilevati dalla promozione graduale riguardino solo la metà delle repliche del servizio. |
Infrastruttura di calcolo replicata |
|
Utilizza un control plane del cluster a livello di regione. |
Il control plane regionale è disponibile durante l'upgrade e il ridimensionamento. |
Crea un node pool multizonale. |
Un node pool di cluster ha almeno tre nodi distribuiti su tre zone. |
Configura una rete VPC condivisa. |
La rete VPC condivisa copre due regioni. Un errore regionale influisce solo sul traffico di rete verso e dalle risorse nella regione in cui si verifica l'errore. |
Replica il registry delle immagini. |
Le immagini vengono archiviate in Artifact Registry, che è configurato per eseguire la replica in più regioni in modo che un'interruzione della regione cloud non impedisca lo scaling up dell'applicazione nella regione sopravvissuta. |
Servizi replicati |
|
Esegui il deployment delle repliche del servizio in due regioni. |
In caso di interruzione del servizio a livello regionale, un servizio Kubernetes rimane disponibile negli ambienti di produzione e non di produzione. |
Utilizza gli aggiornamenti in sequenza per le modifiche ai servizi all'interno di una regione. |
Puoi aggiornare i servizi Kubernetes utilizzando un pattern di deployment con aggiornamento in sequenza che riduce i rischi e i tempi di inattività. |
Configura tre repliche in una regione per ogni servizio. |
Un servizio Kubernetes ha almeno tre repliche (pod) per supportare gli aggiornamenti graduali nell'ambiente di produzione e non di produzione. |
Distribuisci i pod del deployment in più zone. |
I servizi Kubernetes sono distribuiti su VM in zone diverse utilizzando una stanza anti-affinità. È possibile tollerare un'interruzione di un singolo nodo o un'interruzione completa della zona senza generare traffico cross-region aggiuntivo tra i servizi dipendenti. |
Archiviazione replicata |
|
Esegui il deployment di istanze di database multizona. |
AlloyDB per PostgreSQL offre alta disponibilità in una regione. I nodi ridondanti della sua istanza principale si trovano in due zone diverse della regione. L'istanza principale mantiene la disponibilità a livello di regione attivando un failover automatico nella zona di standby se la zona attiva riscontra un problema. L'archiviazione regionale contribuisce a garantire la durabilità dei dati in caso di perdita di una singola zona. |
Replica i database tra regioni. |
AlloyDB per PostgreSQL utilizza la replica tra regioni per fornire funzionalità di recupero calamitoso. Il database replica in modo asincrono i dati del cluster primario in cluster secondari situati in regioniGoogle Cloud separate. |
Operazioni |
|
Esegui il provisioning delle applicazioni per il doppio del carico previsto. |
Se un cluster non funziona (ad esempio a causa di un'interruzione del servizio a livello regionale), la parte del servizio in esecuzione nel cluster rimanente può assorbire completamente il carico. |
Riparazione automatica dei nodi. |
I cluster sono configurati con la riparazione automatica dei nodi. Se i controlli di integrità consecutivi di un nodo non superano ripetutamente un periodo di tempo prolungato, GKE avvia un processo di riparazione per quel nodo. |
Assicurati che gli upgrade dei pool di nodi siano sensibili alle applicazioni. |
I deployment definiscono un budget di interruzione dei pod con |
Riavviare automaticamente i servizi in stato di deadlock. |
Il deployment alla base di un servizio definisce un probe di attività, che identifica e riavvia i processi in stato di deadlock. |
Verifica automaticamente che le repliche siano pronte. |
Il deployment alla base di un servizio definisce un probe di idoneità, che identifica quando un'applicazione è pronta per essere pubblicata dopo l'avvio. Un controllo di idoneità elimina la necessità di controlli manuali o attese temporizzate durante gli aggiornamenti incrementali e gli upgrade dei pool di nodi. |
L'architettura di riferimento è progettata per le applicazioni con requisiti di alta disponibilità a livello di zona e di regione. L'alta disponibilità comporta alcuni costi, ad esempio i costi di parti di ricambio di riserva o di replica tra regioni. La sezione Alternative descrive alcuni modi per ridurre questi costi.
Quote della piattaforma, limiti di prestazioni e limiti di scalabilità
Puoi controllare le quote, le prestazioni e il ridimensionamento delle risorse nella piattaforma per sviluppatori. Il seguente elenco descrive alcuni elementi da prendere in considerazione:
- L'infrastruttura di base richiede numerosi progetti e ogni tenant aggiuntivo richiede quattro progetti. Potresti dover richiedere una quota del progetto aggiuntiva prima di eseguire il deployment e di aggiungere altri tenant.
- È previsto un limite di 100 risorse MultiClusterGateway per ogni progetto. Ogni servizio Kubernetes rivolto a internet sulla piattaforma per sviluppatori richiede un MultiClusterGateway.
- Cloud Logging ha un limite di 100 bucket in un progetto. L'accesso ai log per tenant nel blueprint si basa su un bucket per ogni tenant.
- Per creare più di 20 tenant, puoi richiedere un aumento della quota del progetto per le risorse Ambito e Spazio dei nomi ambito. Per istruzioni su come visualizzare le quote, consulta Visualizzare e gestire le quote. Utilizza un filtro per trovare i tipi di quota
gkehub.googleapis.com/global-per-project-scopesegkehub.googleapis.com/global-per-project-scope-namespaces.
Passaggi successivi
- Scopri di più sull'architettura di servizio (documento successivo di questa serie).