Google Cloud offre due piattaforme principali per l'esecuzione di applicazioni containerizzate: GKE per l'esecuzione di container su cluster Kubernetes e Cloud Run per l'esecuzione di container direttamente sull' Google Cloud infrastruttura. Ma quando è consigliabile utilizzare una o l'altra? E puoi utilizzarle entrambe? Questa pagina fornisce un confronto tra le due piattaforme e i relativi vantaggi e ti aiuta a scoprire se una strategia a piattaforma singola o ibrida è adatta alle tue esigenze.
Questa pagina è pensata per gli amministratori dell'infrastruttura e gli operatori delle applicazioni che eseguono un insieme diversificato di carichi di lavoro containerizzati e vogliono sfruttare i punti di forza di Google Kubernetes Engine (GKE) e Cloud Run per eseguire il deployment delle applicazioni sulla Google Cloud piattaforma.
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 soddisfano diversi livelli di complessità dei carichi di lavoro. Tuttavia, non è necessario 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ò consentirti di 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 di portabilità relativamente elevato:
Entrambe le piattaforme utilizzano immagini container standard come artefatti di deployment. Puoi utilizzare la stessa immagine per l'applicazione in entrambe le piattaforme senza modifiche, consentendo così la migrazione senza interruzioni dei carichi di lavoro tra GKE e Cloud Run. Non è necessario aggiornare la configurazione dell'integrazione continua per eseguire la migrazione tra GKE e Cloud Run, a condizione che le immagini container siano archiviate in Artifact Registry.
GKE e Cloud Run utilizzano entrambi un modello di API dichiarativo. L'API Cloud Run Admin v1 è progettata per essere compatibile con l'API Kubernetes. Ciò significa che puoi utilizzare concetti Kubernetes familiari come deployment, servizi e scalabilità automatica orizzontale dei pod per gestire il servizio Cloud Run. Questa somiglianza semplifica la traduzione delle configurazioni tra le due piattaforme.
Le risorse sono rappresentate in 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.
Sia GKE che Cloud Run si integrano perfettamente con Cloud Logging e Cloud Monitoring, fornendoti una visualizzazione centralizzata della Google Cloud console 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 delle risorse GKE o dei servizi Cloud Run utilizzando Cloud Deploy. In alternativa, se preferisci, puoi eseguire il deployment simultaneo dell'applicazione sia su GKE che su Cloud Run utilizzando il deployment parallelo.
Puoi facilitare 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 interruzioni da una piattaforma all'altra.
Google Cloud fornisce strumenti di sicurezza per migliorare la tua security posture quando utilizzi entrambi i runtime. La scansione del sistema operativo consente di eseguire la scansione dei container per rilevare le vulnerabilità prima del 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 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 funzionalità migliori di GKE e Cloud Run e sapere quando spostare i carichi di lavoro tra le due piattaforme, è importante capire in cosa differiscono i due servizi.
| Funzionalità | GKE | Cloud Run |
|---|---|---|
| Deployment e gestione | Gestisci i cluster Kubernetes, inclusi configurazione dei nodi, networking, scalabilità e upgrade. Google Cloud gestisce l'infrastruttura sottostante e fornisce strumenti per semplificare le operazioni del cluster, ma la responsabilità per gli aspetti principali di Kubernetes rimane tua. |
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 del cluster Kubernetes. Puoi creare personalizzazioni avanzate delle configurazioni dei nodi, delle policy di rete, delle impostazioni di sicurezza e degli add-on. |
Controllo limitato sull'infrastruttura sottostante. Puoi configurare elementi come 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 applicazioni | Supporta applicazioni stateful e stateless ed è ideale per applicazioni complesse con esigenze di risorse specifiche. | Ideale per servizi stateless, basati su richieste o eventi, servizi web e funzioni. |
| Modello di determinazione del prezzo | Pagamento per cluster all'ora, indipendentemente dalla modalità operativa (Standard o Autopilot), dalle dimensioni o dalla topologia del cluster. | Pagamento in base all'utilizzo, 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 stateless che gestisce la navigazione, la ricerca e il pagamento dei prodotti.
Gestione dell'inventario dei prodotti: un servizio stateful che gestisce la disponibilità e gli aggiornamenti dei prodotti.
Motore per suggerimenti: un microservizio complesso che genera suggerimenti sui prodotti personalizzati per ogni utente.
Job di elaborazione batch: include 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 ottenere prestazioni ottimali. Ecco un modo per implementare un approccio ibrido per i tuoi 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 e l'app mobile e per i job di elaborazione batch. Il deployment di questi servizi su Cloud Run offre i seguenti vantaggi:
Scalabilità automatica quando vengono gestiti picchi di traffico e job batch di grandi dimensioni senza intervento manuale.
Efficienza dei costi con un modello di pagamento in base all'utilizzo. 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 man mano che gli aggiornamenti sono disponibili immediatamente, migliorando l'esperienza utente.
Facile integrazione con altri Google Cloud servizi. Ad esempio, per l'elaborazione basata su eventi, puoi utilizzare le funzioni Cloud Run per avviare job di elaborazione batch su Cloud Run e abilitare flussi di lavoro senza interruzioni.
La gestione dell'inventario dei prodotti è un servizio stateful che richiede un controllo granulare e potenzialmente soluzioni di archiviazione personalizzate. Decidi di utilizzare GKE per eseguire il deployment di questo servizio perché offre spazio di archiviazione permanente e ti consente di collegare volumi per la persistenza e l'affidabilità dei dati dei prodotti.
Il motore per suggerimenti è un microservizio complesso che trae vantaggio da GKE. Con GKE, puoi gestire dipendenze complesse ed esercitare un controllo granulare sull'allocazione e sulla scalabilità delle risorse.
GKE è più adatto per architetture di microservizi complesse, applicazioni stateful, carichi di lavoro che richiedono configurazioni di infrastruttura o rete personalizzate e scenari in cui è essenziale un controllo approfondito di Kubernetes. Cloud Run è più adatto per le app basate su eventi. È ideale per servizi web stateless, API, job batch e altri carichi di lavoro che traggono vantaggio dai prezzi in base all'utilizzo.
L'esempio precedente mostra come la combinazione di GKE e Cloud Run possa fornire una soluzione potente e flessibile per la tua piattaforma di e-commerce. Ottieni i vantaggi di entrambe le piattaforme: efficienza serverless per i carichi di lavoro stateless e controllo Kubernetes per microservizi complessi e componenti stateful.
Per una visualizzazione unificata dei componenti disparati di cui è stato eseguito il deployment con un approccio ibrido e per vedere come funzionano insieme come un'applicazione coesa, puoi utilizzare App Hub. Per ulteriori informazioni, consulta Risorse supportate di App Hub.
Considerazioni
GKE e Cloud Run si completano a vicenda, rispondendo a esigenze diverse in un panorama di applicazioni complesse.
Di seguito sono riportate alcune considerazioni sull'adozione di un approccio ibrido al deployment dei carichi di lavoro:
Esegui microservizi stateless su Cloud Run per l'efficienza dei costi e la scalabilità.
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 VPC diretta. 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 che su GKE, consentendoti di spostare gradualmente il traffico da una piattaforma all'altra.
Per esporre i servizi Cloud Run in Virtual Private Cloud dietro indirizzi 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 esigenze.
Quando non utilizzare GKE e Cloud Run insieme
Sebbene GKE e Cloud Run offrano un approccio interessante per molti carichi di lavoro containerizzati, in alcune situazioni il loro utilizzo congiunto potrebbe non essere la soluzione migliore. Ecco alcuni esempi di casi in cui potresti decidere di non adottare un approccio ibrido:
Microservizi strettamente accoppiati: se i microservizi sono altamente dipendenti l'uno dall'altro e richiedono comunicazioni frequenti a bassa latenza, la loro gestione su piattaforme separate può introdurre complessità. Le 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, il suo utilizzo per parti dell'applicazione potrebbe richiedere un refactoring o soluzioni alternative significative. Ciò può annullare i vantaggi serverless e introdurre un overhead di manutenzione specifico della piattaforma.
Vincoli 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 rispetto alla fatturazione in base all'utilizzo di Cloud Run. Se hai carichi di lavoro prevedibili, potresti non utilizzare completamente i vantaggi della scalabilità automatica di Cloud Run, rendendo più interessante il costo fisso di GKE.
L'approccio migliore dipende in definitiva dalle tue esigenze e priorità specifiche. Valuta attentamente i requisiti dell'applicazione, i vincoli delle risorse e le competenze del team prima di decidere 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.
Pacchettizza il deployment Kubernetes in un container compatibile con Cloud Run seguendo la procedura descritta in Eseguire la migrazione da Kubernetes a Cloud Run.