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 al cloud che devono scegliere un runtime dei container 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 un capacità. 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 la gestione degli utenti dei e l'infrastruttura di computing.

  • Ambienti di runtime meno gestiti:

    • GKE Standard, ottimizzato per le aziende carichi di lavoro standard e offre scalabilità a un cluster singolo fino a 15.000 nodi.
    • Compute Engine che include i componenti ottimizzati per l'acceleratore Famiglia di macchine virtuali A3 per machine learning (ML) e computing ad alte prestazioni (HPC) carichi di lavoro con scale out impegnativi.

    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 un una visione più ampia degli ambienti di runtime di Google Cloud, consulta Opzioni di hosting di applicazioni Google Cloud guida.

Panoramica degli ambienti

Questa sezione fornisce una panoramica di Cloud Run e di GKE Autopilot. Cloud Run e GKE Autopilot sono entrambi strettamente integrati in Google Cloud, quindi c'è molta 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 inoltre VPC Networking, Identity-Aware Proxy (IAP), e Google Cloud Armor per quando è necessario un networking privato più granulare. Entrambe le piattaforme ti addebita 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 distribuzione continua Cloud Deploy, per garantire che il deployment delle applicazioni venga eseguito in modo sicuro e affidabile e produzione. Ciò significa che tu e i tuoi team avete il controllo sulle decisioni relative alla compilazione e al deployment.

Data la condivisione tra le due piattaforme, potresti prendere in considerazione sfruttare i punti di forza di ciascuno adottando un approccio flessibile per eseguire il deployment delle tue applicazioni, come descritto in dettaglio nella guida Usa 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 inoltre il deployment del codice dell'applicazione le seguenti fonti:

  • 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 di base 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 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 carico di lavoro sono adatte a un piattaforma, l'ambiente di runtime serverless di Cloud Run ideale. L'utilizzo di Cloud Run può ridurre l'infrastruttura gestione indipendente, minore configurazione autogestita e conseguente riduzione delle operazioni overhead. 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 fornisce la potente astrazione di una piattaforma aperta, utilizzandola complessità. Se non hai bisogno di Kubernetes, ti consigliamo di valutare per capire 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 condivisione tra Autopilot e Cloud Run descritti precedenti, la migrazione tra le piattaforme è un'attività in assenza di ostacoli 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 carico di lavoro, devi tenere conto considerazioni tecniche e organizzative. Le considerazioni tecniche sono caratteristiche della tua applicazione o dell'ambiente di runtime di Google Cloud. Le considerazioni organizzative non sono tecniche caratteristiche della tua organizzazione o del tuo team che potrebbero influenzare le tue decisioni.

Considerazioni tecniche

Alcune considerazioni tecniche che influenzeranno la scelta sono le seguenti:

  • Controllo e configurabilità: granularità del controllo delle 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 applicazioni stateful: funzionalità per l'archiviazione permanente.
  • Architettura CPU: supporto di diversi tipi di CPU.
  • Offload dell'acceleratore (GPU e TPU): possibilità di eseguire l'offload dell'acceleratore a un hardware dedicato.
  • Elevata capacità di memoria, CPU e altre risorse: livello di varie risorse consumate.
  • Dipendenza esplicita da Kubernetes: requisiti per l'API Kubernetes all'utilizzo delle risorse.
  • RBAC complesso per il multitenancy: supporto per la condivisione delle risorse raggruppate.
  • Tempo massimo di timeout delle attività del container: durata dell'esecuzione di per applicazioni o componenti di lunga durata.

Le seguenti sezioni descrivono nel 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 Superficie API pod di Kubernetes, descritto nel riferire YAML per l'oggetto del servizio Cloud Run e riferire YAML per l'oggetto Cloud Run Job. Queste guide di riferimento possono aiutarti a valutare le due piattaforme insieme ai tuoi requisiti dell'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 ti consigliamo di scegliere Cloud Run come runtime completamente gestito di Google Cloud. 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 ricco e potente insieme di primitive per la configurazione dell'ambiente di rete per le comunicazioni. 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 ricollegamento delle porte e il rilevamento dei servizi DNS integrato all'interno del cluster. GKE Autopilot supporta anche configurabili e flessibili API Gateway. Questa funzionalità offre un potente controllo sul modo in cui il traffico viene instradato e tra i servizi nel 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 scomposti in numerosi microservizi che hanno modelli complessi di interdipendenza. In questi scenari, Le opzioni di configurazione del networking Autopilot possono aiutarti a gestire controllare le interazioni tra i servizi.

Scalabilità orizzontale e verticale

Cloud Run e GKE Autopilot supportare 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 il ridimensionamento in espansione più rapidamente di GKE Autopilot per rispondere agli picchi nel numero di richieste al secondo. Ad esempio, il video dimostrativo "Novità del serverless computing?" 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 il provisioning di 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 scalabilità verticale per variare in modo dinamico la potenza di elaborazione disponibile senza e 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 dei caratteristiche della scalabilità delle tue applicazioni fino a zero, esistono più passaggi di ottimizzazione che puoi adottare per ridurre al minimo il tempo che intercorre tra l'arrivo di una richiesta e al momento giusto in cui la tua applicazione è attiva ed è in grado di elaborare richiesta.

Supporto per le applicazioni stateful

Autopilot offre il supporto completo per i volumi Kubernetes, con il supporto Dischi permanenti che consentono di eseguire un'ampia gamma di deployment stateful, tra cui autogestiti. Sia Cloud Run che GKE Autopilot ti consente di connetterti ad altri servizi come Filestore e i bucket 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. Nella inoltre, il file system in memoria locale viene condiviso con la memoria dei un'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 computing Google Cloud supportano l'architettura della CPU x86. Cloud Run non supporta Processori di architettura ARM, ma Autopilot supporta i nodi gestiti supportati Architettura. Se il tuo carico di lavoro richiede l'architettura Arm, dovrai utilizzare Autopilot.

Offload acceleratore

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

Requisiti elevati di memoria, CPU e altre risorse

Rispetto a Limiti per le richieste di risorse di GKE Autopilot, le risorse massime di CPU e memoria che possono essere utilizzate da una Il servizio o il job Cloud Run (una singola istanza) limitata. A seconda delle caratteristiche dei tuoi carichi di lavoro, Cloud Run potrebbero 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 le API Kubernetes o utilizza Kubernetes risorse personalizzate).
  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 l'architettura multi-tenancy

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 l'ambiente che scegli:

  • Strategia tecnica generica: 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 dello sviluppatore.
  • 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

Organizzazioni o team potrebbero aver concordato strategie per preferire certe tecnologie piuttosto che altre. Ad esempio, se un team ha un accordo per standardizzare ove possibile su serverless o Kubernetes, influenzare o addirittura determinare l'ambiente di runtime di destinazione.

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, ciò potrebbe determinare prestazioni, costi, sicurezza o altri problemi non ottimali caratteristiche.
  • Registrare il carico di lavoro come eccezione alla direzione strategica. Tuttavia, se le eccezioni vengono usate troppo spesso, questo può comportare un portafoglio di tecnologie eterogeneo.
  • Riconsidera la strategia. Tuttavia, ciò può comportare un sovraccarico delle norme che possono ostacolare o bloccare l'avanzamento.

Sfruttare l'ecosistema Kubernetes

Nell'ambito dell'ampia strategia tecnica descritta in precedenza, le organizzazioni o potrebbero decidere di scegliere Kubernetes come piattaforma preferita per via nell'ecosistema, in crescita e significativo. 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 ampio set di strumenti di terze parti, standard solidi e portabilità. Sfruttare l'ecosistema Kubernetes può accelerare lo sviluppo velocità e ridurre il time to market.

Strumenti interni esistenti

In alcuni casi, può essere vantaggioso utilizzare gli ecosistemi di strumenti esistenti all'organizzazione o al 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 dedicato alle applicazioni o ai carichi di lavoro potrebbe avere già esperienza con Kubernetes in grado di accelerare la velocità e la capacità del team di fornire Autopilot. Può volerci del tempo prima che un team apprenda bene un nuovo dell'ambiente di runtime. A seconda del modello operativo, ciò può potenzialmente portare possono comportare una minore affidabilità della piattaforma durante il periodo di miglioramento 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 su Kubernetes potrebbero essere scarse e, di conseguenza, un sovrapprezzo per l'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, considera l'esperienza e le capacità tuo SRE team DevOps e delle piattaforme e altro personale operativo. Le funzionalità i team operativi per supportare in modo efficace l'ambiente di produzione fondamentale 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 scegli di eseguire manualmente l'upgrade delle versioni del piano di controllo. GKE Enterprise include anche per ottimizzare e semplificare per la gestione delle applicazioni in 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. Di selezionando un singolo ambiente di runtime, puoi semplificare ulteriormente le operazioni i processi di machine learning. 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, formare un gruppo di lavoro composto da sviluppatori, del personale, rappresentanti di qualsiasi gruppo centrale per la governance della tecnologia, utenti e consumatori delle applicazioni, sicurezza, team di ottimizzazione cloud e finanziari, 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. I nostri suggerimenti di selezionare un piccolo gruppo di lavoro che includa solo i le parti interessate. 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 l'assistenza tecnica considerazioni 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: