Créer des charges de travail avec état

Ce document explique comment créer et gérer des charges de travail avec état dans un cluster Kubernetes Google Distributed Cloud (GDC) sous air gap. 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.

Ce document s'adresse aux développeurs du groupe d'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 Audiences pour la documentation GDC sous air gap.

Avant de commencer

Pour effectuer les tâches décrites dans ce document, vous devez demander les autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Vous devez disposer de rôles spécifiques pour obtenir les autorisations nécessaires à la création de charges de travail avec état. Les rôles dont vous avez besoin dépendent du fait que vous travaillez dans un cluster partagé à l'échelle de l'organisation ou dans un cluster standard à l'échelle du projet. Pour en savoir plus, consultez Configurations de cluster Kubernetes.

Rôles de cluster partagé

Pour créer, supprimer, modifier ou afficher des charges de travail avec état dans un cluster partagé, demandez à votre administrateur IAM de projet de vous accorder le rôle Administrateur d'espace de noms (namespace-admin). Ce rôle est lié à l'espace de noms de votre projet.

Rôles de cluster standard

Pour créer, supprimer, modifier ou afficher des charges de travail avec état dans un cluster standard, demandez à votre administrateur IAM de projet de vous accorder le rôle Développeur de cluster (cluster-developer). Ce rôle est lié à l'espace de noms de votre projet.

Préparer votre environnement

Pour exécuter des commandes sur un cluster Kubernetes à l'aide de l'API, assurez-vous de disposer des ressources suivantes :

  • Recherchez le nom du cluster Kubernetes ou demandez-le à un membre du groupe d'administrateurs de plate-forme.

  • Connectez-vous et générez le fichier kubeconfig pour le cluster Kubernetes.

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

Créer une ressource StatefulSet

Créez un objet StatefulSet en écrivant un manifeste StatefulSet et en exécutant kubectl apply pour créer la ressource. Pour permettre aux clients d'envoyer des requêtes aux pods de votre ressource StatefulSet de manière stable, 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 dans lequel déployer les charges de travail de conteneur. Pour les clusters partagés, il doit s'agir d'un espace de noms de projet. Pour les clusters standards, il peut s'agir de n'importe quel espace de noms.

  • 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é 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 de 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 de Managed Harbor Service.

  • CONTAINER_STORAGE_VOLUME_PATH: chemin d'accès dans le conteneur où un volume de stockage est monté.

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éé, comme indiqué par le champ metadata: name. L'objet Service cible une application appelée nginx, comme indiqué par 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 de réseau et achemine le trafic Internet vers l'application en conteneur déployée par l'objet StatefulSet.
  • Un objet 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 l'objet StatefulSet exécutent un conteneur, nginx, qui exécute l'image nginx à la 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. Le mountPath est le chemin d'accès dans le conteneur où un volume de stockage est monté.
  • L'objet StatefulSet provisionne trois objets PersistentVolumeClaim, nommés web-www-0, web-www-1 et web-www-2, chacun doté de 1 Go d'espace de stockage provisionné.

Une fois créé, l'objet StatefulSet garantit que le nombre cible 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 éléments de configuration définis 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 un stockage persistant à l'aide d'un objet PersistentVolumeClaim.

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

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

Étape suivante