Panoramica del deployment dei carichi di lavoro

Per eseguire il deployment e gestire le applicazioni containerizzate e altri carichi di lavoro sul tuo di Google Kubernetes Engine (GKE), utilizzi il sistema Kubernetes per creare Oggetti controller Kubernetes. Questi oggetti controller rappresentano applicazioni, daemon e job batch in esecuzione sui tuoi cluster.

Puoi creare questi oggetti controller utilizzando l'API Kubernetes o kubectl, un'interfaccia a riga di comando per Kubernetes installata da gcloud Di solito, crei una rappresentazione dei tuoi l'oggetto controller Kubernetes desiderato come file di configurazione YAML, quindi il file con l'API Kubernetes o l'interfaccia a riga di comando kubectl.

Tipi di carichi di lavoro

Kubernetes offre diversi tipi di oggetti controller che corrispondono diversi tipi di carichi di lavoro che puoi eseguire. Alcuni oggetti controller sono migliori più adatti a rappresentare tipi specifici di carichi di lavoro. Le seguenti sezioni descrivere alcuni tipi comuni di carichi di lavoro e gli oggetti controller Kubernetes che puoi creare per eseguirle sul tuo cluster, ad esempio:

  • Applicazioni stateless
  • Applicazioni stateful
  • Job in batch
  • Daemon

Applicazioni stateless

Un'applicazione stateless non conserva il proprio stato e non salva i dati nell'archiviazione permanente: tutti i dati degli utenti e delle sessioni rimangono nel client.

Alcuni esempi di applicazioni stateless includono i frontend web, Nginx, server web come Apache Tomcat e altre applicazioni web.

Puoi creare un cluster Kubernetes Deployment il deployment di un'applicazione stateless nel tuo cluster. I pod creati dai deployment non sono univoci e non vengono conservati il loro stato, il che semplifica la scalabilità e l'aggiornamento delle applicazioni stateless.

Applicazioni stateful

Un'applicazione stateful richiede il salvataggio o il salvataggio permanente. Le applicazioni stateful utilizzano l'archiviazione permanente, volumi permanenti, per salvare i dati in modo che vengano utilizzati dal server o da altri utenti.

Tra gli esempi di applicazioni stateful ci sono database come MongoDB e code di messaggi come Apache ZooKeeper.

Puoi creare uno StatefulSet Kubernetes per il deployment di un'applicazione stateful. I pod creati dagli oggetti StatefulSet hanno identificatori e possono essere aggiornati in modo ordinato e sicuro.

Job in batch

I job in batch rappresentano attività limitate, indipendenti e spesso parallele che vengono eseguite fino al loro completamento. Alcuni esempi di job batch includono job automatici o pianificati eseguire attività come l'invio di email, il rendering dei video e l'esecuzione molto altro.

Puoi creare un job Kubernetes per eseguire e gestire un'attività batch sul tuo in un cluster Kubernetes. Puoi specificare il numero di pod che devono completare le proprie attività prima del completamento del job, nonché il numero massimo di pod che devono vengono eseguite in parallelo.

Daemon

I daemon eseguono attività in background in corso nei nodi assegnati senza il la necessità di un intervento da parte dell'utente. Esempi di daemon sono i raccoglitori di log come Fluentd e servizi di monitoraggio.

Puoi creare un DaemonSet Kubernetes il deployment di un daemon sul tuo cluster. I DaemonSet creano un pod per nodo e scegliere un nodo specifico in cui eseguire il deployment del DaemonSet.

DaemonSet su GKE Autopilot

GKE amministra i nodi nei cluster che crei utilizzando Modalità operativa Autopilot. Non puoi aggiungere, rimuovere o modificare manualmente i nodi o la parte sottostante macchine virtuali (VM) Compute Engine. Tuttavia, l'oggetto nodo Kubernetes è ancora visibile e Autopilot supporta i DaemonSet come carichi di lavoro.

GKE Autopilot limita alcune funzioni amministrative influisce su tutti i pod dei carichi di lavoro, inclusi i pod gestiti da DaemonSet. DaemonSets che eseguono funzioni amministrative sui nodi con privilegi elevati, come contesto di sicurezza privileged, non verrà eseguito su cluster Autopilot a meno che non sia consentito esplicitamente da GKE.

