Seleziona un ambiente di runtime del contenitore gestito

Last reviewed 2024-08-30 UTC

Questo documento ti aiuta a valutare i requisiti dell'applicazione e a scegliere tra Cloud Run e Google Kubernetes Engine (GKE) Autopilot, in base a considerazioni tecniche e organizzative. Questo documento è destinato agli architetti cloud che devono scegliere un ambiente di runtime del container di destinazione per i loro carichi di lavoro. Google Cloud Presuppone 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 Google Cloud offerte gestite:

Google Cloud offerte dalla più gestita alla meno gestita.

Il diagramma mostra quanto segue:

  • Ambienti di runtime più gestiti (l'argomento principale di questa guida):

    Queste opzioni sono gestite da Google, senza gestione utente dell'infrastruttura di calcolo sottostante.

  • Ambienti di runtime meno gestiti:

    • GKE Standard, ottimizzato per i workload aziendali e offre 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 grado di gestione dell'infrastruttura a livello utente, come le macchine virtuali (VM) che sono 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 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 Google Cloud ambienti di runtime, consulta la guida Google Cloud Opzioni di hosting delle applicazioni.

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 ci sono molte caratteristiche in comune tra i due. 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 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, come ambienti di runtime dei container, Cloud Run e GKE Autopilot sono supportati da servizi che compongono l'ecosistema dei container Google Cloud . Questi servizi includono Cloud Build, Artifact Registry, Autorizzazione binaria e distribuzione continua con Cloud Deploy, per garantire che le tue applicazioni vengano implementate in modo sicuro e affidabile in produzione. 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 alla posizione in cui esegui il deployment delle applicazioni, come descritto nella guida Utilizzare GKE e Cloud Run insieme. Le sezioni seguenti descrivono gli aspetti unici di Cloud Run e Autopilot.

Cloud Run

Cloud Run è una piattaforma di computing gestita serverless che ti consente di eseguire le tue applicazioni direttamente sull'infrastruttura scalabile di Google. Cloud Run fornisce 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:

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

Cloud Run incorpora una funzionalità di creazione e deployment che supporta sia FaaS sia la possibilità di creare dall'origine, oltre alla funzionalità di runtime del container predefinita. 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.

GKE Autopilot

GKE Autopilot è la modalità operativa del cluster predefinita e consigliata in GKE. Autopilot ti consente di eseguire applicazioni su Kubernetes senza l'overhead della gestione dell'infrastruttura. Quando utilizzi Autopilot, Google gestisce gli aspetti sottostanti chiave della configurazione del cluster, tra cui il provisioning e lo scaling dei nodi, la postura 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 l'allocazione delle risorse dell'infrastruttura per garantire la migliore corrispondenza, fornendo al contempo un SLA per i tuoi carichi di lavoro.

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

Scegliere 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 è ideale. L'utilizzo di Cloud Run può comportare una minore infrastruttura da gestire, una minore configurazione autogestita e quindi un overhead operativo inferiore. A meno che tu non voglia o abbia bisogno specificamente di Kubernetes, ti consigliamo di prendere in considerazione prima la soluzione 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 al 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 alla domanda se il workload è adatto al serverless. Data la comunanza tra Autopilot e Cloud Run descritta 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 modo più dettagliato, consulta Migrazione da Cloud Run a GKE e 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' Google Cloud ambiente di runtime. 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 la capacità di aumentare e diminuire dinamicamente.
  • Supporto per le applicazioni stateful: funzionalità per l'archiviazione dello stato persistente.
  • Architettura CPU: supporto di 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 di varie risorse consumate.
  • Dipendenza esplicita da Kubernetes: requisiti per l'utilizzo dell'API Kubernetes.
  • RBAC complesso per il multi-tenancy: supporto per la condivisione di risorse in pool.
  • Tempo di timeout massimo dell'attività del container: durata di 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 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, 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 Kubernetes Pod, 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 Cloud Run è relativamente semplice e si adatta 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 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, valuta la possibilità 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 il bilanciamento del carico di Google Cloud. Tuttavia, GKE Autopilot fornisce anche un insieme ricco e potente di primitive per configurare l'ambiente di rete per le comunicazioni da servizio a servizio. Le opzioni di configurazione includono autorizzazioni granulari e la separazione a livello di rete utilizzando spazi dei nomi e policy di rete, il remapping delle porte e il 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 all'interno e tra i servizi del cluster.

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

Scalabilità orizzontale e verticale

Cloud Run e GKE Autopilot supportano entrambi la scalabilità orizzontale manuale e automatica per servizi e job. Lo scale up orizzontale fornisce una maggiore potenza di elaborazione quando necessario e la rimuove quando non è necessaria. Per un carico di lavoro tipico, Cloud Run può in genere scalare più rapidamente di GKE Autopilot per rispondere ai picchi nel numero di richieste al secondo. Ad esempio, la dimostrazione video "What's New in Serverless Compute?" mostra lo scaling 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 calcolo 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ò scalare automaticamente le tue applicazioni fino a zero repliche quando non vengono utilizzate, il che è utile per determinati 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 più 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 la tua applicazione è in esecuzione ed è in grado di elaborare la richiesta.

Supporto per le applicazioni stateful

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

Cloud Run utilizza un file system in memoria, che potrebbe non essere adatto alle applicazioni che richiedono un file system locale persistente. Inoltre, il file system in memoria locale è condiviso con la memoria dell'applicazione. Pertanto, sia il file system temporaneo sia l'utilizzo della memoria dell'applicazione e del container 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 attività massimo. Un container in esecuzione all'interno di un pod in un cluster Autopilot può essere riprogrammato, nel rispetto di eventuali vincoli configurati con budget per l'interruzione dei pod (PDB). Tuttavia, i pod possono essere eseguiti fino a sette giorni quando sono protetti dall'espulsione causata da upgrade automatici dei nodi o eventi di riduzione della scalabilità. In genere, il timeout dell'attività è più probabile che venga preso in considerazione 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 Google Cloud le piattaforme di calcolo supportano l'architettura CPU x86. Cloud Run non supporta processori con architettura Arm, ma Autopilot supporta nodi gestiti basati sull'architettura Arm. Se il tuo workload richiede l'architettura Arm, devi utilizzare Autopilot.

Offload dell'acceleratore

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

Requisiti elevati di memoria, CPU e altre risorse

Rispetto ai limiti delle richieste di risorse di GKE Autopilot, le risorse massime di CPU e memoria 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 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 il risultato di 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 il multi-tenancy

Se la tua organizzazione ha strutture organizzative particolarmente complesse o requisiti per il multitenancy, 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 tua scelta dell'ambiente:

  • Strategia tecnica generale: l'indirizzo tecnico della tua organizzazione.
  • Sfruttare l'ecosistema Kubernetes: interesse a sfruttare la community OSS.
  • Strumenti interni esistenti: utilizzo di determinati strumenti da parte dell'incumbent.
  • Profili del team di sviluppo: competenze ed esperienza degli sviluppatori.
  • Supporto operativo: competenze e focus dei team operativi.

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

Strategia tecnica generale

Organizzazioni o 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 avvisi:

  • Riprogettare il carico di lavoro. Tuttavia, se il workload non è adatto, questa operazione 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 portafoglio tecnologico disparato.
  • Riconsidera la strategia. Tuttavia, questa operazione può comportare un sovraccarico di 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 decisione di utilizzare l'ecosistema Kubernetes si basa su una community attiva, su una vasta 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 ecosistemi di strumenti esistenti nella tua organizzazione o nel tuo team (per uno qualsiasi degli ambienti). Ad esempio, se utilizzi Kubernetes, potresti 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 consolidate per l'automazione della conformità organizzativa e altre funzionalità la cui implementazione per un ambiente di destinazione alternativo potrebbe essere costosa o richiedere tempi di attesa lunghi.

Profili dei team di sviluppo

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

Per un team in crescita, la capacità di assumere personale potrebbe influenzare la scelta della piattaforma da parte di un'organizzazione. In alcuni mercati, le competenze Kubernetes potrebbero essere scarse e quindi richiedere un premio di 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 SRE, DevOps e piattaforme, nonché 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 implementazione complessi.

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

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

Selezione

Per iniziare la procedura di selezione, parla con i vari stakeholder. Per ogni applicazione, crea un gruppo di lavoro composto da sviluppatori, personale operativo, rappresentanti di qualsiasi gruppo centrale di governance della tecnologia, utenti e consumatori interni dell'applicazione, team di sicurezza, 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 per 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 necessari. Potrebbe non essere necessario che tutti i rappresentanti siano presenti a ogni sessione di lavoro.

Potrebbe essere utile includere anche rappresentanti di altri team o gruppi che hanno esperienza nella creazione e nell'esecuzione di applicazioni su Autopilot o Cloud Run, o 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 dell'applicazione nel nuovo ambiente.

Passaggi successivi

Collaboratori

Autore: Henry Bell | Cloud Solutions Architect

Altri collaboratori: