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 la Federazione delle identità dei carichi di lavoro del parco risorse per GKE per mappare gli account di servizio Kubernetes utilizzati come identità per i pod Account di servizio Google Cloud che controllano l'accesso a Google Cloud i servizi di machine learning. Per contribuire a 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 progetto base, crei tre tipi di gruppi di utenti: di Google Cloud, un team dedicato alle applicazioni (un team per applicazione) e del team delle operazioni di sicurezza.
Il team della piattaforma per sviluppatori è responsabile dello sviluppo e della gestione del Google Cloud. I membri di questo team sono i seguenti:
- Sviluppatori di piattaforme per sviluppatori: questi membri del team estendono il progetto e integrarla 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 l'ambiente di produzione.
- Coordinamento degli aggiornamenti dell'infrastruttura.
- elaborare 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 tale software. Il team tenant è composto di due gruppi: sviluppatori di applicazioni e operatori di applicazioni. I doveri i due gruppi del team tenant sono i seguenti:
- Sviluppatori di applicazioni: questo team scrive ed esegue il debug del codice dell'applicazione. Loro
a volte sono chiamati anche ingegneri del software 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 sono chiamati operatori di servizio,
tecnici di sistema o amministratori di sistema. Le loro responsabilità includono:
le seguenti:
- Pianificazione delle esigenze di capacità a livello di applicazione.
- Creazione di criteri di avviso e definizione degli obiettivi del livello di servizio (SLO) per i servizi di machine learning.
- Diagnosi dei problemi del servizio mediante l'utilizzo di log e metriche specifici un'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 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 base dell'applicazione aziendale utilizza la struttura organizzativa fornito dal progetto base aziendale. Il seguente diagramma mostra come i progetti di progetto di applicazioni aziendali si adattano alla struttura del progetto 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 il applicationfabbrica , utilizzata per creare un'architettura delle applicazioni single-tenant e di integrazione e deployment continui (CI/CD). Questo progetto contiene anche la funzione Config Sync 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. C'è una pipeline per ogni applicazione. |
|
|
|
Contiene i cluster GKE per la piattaforma di sviluppo e la logica utilizzato 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 dei 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 diversi 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 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 i cluster GKE in due diverse regioni per fornire resilienza multiregionale. Per usufruire 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 vengono eseguiti Container-Optimized OS per limitare la superficie di attacco e i nodi del cluster utilizzano nodi GKE schermati per limitare la capacità di un utente malintenzionato di impersonare un nodo.
L'accesso amministrativo ai cluster GKE viene abilitato tramite Connetti il gateway. Nell'ambito del deployment del progetto base, Per ogni ambiente viene utilizzata l'istanza Cloud NAT per fornire pod Config Sync un meccanismo per accedere a risorse su internet, ad esempio GitHub. L'accesso ai cluster GKE è controllato dall'autorizzazione RBAC di Kubernetes basato 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 GKE Enterprise per consentirti di creare, distribuire e gestire il ciclo di vita diverse 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 gestione del servizio
- 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. I tenant hanno come ambito delle risorse all'interno del proprio spazio dei nomi, incluse le 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 associato a uno o più membri del parco risorse cluster.
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 corrispondenti a cluster di esempio in un ambiente, come implementato dal progetto base.
Networking della piattaforma
Per il networking, il deployment dei cluster GKE viene eseguito in un VPC condiviso creati come parte del progetto di base aziendale. 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 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 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 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 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 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 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 cluster ospitato Provider DNS.
Nel progetto base, 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 cluster e VM i pod esterni al cluster possono risolvere i servizi all'interno del cluster.
Firewall della piattaforma
GKE crea automaticamente regole firewall durante la creazione cluster GKE, servizi GKE, Firewall gateway GKE, 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 Enterprise ha una regola predefinita per bloccare il traffico VPC condiviso.
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 a livello di zona sia a livello di regione. Le risorse necessarie per mantenere in esecuzione le applicazioni sono distribuite su due regioni. Tu seleziona le regioni in cui vuoi eseguire il deployment del progetto base. 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 località |
|
|
|
Progetti con risorse in questa località |
|
|
|
Tipi di risorse in questa località |
|
|
|
La tabella seguente riassume come i diversi componenti reagiscono all'interruzione di una regione o un'interruzione di una zona e come puoi mitigare questi effetti.
Ambito dell'errore |
Effetti dei servizi esterni |
Effetti del database | Effetti di creazione e deployment | 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. Potrebbe essere necessario riavviare
Comando |
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 al cluster secondario. |
Non disponibile. |
Non disponibile. |
Regione 2 |
Disponibile. |
Disponibile. |
Disponibile, potrebbe essere necessaria una modifica manuale Le build rimangono disponibili. Tu potrebbe essere necessario eseguire manualmente il deployment delle nuove build. Le build esistenti potrebbero non essere completate correttamente. |
Disponibile. |
Le interruzioni del cloud provider sono solo una delle cause di inattività. Anche l'alta disponibilità dipende da processi e operazioni che aiutano a commettere errori. La la seguente tabella descrive tutte le decisioni prese nel progetto in relazione a l'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 paritaria delle modifiche e il ripristino rapido configurazioni precedenti. |
Promuovi le modifiche gradualmente nei vari ambienti. |
Riduce l'impatto degli errori di software e configurazione. |
Creare ambienti non di produzione e di produzione simili. |
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 completamente gestito di Google Cloud. |
Garantisce che i problemi non rilevati da una promozione graduale abbiano effetto solo che prevede la metà dell'infrastruttura in fase di runtime. |
Modificare un servizio in una regione alla volta all'interno di un ambiente. |
Garantisce che i problemi non rilevati da una promozione graduale abbiano effetto solo delle repliche dei servizi. |
Infrastruttura di calcolo replicata |
|
Utilizza un piano di controllo del cluster a livello di regione. |
Il piano di controllo regionale è disponibile durante l'upgrade e il ridimensionamento. |
Crea un pool di nodi multizonale. |
Un pool di nodi cluster ha almeno tre nodi distribuiti su tre zone. |
Configurare una rete VPC condiviso. |
La rete VPC condivisa copre due regioni. Un errore solo a livello di regione influisce sul traffico di rete da e verso le risorse nella regione in errore. |
Replica il registry delle immagini. |
Le immagini vengono archiviate in Artifact Registry, che è configurato per 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 |
|
Eseguire il deployment delle repliche di servizio in due regioni. |
In caso di interruzione del servizio a livello di regione, un servizio Kubernetes rimane disponibile di produzione e non di produzione. |
Utilizzare gli aggiornamenti in sequenza per le modifiche ai servizi all'interno di una regione. |
Puoi aggiornare i servizi Kubernetes utilizzando un aggiornamento in sequenza un pattern di deployment che riduce rischi e 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 usando un approccio anti-affinità stanza. È 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 quello in cluster secondari situati in cluster regioni di Google Cloud. |
Operazioni |
|
Esegui il provisioning delle applicazioni per un carico doppio rispetto a quello previsto. |
Se si verifica un errore in un cluster, ad esempio a causa di un'interruzione del servizio a livello di regione, del servizio eseguito nel cluster rimanente può assorbire completamente caricamento. |
Riparare i nodi automaticamente. |
I cluster sono configurati con nodo riparazione automatica. Se i controlli di integrità consecutivi di un nodo non superano ripetutamente prolungato, GKE avvia un processo di riparazione su 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. |
Controlla automaticamente se le repliche sono pronte. |
Il deployment che supporta un servizio definisce un idoneità probe, che identifica quando un'applicazione è pronta per essere pubblicata dopo iniziare. 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 applicazioni con servizi requisiti di alta disponibilità. L'alta disponibilità comporta alcuni costi (ad esempio, costi di pezzi di ricambio di riserva o di replica tra regioni). La La sezione Alternative descrive alcuni modi per mitigare l'impatto ambientale questi costi.
Quote della piattaforma, limiti delle prestazioni e limiti di scalabilità
Puoi controllare quote, prestazioni e scalabilità delle risorse nella completamente gestita. Nell'elenco che segue sono descritti 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 rivolto a internet sulla piattaforma per sviluppatori richiede un MultiClusterGateway.
- Cloud Logging ha un limite di 100 bucket in un progetto. Il 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 per le risorse dello spazio dei nomi con ambito e 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).