Per ulteriori informazioni sui limiti applicati da Autopilot, vedi Limitazioni e restrizioni del carico di lavoro. Puoi utilizzare gli oggetti DaemonSet con carichi di lavoro che soddisfano le limitazioni impostate da Autopilot, e DaemonSet di alcuni partner Google Cloud.

Best practice per DaemonSet su Autopilot

GKE utilizza la dimensione totale dei carichi di lavoro di cui hai eseguito il deployment per determinare la dimensione dei nodi di cui Autopilot esegue il provisioning per il cluster. Se aggiungi o ridimensiona un oggetto DaemonSet dopo che Autopilot ha eseguito il provisioning di un nodo GKE non ridimensionerà i nodi esistenti per soddisfare il nuovo totale delle dimensioni del carico di lavoro. DaemonSet con richieste di risorse maggiori di quelle allocabili dei nodi esistenti, dopo aver tenuto conto dei pod di sistema, neppure è stata pianificata su quei nodi.

A partire da GKE versione 1.27.6-gke.1248000, i cluster in La modalità Autopilot rileva i nodi che non possono essere adatti a tutti i DaemonSet. esegui la migrazione dei carichi di lavoro su nodi più grandi che possono soddisfare tutti i DaemonSet. Questo richiede tempo, soprattutto se i nodi eseguono pod di sistema, che devono tempo aggiuntivo per la terminazione controllata in modo che non ci siano interruzioni nel cluster principale le funzionalità di machine learning.

In GKE versione 1.27.5-gke.200 o precedente, consigliamo non pianificabile e drenaggio che non possono ospitare pod DaemonSet.

Per tutte le versioni di GKE, consigliamo le seguenti best practice durante il deployment di DaemonSets su Autopilot:

  • Esegui il deployment dei DaemonSet prima di qualsiasi altro carico di lavoro.
  • Imposta un valore superiore PriorityClass su DaemonSet rispetto ai pod normali. Il valore PriorityClass più elevato GKE rimuove i pod a priorità inferiore per ospitare i pod DaemonSet se il nodo può ospitare quei pod. Ciò aiuta a garantire che DaemonSet è presente su ciascun nodo senza attivare la ricreazione dei nodi.

Gestione degli oggetti dei carichi di lavoro

Puoi creare, gestire ed eliminare gli oggetti utilizzando gli approcci imperativi e dichiarativi. Le seguenti sezioni descrivono questi metodi e i seguenti strumenti che puoi utilizzare per utilizzarli:

Comandi imperativi

I comandi imperativi consentono di eseguire rapidamente creare, visualizzare, aggiornare ed eliminare oggetti con kubectl. Questi comandi sono utile per attività una tantum o per apportare modifiche agli oggetti attivi in un cluster. I comandi imperativi vengono comunemente utilizzati per operare su oggetti attivi di cui è stato eseguito il deployment nel tuo cluster.

kubectl include diversi comandi basati su verbi per creare e modificare oggetti Kubernetes. Ad esempio:

  • run: Genera un nuovo oggetto nel cluster. Se non diversamente specificato, run crea un oggetto Deployment.
  • expose: Crea un nuovo oggetto Service per bilanciare il carico del traffico tra un insieme di pod con etichetta.
  • autoscale: Crea un nuovo oggetto del gestore della scalabilità automatica per scalare automaticamente orizzontalmente un oggetto Controller, ad esempio un oggetto Deployment.

I comandi imperativi non richiedono una conoscenza approfondita dello schema degli oggetti, non richiede file di configurazione.

Configurazione degli oggetti imperativi

Configurazione imperativa degli oggetti crea, aggiorna ed elimina oggetti utilizzando file di configurazione contenenti e le definizioni di oggetti completamente definite. Puoi archiviare i file di configurazione degli oggetti dei sistemi di controllo dei file sorgente e delle modifiche dell'audit con maggiore facilità tramite comandi SQL.

Puoi eseguire kubectl apply, delete e Operazioni replace con file di configurazione directory contenenti i file di configurazione.

Configurazione dichiarativa degli oggetti

La configurazione degli oggetti dichiarativi opera di configurazione archiviati localmente ma non richiede una configurazione delle operazioni da eseguire. Le operazioni vengono invece eseguite rilevato automaticamente per oggetto da kubectl. Questo è utile se lavorare con una directory di file di configurazione con molte operazioni diverse. La gestione dichiarativa degli oggetti richiede una profonda comprensione dell'oggetto e i file di configurazione.

