Deployment di un'applicazione stateful

Autopilot Standard

Questa pagina spiega come eseguire il deployment di un'applicazione stateful utilizzando Google Kubernetes Engine (GKE).

Panoramica

Le applicazioni stateful salvano i dati nello spazio di archiviazione su Persistent Disk per l'utilizzo da parte del server, dei client e di altre applicazioni. Un esempio di applicazione stateful è un database o un archivio di coppie chiave-valore in cui i dati vengono salvati e recuperati da altre applicazioni.

È possibile eseguire il provisioning dinamico dello spazio di archiviazione permanente, in modo che i volumi sottostanti vengano creati on demand. In Kubernetes, il provisioning dinamico viene configurato creando un oggetto StorageClass. In GKE, una StorageClass predefinita consente di eseguire il provisioning dinamico dei dischi permanenti di Compute Engine.

Kubernetes utilizza il controller StatefulSet per eseguire il deployment di applicazioni stateful come oggetti StatefulSet. I pod negli StatefulSet non sono intercambiabili: ogni pod ha un identificatore univoco che viene mantenuto indipendentemente da dove è pianificato.

Le applicazioni stateful sono diverse dalle applicazioni stateless, in cui i dati del client non vengono salvati sul server tra una sessione e l'altra.

Puoi scoprire di più sull'archiviazione permanente nei cluster multizona e regionali.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati che l'applicazione containerizzata sia archiviata in un registro di immagini, ad esempio Artifact Registry.

Puoi seguire la guida rapida per abilitare l'API GKE, creare un cluster e scoprire di più su GKE.

Richiesta di archiviazione permanente in uno StatefulSet

Le applicazioni possono richiedere l'archiviazione permanente con un PersistentVolumeClaim.

In genere, oltre a creare il pod, devi creare oggetti PersistentVolumeClaim. Tuttavia, gli oggetti StatefulSet includono un array volumeClaimTemplates, che genera automaticamente gli oggetti PersistentVolumeClaim. Ogni replica StatefulSet riceve il proprio oggetto PersistentVolumeClaim.

Puoi anche utilizzare un disco preesistente in uno StatefulSet.

Associazione della topologia dinamica

Quando crei StatefulSet che utilizzano PersistentVolume a livello di zona, una best practice è configurare la definizione di StorageClass con la coppia campo-valore volumeBindingMode: WaitForFirstConsumer. Questa impostazione contribuisce a garantire che il provisioning del volume venga ritardato fino a quando non viene pianificato un pod su un nodo integro in una zona con capacità di computing sufficiente. Se utilizzi l'associazione immediata predefinita, rischi di bloccare il volume di un pod in una zona che potrebbe non avere capacità di calcolo sufficiente prima della pianificazione del pod, intrappolando il pod in uno stato Pending.

Creazione di un oggetto StatefulSet

Per creare una risorsa StatefulSet, utilizza il comando kubectl apply.

Il comando kubectl apply utilizza i file manifest per creare, aggiornare ed eliminare le risorse nel cluster. Questo è un metodo dichiarativo di configurazione degli oggetti. Questo metodo conserva le scritture apportate agli oggetti attivi senza unire le modifiche ai file di configurazione degli oggetti.

Linux

Il seguente file manifest è un esempio di un servizio headless e dello StatefulSet che gestisce:

apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: PORT_NAME
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      # Selects Pods with this label.
      app: APP_NAME
  # Headless Service for network identity.
  serviceName: "SERVICE_NAME"
  replicas: 3
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: APP_NAME
    spec:
      containers:
      - name: CONTAINER_NAME
        image: IMAGE
        ports:
        - containerPort: 80
          name: PORT_NAME
        volumeMounts:
        - name: PVC_NAME
          mountPath: MOUNT_PATH
  volumeClaimTemplates:
  - metadata:
      name: PVC_NAME
      annotations:
        KEY: VALUE
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Sostituisci quanto segue:

