Seleziona un ambiente di runtime del container gestito

Last reviewed 2024-08-30 UTC

Questo documento ti aiuta a valutare i requisiti della tua applicazione e a scegliere tra Cloud Run e Google Kubernetes Engine (GKE) Autopilot, in base a considerazioni tecniche e organizzative. Questo documento è rivolto ai cloud architect che devono scegliere un ambiente di runtime dei container di destinazione Google Cloud per i propri workload. Si presume che tu abbia familiarità con Kubernetes e Google Cloude che tu abbia una certa conoscenza degli ambienti di runtime serverless cloud come Cloud Run, Cloud Run Functions o AWS Lambda.

Google Cloud offre diverse opzioni di ambiente di runtime con una gamma di funzionalità. Il seguente diagramma mostra la gamma di offerte gestite di Google Cloud:

OfferteGoogle Cloud dalla più gestita alla meno gestita.

Il diagramma mostra quanto segue:

  • Ambienti di runtime più gestiti (il focus di questa guida):

    Queste opzioni sono gestite da Google, senza che l'utente debba gestire l'infrastruttura di computing sottostante.

  • Ambienti di runtime con gestione minima:

    • GKE Standard, ottimizzato per i workload aziendali e offre una scalabilità a livello di cluster singolo fino a 65.000 nodi.
    • Compute Engine, che include la famiglia di macchine virtuali A3 ottimizzate per l'acceleratore per i workload di machine learning (ML) e computing ad alte prestazioni (HPC).

    Queste opzioni richiedono un certo livello di gestione dell'infrastruttura a livello di utente, ad esempio le macchine virtuali (VM) che sono alla base delle funzionalità di computing. Le VM in GKE Standard sono i nodi del cluster Kubernetes. Le VM in Compute Engine sono l'offerta principale della piattaforma, che puoi personalizzare in base alle tue esigenze.

Questa guida ti aiuta a scegliere tra gli ambienti di runtime più gestiti, Cloud Run e GKE Autopilot. Per una visione più ampia degli ambienti di runtime Google Cloud , consulta la guida Opzioni di hosting delle applicazioniGoogle Cloud .

Panoramica degli ambienti

Questa sezione fornisce una panoramica delle funzionalità di Cloud Run e GKE Autopilot. Cloud Run e GKE Autopilot sono entrambi strettamente integrati in Google Cloud, quindi hanno molti punti in comune. Entrambe le piattaforme supportano più opzioni per il bilanciamento del carico con i servizi di bilanciamento del carico di Google, altamente affidabili e scalabili. Entrambi supportano anche il networking VPC, Identity-Aware Proxy (IAP) e Google Cloud Armor per i casi in cui è richiesto un networking privato più granulare. Entrambe le piattaforme ti addebitano solo le risorse esatte che utilizzi per le tue applicazioni.

Dal punto di vista della distribuzione del software, in quanto ambienti di runtime dei container, Cloud Run e GKE Autopilot sono supportati da servizi che compongono l'ecosistema di container di Google Cloud . Questi servizi includono Cloud Build, Artifact Registry, Autorizzazione binaria e distribuzione continua con Cloud Deploy, per garantire che il deployment delle tue applicazioni in produzione avvenga in modo sicuro e affidabile. Ciò significa che tu e i tuoi team siete responsabili delle decisioni di build e deployment.

A causa della comunanza tra le due piattaforme, potresti voler sfruttare i punti di forza di ciascuna adottando un approccio flessibile per il deployment delle tue applicazioni, come descritto nella guida Utilizza GKE e Cloud Run insieme. Le sezioni seguenti descrivono gli aspetti unici di Cloud Run e Autopilot.

Cloud Run

Cloud Run è una piattaforma di serverless computing gestita che ti consente di eseguire le tue applicazioni direttamente sull'infrastruttura scalabile di Google. Cloud Run fornisce l'automazione e la scalabilità per due tipi principali di applicazioni:

  • Servizi Cloud Run: per il codice che risponde alle richieste web.
  • Job Cloud Run: per il codice che esegue una o più attività in background e poi esce quando il lavoro è completato.

