Panoramica del deployment dei carichi di lavoro

Per eseguire il deployment e gestire le applicazioni containerizzate e altri carichi di lavoro sul tuo cluster Google Kubernetes Engine (GKE), utilizza il sistema Kubernetes per creare oggetti controller Kubernetes. Questi oggetti controller rappresentano le applicazioni, i daemon e i 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 installato da gcloud. In genere, crei una rappresentazione dell'oggetto controller Kubernetes desiderato come file di configurazione YAML e poi utilizzi questo file con l'API Kubernetes o l'interfaccia a riga di comando kubectl.

Tipi di carichi di lavoro

Kubernetes fornisce vari tipi di oggetti controller che corrispondono a diversi tipi di carichi di lavoro. Alcuni oggetti controller sono più adatti a rappresentare tipi specifici di carichi di lavoro. Le seguenti sezioni descrivono alcuni tipi comuni di carichi di lavoro e gli oggetti controller Kubernetes che puoi creare per eseguirli sul tuo cluster, tra cui:

  • che non archiviano lo stato
  • Applicazioni stateful
  • Job in batch
  • Daemon

che non archiviano lo stato

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

Ecco alcuni esempi di applicazioni stateless: frontend web come Nginx, server web come Apache Tomcat e altre applicazioni web.

Puoi creare un deployment Kubernetes per eseguire il deployment di un'applicazione stateless nel cluster. I pod creati dai deployment non sono univoci e non conservano il proprio stato, il che semplifica la scalabilità e l'aggiornamento delle applicazioni stateless.

Applicazioni stateful

Un'applicazione stateful richiede che il suo stato sia salvato o permanente. Le applicazioni stateful utilizzano l'archiviazione permanente, ad esempio volumi permanenti, per salvare i dati in modo che possano essere utilizzati dal server o da altri utenti.

Esempi di applicazioni stateful includono 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 univoci e possono essere aggiornati in modo ordinato e sicuro.

Job in batch

I job batch rappresentano attività limitate, indipendenti e spesso parallele che vengono eseguite fino al loro completamento. Alcuni esempi di job batch includono attività automatiche o pianificate come l'invio di email, il rendering dei video e l'esecuzione di calcoli costosi.

Puoi creare un job Kubernetes per eseguire e gestire un'attività batch sul tuo cluster. 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 essere eseguiti in parallelo.

Daemon

I daemon eseguono attività in background continue nei nodi assegnati senza bisogno di un intervento da parte dell'utente. Esempi di daemon includono 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, consentendoti di scegliere un nodo specifico in cui eseguire il deployment del DaemonSet.

DaemonSet su GKE Autopilot

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

GKE Autopilot limita alcune funzioni amministrative che interessano tutti i pod dei carichi di lavoro, compresi quelli gestiti dai DaemonSet. I DaemonSet che eseguono funzioni amministrative sui nodi che utilizzano privilegi elevati, come il contesto di sicurezza privileged, non vengono eseguiti sui cluster Autopilot, a meno che non sia esplicitamente consentito da GKE.

Per ulteriori informazioni sui limiti applicati da Autopilot, consulta Limitazioni e restrizioni dei carichi di lavoro. Puoi utilizzare i DaemonSet con carichi di lavoro che soddisfano le limitazioni impostate da Autopilot, e i DaemonSet di alcuni partners Google Cloud.

Best practice per DaemonSet su Autopilot

GKE utilizza le dimensioni totali dei carichi di lavoro di cui hai eseguito il deployment per determinare le dimensioni dei nodi di cui Autopilot esegue il provisioning per il cluster. Se aggiungi o ridimensioni un DaemonSet dopo che Autopilot ha eseguito il provisioning di un nodo, GKE non ridimensionerà i nodi esistenti per contenere le nuove dimensioni totali del carico di lavoro. Anche i DaemonSet con richieste di risorse superiori alla capacità allocabile dei nodi esistenti, dopo aver preso in considerazione i pod di sistema, non verranno pianificati su questi nodi.

A partire dalla versione 1.27.6-gke.1248000 di GKE, i cluster in modalità Autopilot rilevano i nodi che non possono essere adatti a tutti i DaemonSet e, nel tempo, eseguono la migrazione dei carichi di lavoro in nodi più grandi, adatti a tutti i DaemonSet. Questo processo richiede un po' di tempo, soprattutto se i nodi eseguono pod di sistema, i quali richiedono altro tempo per essere arrestati in modo controllato in modo che non si verifichino interruzioni delle funzionalità dei cluster principali.

In GKE versione 1.27.5-gke.200 o precedente, consigliamo di contrassegnare come non pianificabile e svuotare i nodi che non supportano i pod DaemonSet.

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

  • Esegui il deployment dei DaemonSet prima di qualsiasi altro carico di lavoro.
  • Impostare un valore PriorityClass per i DaemonSet più alto rispetto ai pod normali. Il valore PriorityClass superiore consente a GKE di rimuovere i pod a priorità inferiore per ospitare i pod DaemonSet, se il nodo può ospitare questi pod. Questo contribuisce a garantire che il DaemonSet sia presente su ogni nodo senza attivare la nuova creazione dei nodi.

Gestione degli oggetti dei carichi di lavoro

Puoi creare, gestire ed eliminare gli oggetti utilizzando metodi imperativi e dichiarativi. Nelle sezioni seguenti vengono descritti questi metodi e i seguenti strumenti che puoi utilizzare per impiegarli:

Comandi imperativi

I comandi imperativi consentono di creare, visualizzare, aggiornare ed eliminare rapidamente gli 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 cluster.

kubectl include diversi comandi basati su verbi per la creazione e la modifica degli 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 etichette.
  • autoscale: crea un nuovo oggetto Autoscaler per scalare automaticamente orizzontalmente un oggetto controller, ad esempio un Deployment.

I comandi imperativi non richiedono una profonda comprensione dello schema degli oggetti e non richiedono file di configurazione.

Configurazione imperativa degli oggetti

La configurazione imperativa degli oggetti crea, aggiorna ed elimina gli oggetti utilizzando i file di configurazione contenenti definizioni di oggetti completamente definite. Puoi archiviare i file di configurazione degli oggetti nei sistemi di controllo dei file sorgente e verificare le modifiche in modo più semplice rispetto ai comandi imperativi.

Puoi eseguire operazioni kubectl apply, delete e replace con file di configurazione o directory contenenti file di configurazione.

Configurazione dichiarativa dell'oggetto

La configurazione dichiarativa degli oggetti opera su file di configurazione archiviati localmente, ma non richiede una definizione esplicita delle operazioni da eseguire. Al contrario, le operazioni vengono rilevate automaticamente per oggetto da kubectl. È utile se stai lavorando con una directory di file di configurazione con molte operazioni diverse. La gestione dichiarativa degli oggetti richiede una solida comprensione degli schemi di oggetti e dei file di configurazione.

Puoi eseguire kubectl apply per creare e aggiornare gli oggetti in modo dichiarativo. apply aggiorna gli oggetti leggendo l'intero oggetto attivo, calcolando le differenze e poi unendo le 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 controlla automaticamente il proxy di memorizzazione nella cache mirror.gcr.io per trovare una copia memorizzata nella cache dell'immagine container. Se una copia memorizzata nella cache non è disponibile, GKE estrae l'immagine richiesta da Docker Hub e il proxy di memorizzazione nella cache potrebbe memorizzare nella cache l'immagine per uso futuro. Per maggiori informazioni, consulta la sezione Pull 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 oggetti attivi dal browser web
  • Puoi visualizzare informazioni dettagliate sugli oggetti, tra cui cronologia delle revisioni, attività ed eventi recenti e i relativi pod gestiti
  • Puoi scalare facilmente deployment, job e oggetti StatefulSet
  • Puoi scalare automaticamente, attivare aggiornamenti in sequenza 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 l'API Kubernetes insieme alle 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 in tempo reale di un oggetto potrebbe essere diversa dal relativo file locale. YAML è generalmente utilizzato per creare e rappresentare oggetti Kubernetes. Puoi anche utilizzare JSON.

Per saperne di più sulle specifiche, sugli stati e sull'API Kubernetes, consulta gli articoli Informazioni sugli oggetti Kubernetes e Riferimento per l'API Kubernetes.

Ispezione delle configurazioni attive

Console

Per ispezionare 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 desiderato.

  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] potrebbe essere deployment, statefulset, job o un altro tipo di oggetto. 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, si teme che alcuni possano utilizzare più risorse rispetto alla loro giusta quota. Puoi utilizzare l'oggetto Kubernetes ResourceQuota per limitare il consumo di risorse all'interno di spazi dei nomi specifici.

GKE applica anche un oggetto gke-resource-quotas immutabile predefinito agli spazi dei nomi sui cluster con massimo 100 nodi per evitare l'instabilità.

Utilizza GitLab per il deployment in GKE

Se utilizzi GitLab per l'integrazione continua, puoi utilizzare il componente GKE GitHub per eseguire il deployment del tuo carico di lavoro in un cluster GKE.

Puoi anche provare il tutorial end-to-end per utilizzare GitLab con Google Cloud.

Per ulteriori informazioni, consulta la panoramica di GitLab su Google Cloud.

Passaggi successivi