Usa GKE e Cloud Run insieme


Questa guida è rivolta agli amministratori dell'infrastruttura e alle applicazioni che eseguono un set diversificato di carichi di lavoro containerizzati e vogliono sfruttare i punti di forza Google Kubernetes Engine (GKE) e Cloud Run per eseguire il deployment Google Cloud Platform. Una strategia ibrida ti consente di ottimizzare i costi, prestazioni e overhead per la gestione.

Dovresti avere familiarità con:

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 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. Tu puoi utilizzare la stessa immagine per la tua applicazione su entrambe le piattaforme senza di modifiche, consentendo così la migrazione senza soluzione di continuità dei carichi di lavoro 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 analogia 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 confrontando i file YAML di un deployment Kubernetes dal 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 gli obiettivi del livello di servizio il monitoraggio (SLO) su entrambi e visualizzare una visualizzazione unificata degli SLO in Cloud Monitoring Fitbit.com.

  • 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 che che ti consente di eseguire il deployment di diversi URL per la stessa applicazione su entrambe le piattaforme. Puoi anche suddividere il traffico verso lo stesso servizio tra GKE e Cloud Run, per consentire una migrazione senza interruzioni da una piattaforma all'altra.

  • Google Cloud fornisce strumenti di sicurezza per migliorare la security posture quando utilizzando entrambi i runtime. Sistema operativo scansione consente di analizzare dei container per individuare le vulnerabilità prima di eseguirne il deployment su entrambe le piattaforme. Un centro Il criterio di Autorizzazione binaria può applicare l'integrazione con il piano di controllo GKE e Cloud Run per consentire o bloccare il deployment di immagini in base ai criteri da te definiti. Con Controlli di servizio VPC, i team di sicurezza possono definire controlli perimetrali granulari in GKE delle risorse 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, inclusi configurazione dei nodi, networking, scalabilità e upgrade.

Google Cloud gestisce l'infrastruttura sottostante e fornisce strumenti per semplificare le operazioni del cluster, ma tu 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 o 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 variabili di ambiente, contemporaneità e connessioni di rete, ma non puoi personalizzare l'infrastruttura o l'ambiente sottostante. Ideale per semplicità e velocità.

Tipi di applicazione Supporta applicazioni stateless e stateful ed è ideale per applicazioni complesse con esigenze specifiche in termini di risorse. È 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à operativa (Standard o Autopilot), dalle dimensioni del cluster o dalla topologia. Pagamento in base al consumo, arrotondato per eccesso ai 100 millisecondi più vicini.

Caso d'uso

Sei l'amministratore di piattaforma di un'azienda di vendita al dettaglio che sta sviluppando un piattaforma di e-commerce. Per eseguire il deployment, hai i seguenti carichi di lavoro containerizzati:

  • Sito web e app mobile frontend: una gestione di applicazioni web stateless navigazione, ricerca e pagamento del prodotto.

  • Gestione dell'inventario dei prodotti: un servizio stateful che gestisce i prodotti disponibilità e aggiornamenti.

  • Motore per suggerimenti: una generazione di microservizi complessa e personalizzata consigli sui prodotti per ogni utente.

  • Job di elaborazione batch: include attività periodiche come l'aggiornamento del prodotto. cataloghi e analizzare il comportamento degli utenti.

Questi carichi di lavoro rappresentano una combinazione di servizi stateless e stateful, di sfruttare GKE e Cloud Run per prestazioni ottimali. Ecco un modo per implementare un approccio ibrido per il tuo carichi di lavoro con scale out impegnativi.

  1. 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 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 grazie alla disponibilità immediata degli aggiornamenti, migliorando l'esperienza un'esperienza senza intervento manuale.

    • Integrazione facile con altri servizi Google Cloud. Ad esempio, per basata su eventi, puoi utilizzare Cloud Functions per avviare la modalità batch di elaborazione dei job su Cloud Run e consentire flussi di lavoro senza interruzioni.

  2. 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.

  3. Il motore per suggerimenti è un microservizio complesso che trae vantaggio GKE Con GKE, puoi gestire complessi ed esercitare un controllo granulare sull'allocazione delle risorse e la scalabilità delle applicazioni.

GKE è più adatto per architetture di microservizi complesse, applicazioni stateful, carichi di lavoro che richiedono un'infrastruttura o una rete personalizzate configurazioni e scenari in cui è essenziale un controllo profondo 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 dei prezzi a consumo.

L'esempio precedente mostra come combinare GKE e Cloud Run può fornire una soluzione potente e flessibile piattaforma di e-commerce. ottieni i vantaggi di entrambe le piattaforme; serverless per i carichi di lavoro stateless e il controllo Kubernetes di microservizi e componenti stateful.

Considerazioni

GKE e Cloud Run si completano a vicenda, esigenze diverse in un panorama applicativo 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 e 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 in GKE automaticamente, il servizio Cloud Run deve essere connesso rete VPC e il servizio Kubernetes deve utilizzare un'istanza 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 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 su Cloud Run GKE, consentendoti di spostare gradualmente il traffico da una piattaforma all'altra.

  • Per esporre i servizi Cloud Run in Virtual Private Cloud mediante 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 a stretto accoppiamento: se i microservizi sono fortemente dipendenti che richiedono comunicazioni frequenti e a bassa latenza, su piattaforme diverse può introdurre complessità. Chiamate di rete frequenti tra le piattaforme potrebbero aumentare i costi generali e i potenziali colli di bottiglia, delle prestazioni.

  • Applicazioni legacy con dipendenze personalizzate: se la tua applicazione si basa su librerie, configurazioni o framework specifici non supportati Cloud Run, il suo utilizzo per parti dell'applicazione potrebbe richiedere un significativo refactoring o soluzioni alternative. Questo può annullare il serverless vantaggi e introducono l'overhead di manutenzione specifico della piattaforma.

  • Vincoli di budget con carichi di lavoro prevedibili: se il carico di lavoro ha sono coerenti con i requisiti di 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 sfruttare appieno i vantaggi della scalabilità automatica 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, i vincoli delle risorse e delle competenze del tuo team prima di decidere dell'architettura di Cloud Run.

Passaggi successivi