Con questi due modelli di deployment, Cloud Run può supportare un'ampia gamma di architetture di applicazioni, consentendo al contempo l'applicazione delle best practice e permettendo agli sviluppatori di concentrarsi sul codice.

Cloud Run supporta anche il deployment del codice dell'applicazione dalle seguenti origini:

  • Singole funzioni leggere
  • Applicazioni complete dal codice sorgente
  • Applicazioni containerizzate

Cloud Run incorpora una funzionalità di build e deployment che supporta sia FaaS sia la possibilità di creare da codice sorgente, oltre alla funzionalità di runtime dei container predefiniti. Quando utilizzi Cloud Run in questo modo, i passaggi di creazione e deployment dell'immagine container dell'applicazione che verrà eseguita sono completamente automatici e non richiedono una configurazione personalizzata da parte tua.

GKE Autopilot

GKE Autopilot è la modalità operativa predefinita e consigliata per i cluster in GKE. Autopilot ti consente di eseguire applicazioni su Kubernetes senza l'overhead della gestione dell'infrastruttura. Quando utilizzi Autopilot, Google gestisce gli aspetti chiave sottostanti della configurazione del cluster, tra cui il provisioning e la scalabilità dei nodi, la security posture predefinita e altre impostazioni preconfigurate. Con Autopilot che gestisce le risorse dei nodi, paghi solo per le risorse richieste dai tuoi workload. Autopilot monitora e ottimizza continuamente l'allocazione delle risorse dell'infrastruttura per garantire la massima idoneità, fornendo al contempo uno SLA per i tuoi workload.

GKE Autopilot supporta workload che potrebbero non essere adatti a Cloud Run. Ad esempio, GKE Autopilot supporta comunemente workload di lunga durata o stateful.

Scegli un ambiente di runtime

In generale, se le caratteristiche del tuo workload sono adatte a una piattaforma gestita, l'ambiente di runtime serverless di Cloud Run è l'ideale. L'utilizzo di Cloud Run può comportare una riduzione dell'infrastruttura da gestire, una minore configurazione autogestita e, di conseguenza, un overhead operativo inferiore. A meno che tu non voglia o non abbia bisogno specificamente di Kubernetes, ti consigliamo di considerare innanzitutto l'ambiente serverless come ambiente di runtime di destinazione. Sebbene Kubernetes fornisca la potente astrazione di una piattaforma aperta, il suo utilizzo aggiunge complessità. Se non hai bisogno di Kubernetes, ti consigliamo di valutare se la tua applicazione è adatta per il serverless. Se esistono criteri che rendono il tuo workload meno adatto al serverless, ti consigliamo di utilizzare Autopilot.

Le sezioni seguenti forniscono maggiori dettagli su alcuni dei criteri che possono aiutarti a rispondere a queste domande, in particolare se il workload è adatto o meno per il serverless. Considerando i punti in comune tra Autopilot e Cloud Run descritti nelle sezioni precedenti, la migrazione tra le piattaforme è un'attività semplice quando non ci sono blocchi tecnici o di altro tipo. Per esplorare le opzioni di migrazione in maggiore dettaglio, consulta Esegui la migrazione da Cloud Run a GKE ed Esegui la migrazione da Kubernetes a Cloud Run.

Quando scegli un ambiente di runtime per il tuo workload, devi tenere conto di considerazioni tecniche e organizzative. Le considerazioni tecniche sono caratteristiche della tua applicazione o dell'ambiente di runtime Google Cloud. Le considerazioni organizzative sono caratteristiche non tecniche della tua organizzazione o del tuo team che potrebbero influenzare la tua decisione.

Considerazioni tecniche

Alcune delle considerazioni tecniche che influenzeranno la tua scelta della piattaforma sono le seguenti:

  • Controllo e configurabilità: granularità del controllo dell'ambiente di esecuzione.
  • Gestione e routing del traffico di rete: configurabilità delle interazioni sulla rete.
  • Scalabilità orizzontale e verticale: supporto per l'espansione e la riduzione dinamica della capacità.
  • Supporto per le applicazioni stateful: funzionalità per l'archiviazione dello stato persistente.
  • Architettura della CPU: supporto per diversi tipi di CPU.
  • Offload dell'acceleratore (GPU e TPU): possibilità di eseguire l'offload del calcolo su hardware dedicato.
  • Capacità elevata di memoria, CPU e altre risorse: livello delle varie risorse consumate.
  • Dipendenza esplicita da Kubernetes: requisiti per l'utilizzo dell'API Kubernetes.
  • RBAC complesso per la multitenancy: supporto per la condivisione di risorse in pool.
  • Tempo di timeout massimo dell'attività del container: durata dell'esecuzione di applicazioni o componenti di lunga durata.

Le sezioni seguenti descrivono in dettaglio queste considerazioni tecniche per aiutarti a scegliere un ambiente di runtime.

Controllo e configurabilità

Rispetto a Cloud Run, GKE Autopilot offre un controllo più granulare dell'ambiente di esecuzione per i tuoi workload. Nel contesto di un pod, Kubernetes fornisce molte primitive configurabili che puoi ottimizzare per soddisfare i requisiti della tua applicazione. Le opzioni di configurazione includono livello di privilegio, parametri di qualità del servizio, gestori personalizzati per gli eventi del ciclo di vita dei container e condivisione dello spazio dei nomi dei processi tra più container.

Cloud Run supporta direttamente un sottoinsieme della superficie dell'API pod Kubernetes, descritta nel file YAML di riferimento per l'oggetto servizio Cloud Run e nel file YAML di riferimento per l'oggetto job Cloud Run. Queste guide di riferimento possono aiutarti a valutare le due piattaforme in base ai requisiti della tua applicazione.

Il contratto del container per l'ambiente di esecuzione di Cloud Run è relativamente semplice e si adatta alla maggior parte dei workload di distribuzione. Tuttavia, il contratto specifica alcuni requisiti che devono essere soddisfatti. Se la tua applicazione o le sue dipendenze non possono soddisfare questi requisiti o se hai bisogno di un controllo più preciso sull'ambiente di esecuzione, Autopilot potrebbe essere più adatto.

Se vuoi ridurre il tempo dedicato alla configurazione e all'amministrazione, ti consigliamo di scegliere Cloud Run come ambiente di runtime. Cloud Run offre meno opzioni di configurazione rispetto ad Autopilot, quindi può aiutarti a massimizzare la produttività degli sviluppatori e a ridurre l'overhead operativo.

Gestione e routing del traffico di rete

Sia Cloud Run che GKE Autopilot si integrano con Google Cloud Load Balancing. Tuttavia, GKE Autopilot fornisce anche un insieme ricco e potente di primitive per configurare l'ambiente di networking per le comunicazioni service-to-service. Le opzioni di configurazione includono autorizzazioni granulari e segregazione a livello di rete utilizzando namespace e policy di rete, rimappatura delle porte e Service Discovery DNS integrato all'interno del cluster. GKE Autopilot supporta anche l'API Gateway, altamente configurabile e flessibile. Questa funzionalità offre un controllo efficace sul modo in cui il traffico viene instradato verso e tra i servizi nel cluster.

Poiché Autopilot è altamente configurabile, può essere l'opzione migliore se hai più servizi con un elevato grado di codipendenza di networking o requisiti complessi relativi al modo in cui il traffico viene instradato tra i componenti dell'applicazione. Un esempio di questo pattern è un'applicazione distribuita suddivisa in numerosi microservizi con pattern complessi di interdipendenza. In questi scenari, le opzioni di configurazione di rete di Autopilot possono aiutarti a gestire e controllare le interazioni tra i servizi.

Scalabilità orizzontale e verticale

Sia Cloud Run che GKE Autopilot supportano la scalabilità orizzontale manuale e automatica per servizi e job. La scalabilità orizzontale fornisce una maggiore potenza di elaborazione quando necessario e la rimuove quando non è più necessaria. Per un workload tipico, Cloud Run di solito può fare lo scale out più rapidamente di GKE Autopilot per rispondere ai picchi del numero di richieste al secondo. Ad esempio, la dimostrazione video "What's New in Serverless Compute?" mostra lo scale up di Cloud Run da zero a oltre 10.000 istanze in circa 10 secondi. Per aumentare la velocità di scalabilità orizzontale su Kubernetes (con un costo aggiuntivo), Autopilot ti consente di eseguire il provisioning di capacità di computing aggiuntiva.

Se la tua applicazione non può scalare aggiungendo altre istanze per aumentare il livello di risorse disponibili, potrebbe essere più adatta ad Autopilot. Autopilot supporta la scalabilità verticale per variare dinamicamente la quantità di potenza di elaborazione disponibile senza aumentare il numero di istanze in esecuzione dell'applicazione.

Cloud Run può fare lo scale down automatico delle tue applicazioni fino a zero repliche quando non vengono utilizzate, il che è utile per alcuni casi d'uso che si concentrano in modo particolare sull'ottimizzazione dei costi. A causa delle caratteristiche di scalabilità a zero delle tue applicazioni, esistono diversi passaggi di ottimizzazione che puoi eseguire per ridurre al minimo il tempo che intercorre tra l'arrivo di una richiesta e il momento in cui l'applicazione è attiva e funzionante e in grado di elaborare la richiesta.

Supporto per le applicazioni stateful

Autopilot offre un supporto completo dei volumi Kubernetes, supportato da Persistent Disk che ti consentono di eseguire un'ampia gamma di deployment stateful, inclusi i database autogestiti. Sia Cloud Run che GKE Autopilot ti consentono di connetterti ad altri servizi come i bucket Cloud Storage e Filestore. Entrambi includono anche la possibilità di montare bucket di archivi di oggetti nel file system con Cloud Storage FUSE.

Cloud Run utilizza un file system in memoria, che potrebbe non essere adatto per le applicazioni che richiedono un file system locale permanente. Inoltre, il file system in memoria locale è condiviso con la memoria della tua applicazione. Pertanto, sia il file system temporaneo sia la memoria utilizzata dall'applicazione e dal container contribuiscono all'esaurimento del limite di memoria. Puoi evitare questo problema se utilizzi un volume in memoria dedicato con un limite di dimensioni.

Un container di servizi o job Cloud Run ha un timeout delle attività massimo. Un container in esecuzione all'interno di un pod in un cluster Autopilot può essere ripianificato, in base a eventuali vincoli configurati con i budget di interruzione dei pod (PDB). Tuttavia, i pod possono essere eseguiti per un massimo di sette giorni se sono protetti dall'espulsione causata da upgrade automatici dei nodi o eventi di scale down. In genere, il timeout delle attività è più probabile che sia un fattore da considerare per i workload batch in Cloud Run. Per i workload di lunga durata e per le attività batch che non possono essere completate entro la durata massima dell'attività, Autopilot potrebbe essere l'opzione migliore.

Architettura della CPU

Tutte le piattaforme di computing Google Cloud supportano l'architettura della CPU x86. Cloud Run non supporta i processori con architettura Arm, ma Autopilot supporta i nodi gestiti basati sull'architettura Arm. Se il tuo workload richiede l'architettura Arm, dovrai utilizzare Autopilot.

Offload dell'acceleratore

Autopilot supporta l'utilizzo di GPU e l'utilizzo di TPU, inclusa la possibilità di utilizzare risorse prenotate. Cloud Run supporta l'utilizzo di GPU con alcune limitazioni.

Requisiti elevati di memoria, CPU e altre risorse

Rispetto ai limiti delle richieste di risorse di GKE Autopilot, le risorse di CPU e memoria massime che possono essere utilizzate da un singolo servizio o job Cloud Run (una singola istanza) sono limitate. A seconda delle caratteristiche dei tuoi workload, Cloud Run potrebbe avere altri limiti che vincolano le risorse disponibili. Ad esempio, il timeout di avvio e il numero massimo di connessioni in uscita potrebbero essere limitati con Cloud Run. Con Autopilot, alcuni limiti potrebbero non essere applicati o potrebbero avere valori consentiti più elevati.

