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 eseguire il deployment di applicazioni sulla piattaforma Google Cloud. Una strategia ibrida ti consente di ottimizzare i costi, prestazioni e overhead per la gestione.
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 diversi vantaggi per l'esecuzione applicazioni containerizzate e si adattano a diversi livelli di carico di lavoro complessità. Tuttavia, non devi scegliere tra le due piattaforme. Puoi sfruttare contemporaneamente i punti di forza di GKE Cloud Run eseguendo la migrazione dei carichi di lavoro tra le due piattaforme necessità.
Di seguito sono riportati alcuni vantaggi dell'utilizzo di entrambi i runtime per eseguire il deployment dei carichi di lavoro:
GKE e Cloud Run offrono un livello relativamente alto portabilità:
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 configurazione dell'integrazione continua per eseguire la migrazione tra GKE e Cloud Run, purché le immagini container siano archiviati in Artifact Registry.
GKE e Cloud Run utilizzano entrambi un modello API dichiarativo. L'API Cloud Run Admin v1 è progettata per essere compatibili con l'API Kubernetes. Ciò significa che puoi utilizzare le Concetti di base di Kubernetes come deployment, servizi e pod orizzontale gestore della scalabilità automatica per gestire il tuo servizio Cloud Run. Questa somiglianza semplifica la traduzione delle configurazioni tra le due piattaforme.
Le risorse sono rappresentate in file YAML con le stesse struttura standard, per cui è quindi facile eseguire la migrazione da un runtime all'altro. 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, che forniscono una vista centralizzata sulla console Google Cloud per osservare le metriche dell'applicazione a prescindere 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 in entrambe le risorse GKE o Cloud Run utilizzando Cloud Deploy. Oppure, se eseguire il deployment dell'applicazione su GKE e Cloud Run utilizzando il deployment parallelo.
Puoi facilitare il traffico avanzato mediante l'uso di bilanciatori del carico esterni ed interni per i servizi su GKE in 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.
Confronto tra GKE e Cloud Run
Per sfruttare le migliori funzionalità di GKE Cloud Run e sapere quando spostare i carichi di lavoro da uno all'altro, è importante per comprendere le differenze tra i due servizi.
| 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 potrà 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 delle configurazioni dei nodi, dei criteri di rete, delle impostazioni di sicurezza e dei componenti aggiuntivi. |
Controllo limitato sull'infrastruttura sottostante. Puoi configurare elementi come le variabili di ambiente, la contemporaneità e le connessioni di rete, ma non puoi personalizzare l'infrastruttura o l'ambiente sottostante. 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 funzioni, servizi web e servizi stateless, basati su richieste o 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. | Pagamento in base al 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 stateful che gestisce i prodotti disponibilità e aggiornamenti.
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 una combinazione di servizi stateless e stateful, di sfruttare GKE e Cloud Run per per ottenere prestazioni ottimali. Ecco un modo per implementare un approccio ibrido per il tuo carichi di lavoro con scale out impegnativi.
Dopo aver letto i criteri di idoneità delle carichi di lavoro Cloud Run, decidi di utilizzare Cloud Run per sito web e app mobile e i job di elaborazione batch. Il deployment di questi servizi su Cloud Run presenta i seguenti vantaggi:
La scalabilità automatica come picchi di traffico e job batch di grandi dimensioni viene gestita senza un intervento manuale.
Efficienza dei costi con un modello di pagamento in base al consumo. Paghi solo quando gli utenti esplorazione o pagamento, nonché utilizzo delle risorse durante il job batch dell'esecuzione.
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 stateful che richiede soluzioni di archiviazione di controllo e potenzialmente personalizzate. Decidi di utilizzare GKE per eseguire il deployment di questo servizio, poiché offre spazio di archiviazione permanente e 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 complessi ed esercitare un controllo granulare sull'allocazione delle risorse e la scalabilità delle applicazioni.
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 è più adatto 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 combinare GKE e Cloud Run può fornire una soluzione potente e flessibile 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 microservizi complessi e componenti stateful.
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 fare quando si adotta un approccio ibrido a eseguendo il deployment dei carichi di lavoro:
Esegui microservizi stateless su Cloud Run per l'efficienza in termini di costi e o scalabilità.
Esegui il deployment di complesse applicazioni stateful su cui è richiesta una profonda personalizzazione con GKE.
Se usi una rete privata su Google Cloud, per accedere alle risorse un cluster GKE dal tuo servizio Cloud Run, puoi inviare una richiesta a una rete Virtual Private Cloud (VPC) utilizzando VPC diretto in uscita. Per accedere ai servizi Kubernetes nel cluster GKE, il servizio Cloud Run deve essere collegato 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 da questo bilanciatore del carico per i servizi in entrambi i runtime, puoi il deployment della stessa applicazione sia in Cloud Run GKE, consentendoti 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 migrare a di GKE in base alle esigenze.
Quando non utilizzare GKE e Cloud Run insieme
Sebbene GKE e Cloud Run offrano un approccio convincente per molti carichi di lavoro containerizzati, ci sono situazioni in cui li utilizzano insieme potrebbe non essere la soluzione migliore. Ecco alcuni esempi di casi in cui potresti decidere di non adotta 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 sovraccarichi 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 Cloud Run per parti dell'applicazione potrebbe richiedere refactoring o soluzioni alternative significativi. Ciò può annullare i vantaggi del serverless e introdurre un overhead di manutenzione specifico della piattaforma.
Vincoli di budget con carichi di lavoro prevedibili: se il carico di lavoro ha costanti requisiti delle risorse e non disponi di un budget limitato, Il modello pay-per-node di GKE potrebbe essere più conveniente rispetto Fatturazione con pagamento in base al consumo 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, i vincoli delle risorse e delle competenze del tuo team prima di decidere dell'architettura di 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 tuo deployment Kubernetes in un ambiente compatibile con Cloud Run container in seguito a Migrazione da Kubernetes a in Cloud Run.