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 progetto utilizza Fleet Workload Identity per mappare gli account di servizio Kubernetes utilizzati come identità per i pod agli account di servizio Google Cloud che controllano l'accesso ai servizi Google Cloud. Per contribuire a proteggerti dalle escalation cross-environment, ogni ambiente ha un pool di identità separato (noto come insieme di provider di identità attendibili) per i propri account Workload Identity.
Utente tipo della piattaforma
Quando esegui il deployment del progetto base, crei tre tipi di gruppi di utenti: un team della piattaforma di sviluppo, un team delle applicazioni (un team per applicazione) e un team delle operazioni di sicurezza.
Il team della piattaforma per sviluppatori è responsabile dello sviluppo e della gestione della piattaforma. I membri di questo team sono i seguenti:
- Sviluppatori di piattaforme per sviluppatori: questi membri del team estendono il progetto base e lo integrano nei sistemi esistenti. Il team crea anche nuovi modelli di applicazione.
- Amministratore della piattaforma per sviluppatori. Questo team è responsabile di quanto segue:
- Approvazione della creazione di team di nuovi tenant.
- Esecuzione di attività pianificate e non pianificate che interessano più tenant, tra cui:
- Approvazione della promozione di applicazioni nell'ambiente non di produzione e nell'ambiente di produzione.
- Coordinare gli aggiornamenti dell'infrastruttura.
- Creare piani di capacità a livello di piattaforma.
Un tenant della piattaforma per sviluppatori è un unico team di sviluppo software e i responsabili del funzionamento di quel software. Il team tenant è costituito da due gruppi: sviluppatori di applicazioni e operatori di applicazioni. I compiti dei due gruppi del team tenant sono i seguenti:
- Sviluppatori di applicazioni: questo team scrive ed esegue il debug del codice dell'applicazione. A volte sono anche denominati ingegneri del software o sviluppatori full-stack. Le loro responsabilità includono:
- Esecuzione di test e controllo di qualità su un componente dell'applicazione quando ne viene eseguito il deployment nell'ambiente di sviluppo.
- Gestione di risorse cloud di proprietà dell'applicazione (come database e bucket di archiviazione) nell'ambiente di sviluppo.
- Progettazione di schemi di database o archiviazione per l'utilizzo da parte delle 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 alla produzione. Sono chiamati a volte operatori di servizio, tecnici di sistema o amministratori di sistema. Tra le loro responsabilità figurano:
- Pianificazione delle esigenze di capacità a livello di applicazione.
- Creazione di criteri di avviso e impostazione degli obiettivi del livello di servizio (SLO) per i servizi.
- Diagnostica dei problemi del servizio mediante l'utilizzo di log e metriche specifici dell'applicazione.
- Rispondere ad avvisi e pagine, ad esempio quando un servizio non soddisfa i suoi SLO.
- Collaborazione con uno o più gruppi di sviluppatori di applicazioni.
- Approvazione del deployment di nuove versioni in produzione.
- Gestione di risorse cloud di proprietà dell'applicazione in ambienti non di produzione e di produzione (ad esempio, backup e aggiornamenti dello schema).
Struttura organizzativa della piattaforma
Il progetto di base dell'applicazione aziendale utilizza la struttura organizzativa fornita dal progetto di base dell'azienda. Il seguente diagramma mostra in che modo i progetti del progetto base per le applicazioni aziendali si adattano alla struttura del progetto di base.
Progetti della piattaforma
La seguente tabella descrive i progetti aggiuntivi, oltre a quelli forniti dal progetto di base, di cui il progetto di base ha bisogno per eseguire il deployment di risorse, configurazioni e applicazioni.
| Cartella | Progetto | Descrizione |
|---|---|---|
|
|
Contiene la pipeline di infrastruttura multi-tenant per il deployment dell'infrastruttura tenant. |
|
Contiene la fabbrica di applicazioni , utilizzata per creare un'architettura delle applicazioni single-tenant e pipeline di integrazione continua e deployment continuo (CI/CD). Questo progetto contiene anche la risorsa Config Sync utilizzata 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 utilizzata per registrare i cluster per la gestione del parco risorse. |
( |
Contiene tutti i servizi per le applicazioni single-tenant, come database o altri servizi gestiti, utilizzati da un team per le applicazioni. |
Architettura dei cluster della piattaforma
Il progetto esegue il deployment delle applicazioni in tre ambienti: sviluppo, non produzione e produzione. Ogni ambiente è associato a un parco risorse. In questo progetto base, un parco risorse è un progetto che include uno o più cluster. Tuttavia, i parchi risorse possono anche raggruppare diversi progetti. Un parco risorse fornisce un confine logico di sicurezza per il controllo amministrativo. Un parco risorse fornisce un modo per raggruppare e normalizzare logicamente i cluster Kubernetes, oltre a semplificare l'amministrazione dell'infrastruttura.
Il seguente diagramma mostra due cluster GKE, creati in ciascun ambiente per il deployment delle applicazioni. I due cluster agiscono come cluster GKE identici in due regioni diverse per fornire resilienza multiregionale. Per sfruttare le funzionalità del parco risorse, il progetto base utilizza il concetto di identicità tra oggetti dello spazio dei nomi, servizi e identità.
Il progetto dell'applicazione aziendale utilizza cluster GKE con spazi privati abilitati tramite l'accesso Private Service Connect al piano di controllo e 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 dei cluster eseguono il sistema operativo ottimizzato per i container per limitare la superficie di attacco, mentre i nodi dei cluster utilizzano i nodi GKE schermati per limitare la capacità di un utente malintenzionato di impersonare un nodo.
L'accesso amministrativo ai cluster GKE è abilitato tramite il gateway di connessione. Come parte del deployment del progetto base, viene utilizzata un'istanza Cloud NAT per ogni ambiente per fornire ai pod e a Config Sync un meccanismo per accedere a risorse su internet come GitHub. L'accesso ai cluster GKE è controllato dall'autorizzazione Kubernetes RBAC basata su Google Gruppi per GKE. I gruppi consentono di controllare le identità tramite un sistema centrale di gestione delle identità controllato dagli amministratori delle identità.
Componenti della piattaforma GKE Enterprise
La piattaforma per sviluppatori utilizza 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 progetto base sono i seguenti:
- GKE per la gestione dei container
- Policy Controller per la gestione e l'applicazione dei criteri
- Anthos Service Mesh per la gestione dei servizi
- Autorizzazione binaria per l'attestazione delle immagini container
- Controller gateway GKE per il controller gateway multi-cluster per i cluster GKE
Gestione del parco risorse della piattaforma
I parchi risorse offrono la possibilità di gestire più cluster GKE in un unico modo unificato. La gestione dei team del parco risorse semplifica il provisioning e la gestione delle risorse di infrastruttura da parte degli amministratori di piattaforma per i tenant della piattaforma di sviluppo. I tenant hanno il controllo dell'ambito delle risorse all'interno del proprio spazio dei nomi, inclusi 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 membri del parco risorse.
Gli spazi dei nomi del parco risorse forniscono il controllo su chi può accedere a spazi dei nomi specifici all'interno del parco risorse. L'applicazione utilizza due cluster GKE di cui viene eseguito il deployment in un parco risorse, con tre ambiti team e ogni ambito ha 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 implementati dal progetto base.
Networking della piattaforma
Per il networking, il deployment dei cluster GKE viene eseguito in un VPC condiviso creato come parte del progetto di base aziendale. I cluster GKE richiedono l'assegnazione di più intervalli di indirizzi IP negli ambienti di sviluppo, non di produzione e produzione. Ogni cluster GKE utilizzato dal progetto richiede intervalli di indirizzi IP separati allocati per nodi, pod, servizi e piano di controllo. Le istanze AlloyDB per PostgreSQL richiedono anche intervalli di indirizzi IP separati.
La seguente tabella descrive le subnet VPC e gli intervalli di indirizzi IP utilizzati nei diversi ambienti per il deployment dei cluster di progetto. Per l'ambiente di sviluppo nella regione 2 del cluster GKE dell'applicazione, il progetto esegue il deployment di un solo spazio di indirizzi IP anche se è disponibile uno spazio di indirizzi IP allocato 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 piano di controllo 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 piano di controllo 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 uno schema di allocazione degli indirizzi IP, consulta Gestione degli indirizzi IP in GKE e Pianificazione degli indirizzi IPv4 di GKE.
DNS della piattaforma
Il progetto utilizza Cloud DNS per GKE per fornire una risoluzione DNS per pod e servizi Kubernetes. Cloud DNS per GKE è un DNS gestito che non richiede un provider DNS ospitato nel cluster.
Nel progetto base, 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 la risoluzione dei servizi tra 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 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 progetto di base aziendale ha una regola predefinita per bloccare il traffico nel VPC condiviso.
Accesso della piattaforma ai servizi Google Cloud
Poiché le applicazioni del progetto utilizzano cluster privati, l'accesso privato Google fornisce l'accesso ai servizi Google Cloud.
Alta disponibilità della piattaforma
Il progetto base è stato progettato per essere resiliente in caso di interruzioni di zone e regioni. Le risorse necessarie per mantenere in esecuzione le applicazioni sono distribuite in due regioni. Devi selezionare le regioni in cui vuoi eseguire il deployment del progetto base. Le risorse che non si trovano nel percorso critico per la gestione e la risposta al carico sono solo una regione o sono globali. La seguente tabella descrive le risorse e dove viene eseguito il deployment.
Località |
Regione 1 |
Regione 2 |
Globale |
|---|---|---|---|
Ambienti con risorse in questa località |
|
|
|
Progetti con risorse in questa località |
|
|
|
Tipi di risorse in questa località |
|
|
|
La tabella seguente riassume in che modo i diversi componenti reagiscono a un'interruzione di una regione o a una zona e come è possibile mitigare questi effetti.
Ambito 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 in standby diventa attiva senza RPO. |
Disponibile, potrebbe essere necessario apportare una modifica manuale. Potrebbe essere necessario riavviare qualsiasi comando |
Disponibile, potrebbe essere necessario apportare una modifica manuale. Potrebbe essere necessario riavviare qualsiasi comando |
Una zona della regione 2 |
Disponibile. |
Disponibile. |
Disponibile. |
Disponibile, potrebbe essere necessario apportare una modifica manuale. Potrebbe essere necessario riavviare qualsiasi comando |
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 necessario apportare una modifica manuale Le build rimangono disponibili. Potrebbe essere necessario eseguire manualmente il deployment di nuove build. Le build esistenti potrebbero non essere completate correttamente. |
Disponibile. |
Le interruzioni del provider di servizi cloud sono solo una fonte di tempo di inattività. L'alta disponibilità dipende anche da processi e operazioni che riducono la probabilità di errori. La tabella seguente descrive tutte le decisioni prese nel progetto che riguardano l'alta disponibilità e i motivi di queste decisioni.
| Decisione sul progetto | Impatto sulla disponibilità |
|---|---|
Gestione del cambiamento |
|
Utilizza GitOps e IaC. |
Supporta la revisione delle modifiche da parte di colleghi e supporta il ripristino rapido delle configurazioni precedenti. |
Promuovi gradualmente i cambiamenti attraverso gli ambienti. |
Riduce l'impatto degli errori di software e configurazione. |
Rendere gli ambienti non di produzione e di produzione simili. |
Garantisce che le differenze non ritardano il rilevamento di un errore. Entrambi gli ambienti sono a due regioni. |
Modifica le risorse replicate di una regione alla volta all'interno di un ambiente. |
Garantisce che i problemi non rilevati da una promozione graduale influiscano solo sulla metà dell'infrastruttura di runtime. |
Modificare un servizio in una regione alla volta all'interno di un ambiente. |
Garantisce che i problemi che non vengono rilevati da una promozione graduale interessano solo la metà delle repliche del servizio. |
Infrastruttura di computing replicata |
|
Utilizza un piano di controllo del cluster a livello di regione. |
Il piano di controllo a livello di regione è disponibile durante l'upgrade e il ridimensionamento. |
Crea un pool di nodi multizona. |
Un pool di nodi cluster ha almeno tre nodi distribuiti in tre zone. |
Configura una rete VPC condiviso. |
La rete VPC condivisa copre due regioni. Un errore a livello di regione interessa solo il traffico di rete da e verso le risorse nella regione interessata. |
Replica il registro delle immagini. |
Le immagini sono archiviate in Artifact Registry, che è configurato per replicare in più regioni in modo che un'interruzione di una regione cloud non impedisca lo scale up delle applicazioni nella regione esistente. |
Servizi replicati |
|
Eseguire il deployment delle repliche di servizio in due regioni. |
In caso di interruzione di una regione, un servizio Kubernetes rimane disponibile negli ambienti di produzione e non. |
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 i rischi e i tempi di inattività. |
Configura tre repliche in una regione per ogni servizio. |
Un servizio Kubernetes include almeno tre repliche (pod) per supportare gli aggiornamenti in sequenza nell'ambiente di produzione e non di produzione. |
Distribuisci i pod del deployment su più zone. |
I servizi Kubernetes sono distribuiti tra le VM in zone diverse utilizzando unastanza di anti-affinità. Un'interruzione di un singolo nodo o di una zona completa può essere tollerata senza comportare traffico aggiuntivo tra regioni tra i servizi dipendenti. |
Spazio di archiviazione replicato |
|
Esegui il deployment di istanze di database multizona. |
AlloyDB per PostgreSQL offre alta disponibilità in una regione. I nodi ridondanti dell'istanza principale si trovano in due zone diverse della regione. L'istanza principale mantiene la disponibilità a livello regionale attivando un failover automatico per la zona in standby se si verifica un problema nella zona attiva. L'archiviazione a livello di regione garantisce 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 ripristino di emergenza. Il database replica in modo asincrono i dati del cluster principale in cluster secondari che si trovano in regioni Google Cloud separate. |
Operazioni |
|
Eseguire il provisioning delle applicazioni per un carico previsto doppio. |
Se un cluster non funziona (ad esempio a causa di un'interruzione del servizio a livello di regione), la porzione del servizio eseguito 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 vanno a buon fine ripetutamente in 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 |
Riavvia automaticamente i servizi con deadlock. |
Il deployment che supporta un servizio definisce un probe di attività, che identifica e riavvia i processi con deadlock. |
Verifica automaticamente se le repliche sono 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 a tempo 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 regionale. Garantire l'alta disponibilità comporta alcuni costi (ad esempio, costi di riserva in standby o costi di replica tra regioni). La sezione Alternative descrive alcuni modi per mitigare questi costi.
Quote della piattaforma, limiti delle prestazioni e limiti di scalabilità
Puoi controllare quote, prestazioni e scalabilità delle risorse nella piattaforma per sviluppatori. Nell'elenco seguente sono descritti alcuni aspetti da considerare:
- L'infrastruttura di base richiede numerosi progetti e ogni tenant aggiuntivo richiede quattro progetti. Potresti dover richiedere una quota di progetto aggiuntiva prima di eseguire il deployment e di aggiungere altri tenant.
- Esiste un limite di 100 risorse MultiClusterGateway per ogni progetto. Ogni servizio Kubernetes rivolto a internet sulla piattaforma di sviluppo richiede un MultiClusterGateway.
- Cloud Logging ha un limite di 100 bucket in un progetto. L'accesso ai log per-tenant nel progetto 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 di ambito e spazio dei nomi. Per istruzioni su come visualizzare le quote, vedi 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
- Leggi ulteriori informazioni sull'architettura dei servizi (documento successivo di questa serie).