• STATEFULSET_NAME: il nome dello StatefulSet, ad esempio web.
• SERVICE_NAME: il nome del servizio, ad esempio nginx.
• APP_NAME: il nome dell'applicazione eseguita nei pod, ad esempio nginx.
• CONTAINER_NAME: il nome dei container nei pod, ad esempio nginx.
• IMAGE: la tua immagine container, ad esempio nginx:stable.
• PORT_NAME: il nome della porta aperta dallo StatefulSet, ad esempio web.
• PVC_NAME: il nome del PersistentVolumeClaim, ad esempio www.
• MOUNT_PATH: il percorso nel container in cui è montato lo spazio di archiviazione, ad esempio /usr/share/nginx/html.
• KEY e VALUE: una coppia chiave-valore di annotazione da applicare ai metadati PersistentVolumeClaim. Puoi utilizzare le annotazioni per collegare agli oggetti metadati non identificativi arbitrari che possono essere recuperati da client come strumenti e librerie. Per scoprire di più, consulta Annotazioni.

In questo file, il campo kind specifica che deve essere creato un oggetto StatefulSet con le specifiche definite nel file. Questo StatefulSet di esempio produce tre pod replicati e apre la porta 80 per esporre lo StatefulSet a internet.

Windows

Quando utilizzi cluster con pool di nodi Windows Server, devi creare un oggetto StorageClass perché l'oggetto StorageClass predefinito utilizza ext4 come tipo di file system, che funziona solo per i container Linux. Se utilizzi un disco permanente di Compute Engine, devi utilizzare NTFS come tipo di archiviazione dei file, come mostrato nell'esempio seguente:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  # Defines a name for this StorageClass.
  name: STORAGECLASS_NAME
parameters:
  # Specifies the type of Google Compute Engine persistent disk.
  type: pd-standard
  # Uses NTFS file system, which is crucial for Windows nodes
  fstype: NTFS
# The provisioner for Google Compute Engine persistent disks.
provisioner: kubernetes.io/gce-pd
# Specifies that the PersistentVolume will be deleted if the PersistentVolumeClaim is deleted.
reclaimPolicy: Delete
# Delays volume binding until a Pod using the PVC is scheduled.
volumeBindingMode: WaitForFirstConsumer

Il seguente manifest StatefulSet utilizza l'oggetto StorageClass definito sopra. Crea quattro coppie PersistentVolume e PersistentVolumeClaim per rappresentare quattro Persistent Disk di Compute Engine. Ogni pod nello StatefulSet utilizza un disco permanente.

Per assicurarti che i pod siano pianificati correttamente sui nodi Windows Server, devi aggiungere un selettore di nodi alla specifica del pod.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  replicas: 4
  selector:
    matchLabels:
      # Selects Pods with this label.
      app: APP_NAME
  template:
    metadata:
      labels:
        # Labels applied to the Pods created by the StatefulSet.
        app: APP_NAME
      name: CONTAINER_NAME
    spec:
      nodeSelector:
        # Ensures Pods are scheduled on Windows nodes.
        kubernetes.io/os: windows
      containers:
      - name: CONTAINER_NAME
        image: IMAGE
        ports:
        - containerPort: 80
          name: PORT_NAME
        volumeMounts:
        - name: PVC_NAME
          mountPath: MOUNT_PATH
  volumeClaimTemplates:
  - metadata:
      name: PVC_NAME
    spec:
      # Specifies the StorageClass to use, which is crucial for Windows nodes.
      storageClassName: STORAGECLASS_NAME
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Sostituisci quanto segue:

• STATEFULSET_NAME: il nome dello StatefulSet, ad esempio web-windows.
• APP_NAME: il nome dell'applicazione eseguita nei pod, ad esempio iis.
• CONTAINER_NAME: il nome dei container nei pod, ad esempio iis.
• IMAGE: la tua immagine container, ad esempio mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019.
• PORT_NAME: il nome della porta aperta dallo StatefulSet, ad esempio http.
• PVC_NAME: il nome del PersistentVolumeClaim, ad esempio iis-state.
• MOUNT_PATH: il percorso nel container in cui è montato lo spazio di archiviazione, ad esempio C:\mnt\state.
• STORAGECLASS_NAME: il nome di StorageClass, ad esempio my-storage-class.

