Questa sezione descrive i controlli utilizzati nella piattaforma per sviluppatori.
Identità della piattaforma, ruoli e gruppi
L'accesso ai servizi Google Cloud richiede identità Google Cloud. Il progetto utilizza il parco risorse Workload Identity 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 cross-environment, ha un pool di identità separato (noto come insieme di identità attendibili provider) per i propri account Workload Identity.
Utenti tipo 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 una nuova modelli di machine learning.
- Amministratore di piattaforma per sviluppatori: questo team è responsabile della
seguenti:
- .
- Approvazione della creazione di team di nuovi 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.
- Coordinare gli aggiornamenti dell'infrastruttura.
- Realizzazione di 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. Loro
le responsabilità includono:
- L'esecuzione di test e controlli di qualità su un componente dell'applicazione quando il deployment nell'ambiente di sviluppo.
- Gestione delle risorse cloud di proprietà delle applicazioni (ad esempio database e spazio di archiviazione) bucket) nell'ambiente di sviluppo.
- Progettazione di schemi di database o archiviazione per l'uso da parte delle applicazioni.
- Operatori delle applicazioni o Site Reliability Engineer (SRE): questo team
gestisce l'affidabilità delle applicazioni in esecuzione
ambienti e l'avanzamento sicuro delle modifiche apportate
gli sviluppatori 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 le sue SLO.
- Collaborazione con uno o più gruppi di sviluppatori di applicazioni.
- Approvazione del deployment di nuove versioni in produzione.
- Gestione delle risorse cloud di proprietà delle applicazioni nei settori non di produzione e ambienti 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 da il progetto di base necessario per il deployment risorse, configurazioni e applicazioni.
| Cartella | Progetto | Descrizione |
|---|---|---|
|
|
Contiene il parametro multi-tenant dell'infrastruttura per eseguire il deployment dell'infrastruttura 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 sono in 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 delle applicazioni a singolo tenant, come database o e altri servizi gestiti usati dal team delle applicazioni. |
Architettura dei cluster della piattaforma
Il progetto esegue il deployment delle applicazioni in tre ambienti: sviluppo, non in produzione e in produzione. Ogni ambiente è associato a un parco risorse. In questo progetto, 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 logica 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 ognuno per il deployment delle applicazioni. I due cluster si comportano come i cluster GKE in due diverse regioni per fornire resilienza multiregionale. A sfruttare le funzionalità del parco risorse, il progetto utilizza il concetto identicità tra oggetti dello spazio dei nomi, servizi e identità.
Il progetto base dell'applicazione aziendale utilizza cluster GKE con spazi privati abilitati tramite l'accesso a Private Service Connect al piano di controllo e pool di nodi privati per rimuovere da internet potenziali superfici di attacco. Né il cluster nodi né il piano di controllo dispone di 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 consentono di controllare le identità utilizzando un sistema centrale di gestione delle identità 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 di GKE Enterprise utilizzati nella deployment di progetti base:
- 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 attestazione dell'immagine container
- Controller gateway GKE per il controller gateway multi-cluster per i cluster GKE
Gestione del parco risorse della piattaforma
Parchi risorse consente di gestire più cluster GKE in un unico in modo unificato. Gestione dei team del parco risorse semplifica il provisioning e la gestione per gli amministratori della piattaforma dell'infrastruttura per i tenant delle piattaforme di sviluppo. 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 utilizza 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 forniscono il controllo su chi ha accesso a spazi dei nomi specifici all'interno della tua flotta. L'applicazione utilizza due cluster GKE di cui viene eseguito il deployment in un parco risorse, con tre ambiti dei team e ciascuno dei quali ha 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 più intervalli di indirizzi IP da assegnare nell'ambiente di sviluppo, ambienti di lavoro e di produzione. Ogni cluster GKE utilizzato dal progetto richiede intervalli di indirizzi IP separati allocati per nodi, pod, servizi dal piano di controllo. Le istanze AlloyDB per PostgreSQL richiedono anche un indirizzo IP separato di indirizzi IP esterni.
La tabella seguente descrive le subnet VPC e gli intervalli di indirizzi IP utilizzati nei diversi ambienti per eseguire il deployment dei cluster dei progetti. Per nella regione del cluster GKE delle applicazioni 2, esegue il deployment di uno spazio di indirizzi IP anche se è presente uno spazio di indirizzi IP allocati per due cluster GKE di sviluppo.
| Risorsa | Tipo di intervallo di indirizzi IP | Sviluppo | Non 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 la 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 in tutti i cluster GKE di un progetto di condividere un singolo DNS zona di destinazione. 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à per tutte le le regole firewall create automaticamente sono pari a 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 del progetto usano 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 di corrente sia a livello di zona che di regione. Le risorse necessarie per mantenere le applicazioni in esecuzione sono distribuite in due regioni. Tu seleziona le regioni in cui vuoi eseguire il deployment del progetto base. Risorse che sono non nel percorso critico per la pubblicazione e la risposta al carico sono solo una regione o sono globali. La tabella seguente descrive le risorse e la loro posizione di cui è stato 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 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. Lo standby di rete diventa attiva con zero RPO. |
Disponibile, potrebbe essere necessaria una modifica manuale. Potrebbe essere necessario riavviare
Comando |
Disponibile, potrebbe essere necessaria una modifica manuale. Potrebbe essere necessario riavviare
Comando |
Una zona della regione 2 |
Disponibile. |
Disponibile. |
Disponibile. |
Disponibile, potrebbe essere necessaria una modifica manuale. Potrebbe essere necessario riavviare
Comando |
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 sul progetto | Impatto sulla disponibilità |
|---|---|
Gestione dei cambiamenti |
|
Usa 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 configurazione e del software. |
Creare ambienti non di produzione e di produzione simili. |
Garantisce che le differenze non ritardano il rilevamento di un errore. Entrambi 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 |
|
Usa 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 multizona. |
Un pool di nodi cluster ha almeno tre nodi distribuiti su tre diverse. |
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 registro di immagini. |
Le immagini vengono archiviate in Artifact Registry, configurato per replicare in più regioni in modo che un'interruzione della regione cloud non impedisca lo scale up 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 processo di aggiornamento del pattern di deployment che riduce rischi e tempi di inattività. |
Configurare tre repliche in una regione per ogni servizio. |
Un servizio Kubernetes deve supportare almeno tre repliche (pod) aggiornamenti in sequenza, in produzione e non completamente gestito di Google Cloud. |
Distribuisci i pod del deployment su 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'intera zona senza incorrere in traffico aggiuntivo tra regioni tra i servizi dipendenti. |
Spazio di archiviazione replica |
|
Esegui il deployment di istanze di database multizona. |
AlloyDB per PostgreSQL offre alta disponibilità in una regione. È principale i nodi ridondanti dell'istanza si trovano in due diverse zone della regione. La l'istanza principale mantiene la disponibilità a livello regionale attivando un'istanza fai il failover alla zona di standby se si verifica un problema nella zona attiva. A livello di regione l'archiviazione contribuisce a fornire la durabilità dei dati in caso di perdita in una singola zona. |
Replica i database tra regioni. |
AlloyDB per PostgreSQL utilizza la replica tra regioni per fornire dati di emergenza per il ripristino di emergenza. 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 del pool di nodi siano sensibili alle applicazioni. |
I deployment definiscono un pod
budget per interruzione con |
Riavvia automaticamente i servizi con deadlock. |
Il deployment che supporta un servizio definisce un'attività probe, che identifica e riavvia i processi con 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 probe di idoneità elimina la necessità di controlli manuali o di attese con orario durante gli aggiornamenti in sequenza e gli upgrade del 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 riserva in standby o costi 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.
- Esiste un limite di 100 risorse MultiClusterGateway per ogni progetto. Ciascuna per il servizio Kubernetes per internet sulla piattaforma di sviluppo 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 sulla visualizzazione
quote, consulta Visualizzare e gestire le quote. Usa un filtro per trovare
gkehub.googleapis.com/global-per-project-scopesegkehub.googleapis.com/global-per-project-scope-namespacestipi di quota.
Passaggi successivi
- Leggi ulteriori informazioni sull'architettura dei servizi (nel prossimo documento tra questa serie).