Seleziona un ambiente di runtime del contenitore 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 agli architetti cloud che devono scegliere un ambiente di runtime del contenitore di destinazione Google Cloud per i propri carichi di lavoro. Si presume che tu abbia familiarità con Kubernetes e Google Cloud e che tu abbia una certa conoscenza degli ambienti di runtime serverless cloud come Cloud Run, le funzioni Cloud Run o AWS Lambda.

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

Offerte Google Cloud dal livello di gestione più alto a quello più basso.

Il diagramma mostra quanto segue:

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

    Queste opzioni sono gestite da Google, senza che gli utenti debbano gestire l'infrastruttura di calcolo sottostante.

  • Ambienti di runtime meno gestiti:

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

    Queste opzioni richiedono un certo grado di gestione dell'infrastruttura a livello di utente, come le macchine virtuali (VM) alla base delle funzionalità di calcolo. Le VM in GKE Standard sono i nodi del cluster Kubernetes. Le VM in Compute Engine sono l'offerta di piattaforma di base, 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 panoramica più ampia degli ambienti di runtime di Google Cloud, consulta la guida Opzioni di hosting delle applicazioni Google 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 presentano molte analogie. 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 inoltre VPC Networking, Identity-Aware Proxy (IAP), e Google Cloud Armor per quando è necessario 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 dai servizi che compongono l'ecosistema di container di Google Cloud. Questi servizi includono Cloud Build, Artifact Registry, Autorizzazione binaria, e la distribuzione continua con Cloud Deploy, per contribuire a garantire che le applicazioni vengano implementate in produzione in modo sicuro e affidabile. Ciò significa che tu e i tuoi team avete il controllo sulle decisioni relative alla compilazione e al deployment.

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

Cloud Run

Cloud Run è una piattaforma di calcolo gestita serverless che ti consente di eseguire le tue applicazioni direttamente sull'infrastruttura scalabile di Google. Cloud Run offre automazione e 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 al termine del lavoro.

Con questi due modelli di deployment, Cloud Run può supportare un'ampia gamma di architetture di applicazioni, consentendo al contempo le best practice e lasciando che gli sviluppatori si concentrino sul codice.

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

  • Funzioni leggere individuali
  • Applicazioni complete dal codice sorgente
  • Applicazioni containerizzate

Cloud Run incorpora una funzionalità di compilazione e deployment che supporta sia FaaS sia la possibilità di compilare dall'origine, oltre alla funzionalità di runtime del container precompilato. Quando utilizzi Cloud Run in questo modo, i passaggi di creazione ed esecuzione dell'immagine del contenitore dell'applicazione che verrà eseguita sono completamente automatici, e non richiedono configurazione personalizzata.

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 fondamentali della configurazione del cluster, tra cui il provisioning e la scalabilità dei nodi, la posizione di sicurezza predefinita e altre impostazioni preconfigurate. Con Autopilot che gestisce le risorse dei nodi, paghi solo per le risorse richieste dai tuoi carichi di lavoro. Autopilot monitora e ottimizza continuamente le risorse dell'infrastruttura per garantire la migliore adattabilità, fornendo al contempo un SLA per i tuoi carichi di lavoro.

GKE Autopilot supporta carichi di lavoro che potrebbero non essere adatti per Cloud Run. Ad esempio, GKE Autopilot supporta in genere i carichi di lavoro di lunga durata o stateful.

Scegli un ambiente di runtime

In generale, se le caratteristiche del tuo carico di lavoro sono adatte a una piattaforma gestita, l'ambiente di runtime serverless di Cloud Run è ideale. L'utilizzo di Cloud Run può comportare meno infrastruttura da gestire, meno configurazione self-managed e, di conseguenza, un overhead operativo inferiore. A meno che tu non voglia o non abbia bisogno specificamente di Kubernetes, ti consigliamo di prendere in considerazione innanzitutto l'ambiente di runtime serverless come 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 al serverless. Se esistono criteri che rendono il tuo carico di lavoro meno adatto al serverless, ti consigliamo di utilizzare Autopilot.

Le sezioni seguenti forniscono ulteriori dettagli su alcuni dei criteri che possono aiutarti a rispondere a queste domande, in particolare alla domanda se il carico di lavoro è adatto a serverless. Data la somiglianza tra Autopilot e Cloud Run descritta nelle sezioni precedenti, la migrazione tra le piattaforme è un'operazione semplice se non ci sono blocchi tecnici o di altro tipo. Per esaminare le opzioni di migrazione in modo più dettagliato, consulta Eseguire la migrazione da Cloud Run a GKE e Eseguire la migrazione da Kubernetes a Cloud Run.

Quando scegli un ambiente di runtime per il tuo workload, devi prendere in considerazione considerazioni tecniche e organizzative. Le considerazioni tecniche sono caratteristiche della tua applicazione o dell'ambiente di runtime di Google Cloud. Le considerazioni organizzative sono caratteristiche non tecniche della tua organizzazione o del tuo team che potrebbero influire sulla tua decisione.

