Controlli della piattaforma per sviluppatori

Questa sezione descrive i controlli utilizzati nella piattaforma per sviluppatori.

Identità, ruoli e gruppi della piattaforma

L'accesso ai servizi Google Cloud richiede identità Google Cloud . Il blueprint utilizza la federazione delle identità per i carichi di lavoro per GKE per mappare i service account Kubernetes utilizzati come identità per i pod ai service accountGoogle Cloud che controllano l'accesso ai servizi Google Cloud. Per contribuire a proteggere dalle riassegnazioni tra ambienti, ogni ambiente ha un pool di identità separato (noto come insieme di provider di identità attendibili) per i suoi account Workload Identity Federation for GKE.

Utenti tipo 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 sviluppatori è responsabile dello sviluppo e della gestione della piattaforma per sviluppatori. I membri di questo team sono:

• Sviluppatori della piattaforma per sviluppatori: questi membri del team estendono il blueprint e lo integrano nei sistemi esistenti. Questo team crea anche nuovi modelli di applicazione.
• Amministratore della piattaforma per sviluppatori:questo team è responsabile di:
  • Approvazione della creazione di nuovi team tenant.
  • Esecuzione di 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.
  • Creazione di piani di capacità a livello di piattaforma.

Un tenant della piattaforma di sviluppo è un singolo team di sviluppo software e le persone responsabili del funzionamento di quel 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 ed esegue il debug del codice dell'applicazione. A volte vengono chiamati anche ingegneri del software o sviluppatori full-stack. Le loro responsabilità includono:
  • Eseguire test e controllo qualità su un componente dell'applicazione quando viene implementato nell'ambiente di sviluppo.
  • Gestione delle risorse cloud di proprietà dell'applicazione (come database e bucket di archiviazione) nell'ambiente di sviluppo.
  • Progettazione di schemi di database o di archiviazione da utilizzare nelle applicazioni.
• Operatori di 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 di applicazioni in produzione. A volte vengono chiamati operatori di servizio, ingegneri di sistema o amministratori di sistema. Le loro responsabilità includono quanto segue:
  • Pianificazione delle 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 del servizio utilizzando log e metriche specifici per l'applicazione.
  • Rispondere ad avvisi e pagine, ad esempio quando un servizio non soddisfa i suoi SLO.
  • Lavorare con un gruppo o più gruppi di sviluppatori di applicazioni.
  • Approvazione del deployment di 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 dell'applicazione aziendale si inseriscono nella struttura del blueprint di base.

Progetti della piattaforma

La seguente tabella 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
common	eab-infra-cicd	Contiene la pipeline dell'infrastruttura multi-tenant per eseguire il deployment dell'infrastruttura tenant.
	eab-app-factory	Contiene la fabbrica di applicazioni , che viene utilizzata per creare l'architettura dell'applicazione single-tenant e pipeline di integrazione continua e deployment continuo (CI/CD). Questo progetto contiene anche Config Sync utilizzato per la configurazione del cluster GKE.
	eab-{tenant}-cicd	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.
development, nonproduction, production	eab-gke	Contiene i cluster GKE per la piattaforma per sviluppatori e la logica utilizzata per registrare i cluster per la gestione del parco risorse.
	eab-{tenant} (1-n)	Contiene tutti i servizi applicativi single-tenant, come database o altri servizi gestiti utilizzati da un team di sviluppo di applicazioni.

Architettura del cluster della piattaforma

Il blueprint esegue il deployment delle applicazioni in tre ambienti: sviluppo, non di produzione e produzione. Ogni ambiente è associato a una flotta. 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 limite 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 il deployment delle applicazioni. I due cluster fungono da cluster GKE identici in due regioni diverse per fornire resilienza multiregionale. Per sfruttare le funzionalità del parco risorse, il blueprint utilizza il concetto di identicità tra oggetti spazio dei nomi, servizi e identità.

Il blueprint dell'applicazione aziendale utilizza cluster GKE con spazi privati abilitati tramite l'accesso Private Service Connect al control plane e pool di nodi privati per rimuovere potenziali superfici di attacco da internet. Né i nodi del cluster né il control plane hanno un endpoint pubblico. I nodi del cluster eseguono Container-Optimized OS per limitare la superficie di attacco e utilizzano nodi GKE schermati per limitare la capacità di un malintenzionato di impersonare un nodo.

L'accesso amministrativo ai cluster GKE è abilitato tramite il gateway Connect. Nell'ambito del deployment del blueprint, per ogni ambiente viene utilizzata un'istanza Cloud NAT per fornire a pod e Config Sync un meccanismo per accedere alle risorse su internet, ad esempio 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à centrale controllato dagli amministratori delle identità.

Componenti della piattaforma GKE Enterprise

La piattaforma per sviluppatori utilizza i componenti di GKE Enterprise per consentirti di creare, distribuire e gestire il ciclo di vita delle tue applicazioni. I componenti di 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 l'attestazione delle immagini container
• GKE Gateway Controller per il controller gateway multicluster per i cluster GKE

Gestione del parco risorse della piattaforma

I parchi risorse ti consentono di gestire più cluster GKE in modo unificato. La gestione dei team nel parco risorse consente agli amministratori della piattaforma di eseguire il provisioning e la gestione delle risorse dell'infrastruttura per i tenant della piattaforma per sviluppatori. I tenant hanno il controllo con ambito delle risorse all'interno del proprio spazio dei nomi, incluse applicazioni, log e 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 membro 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 del 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 il networking, i cluster GKE vengono implementati in un VPC condiviso creato nell'ambito del progetto di fondazione di un'azienda. I cluster GKE richiedono l'assegnazione di più intervalli di indirizzi IP negli ambienti di sviluppo, non di produzione e di produzione. Ogni cluster GKE utilizzato dal blueprint richiede intervalli di indirizzi IP separati allocati per i nodi, i pod, i servizi e il control plane. Le istanze AlloyDB per PostgreSQL richiedono anche intervalli di indirizzi IP separati.

La tabella seguente descrive le subnet VPC e gli intervalli di indirizzi IP utilizzati nei diversi ambienti per il deployment dei cluster blueprint. Per l'ambiente di sviluppo nella regione 2 del cluster GKE dell'applicazione, il blueprint esegue il deployment di un solo spazio di indirizzi IP, anche se è stato allocato spazio di indirizzi IP per due cluster GKE di sviluppo.

Risorsa	Tipo di intervallo di indirizzi IP	Sviluppo	Non di produzione	Produzione
Regione 1 del cluster GKE dell'applicazione	Intervallo di indirizzi IP principali	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 2 del cluster GKE dell'applicazione	Intervallo di indirizzi IP principali	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 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 nel cluster.

Nel blueprint, Cloud DNS è configurato per l'ambito VPC. L'ambito VPC consente ai servizi in tutti i cluster GKE di un progetto di condividere una singola zona DNS. Una singola zona DNS consente di risolvere i servizi nei cluster e le VM o i pod al di fuori del 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 GKE Gateway e firewall GKE Ingress 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 di base dell'impresa ha una regola predefinita per bloccare il traffico nel VPC condiviso.

Accesso alla piattaforma ai servizi Google Cloud

Poiché le applicazioni blueprint utilizzano cluster privati, l'accesso privato Google fornisce l'accesso ai servizi Google Cloud .

Alta disponibilità della piattaforma

Il blueprint è stato progettato per essere resiliente alle interruzioni di zona e regione. Le risorse necessarie per mantenere in esecuzione le applicazioni sono distribuite su due regioni. Selezioni le regioni in cui vuoi eseguire il deployment del blueprint. Le risorse che non si trovano nel percorso critico per la gestione e la risposta al carico si trovano in una sola regione o sono globali. La tabella seguente descrive le risorse e la loro posizione di deployment.

Località	Regione 1	Regione 2	Globale
Ambienti con risorse in questa località	common development nonproduction production	nonproduction production	common development nonproduction production
Progetti con risorse in questa località	eab-gke-{env} eab-infra-cicd eab-{ns}-cicd	eab-gke-{env} eab-{ns}-cicd (only for the Artifact Registry mirror)	eab-gke-{env}
Tipi di risorse in questa località	Cluster GKE (applicazioni e configurazione del gateway) Artifact Registry AlloyDB per PostgreSQL Cloud Build Cloud Deploy	Cluster GKE (solo applicazioni) Artifact Registry AlloyDB per PostgreSQL	Cloud Logging Cloud Monitoring Cloud Load Balancing Ambiti del parco risorse Spazi dei nomi del parco risorse

La seguente tabella riassume il modo in cui i diversi componenti reagiscono a un'interruzione a livello di regione o di zona e come puoi mitigare questi effetti.

Ambito dell'errore	Effetti dei servizi esterni	Effetti del database	Creare ed eseguire il deployment degli effetti	Effetti delle pipeline Terraform
Una zona della regione 1	Disponibile.	Disponibile. L'istanza di standby diventa attiva con RPO pari a zero.	Disponibile, potrebbe essere necessaria una modifica manuale. Potresti dover riavviare qualsiasi comando terraform apply in corso, ma completato durante l'interruzione.	Disponibile, potrebbe essere necessaria una modifica manuale. Potresti dover riavviare qualsiasi comando terraform apply in corso, ma completato durante l'interruzione.
Una zona della regione 2	Disponibile.	Disponibile.	Disponibile.	Disponibile, potrebbe essere necessaria una modifica manuale. Potresti dover riavviare qualsiasi comando terraform apply in corso, ma completato durante l'interruzione.
Regione 1	Disponibile.	È necessaria una modifica manuale. Un operatore deve promuovere il cluster secondario manualmente.	Non disponibile.	Non disponibile.
Regione 2	Disponibile.	Disponibile.	Disponibile, potrebbe essere necessaria una modifica manuale Le build rimangono disponibili. Potresti dover eseguire il deployment manualmente di nuove build. Le build esistenti potrebbero non essere completate correttamente.	Disponibile.

