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 en mode 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.

• 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