Considerazioni tecniche

Di seguito sono riportate alcune considerazioni tecniche che influenzeranno la tua scelta della piattaforma:

  • 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 la crescita e la riduzione dinamica della capacità.
  • Supporto per le applicazioni stateful: funzionalità per lo stoccaggio dell'étate permanente.
  • Architettura della CPU: supporto di diversi tipi di CPU.
  • Offload dell'acceleratore (GPU e TPU): possibilità di scaricare il calcolo su hardware dedicato.
  • Elevata capacità di memoria, CPU e altre risorse: livello di varie risorse consumate.
  • Dipendenza esplicita da Kubernetes: requisiti per l'utilizzo dell'API Kubernetes.
  • RBAC complesso per il multitenancy: supporto per la condivisione delle risorse raggruppate.
  • Tempo di timeout massimo della task del contenitore: durata di esecuzione di applicazioni o componenti a vita lunga.

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 carichi di lavoro. 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, handler personalizzati per gli eventi del ciclo di vita dei container, e condivisione del nome dello spazio dei processi tra più contenitori.

Cloud Run supporta direttamente un sottoinsieme della piattaforma dell'API Pod di 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 contenitore per l'ambiente di esecuzione Cloud Run è relativamente semplice e adatto alla maggior parte dei carichi di lavoro di pubblicazione. Tuttavia, il contratto specifica alcuni requisiti che devono essere soddisfatti. Se la tua applicazione o le sue dipendenze non sono in grado di soddisfare questi requisiti o se hai bisogno di un grado di controllo più fine 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 i costi di gestione.

Gestione e instradamento del traffico di rete

Sia Cloud Run che GKE Autopilot si integrano con il bilanciamento del carico di Google Cloud. Tuttavia, GKE Autopilot fornisce inoltre un insieme completo e potente di primitive per configurare l'ambiente di rete per le comunicazioni tra servizi. Le opzioni di configurazione includono autorizzazioni granulari e segregazione a livello di livello di rete mediante l'utilizzo di spazi dei nomi e policy di rete, il ricoprimento 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 indirizzato nei servizi e tra i servizi del cluster.

Poiché Autopilot è altamente configurabile, può essere l'opzione migliore se hai più servizi con un elevato grado di dipendenza in rete o requisiti complessi per il routing del traffico tra i componenti dell'applicazione. Un esempio di questo pattern è un'applicazione distribuita che viene distinta in numerosi microservizi che hanno pattern complessi di interdipendenza. In questi scenari, le opzioni di configurazione di Autopilot Networking 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. Lo scaling orizzontale offre una maggiore potenza di elaborazione quando è richiesta e la rimuove quando non è necessaria. Per un carico di lavoro tipico, solitamente Cloud Run può eseguire lo scaling out più rapidamente di GKE Autopilot per rispondere agli picchi nel numero di richieste al secondo. Ad esempio, la dimostrazione video "Novità del calcolo serverless" mostra il ridimensionamento di Cloud Run da zero a oltre 10.000 istanze in circa 10 secondi. Per aumentare la velocità della scalabilità orizzontale su Kubernetes (a un costo aggiuntivo), Autopilot ti consente di provisionare una capacità di calcolo aggiuntiva.

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

Cloud Run può scalare automaticamente le applicazioni fino a zero repliche quando non sono in uso, il che è utile per determinati casi d'uso che si concentrano in modo particolare sull'ottimizzazione dei costi. A causa delle caratteristiche del modo in cui le applicazioni possono scalare a zero, esiste più passaggi di ottimizzazione che puoi eseguire per ridurre al minimo il tempo tra l'arrivo di una richiesta e il momento in cui l'applicazione è in esecuzione ed è in grado di elaborare la richiesta.

Supporto per le applicazioni stateful

Autopilot offre un supporto completo dei volumi Kubernetes, supportato da dischi permanenti che ti consentono di eseguire una vasta gamma di implementazioni con stato, inclusi i database self-managed. Sia Cloud Run che GKE Autopilot ti consentono di connetterti ad altri servizi come i bucket Filestore e Cloud Storage. Entrambi includono anche la possibilità di montare i bucket dell'object store 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 l'utilizzo della memoria dell'applicazione e del contenitore contribuiscono a esaurire il limite di memoria. Puoi evitare questo problema se utilizzi un volume in memoria dedicato con un limite di dimensioni.

Un container di servizio o job Cloud Run ha un timeout della task massimo. Un contenitore in esecuzione all'interno di un pod in un cluster Autopilot può essere riprogrammato, in base a eventuali vincoli configurati con i budget per le interruzioni 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 riduzione. In genere, il timeout dell'attività è più probabile che sia un fattore da considerare per i carichi di lavoro batch in Cloud Run. Per i carichi di lavoro 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 CPU

Tutte le piattaforme di calcolo di Google Cloud supportano l'architettura CPU x86. Cloud Run non supporta processori con architettura ARM, ma Autopilot supporta i nodi gestiti basati su architettura ARM. Se il tuo carico di lavoro 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 consumare risorse riservate. Cloud Run supporta l'utilizzo delle GPU con alcune limitazioni.

Requisiti elevati di memoria, CPU e altre risorse

Rispetto ai limiti di richiesta 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 carichi di lavoro, Cloud Run potrebbe avere altri limiti che limitano 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 il risultato di uno dei seguenti motivi:

  1. I requisiti dell'applicazione (ad esempio, l'applicazione chiama API Kubernetes o utilizza risorse personalizzate 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 complessa per il multitenancy

Se la tua organizzazione ha strutture organizzative o requisiti per il multitenancy particolarmente complessi, utilizza Autopilot per sfruttare il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes. Per un'opzione più semplice, puoi utilizzare le funzionalità di sicurezza e separazione integrate in Cloud Run.

Considerazioni organizzative

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

  • Strategia tecnica generale: la direzione tecnica della tua organizzazione.
  • Sfruttamento dell'ecosistema Kubernetes: interesse a sfruttare la community di software open source.
  • Strumenti interni esistenti: utilizzo attuale di determinati strumenti.
  • Profili del team di sviluppo: competenze ed esperienza degli sviluppatori.
  • Assistenza operativa: competenze e obiettivi 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 avere strategie concordate per preferire determinate tecnologie rispetto ad altre. Ad esempio, se un team ha un accordo per standardizzare, ove possibile, su serverless o Kubernetes, questo accordo potrebbe influenzare o addirittura dettare un ambiente di runtime target.

Se un determinato carico di lavoro non è adatto all'ambiente di runtime specificato nella strategia, puoi decidere di eseguire una o più delle seguenti operazioni, con le relative limitazioni:

  • Ridisegna il carico di lavoro. Tuttavia, se il carico di lavoro non è adatto, questa operazione potrebbe comportare prestazioni, costi, sicurezza o altre caratteristiche non ottimali.
  • Registra il carico di lavoro come eccezione alla direzione strategica. Tuttavia, se le eccezioni vengono usate troppo spesso, il risultato può essere un portafoglio di tecnologie eterogeneo.
  • Riconsidera la strategia. Tuttavia, questa operazione può comportare un overhead delle norme che può ostacolare o bloccare l'avanzamento.

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 di scelta per via del suo 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, un'ampia gamma di strumenti di terze parti, standard solidi e portabilità. 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, puoi scegliere di continuare a utilizzare strumenti di deployment come ArgoCD, strumenti di sicurezza e criteri 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 lungo tempo di implementazione per un ambiente target alternativo.

Profili del team di sviluppo

Un team di applicazioni o carichi di lavoro potrebbe avere esperienza precedente con Kubernetes che può accelerare la velocità e la capacità del team di eseguire il deployment su Autopilot. Un team può impiegare del tempo per acquisire dimestichezza con un nuovo ambiente di runtime. A seconda del modello operativo, questa operazione potrebbe potenzialmente contribuire a ridurre l'affidabilità della piattaforma durante il periodo di aggiornamento delle competenze.

Per un team in crescita, la capacità di assumere potrebbe influire sulla scelta della piattaforma da parte di un'organizzazione. In alcuni mercati, le competenze Kubernetes potrebbero essere scarse e quindi pretendere un premio di assunzione. La scelta di un ambiente come Cloud Run può aiutarti a semplificare la procedura di assunzione e consentire una crescita più rapida del team rispettando il budget.

Assistenza operativa

Quando scegli un ambiente di runtime, prendi in considerazione 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à, dall'utilizzo di procedure manuali o da meccanismi di implementazione complicati.

Se utilizzi Kubernetes, un team di operations o di ingegneria della piattaforma centrale può gestire gli upgrade di Kubernetes Autopilot. Sebbene gli upgrade siano automatici, in genere il personale operativo li monitora attentamente per garantire interruzioni minime dei carichi di lavoro. Alcune organizzazioni scelgono di eseguire manualmente l'upgrade delle versioni del piano di controllo. GKE Enterprise include inoltre funzionalità per semplificare e velocizzare la gestione delle applicazioni su più cluster.

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

Selezione

Per iniziare la procedura di selezione, parla con i vari stakeholder. Per ogni applicazione, riunisci un gruppo di lavoro composto da sviluppatori, personale operativo, rappresentanti di qualsiasi gruppo di governance della tecnologia centrale, utenti e consumatori di applicazioni interne, sicurezza, team di ottimizzazione finanziaria del cloud e altri ruoli o gruppi all'interno della tua organizzazione che potrebbero essere pertinenti. Puoi scegliere di distribuire un sondaggio per raccogliere informazioni al fine di raccogliere le caratteristiche delle applicazioni e condividere i risultati prima della sessione. Ti consigliamo di selezionare un piccolo gruppo di lavoro che includa solo gli stakeholder richiesti. Tutti i rappresentanti potrebbero non essere necessari 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 orientare 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 dell'applicazione nel nuovo ambiente.

Passaggi successivi

Collaboratori

Autore: Henry Bell | Cloud Solutions Architect

Altri collaboratori: