Charges de travail de conteneur dans GDC

Cette page de présentation explique le modèle d'exploitation des charges de travail de conteneurs dans un cluster Kubernetes Google Distributed Cloud (GDC) sous air gap. GDC fournit un service Kubernetes géré qui prend en charge les applications de conteneurs natives de Kubernetes, largement utilisées et compatibles avec Google Kubernetes Engine (GKE).

Cette page s'adresse aux développeurs du groupe d'opérateurs d'applications, qui sont chargés de gérer les charges de travail d'applications pour leur organisation. Pour en savoir plus, consultez Audiences pour la documentation GDC sous air gap.

Applications Kubernetes pour un environnement déconnecté

GKE on GDC est un service Kubernetes géré qui intègre par défaut de nombreuses fonctionnalités GKE dans votre univers GDC. Ce service vous évite d'avoir à installer, mettre à niveau, intégrer et exécuter vous-même Kubernetes Open Source. Vous pouvez exploiter et gérer la distribution Kubernetes fournie avec une API KRM standard, comme toute autre offre Kubernetes déclarative et idempotente. De même, GKE on GDC est disponible dans la console GDC, la CLI gdcloud et Terraform. Pour en savoir plus sur les clusters Kubernetes GDC, consultez la présentation des clusters Kubernetes. Pour en savoir plus sur les concepts clés de Kubernetes, consultez la documentation GKE pour commencer à découvrir Kubernetes.

État de la charge de travail du conteneur

Dans GDC, les conteneurs sont déployés dans des clusters Kubernetes comme suit :

Vous pouvez effectuer un scaling horizontal des nœuds de votre cluster Kubernetes GDC en fonction des exigences de vos charges de travail de conteneurs, même après le provisionnement du cluster, à mesure que vos besoins de calcul évoluent.

Kubernetes fournit plusieurs ressources de charge de travail intégrées pour atteindre l'état d'application de conteneur souhaité. Pour en savoir plus, consultez la documentation sur les charges de travail Kubernetes .

Charges de travail sans état

Les charges de travail sans état sont des applications qui ne stockent pas de données ni d'état d'application dans le cluster Kubernetes ou dans un espace de stockage persistant. Au lieu de cela, les données et l'état de l'application sont conservés par le client, ce qui rend les applications sans état plus évolutives. Par exemple, une application d'interface peut être sans état : vous déployez plusieurs instances dupliquées pour augmenter sa disponibilité et procédez à une réduction lorsque la demande est faible, et les instances dupliquées n'ont pas besoin d'identités uniques.

Kubernetes utilise la Deployment ressource pour déployer des applications sans état en tant que pods uniformes et non uniques Pods. Les déploiements gèrent l'état souhaité de votre application, par exemple :

  • Le nombre de pods pour exécuter votre application
  • La version de l'image de conteneur à exécuter
  • Les étiquettes des pods

Vous pouvez modifier l'état souhaité de manière dynamique en mettant à jour la spécification Pod de la ressource Deployment.

Les applications sans état s'opposent aux charges de travail avec état, dans lesquelles un espace de stockage persistant permet d'enregistrer les données et l'état de l'application.

Charges de travail avec état

Les charges de travail avec état sont des applications qui enregistrent les données dans un stockage sur disque persistant destiné au serveur, aux clients et aux autres applications. Une application avec état est, par exemple, une base de données ou un espace de stockage de paires clé/valeur où les données sont enregistrées et récupérées par d'autres applications. Vous devez provisionner un espace de stockage persistant pour que votre application avec état puisse l'utiliser.

Kubernetes utilise la StatefulSet ressource pour déployer des applications avec état. Les pods des ressources StatefulSet ne sont pas interchangeables : chaque pod possède un identifiant unique qui est maintenu, peu importe l'emplacement lié à sa planification.

Les applications avec état diffèrent des charges de travail sans état, dans lesquelles les données client ne sont pas enregistrées sur le serveur entre les sessions.

Stockage persistant pour les conteneurs

GDC fournit un stockage de blocs persistant via PersistentVolumeClaim (PVC) objets. Une PVC est une requête de stockage référencée par un objet Pod. Un pod est un groupe d'un ou plusieurs conteneurs qui partagent des ressources réseau et de stockage. Une PVC a un cycle de vie indépendant de celui du pod, ce qui lui permet de persister au-delà d'un seul pod.

Vous pouvez provisionner de manière dynamique un espace de stockage persistant pour vos charges de travail avec état, de sorte que les volumes sous-jacents soient créés à la demande. Dans GDC, vous configurez le provisionnement dynamique en créant l'objet StorageClass préinstallé standard-rwo. L'objet standard-rwo est une classe de stockage de blocs ReadWriteOnce (RWO) qui permet à un volume d'accéder à un seul nœud à la fois.

Vous pouvez également créer un VolumeSnapshot objet pour copier le volume de stockage de votre application de conteneur à un moment donné sans créer de volume entièrement nouveau. Par exemple, un administrateur de base de données peut créer un instantané de volume pour sauvegarder les bases de données avant d'effectuer des modifications d'édition ou de suppression.

Étape suivante