Crea workload stateful

Questo documento spiega come creare e gestire i workload stateful all'interno di un cluster Kubernetes con air gap di Google Distributed Cloud (GDC). I workload stateful ti consentono di scalare il deployment dell'applicazione con spazio di archiviazione permanente. Lo spazio di archiviazione permanente fornisce alla tua applicazione identità coerenti e nomi host stabili, indipendentemente da dove vengono pianificati i suoi carichi di lavoro.

Questo documento è destinato agli sviluppatori del gruppo di operatori di applicazioni, che sono responsabili della creazione dei carichi di lavoro delle applicazioni per la loro organizzazione. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC con air gap.

Prima di iniziare

Per completare le attività descritte in questo documento, devi richiedere le autorizzazioni necessarie e preparare l'ambiente.

Richiedi ruoli IAM

Devi disporre di ruoli specifici per ottenere le autorizzazioni necessarie per creare carichi di lavoro stateful. I ruoli necessari dipendono dal fatto che tu stia lavorando all'interno di un cluster condiviso con ambito organizzazione o di un cluster standard con ambito progetto. Per saperne di più, consulta Configurazioni dei cluster Kubernetes.

Ruoli cluster condivisi

Per creare, eliminare, modificare o visualizzare carichi di lavoro stateful in un cluster condiviso, chiedi all'amministratore IAM del progetto di concederti il ruolo Amministratore spazio dei nomi (namespace-admin). Questo ruolo è associato allo spazio dei nomi del progetto.

Ruoli cluster standard

Per creare, eliminare, modificare o visualizzare carichi di lavoro stateful in un cluster standard, chiedi all'amministratore IAM del progetto di concederti il ruolo Sviluppatore cluster (cluster-developer). Questo ruolo è associato allo spazio dei nomi del progetto.

prepara l'ambiente

Per eseguire comandi su un cluster Kubernetes utilizzando l'API, assicurati di disporre delle seguenti risorse:

  • Individua il nome del cluster Kubernetes o chiedi a un membro del gruppo di amministratori della piattaforma qual è il nome del cluster.

  • Accedi e genera il file kubeconfig per il cluster Kubernetes.

  • Utilizza il percorso kubeconfig del cluster Kubernetes per sostituire KUBERNETES_CLUSTER_KUBECONFIG in queste istruzioni.

Crea una risorsa StatefulSet

Crea un oggetto StatefulSet scrivendo un manifest StatefulSet e eseguendo kubectl apply per creare la risorsa. Per fornire un modo stabile per i client di inviare richieste ai pod della risorsa StatefulSet, devi anche creare un oggetto Service.

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

Per creare una risorsa StatefulSet e Service, esegui:

kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      app: APP_LABEL_NAME
  serviceName: "SERVICE_NAME"
  replicas: NUMBER_OF_REPLICAS
  template:
    metadata:
      labels:
        app: APP_LABEL_NAME
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: CONTAINER_STORAGE_VOLUME_PATH
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

Sostituisci quanto segue:

  • KUBERNETES_CLUSTER_KUBECONFIG: il file kubeconfig per il cluster in cui stai eseguendo il deployment dei carichi di lavoro dei container.

  • NAMESPACE: lo spazio dei nomi in cui eseguire il deployment dei workload dei container. Per i cluster condivisi, deve trattarsi di uno spazio dei nomi del progetto. Per i cluster standard, può essere qualsiasi spazio dei nomi.

  • SERVICE_NAME: il nome dell'oggetto Service. Assicurati che l'oggetto StatefulSet imposti l'oggetto Service anche nel suo serviceName.

  • APP_NAME: il nome dell'applicazione da eseguire all'interno del deployment.

  • APP_LABEL_NAME: il selettore di etichette che determina quali pod appartengono all'oggetto StatefulSet.

  • STATEFULSET_NAME: il nome dell'oggetto StatefulSet.

  • NUMBER_OF_REPLICAS: il numero di oggetti Pod replicati gestiti dal deployment.

  • CONTAINER_NAME: il nome del contenitore.

  • CONTAINER_IMAGE: il nome dell'immagine container. Devi includere il percorso del registro dei container e la versione dell'immagine, ad esempio REGISTRY_PATH/nginx:1.23. Per saperne di più sull'impostazione del percorso del registro dei container, consulta la panoramica del servizio Managed Harbor.

  • CONTAINER_STORAGE_VOLUME_PATH: il percorso all'interno del container in cui è montato un volume di archiviazione.

Ad esempio, il seguente oggetto StatefulSet e l'oggetto Service corrispondente creano carichi di lavoro dei container stateful:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: REGISTRY_PATH/nginx:1.23
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

In questo esempio:

  • Viene creato un oggetto Service denominato nginx, indicato dal campo metadata: name. L'oggetto Service ha come target un'app chiamata nginx, indicata da labels.app: nginx e selector.app: nginx. L'oggetto Service espone la porta 80 e la denomina web. Questo oggetto Service controlla il dominio di rete e instrada il traffico internet all'applicazione containerizzata di cui è stato eseguito il deployment dall'oggetto StatefulSet.
  • Viene creato un StatefulSet denominato web con tre oggetti Pod replicati, come impostato dal campo replicas: 3.
  • Il modello Pod, impostato dalla sezione .spec.template, indica che i relativi oggetti Pod sono etichettati app: nginx.
  • La specifica Pod, impostata dalla sezione .template.spec, indica che i pod di StatefulSet eseguono un container, nginx, che esegue l'immagine nginx alla versione 1.23.
  • La specifica Pod utilizza la porta web aperta dall'oggetto Service.
  • La sezione .template.spec.volumeMounts specifica un campo mountPath, denominato www. mountPath è il percorso nel container in cui è montato un volume di archiviazione.
  • StatefulSet esegue il provisioning di tre oggetti PersistentVolumeClaim denominati web-www-0, web-www-1 e web-www-2, con 1 GB di spazio di archiviazione di cui è stato eseguito il provisioning ciascuno.

Una volta creato, StatefulSet garantisce che il numero target di oggetti Pod sia in esecuzione e disponibile in qualsiasi momento. StatefulSet sostituisce automaticamente gli oggetti Pod che non funzionano o vengono rimossi dai nodi e associa nuovi oggetti Pod alle risorse di archiviazione, alle richieste e ai limiti delle risorse e ad altre configurazioni definite nella specifica Pod dell'oggetto StatefulSet.

Richiedere l'archiviazione permanente in una risorsa StatefulSet

Lo spazio di archiviazione permanente può essere sottoposto a provisioning dinamico in modo che i volumi sottostanti vengano creati on demand. Le applicazioni possono richiedere l'archiviazione permanente con un oggetto PersistentVolumeClaim.

In genere, devi creare oggetti PersistentVolumeClaim oltre a creare l'oggetto Pod. Tuttavia, gli oggetti StatefulSet includono un array volumeClaimTemplates che genera gli oggetti PersistentVolumeClaim. Ogni replica StatefulSet ha il proprio oggetto PersistentVolumeClaim.

Per saperne di più, consulta Configura l'archiviazione dei container.

Passaggi successivi