Dipendenza esplicita da Kubernetes

Alcune applicazioni, librerie o framework potrebbero avere una dipendenza esplicita da Kubernetes. La dipendenza da Kubernetes potrebbe essere dovuta a uno dei seguenti motivi:

  1. I requisiti dell'applicazione (ad esempio, l'applicazione chiama le API Kubernetes o utilizza le risorse personalizzate di Kubernetes).
  2. I requisiti degli strumenti utilizzati per configurare o eseguire il deployment dell'applicazione (ad esempio Helm).
  3. I requisiti di assistenza di un creator o fornitore di terze parti.

In questi scenari, Autopilot è l'ambiente di runtime di destinazione perché Cloud Run non supporta Kubernetes.

RBAC complesso per la multitenancy

Se la tua organizzazione ha strutture organizzative o requisiti di multi-tenancy particolarmente complessi, utilizza Autopilot in modo da poter sfruttare il controllo degli accessi basato su ruoli (RBAC) di Kubernetes. Per un'opzione più semplice, puoi utilizzare le funzionalità di sicurezza e segregazione integrate in Cloud Run.

Considerazioni organizzative

Di seguito sono riportate alcune delle considerazioni organizzative che influenzeranno la tua scelta dell'ambiente:

  • Strategia tecnica generale: la direzione tecnica della tua organizzazione.
  • Sfruttare l'ecosistema Kubernetes: interesse a sfruttare la community OSS.
  • Strumenti interni esistenti: utilizzo di determinati strumenti.
  • Profili del team di sviluppo: competenze ed esperienza degli sviluppatori.
  • Assistenza operativa: capacità e focus dei team operativi.

Le sezioni seguenti descrivono in dettaglio queste considerazioni organizzative per aiutarti a scegliere un ambiente.

Strategia tecnica generale

Le organizzazioni o i team potrebbero aver concordato strategie per preferire determinate tecnologie rispetto ad altre. Ad esempio, se un team ha un accordo per standardizzare, ove possibile, l'utilizzo di serverless o Kubernetes, questo accordo potrebbe influenzare o addirittura imporre un ambiente di runtime di destinazione.

Se un determinato workload non è adatto all'ambiente di runtime specificato nella strategia, puoi decidere di eseguire una o più delle seguenti operazioni, con i relativi avvertimenti:

  • Riprogetta l'architettura del workload. Tuttavia, se il workload non è adatto, ciò potrebbe comportare prestazioni, costi, sicurezza o altre caratteristiche non ottimali.
  • Registra il workload come eccezione alla direzione strategica. Tuttavia, se le eccezioni vengono utilizzate in modo eccessivo, ciò può comportare un portfolio tecnologico eterogeneo.
  • Riconsidera la strategia. Tuttavia, ciò può comportare un overhead delle policy che può ostacolare o bloccare i progressi.

Sfruttare l'ecosistema Kubernetes

Nell'ambito della strategia tecnica generale descritta in precedenza, le organizzazioni o i team potrebbero decidere di selezionare Kubernetes come piattaforma preferita a causa dell'ecosistema significativo e in crescita. Questa scelta è diversa dalla selezione di Kubernetes a causa delle dipendenze tecniche delle applicazioni, come descritto nella sezione precedente Dipendenza esplicita da Kubernetes. La scelta di utilizzare l'ecosistema Kubernetes pone l'accento su una community attiva, su un'ampia gamma di strumenti di terze parti e su standard e portabilità solidi. Sfruttare l'ecosistema Kubernetes può accelerare la velocità di sviluppo e ridurre il time to market.

Strumenti interni esistenti

In alcuni casi, può essere vantaggioso utilizzare gli ecosistemi di strumenti esistenti nella tua organizzazione o nel tuo team (per qualsiasi ambiente). Ad esempio, se utilizzi Kubernetes, potresti scegliere di continuare a utilizzare strumenti di deployment come ArgoCD, strumenti di sicurezza e policy come Gatekeeper e gestione dei pacchetti come Helm. Gli strumenti esistenti potrebbero includere regole stabilite per l'automazione della conformità dell'organizzazione e altre funzionalità che potrebbero essere costose o richiedere un tempo di risposta lungo per l'implementazione in un ambiente di destinazione alternativo.

