Charges de travail de conteneur dans GDC

Cette page de présentation explique le modèle opérationnel des charges de travail de conteneurs dans un cluster Kubernetes Google Distributed Cloud (GDC) isolé. GDC fournit un service Kubernetes géré qui est compatible avec les applications de conteneurs natifs Kubernetes largement utilisées et compatibles avec Google Kubernetes Engine (GKE).

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

Applications Kubernetes pour un environnement déconnecté

GKE sur GDC est un service Kubernetes géré qui intègre de nombreuses fonctionnalités GKE dans votre univers GDC par défaut. Ce service vous évite d'installer, de mettre à niveau, d'intégrer et d'exécuter vous-même Kubernetes Open Source. Vous pouvez exploiter et gérer la distribution Kubernetes fournie avec une API KRM standard, comme n'importe quelle autre offre Kubernetes déclarative et idempotente. De même, GKE sur GDC est proposé depuis la console GDC, la gcloud CLI 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 sur Premiers pas avec 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 les 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 souhaité de votre application de conteneur. 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 ni dans l'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 ressource Deployment pour déployer des applications sans état en tant que pods uniformes non uniques. Les déploiements gèrent l'état souhaité de votre application, par exemple :

  • Nombre de pods pour exécuter votre application.
  • Version de l'image de conteneur à exécuter.
  • Libellés 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, qui utilisent un stockage persistant pour enregistrer les données et l'état des applications.

Charges de travail avec état

Les charges de travail avec état sont des applications qui enregistrent des 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 stockage persistant pour que votre application avec état puisse l'utiliser.

Kubernetes utilise la ressource StatefulSet 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 persistant de blocs et de fichiers via des objets PersistentVolumeClaim (PVC). Une PVC est une demande 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. Un 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 stockage persistant pour vos charges de travail avec état, de sorte que les volumes sous-jacents sont créés à la demande. Dans GDC, vous configurez le provisionnement dynamique en créant l'un des objets StorageClass préinstallés suivants :

  • standard-rwo : classe de stockage par blocs ReadWriteOnce (RWO). Le volume ne peut être accessible que par un seul nœud à la fois. Cette classe de stockage offre une garantie et une limite d'opérations d'entrée/sortie par seconde (IOPS) de 3 IOPS par Gio.

  • system-performance-rwo : classe de stockage de blocs de performances ReadWriteOnce. Cette classe de stockage est une version plus performante du stockage RWO. Elle offre une garantie et une limite d'IOPS de 30 IOPS par Gio.

Vous pouvez également créer un objet VolumeSnapshot pour copier le volume de stockage de votre application de conteneur à un moment précis sans créer de volume. 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 (édition ou suppression).

Étapes suivantes