Questa guida è pensata per gli amministratori di infrastruttura e gli operatori delle applicazioni che eseguono un set eterogeneo 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 Platform. Una strategia ibrida consente di ottimizzare costi, prestazioni e overhead di gestione.
Dovresti conoscere bene:
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.
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 alto di portabilità:
Entrambe le piattaforme utilizzano immagini container standard come artefatti di deployment. Puoi utilizzare la stessa immagine per l'applicazione in entrambe le piattaforme senza alcuna modifica, consentendo così una 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, purché le immagini container 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 Kubernetes familiari come deployment, servizi e scalabilità automatica orizzontale dei pod 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 la stessa struttura dichiarativa e standard, quindi possono essere facilmente migrate tra i runtime. Ecco un esempio di confronto tra 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, offrendo una visualizzazione centralizzata della console Google Cloud per osservare le metriche delle applicazioni indipendentemente dalla piattaforma. Puoi inoltre utilizzare il monitoraggio degli obiettivi a 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 nelle risorse GKE o nei servizi Cloud Run utilizzando Cloud Deploy. Oppure, se preferisci, esegui contemporaneamente il deployment dell'applicazione sia su GKE sia 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 diversi URL per la stessa applicazione su entrambe le piattaforme. Puoi anche suddividere il traffico verso lo stesso servizio tra GKE e Cloud Run, in modo da garantire una migrazione senza soluzione di continuità da una piattaforma all'altra.
Google Cloud fornisce strumenti di sicurezza per migliorare la tua strategia di sicurezza quando utilizzi entrambi i runtime. L'analisi del sistema operativo consente di eseguire la scansione dei container per rilevare le vulnerabilità prima del deployment su una delle due piattaforme. Un criterio centrale di Autorizzazione binaria può applicare l'integrazione con il piano di controllo 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 in tutte 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 uno all'altro, è importante capire in che modo i due servizi differiscono l'uno dall'altro.
| Selezione delle | GKE | Cloud Run |
|---|---|---|
| Deployment e gestione | Gestire i cluster Kubernetes, inclusi configurazione dei nodi, networking, scalabilità e upgrade. Google Cloud gestisce l'infrastruttura sottostante e fornisce strumenti per semplificare le operazioni dei 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 sarà in grado di creare il container al posto tuo. Non è necessario creare un cluster o 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 come variabili di ambiente, contemporaneità e connessioni di rete, ma non puoi personalizzare l'infrastruttura o l'ambiente di base. Ideale per semplicità e velocità. |
| Tipi di applicazioni | Supporta applicazioni stateless e stateful ed è ideale per applicazioni complesse con esigenze di risorse specifiche. | Più adatto per servizi, funzioni e servizi web su richiesta, stateless o basati su eventi. |
| Modello di determinazione del prezzo | Pagamento per cluster all'ora, indipendentemente da modalità operativa (Standard o Autopilot), dimensione del cluster o topologia. | Paga solo per le risorse utilizzate, arrotondate per eccesso ai 100 millisecondi più vicini. |
Caso d'uso
Supponiamo che tu sia l'amministratore di una società di vendita al dettaglio che crea una grande piattaforma di e-commerce. Hai i seguenti carichi di lavoro containerizzati di cui eseguire il deployment:
Sito web e app mobile di 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 personalizzati sui prodotti 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 una combinazione di servizi stateless e stateful, per cui puoi decidere di sfruttare GKE e Cloud Run per ottenere 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 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 i picchi di traffico e i job batch di grandi dimensioni vengono gestiti senza intervento manuale.
Efficienza in termini di costi con un modello di pagamento in base al consumo. Paghi soltanto quando gli utenti navigano o effettuano il pagamento e quando le risorse vengono utilizzate durante l'esecuzione del job batch.
Deployment più rapidi grazie agli aggiornamenti disponibili immediatamente, migliorando l'esperienza utente.
Facile integrazione con altri servizi Google Cloud. Ad esempio, per l'elaborazione basata sugli eventi, puoi utilizzare Cloud Functions per avviare job di elaborazione batch su Cloud Run e consentire flussi di lavoro senza interruzioni.
La gestione dell'inventario dei prodotti è un servizio stateful che richiede un controllo granulare e soluzioni di archiviazione potenzialmente personalizzate. Decidi di utilizzare GKE per eseguire il deployment di questo servizio, che offre archiviazione permanente e ti consente di collegare i volumi per garantire persistenza e affidabilità dei dati di prodotto.
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 la scalabilità delle risorse.
GKE è più adatto per architetture di microservizi complesse, applicazioni stateful, carichi di lavoro che richiedono un'infrastruttura personalizzata o configurazioni di rete e scenari in cui è essenziale un controllo approfondito su 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 di pagamento in base al consumo.
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. Puoi usufruire dei vantaggi di entrambe le piattaforme, dell'efficienza serverless per i carichi di lavoro stateless e del controllo di Kubernetes per microservizi complessi e componenti stateful.
Considerazioni
GKE e Cloud Run si completano a vicenda, soddisfacendo esigenze diverse in un panorama applicativo complesso.
Ecco alcune considerazioni da fare quando si adotta un approccio ibrido al deployment dei carichi di lavoro:
Esegui microservizi stateless su Cloud Run per ottenere efficienza 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 del tuo cluster GKE dal servizio Cloud Run, puoi inviare una richiesta a una rete Virtual Private Cloud (VPC) utilizzando il traffico VPC diretto in uscita. Per accedere ai servizi del cluster GKE, il servizio Cloud Run deve essere connesso alla rete VPC del cluster e il servizio GKE deve utilizzare un bilanciatore del carico di rete passthrough interno.
Per eseguire la migrazione del traffico tra Cloud Run e GKE, puoi esporre gli endpoint esterni dietro un Application Load Balancer esterno globale. Quando implementi questo bilanciatore del carico per i servizi in entrambi i runtime, puoi eseguire il deployment della stessa applicazione sia su Cloud Run che su GKE, in modo da 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, esistono situazioni in cui utilizzarli insieme potrebbe non essere la soluzione ideale. Ecco alcuni esempi dei casi in cui potresti decidere di non adottare un approccio ibrido:
Microservizi ad accoppiamento stretto: se i tuoi microservizi sono molto dipendenti l'uno dall'altro e richiedono comunicazioni frequenti e a bassa latenza, la loro gestione su piattaforme separate può comportare delle complessità. Chiamate di rete frequenti tra le piattaforme potrebbero aggiungere overhead e potenziali colli di bottiglia, con ripercussioni sulle prestazioni.
Applicazioni legacy con dipendenze personalizzate: se la tua applicazione si basa su librerie, framework o configurazioni specifiche non supportati da Cloud Run, il suo utilizzo per parti dell'applicazione potrebbe richiedere un refactoring significativo o soluzioni alternative. Ciò può annullare i vantaggi del serverless e introdurre un overhead di manutenzione specifico per la piattaforma.
Vincoli di budget con carichi di lavoro prevedibili: se il tuo carico di lavoro ha requisiti coerenti in termini di risorse e hai un budget limitato, il modello di pagamento per nodo di GKE potrebbe essere più conveniente rispetto alla fatturazione con pagamento in base al consumo di Cloud Run. Se i tuoi carichi di lavoro sono prevedibili, potresti non utilizzare appieno i vantaggi della scalabilità automatica di Cloud Run, rendendo più allettante 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 l'esperienza del team prima di decidere un'architettura ibrida GKE e Cloud Run.
Passaggi successivi
Scopri come convertire il tuo servizio Cloud Run in un deployment Kubernetes in Eseguire la migrazione da Cloud Run a GKE.
Compila il tuo deployment Kubernetes in un container compatibile con Cloud Run seguendo Esegui la migrazione da Kubernetes a Cloud Run.