Le interruzioni del provider di servizi cloud sono solo una delle cause di inattività. 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 motivi di queste decisioni.

Decisione relativa al progetto base	Impatto sulla disponibilità
Gestione dei cambiamenti
Utilizza GitOps e IaC.	Supporta la revisione tra pari delle modifiche e il ripristino rapido delle configurazioni precedenti.
Promuovi le modifiche gradualmente negli ambienti.	Riduce l'impatto degli errori di software e configurazione.
Rendi simili gli ambienti non di produzione e di produzione.	Garantisce che le differenze non ritardino il rilevamento di un errore. Entrambi gli ambienti sono a due regioni.
Modifica le risorse replicate una regione alla volta all'interno di un ambiente.	Garantisce che i problemi non rilevati dalla promozione graduale influiscano solo sulla metà dell'infrastruttura di runtime.
Modifica un servizio in una regione alla volta all'interno di un ambiente.	Assicura che i problemi non rilevati dalla promozione graduale influiscano solo su metà delle repliche del servizio.
Infrastruttura di calcolo replicata
Utilizza un control plane del cluster regionale.	Il control plane regionale è disponibile durante l'upgrade e il ridimensionamento.
Crea un pool di nodi multizona.	Un pool di nodi del cluster ha almeno tre nodi distribuiti su tre zone.
Configura una rete VPC condiviso.	La rete VPC condivisa copre due regioni. Un errore regionale influisce solo sul traffico di rete da e verso le risorse nella regione in errore.
Replica il registro delle immagini.	Le immagini vengono archiviate in Artifact Registry, configurato per la replica in più regioni, in modo che un'interruzione della regione cloud non impedisca lo scale up dell'applicazione nella regione sopravvissuta.
Servizi replicati
Esegui il deployment delle repliche del servizio in due regioni.	In caso di interruzione 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 di aggiornamento in sequenza che riduce il rischio 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 in sequenza nell'ambiente di produzione e non di produzione.
Distribuisci i pod del deployment in più zone.	I servizi Kubernetes sono distribuiti tra le VM in zone diverse utilizzando una stanza anti-affinità. È possibile tollerare l'interruzione di un singolo nodo o l'interruzione completa di una zona senza incorrere in 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 dell'istanza primaria si trovano in due zone diverse della regione. L'istanza primaria mantiene la disponibilità regionale 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 di emergenza. Il database replica in modo asincrono i dati del cluster primario nei cluster secondari che si trovano 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 regionale), la parte del servizio in esecuzione nel cluster rimanente può assorbire completamente il carico.
Ripara automaticamente i nodi.	I cluster sono configurati con la riparazione automatica dei nodi. Se i controlli di integrità consecutivi di un nodo non riescono ripetutamente per un periodo di tempo prolungato, GKE avvia un processo di riparazione per quel nodo.
Assicurati che gli upgrade dei pool di nodi siano consapevoli dell'applicazione.	I deployment definiscono un budget di interruzione dei pod con maxUnavailable: 1 per consentire upgrade pool di nodi pool nei cluster di grandi dimensioni. Non più di una delle tre repliche (nell'ambiente di sviluppo) o una delle sei (negli ambienti non di produzione e di produzione) non sono disponibili durante gli upgrade del pool di nodi.
Riavvia automaticamente i servizi in deadlock.	Il deployment che supporta un servizio definisce un probe di attività, che identifica e riavvia i processi in deadlock.
Controlla automaticamente che le repliche siano pronte.	Il deployment che supporta un servizio definisce un probe di idoneità, che identifica quando un'applicazione è pronta per essere utilizzata dopo l'avvio. Un probe di idoneità elimina la necessità di controlli manuali o attese temporizzate durante gli aggiornamenti in sequenza e gli upgrade del pool di nodi.

L'architettura di riferimento è progettata per applicazioni con requisiti di alta disponibilità a livello di zona e regione. Garantire l'alta disponibilità comporta alcuni costi (ad esempio, costi di ricambio in standby o costi 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, il rendimento e lo scaling 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 di progetto aggiuntiva prima del deployment e prima di aggiungere altri tenant.
• È previsto un limite di 100 risorse MultiClusterGateway per progetto. Ogni servizio Kubernetes accessibile da internet sulla piattaforma per sviluppatori richiede un MultiClusterGateway.
• Cloud Logging prevede 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 Scope e Scope Namespace. Per istruzioni sulla visualizzazione delle quote, vedi Visualizza e gestisci le quote. Utilizza un filtro per trovare i tipi di quota gkehub.googleapis.com/global-per-project-scopes e gkehub.googleapis.com/global-per-project-scope-namespaces.

Passaggi successivi

• Scopri di più sull'architettura dei servizi (il documento successivo di questa serie).