Per creare una risorsa StatefulSet, esegui questo comando sostituendo STATEFULSET_FILE con il nome del file manifest:

kubectl apply -f STATEFULSET_FILE

Puoi anche utilizzare kubectl apply -f DIRECTORY/ per creare tutti gli oggetti (ad eccezione di quelli esistenti) definiti nei file di configurazione archiviati in una directory.

Nota: kubectl apply non va a buon fine se non hai un cluster attivo.

Ispezione di un oggetto StatefulSet

kubectl

Per ispezionare lo StatefulSet, esegui questo comando:

kubectl get statefulset STATEFULSET_NAME -o yaml

Questo comando mostra la configurazione attiva della risorsa StatefulSet in formato YAML.

Per elencare i pod creati dallo StatefulSet, esegui questo comando:

kubectl get pods -l app=APP_NAME

In questo comando, il flag -l indica a kubectl di recuperare tutti i pod etichettati per APP_NAME.

L'output è simile al seguente:

NAME                                READY     STATUS    RESTARTS   AGE
pod-name                            1/1       Running   0          1m
pod-name                            1/1       Running   0          1m

Per ottenere informazioni dettagliate sullo StatefulSet, esegui questo comando:

kubectl describe statefulset STATEFULSET_NAME

Per ottenere informazioni su un pod specifico, esegui questo comando:

kubectl describe pod POD_NAME

Per elencare gli oggetti PersistentVolumeClaim creati, esegui questo comando:

kubectl get pvc

L'output è simile al seguente:

NAME                            STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
STATEFULSET_NAME-PVC_NAME-0     Bound     pvc-bdff4e1e-183e-11e8-bf6d-42010a800002   1G         RWO            standard        9s
STATEFULSET_NAME-PVC_NAME-1     Bound     pvc-bdff4e1e-183e-11e8-bf6d-42010a800003   1G         RWO            standard        9s
STATEFULSET_NAME-PVC_NAME-2     Bound     pvc-bdff4e1e-183e-11e8-bf6d-42010a800004   1G         RWO            standard        9s

Per ottenere informazioni su un PersistentVolumeClaim specifico, esegui questo comando:

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Per ottenere informazioni su un PersistentVolume specifico, esegui questo comando:

kubectl describe pv PV_NAME

Console

Per ispezionare uno StatefulSet, segui questi passaggi:

1. Vai alla pagina Workload nella console Google Cloud .

   Vai a Carichi di lavoro

2. Nell'elenco dei workload, fai clic sul nome dello StatefulSet che vuoi ispezionare.

3. Nella pagina Dettagli StatefulSet, esegui una delle seguenti operazioni:

   • Fai clic sulla scheda Cronologia delle revisioni per visualizzare la cronologia delle revisioni dello StatefulSet.
   • Fai clic sulla scheda Eventi per visualizzare tutti gli eventi correlati allo StatefulSet.
   • Fai clic sulla scheda Log per visualizzare i log dei container per lo StatefulSet.
   • Fai clic sulla scheda YAML per visualizzare, copiare o scaricare il file YAML di configurazione per lo StatefulSet.

Aggiornamento di un oggetto StatefulSet

Esistono diversi modi per aggiornare gli StatefulSet. Il metodo dichiarativo comune è kubectl apply. Per aggiornare lo StatefulSet direttamente dalla shell o in un editor preferito, puoi utilizzare kubectl edit. Puoi anche utilizzare l'editor YAML dal menu Workload GKE nella console Google Cloud .

Puoi implementare gli aggiornamenti alla specifica dei pod per una risorsa StatefulSet, ad esempio l'immagine, l'utilizzo/le richieste delle risorse o la configurazione.

kubectl apply

Puoi aggiornare lo StatefulSet applicando un file manifest nuovo o aggiornato. Questo è utile per apportare varie modifiche allo StatefulSet, ad esempio quando esegui lo scale up o lo scale down o per specificare una nuova versione dell'applicazione.

Nota: per aggiornare una risorsa con kubectl apply, la risorsa deve essere stata creata utilizzando kubectl apply o kubectl create --save-config.

Per aggiornare uno StatefulSet, esegui questo comando:

kubectl apply -f STATEFULSET_FILE

Sostituisci STATEFULSET_FILE con il manifest di aggiornamento.

Il comando kubectl apply applica un file manifest a una risorsa. Se la risorsa specificata non esiste, viene creata dal comando.

Per saperne di più su kubectl apply, consulta la documentazione di riferimento di kubectl.

Console

Per modificare la configurazione live di uno StatefulSet, segui questi passaggi:

1. Vai alla pagina Workload nella console Google Cloud .

   Vai a Carichi di lavoro

2. Nell'elenco dei workload, fai clic sul nome dello StatefulSet da modificare.

3. Fai clic su Modifica.

4. Modifica il file YAML di configurazione come preferisci.

5. Fai clic su Salva.

Nota: sebbene sia possibile specificare un PersistentVolume diverso, non è possibile aggiornare le risorse PersistentVolume esistenti.

Ispezione dell'implementazione dell'aggiornamento

Per esaminare l'implementazione dello StatefulSet, esegui questo comando:

kubectl rollout status statefulset STATEFULSET_NAME

Per visualizzare la cronologia di implementazione dello StatefulSet, esegui questo comando:

kubectl rollout history statefulset STATEFULSET_NAME

Per annullare un'implementazione, esegui questo comando:

kubectl rollout undo statefulset STATEFULSET_NAME

Strategie di aggiornamento

Il campo updateStrategy di StatefulSet consente di configurare e disattivare gli aggiornamenti in sequenza automatici per container, etichette, richieste di risorse, limiti e annotazioni per i pod in un oggetto StatefulSet.

Puoi scoprire di più sulle strategie di aggiornamento per gli StatefulSet nella documentazione di Kubernetes.

Scalabilità di uno StatefulSet

kubectl

Il comando kubectl scale può essere utilizzato in qualsiasi momento per scalare lo StatefulSet.

Per scalare manualmente uno StatefulSet, esegui questo comando:

kubectl scale statefulset STATEFULSET_NAME --replicas NUMBER_OF_REPLICAS

Sostituisci NUMBER_OF_REPLICAS con il numero desiderato di pod replicati.

Console

Per scalare uno StatefulSet, segui questi passaggi:

1. Vai alla pagina Workload nella console Google Cloud .

   Vai a Carichi di lavoro

2. Nell'elenco dei workload, fai clic sul nome dello StatefulSet da modificare.

3. Fai clic su Azioni > Scala > Modifica repliche.

4. Inserisci il nuovo numero di Repliche per lo StatefulSet.

5. Fai clic su Scala.

Eliminazione di uno StatefulSet

kubectl

Per eliminare uno StatefulSet, esegui questo comando:

kubectl delete statefulset STATEFULSET_NAME

Console

Per eliminare uno StatefulSet, segui questi passaggi:

1. Vai alla pagina Workload nella console Google Cloud .

   Vai a Carichi di lavoro

2. Nell'elenco dei workload, seleziona uno o più StatefulSet da eliminare.

3. Fai clic su Elimina.

4. Quando ti viene richiesto di confermare, fai clic su Elimina.

Passaggi successivi

• Scopri come eseguire il deployment di un cluster MySQL su GKE per l'alta affidabilità
• Scopri di più sul deployment di applicazioni stateless.
• Segui un tutorial sull'upgrade di un cluster che esegue un workload stateful.