Google Cloud offre due piattaforme principali per l'esecuzione di applicazioni containerizzate: GKE per l'esecuzione di container sui cluster Kubernetes e Cloud Run per l'esecuzione di container direttamente nell'infrastruttura Google Cloud. Ma quando dovresti utilizzare l'una o l'altra? Puoi utilizzare entrambe? Questa pagina offre un confronto tra le due piattaforme e i relativi vantaggi e ti aiuta a capire se una strategia ibrida o monopiattaforma è adatta alle tue esigenze.
Questa pagina è progettata per gli amministratori dell'infrastruttura e gli operatori di applicazioni che eseguono un insieme diversificato di carichi di lavoro containerizzati e vogliono sfruttare i punti di forza sia di Google Kubernetes Engine (GKE) sia di Cloud Run per distribuire le applicazioni sulla Google Cloud Platform.
Prima di leggere questa pagina, assicurati di conoscere:
Carichi di lavoro stateless e stateful
Perché utilizzare GKE e Cloud Run insieme?
GKE e Cloud Run offrono vantaggi diversi per l'esecuzione di applicazioni containerizzate e si adattano a diversi livelli di complessità del carico di lavoro. Tuttavia, non devi scegliere tra le due piattaforme. Puoi sfruttare contemporaneamente i punti di forza di GKE e Cloud Run eseguendo la migrazione dei carichi di lavoro tra le due piattaforme in base alle esigenze. Una strategia ibrida come questa può aiutarti a ottimizzare i costi, le prestazioni e l'overhead di gestione.
Di seguito sono riportati alcuni vantaggi dell'utilizzo di entrambi i runtime per il deployment dei carichi di lavoro:
GKE e Cloud Run offrono un livello relativamente elevato di trasportabilità:
Entrambe le piattaforme utilizzano immagini container standard come artefatti di deployment. Puoi utilizzare la stessa immagine per la tua applicazione in entrambe le piattaforme senza alcuna modifica, consentendo così la migrazione senza problemi dei carichi di lavoro tra GKE e Cloud Run. Non è necessario aggiornare la configurazione di integrazione continua per eseguire la migrazione tra GKE e Cloud Run, a condizione che le immagini dei contenitori siano archiviate in Artifact Registry.
GKE e Cloud Run utilizzano entrambi un modello API dichiarativo. L'API Cloud Run Admin v1 è progettata per essere compatibile con l'API Kubernetes. Ciò significa che puoi utilizzare concetti di Kubernetes familiari come deployment, servizi e scalabilità automatica dei pod orizzontali per gestire il tuo servizio Cloud Run. Questa somiglianza consente di tradurre più facilmente le configurazioni tra le due piattaforme.
Le risorse sono rappresentate nei file YAML con la stessa struttura dichiarativa e standard e possono quindi essere migrate facilmente tra i runtime. Ecco un esempio che confronta i file YAML di un deployment Kubernetes e di un servizio Cloud Run.
GKE e Cloud Run si integrano perfettamente con Cloud Logging e Cloud Monitoring, fornendoti una visualizzazione centralizzata nella console Google Cloud per osservare le metriche delle applicazioni indipendentemente dalla piattaforma. Puoi anche utilizzare il monitoraggio degli obiettivi del livello di servizio (SLO) su entrambe le piattaforme e visualizzare una visualizzazione unificata degli SLO nella dashboard di Cloud Monitoring.
Puoi implementare la distribuzione continua alle risorse GKE o ai servizi Cloud Run utilizzando Cloud Deploy. In alternativa, se preferisci, esegui il deployment dell'applicazione contemporaneamente in GKE e Cloud Run utilizzando il deployment parallelo.
Puoi semplificare la gestione avanzata del traffico utilizzando bilanciatori del carico esterni e interni per i servizi su GKE e Cloud Run. Ciò include la possibilità di esporre endpoint esterni in modo da poter eseguire il deployment ed eseguire URL diversi per la stessa applicazione su entrambe le piattaforme. Puoi anche suddividere il traffico verso lo stesso servizio tra GKE e Cloud Run, consentendo una migrazione senza problemi da una piattaforma all'altra.
Google Cloud fornisce strumenti di sicurezza per migliorare la tua strategia di sicurezza quando utilizzi entrambi i runtime. La scansione del sistema operativo ti consente di eseguire la scansione dei container per rilevare le vulnerabilità prima di eseguire il deployment su una delle due piattaforme. Un criterio di Autorizzazione binaria centrale può applicare l'integrazione con il piano di controllo di GKE e Cloud Run per consentire o bloccare il deployment delle immagini in base ai criteri che definisci. Con i Controlli di servizio VPC, i team di sicurezza possono definire controlli perimetrali granulari per le risorse GKE e Cloud Run.
Confronta GKE e Cloud Run
Per sfruttare le migliori funzionalità di GKE e Cloud Run e sapere quando spostare i carichi di lavoro da un servizio all'altro, è importante capire in che modo i due servizi differiscono tra loro.
| Funzionalità | GKE | Cloud Run |
|---|---|---|
| Deployment e gestione | Gestisci i cluster Kubernetes, inclusa la configurazione dei nodi, il networking, la scalabilità e gli upgrade. Google Cloud gestisce l'infrastruttura sottostante e fornisce strumenti per semplificare le operazioni del cluster, ma sei comunque responsabile degli aspetti fondamentali di Kubernetes. |
Esegui i container direttamente sull'infrastruttura scalabile di Google Cloud. Devi solo fornire il codice sorgente o un'immagine container e Cloud Run può creare il container per te. Non devi creare un cluster né eseguire il provisioning e la gestione dell'infrastruttura. |
| Controllo e flessibilità | Controllo completo sul cluster Kubernetes. Puoi creare personalizzazioni avanzate di configurazioni dei nodi, criteri di rete, impostazioni di sicurezza e componenti aggiuntivi. |
Controllo limitato sull'infrastruttura sottostante. Puoi configurare elementi quali variabili di ambiente, concorrenza e connessioni di rete, ma non puoi personalizzare l'infrastruttura o l'ambiente sottostanti. Ideale per semplicità e velocità. |
| Tipi di applicazione | Supporta sia le applicazioni stateless che quelle stateful ed è ideale per applicazioni complesse con esigenze di risorse specifiche. | Ideale per servizi, web service e funzioni stateless, su richiesta o basati su eventi. |
| Modello di determinazione del prezzo | Pagamento per cluster all'ora, indipendentemente dalla modalità di funzionamento (Standard o Autopilot), dalle dimensioni o dalla topologia del cluster. | A consumo, arrotondato per eccesso ai 100 millisecondi più vicini. |
Caso d'uso
Supponiamo che tu sia un amministratore della piattaforma di un'azienda di vendita al dettaglio che sta creando una grande piattaforma di e-commerce. Devi eseguire il deployment dei seguenti carichi di lavoro containerizzati:
Sito web e app mobile frontend: un'applicazione web senza stato che gestisce la navigazione, la ricerca e il pagamento dei prodotti.
Gestione dell'inventario dei prodotti: un servizio con stato che gestisce la disponibilità e gli aggiornamenti dei prodotti.
Motore per suggerimenti: un microservizio complesso che genera consigli personalizzati sui prodotti per ogni utente.
Job di elaborazione batch: includono attività periodiche come l'aggiornamento dei cataloghi di prodotti e l'analisi del comportamento degli utenti.
Questi carichi di lavoro rappresentano un mix di servizi stateless e stateful, quindi decidi di sfruttare sia GKE che Cloud Run per prestazioni ottimali. Ecco un modo per implementare un approccio ibrido per i carichi di lavoro.
Dopo aver letto i criteri di idoneità dei carichi di lavoro Cloud Run, decidi di utilizzare Cloud Run per il sito web, l'app mobile e i job di elaborazione batch. Il deployment di questi servizi su Cloud Run offre i seguenti vantaggi:
La scalabilità automatica consente di gestire i picchi di traffico e i job batch di grandi dimensioni senza intervento manuale.
Efficienza in termini di costi con un modello a consumo. Paghi solo quando gli utenti navigano o effettuano il pagamento e quando le risorse vengono utilizzate durante l'esecuzione dei job batch.
Deployment più rapidi perché gli aggiornamenti sono disponibili immediatamente, migliorando l'esperienza utente.
Facile integrazione con altri servizi Google Cloud. Ad esempio, per l'elaborazione basata su eventi, puoi utilizzare le funzioni Cloud Run per avviare job di elaborazione collettiva su Cloud Run e abilitare flussi di lavoro senza interruzioni.
La gestione dell'inventario dei prodotti è un servizio con stato che richiede un controllo granulare e soluzioni di archiviazione potenzialmente personalizzate. Decidi di utilizzare GKE per eseguire il deployment di questo servizio in quanto offre archiviazione permanente e ti consente di collegare volumi per la persistenza e l'affidabilità dei dati di prodotto.
Il motore di consigli è un microservizio complesso che sfrutta GKE. Con GKE puoi gestire dipendenze complesse ed esercitare un controllo granulare sull'allocazione e sul scaling delle risorse.
GKE è ideale per architetture di microservizi complesse, applicazioni stateful, carichi di lavoro che richiedono configurazioni di rete o dell'infrastruttura personalizzate e scenari in cui è essenziale un controllo approfondito di Kubernetes. Cloud Run è ideale per le app basate su eventi. È ideale per servizi web stateless, API, job batch e altri carichi di lavoro che beneficiano di prezzi di pagamento per utilizzo.
L'esempio precedente mostra come la combinazione di GKE e Cloud Run può fornire una soluzione efficace e flessibile per la tua piattaforma di e-commerce. Puoi usufruire dei vantaggi di entrambe le piattaforme: l'efficienza serverless per i carichi di lavoro stateless e il controllo Kubernetes per i microservizi e i componenti stateful complessi.
Considerazioni
GKE e Cloud Run si completano a vicenda, rispondendo a esigenze diverse in un panorama di applicazioni complesso.
Di seguito sono riportate alcune considerazioni da tenere presenti quando si adotta un approccio ibrido per il deployment dei carichi di lavoro:
Esegui microservizi stateless su Cloud Run per ottenere convenienza e scalabilità in termini di costi.
Esegui il deployment di applicazioni stateful complesse che richiedono una personalizzazione approfondita su GKE.
Se utilizzi una rete privata su Google Cloud, per accedere alle risorse nel tuo cluster GKE dal servizio Cloud Run, puoi inviare una richiesta a una rete Virtual Private Cloud (VPC) utilizzando l'uscita diretta VPC. Per accedere ai servizi Kubernetes nel cluster GKE, il servizio Cloud Run deve essere connesso alla rete VPC del cluster e il servizio Kubernetes deve utilizzare un bilanciatore del carico di rete passthrough interno.
Per eseguire la migrazione del traffico tra Cloud Run e GKE, puoi esporre endpoint esterni dietro un bilanciatore del carico delle applicazioni esterno globale. Quando implementi questo bilanciatore del carico davanti ai servizi in entrambi i runtime, puoi eseguire il deployment della stessa applicazione sia su Cloud Run sia su GKE, il che ti consente di spostare gradualmente il traffico da una piattaforma all'altra.
Per esporre i servizi Cloud Run in Virtual Private Cloud dietro IP privati, utilizza un bilanciatore del carico interno.
Ricorda che, se i tuoi carichi di lavoro sono già su Cloud Run, puoi sempre eseguire la migrazione a GKE in base alle tue esigenze.
Quando non utilizzare GKE e Cloud Run insieme
Sebbene GKE e Cloud Run offrano un approccio convincente per molti carichi di lavoro containerizzati, in alcune situazioni l'utilizzo combinato potrebbe non essere la soluzione migliore. Ecco alcuni esempi di casi in cui potresti decidere di non adottare un approccio ibrido:
Microservizi accoppiati rigidamente: se i microservizi sono altamente dipendenti tra loro e richiedono comunicazioni frequenti e a bassa latenza, la loro gestione su piattaforme separate può introdurre complessità. Chiamate di rete frequenti tra le piattaforme potrebbero aggiungere overhead e potenziali colli di bottiglia, con un impatto sulle prestazioni.
Applicazioni legacy con dipendenze personalizzate: se la tua applicazione si basa su librerie, framework o configurazioni specifiche non supportate da Cloud Run, l'utilizzo di queste per parti dell'applicazione potrebbe richiedere refactoring o soluzioni alternative significative. Ciò può annullare i vantaggi del serverless e introdurre un overhead di manutenzione specifico della piattaforma.
Limiti di budget con carichi di lavoro prevedibili: se il tuo carico di lavoro ha requisiti di risorse coerenti e hai un budget limitato, il modello di pagamento per nodo di GKE potrebbe essere più conveniente della fatturazione pay-per-use di Cloud Run. Se hai carichi di lavoro prevedibili, potresti non utilizzare appieno i vantaggi della scalabilità automatica di Cloud Run, rendendo più interessante il costo fisso di GKE.
L'approccio migliore dipende in ultima analisi dalle tue esigenze e priorità specifiche. Valuta attentamente i requisiti, le limitazioni delle risorse e le competenze del team della tua applicazione prima di decidere su un'architettura ibrida GKE e Cloud Run.
Passaggi successivi
Scopri come convertire il servizio Cloud Run in un deployment Kubernetes in Eseguire la migrazione da Cloud Run a GKE.
Esegui il packaging del deployment Kubernetes in un container compatibile con Cloud Run seguendo la procedura descritta in Eseguire la migrazione da Kubernetes a Cloud Run.