Puoi eseguire kubectl apply per creare e aggiornare gli oggetti in modo dichiarativo. apply di aggiornamenti leggendo l'intero oggetto attivo, calcolando le differenze, quindi unendo queste differenze inviando richieste di patch al server API.

Immagini Docker Hub pubbliche

Quando esegui il deployment di un'immagine container pubblica da Docker Hub, GKE verifica automaticamente la presenza di una copia memorizzata nella cache sul proxy di memorizzazione nella cache mirror.gcr.io dell'immagine container. Se una copia memorizzata nella cache non è disponibile, esegue il pull dell'immagine richiesta da Docker Hub e il proxy di memorizzazione nella cache potrebbe dell'immagine per uso futuro. Per ulteriori informazioni, vedi Estrazione delle immagini memorizzate nella cache.

Console

Dopo aver eseguito il deployment di un carico di lavoro utilizzando kubectl o l'API, puoi utilizzare Menu Carichi di lavoro di GKE nella console Google Cloud per ispezionare, gestire e modificare i carichi di lavoro in esecuzione sui tuoi cluster.

Il menu offre le seguenti funzionalità:

  • Puoi usare l'editor di testo basato su YAML per modificare gli oggetti attivi dal tuo browser
  • Puoi visualizzare informazioni dettagliate sugli oggetti, tra cui la cronologia delle revisioni, eventi e attività recenti e i relativi pod gestiti
  • Puoi scalare facilmente deployment, job e oggetti StatefulSet
  • Puoi scalare automaticamente, attivare gli aggiornamenti in sequenza e scalare manualmente i deployment. dal menu Azioni.
  • Puoi utilizzare Cloud Shell per ispezionare, modificare ed eliminare qualsiasi .

API

Puoi utilizzare l'API REST GKE e API Kubernetes e Librerie client di Google Cloud per creare e gestire i carichi di lavoro in modo programmatico.

File di configurazione

Quando esegui il deployment di un carico di lavoro usando uno dei metodi descritti in precedenza, GKE aggiunge al cluster un file di configurazione che rappresenta dell'oggetto.

La configurazione pubblicata di un oggetto potrebbe essere diversa dal relativo file locale. YAML è più comunemente usato per creare e rappresentare oggetti Kubernetes. Puoi anche utilizzare JSON.

Per saperne di più sulle specifiche, sugli stati e sulle specifiche degli oggetti Kubernetes per l'API, consulta Comprensione degli oggetti Kubernetes e il riferimento dell'API Kubernetes.

Ispezione delle configurazioni pubblicate

Console

Per ispezionare la configurazione in tempo reale di un oggetto di cui è stato eseguito il deployment, esegui la seguenti passaggi:

  1. Vai alla pagina Carichi di lavoro nella console Google Cloud.

    Vai a Carichi di lavoro

  2. Seleziona il carico di lavoro che ti interessa.

  3. Fai clic su YAML.

gcloud

Per ispezionare la configurazione in tempo reale di un oggetto di cui è stato eseguito il deployment, esegui questo comando: :

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] può essere deployment, statefulset, job o un altro oggetto di testo. Ad esempio:

kubectl get deployment my-stateless-app -o yaml

Gestione dell'utilizzo delle risorse con le quote

Quando molti utenti o team condividono le risorse nel tuo cluster, esiste un problema che alcuni potrebbero utilizzare più della loro giusta quota. Puoi utilizzare il cluster Kubernetes Oggetto ResourceQuota per limitare il consumo delle risorse all'interno di spazi dei nomi specifici.

GKE applica anche un valore gke-resource-quotas immutabile predefinito agli spazi dei nomi sui cluster con 100 nodi o meno per evitare instabilità.

Utilizza GitLab per il deployment su GKE

Se usi GitLab per l'integrazione continua, puoi utilizzare Componente GKE GitHub per il deployment del carico di lavoro in un cluster GKE.

Puoi anche provare il tutorial end-to-end per l'utilizzo di GitLab con Google Cloud.

Per saperne di più, consulta la panoramica di GitLab su Google Cloud.

Passaggi successivi