Créer des charges de travail avec état

Cette page explique comment créer et gérer des charges de travail avec état dans un cluster Kubernetes Google Distributed Cloud (GDC) isolé. Les charges de travail avec état vous permettent de mettre à l'échelle le déploiement de votre application avec un stockage persistant. Le stockage persistant fournit à votre application des identités cohérentes et des noms d'hôtes stables, quel que soit l'endroit où ses charges de travail sont planifiées.

Cette page s'adresse aux développeurs du groupe des opérateurs d'applications, qui sont chargés de créer des charges de travail d'application pour leur organisation. Pour en savoir plus, consultez la documentation sur les audiences pour GDC air-gapped.

Avant de commencer

Pour exécuter des commandes sur un cluster Kubernetes, assurez-vous de disposer des ressources suivantes :

  1. Recherchez le nom du cluster Kubernetes ou demandez-le à votre administrateur de plate-forme.

  2. Connectez-vous et générez le fichier kubeconfig pour le cluster Kubernetes si vous n'en avez pas.

  3. Utilisez le chemin d'accès kubeconfig du cluster Kubernetes pour remplacer KUBERNETES_CLUSTER_KUBECONFIG dans ces instructions.

Pour obtenir les autorisations requises pour créer des charges de travail avec état, demandez à votre administrateur IAM de l'organisation de vous attribuer le rôle d'administrateur de l'espace de noms (namespace-admin) dans l'espace de noms de votre projet.

Créer une ressource StatefulSet

Créez un objet StatefulSet en écrivant un fichier manifeste StatefulSet et en exécutant kubectl apply pour créer la ressource. Pour fournir aux clients un moyen stable d'envoyer des requêtes aux pods de votre ressource StatefulSet, vous devez également créer un objet Service.

La commande kubectl apply utilise des fichiers manifestes pour créer, mettre à jour et supprimer des ressources dans votre cluster Kubernetes. Il s'agit d'une méthode déclarative de configuration d'objet. Cette méthode conserve les écritures effectuées sur les objets actifs sans fusionner les modifications dans les fichiers de configuration d'objet.

Pour créer une ressource StatefulSet et Service, exécutez la commande suivante :

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

Remplacez les éléments suivants :

  • KUBERNETES_CLUSTER_KUBECONFIG : fichier kubeconfig du cluster sur lequel vous déployez des charges de travail de conteneur.

  • NAMESPACE : espace de noms du projet dans lequel déployer les charges de travail du conteneur.

  • SERVICE_NAME : nom de l'objet Service. Assurez-vous que l'objet StatefulSet définit également l'objet Service dans son serviceName.

  • APP_NAME : nom de l'application à exécuter dans le déploiement.

  • APP_LABEL_NAME : sélecteur de libellés qui détermine les pods appartenant à l'objet StatefulSet.

  • STATEFULSET_NAME : nom de l'objet StatefulSet.

  • NUMBER_OF_REPLICAS : nombre d'objets Pod répliqués gérés par le déploiement.

  • CONTAINER_NAME : nom du conteneur.

  • CONTAINER_IMAGE : nom de l'image du conteneur. Vous devez inclure le chemin d'accès au registre de conteneurs et la version de l'image, par exemple REGISTRY_PATH/nginx:1.23. Pour en savoir plus sur la définition du chemin d'accès au registre de conteneurs, consultez la présentation du service Managed Harbor.

  • CONTAINER_STORAGE_VOLUME_PATH : chemin d'accès dans le conteneur sur lequel un volume de stockage est installé.

Par exemple, l'objet StatefulSet suivant et l'objet Service correspondant créent des charges de travail de conteneur avec état :

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

Dans cet exemple :

  • Un objet Service nommé nginx est créé, indiqué par le champ metadata: name. L'objet Service cible une application appelée nginx, définie par les champs labels.app: nginx et selector.app: nginx. L'objet Service expose le port 80 et le nomme web. Cet objet Service contrôle le domaine réseau et achemine le trafic Internet vers l'application conteneurisée déployée par l'objet StatefulSet.
  • Un StatefulSet nommé web est créé avec trois objets Pod répliqués, comme défini par le champ replicas: 3.
  • Le modèle Pod, défini par la section .spec.template, indique que ses objets Pod sont libellés app: nginx.
  • La spécification Pod, définie par la section .template.spec, indique que les pods de StatefulSet exécutent un conteneur, nginx, qui exécute l'image nginx dans sa version 1.23.
  • La spécification Pod utilise le port Web ouvert par l'objet Service.
  • La section .template.spec.volumeMounts spécifie un champ mountPath, nommé www. mountPath est le chemin d'accès dans le conteneur où un volume de stockage est installé.
  • StatefulSet provisionne trois objets PersistentVolumeClaim, nommés web-www-0, web-www-1 et web-www-2, avec 1 Go d'espace de stockage provisionné chacun.

Une fois créé, le StatefulSet garantit que le nombre souhaité d'objets Pod est en cours d'exécution et disponible à tout moment. L'objet StatefulSet remplace automatiquement les objets Pod qui échouent ou sont évincés de leurs nœuds, et associe de nouveaux objets Pod aux ressources de stockage, aux demandes de ressources et aux limites, ainsi qu'aux autres configurations définies dans la spécification Pod de l'objet StatefulSet.

Demander un stockage persistant dans une ressource StatefulSet

Le stockage persistant peut être provisionné de manière dynamique, de sorte que les volumes sous-jacents sont créés à la demande. Les applications peuvent demander stockage persistant à l'aide d'un objet PersistentVolumeClaim.

En règle générale, vous devez créer des objets PersistentVolumeClaim en plus de créer l'objet Pod. Cependant, les objets StatefulSet incluent un tableau volumeClaimTemplates qui génère les objets PersistentVolumeClaim. Chaque réplica StatefulSet obtient son propre objet PersistentVolumeClaim.

Pour en savoir plus, consultez Configurer le stockage des conteneurs.