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 fornisce diversi tipi di oggetti controller che corrispondono a diversi tipi di carichi di lavoro che puoi eseguire. Alcuni oggetti controller sono più adatti per rappresentare tipi specifici di carichi di lavoro. Le sezioni seguenti descrivono alcuni tipi comuni di carichi di lavoro e gli oggetti del controller Kubernetes che puoi creare per eseguirli sul tuo cluster, tra cui:

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

Applicazioni stateless

Un'applicazione stateless non conserva il proprio stato e non salva alcun dato nello spazio di archiviazione permanente: tutti i dati utente e della sessione rimangono nel client.

Alcuni esempi di applicazioni stateless includono front-end web come 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 mantengono il loro stato, il che semplifica la scalabilità e l'aggiornamento delle applicazioni senza stato.

Applicazioni stateful

Un'applicazione stateful richiede che il relativo stato venga salvato o sia permanente. Le applicazioni stateful utilizzano lo spazio di archiviazione permanente, ad esempio i volumi permanenti, per salvare i dati da utilizzare dal server o da altri utenti.

Alcuni esempi di applicazioni stateful sono database come MongoDB e code di messaggi come Apache ZooKeeper.

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

Job in batch

I job batch rappresentano attività finite, indipendenti e spesso parallele che vengono eseguite fino al 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 demoni eseguono attività in background continue nei nodi assegnati senza bisogno di intervento da parte dell'utente. Esempi di daemon sono i raccoglitori di log come Fluentd e servizi di monitoraggio.

Puoi creare un DaemonSet Kubernetes per eseguire 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 dei cluster che crei utilizzando la 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, consulta Limiti e restrizioni per i carichi di lavoro. Puoi utilizzare i DaemonSet con carichi di lavoro che soddisfano le limitazioni impostate da Autopilot, nonché i DaemonSet di alcuni partner di 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 aggiunti o ridimensioni un DaemonSet dopo che Autopilot ha eseguito il provisioning di un nodo, GKE non ridimensionerà i nodi esistenti per adattarli alle nuove dimensioni totali 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 dalla versione GKE 1.27.6-gke.1248000, i cluster in modalità Autopilot rilevano i nodi che non possono contenere tutti i DaemonSet e, nel tempo, eseguono la migrazione dei carichi di lavoro a nodi più grandi che possono contenere 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 consente a GKE di espellere i pod con priorità inferiore per accogliere i pod DaemonSet se il nodo può ospitarli. 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 sezioni seguenti descrivono questi metodi, nonché gli strumenti che puoi utilizzare per applicarli:

Comandi imperativi

I comandi imperativi consentono di eseguire rapidamente creare, visualizzare, aggiornare ed eliminare oggetti con kubectl. Questi comandi sono utili 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 offre diversi comandi basati su verbi per creare e modificare gli 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 su un insieme di pod etichettati.
  • autoscale: crea un nuovo oggetto Autoscaler per eseguire la scalabilità automatica orizzontale di un oggetto controller, ad esempio un deployment.

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

Configurazione degli oggetti imperativi

La configurazione degli oggetti imperativi crea, aggiorna ed elimina gli oggetti utilizzando file di configurazione contenenti definizioni di oggetti completamente definite. Puoi archiviare i file di configurazione degli oggetti dei sistemi di controllo dei file sorgente e delle modifiche di 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 dichiarativa opera su file di configurazione archiviati localmente, ma non richiede la definizione esplicita delle operazioni da eseguire. Le operazioni vengono invece rilevate automaticamente per oggetto da kubectl. Questa operazione è utile se lavori con una directory di file di configurazione con molte operazioni diverse. La gestione degli oggetti dichiarativi richiede una profonda conoscenza degli schemi degli oggetti e dei 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 di container pubblica da Docker Hub, GKE controlla automaticamente il proxy con cache mirror.gcr.io per verificare la presenza di una copia memorizzata nella cache dell'immagine del container. Se non è disponibile una copia memorizzata nella cache, GKE recupera l'immagine richiesta da Docker Hub e il proxy con memorizzazione nella cache potrebbe memorizzare l'immagine per un uso futuro. Per ulteriori informazioni, consulta la sezione Estrazione delle immagini memorizzate nella cache.

Console

Dopo aver eseguito il deployment di un carico di lavoro utilizzando kubectl o l'API, puoi utilizzare il 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 utilizzare l'editor di testo basato su YAML per modificare gli oggetti in tempo reale dal browser web.
  • Puoi visualizzare informazioni dettagliate sugli oggetti, tra cui la cronologia delle revisioni, gli eventi e le attività recenti e i relativi pod gestiti
  • Puoi scalare facilmente deployment, job e StatefulSet
  • Puoi eseguire il ridimensionamento automatico, attivare gli aggiornamenti incrementali e scalare manualmente i deployment dal menu Azioni.
  • Puoi utilizzare Cloud Shell per ispezionare, modificare ed eliminare qualsiasi oggetto.

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 utilizzando uno dei metodi descritti in precedenza, GKE aggiunge al cluster un file di configurazione che rappresenta l'oggetto.

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

Per saperne di più sulle specifiche, sugli stati e sull'API degli oggetti Kubernetes, consulta Informazioni sugli oggetti Kubernetes e la documentazione di riferimento dell'API Kubernetes.

Ispezione delle configurazioni attive

Console

Per controllare la configurazione in tempo reale di un oggetto di cui è stato eseguito il deployment, segui questi 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 inoltre un gke-resource-quotas oggetto immutabile predefinito agli spazi dei nomi nei cluster con massimo 100 nodi per evitare instabilità.

Utilizzare GitLab per eseguire il deployment in GKE

Se utilizzi GitLab per l'integrazione continua, puoi utilizzare il componente GKE di GitLab per eseguire il deployment del tuo 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