Profili dei team di sviluppo

Un team di applicazioni o workload potrebbe avere un'esperienza precedente con Kubernetes che può accelerare la velocità e la capacità del team di fornire risultati su Autopilot. Un team può impiegare del tempo per acquisire dimestichezza con un nuovo ambiente di runtime. A seconda del modello operativo, ciò potrebbe comportare una minore affidabilità della piattaforma durante il periodo di upskilling.

Per un team in crescita, la capacità di assunzione potrebbe influenzare la scelta della piattaforma da parte di un'organizzazione. In alcuni mercati, le competenze relative a Kubernetes potrebbero essere scarse e, di conseguenza, richiedere un premio per l'assunzione. La scelta di un ambiente come Cloud Run può aiutarti a semplificare il processo di assunzione e consentire una crescita più rapida del team nel rispetto del budget.

Supporto operativo

Quando scegli un ambiente di runtime, considera l'esperienza e le capacità dei tuoi team di SRE, DevOps e piattaforme e di altro personale operativo. Le capacità dei team operativi di supportare efficacemente l'ambiente di produzione sono fondamentali dal punto di vista dell'affidabilità. È inoltre fondamentale che i team operativi possano supportare gli ambienti di pre-produzione per garantire che la velocità degli sviluppatori non sia ostacolata da tempi di inattività, dipendenza da processi manuali o meccanismi di deployment complessi.

Se utilizzi Kubernetes, un team centrale di ingegneria della piattaforma o delle operazioni può gestire gli upgrade di Kubernetes Autopilot. Sebbene gli upgrade siano automatici, il personale operativo li monitorerà attentamente per garantire interruzioni minime dei workload. Alcune organizzazioni scelgono di eseguire manualmente l'upgrade delle versioni del control plane. GKE include anche funzionalità per semplificare la gestione delle applicazioni su più cluster.

A differenza di Autopilot, Cloud Run non richiede overhead di gestione continuo o upgrade del control plane. Utilizzando Cloud Run, puoi semplificare i processi operativi. Selezionando un unico ambiente di runtime, puoi semplificare ulteriormente i processi operativi. Se scegli di utilizzare più ambienti di runtime, devi assicurarti che il team abbia la capacità, le competenze e l'interesse per supportarli.

Selezione

Per iniziare il processo di selezione, parla con i vari stakeholder. Per ogni applicazione, riunisci un gruppo di lavoro composto da sviluppatori, personale operativo, rappresentanti di qualsiasi gruppo centrale di governance della tecnologia, utenti e consumatori interni delle applicazioni, team di sicurezza, team di ottimizzazione finanziaria del cloud e altri ruoli o gruppi all'interno della tua organizzazione che potrebbero essere pertinenti. Potresti scegliere di distribuire un sondaggio per raccogliere informazioni sulle caratteristiche delle applicazioni e condividere i risultati prima della sessione. Ti consigliamo di selezionare un piccolo gruppo di lavoro che includa solo gli stakeholder necessari. La presenza di tutti i rappresentanti potrebbe non essere necessaria per ogni sessione di lavoro.

Potresti anche trovare utile includere rappresentanti di altri team o gruppi con esperienza nella creazione e nell'esecuzione di applicazioni su Autopilot o Cloud Run o su entrambi. Utilizza le considerazioni tecniche e organizzative di questo documento per guidare la conversazione e valutare l'idoneità della tua applicazione per ciascuna delle potenziali piattaforme.

Ti consigliamo di pianificare un controllo dopo alcuni mesi per confermare o rivedere la decisione in base ai risultati del deployment della tua applicazione nel nuovo ambiente.

Passaggi successivi

Collaboratori

Autore: Henry Bell | Cloud Solutions Architect

Altri collaboratori: