Présentation du déploiement des charges de travail


Pour déployer et gérer vos applications conteneurisées et d'autres charges de travail sur votre cluster Google Kubernetes Engine (GKE), vous devez utiliser le système Kubernetes pour créer des objets contrôleurs Kubernetes. Ces objets contrôleurs représentent les applications, daemons et tâches par lots exécutés sur vos clusters.

Vous pouvez créer ces objets contrôleurs à l'aide de l'API Kubernetes ou en passant par kubectl, une interface de ligne de commande pour Kubernetes installée par gcloud. Généralement, vous construisez une représentation de l'objet contrôleur Kubernetes souhaité sous forme de fichier de configuration YAML, puis vous utilisez ce fichier avec l'API Kubernetes ou l'interface de ligne de commande kubectl.

Types de charges de travail

Kubernetes fournit différents types d'objets contrôleurs correspondant à différents types de charges de travail que vous pouvez exécuter. Certains objets contrôleurs sont plus adaptés pour représenter certains types de charges de travail spécifiques. Les sections suivantes décrivent certains types de charges de travail courants et les objets contrôleurs Kubernetes que vous pouvez créer pour les exécuter sur votre cluster, en particulier :

  • Applications sans état
  • Applications avec état
  • Tâches par lots
  • Daemons

Applications sans état

Une application sans état ne conserve pas son état et n'enregistre aucune donnée en stockage persistant : toutes les données d'utilisateur et de session restent auprès du client.

Les interfaces Web telles que Nginx, les serveurs Web tels qu'Apache Tomcat et d'autres applications Web constituent des exemples d'applications sans état.

Vous pouvez créer un déploiement Kubernetes pour déployer une application sans état sur votre cluster. Les pods créés par les déploiements ne sont pas uniques et ne conservent pas leur état, ce qui facilite la mise à l'échelle et la mise à jour des applications sans état.

Applications avec état

Une application avec état nécessite que son état soit enregistré ou persistant. Les applications avec état utilisent un stockage persistant, par exemple des volumes persistants, pour enregistrer des données destinées au serveur ou à d'autres utilisateurs.

Les bases de données telles que MongoDB et les files d'attente de messages du type Apache ZooKeeper constituent des exemples d'applications avec état.

Vous pouvez créer un objet Kubernetes StatefulSet pour déployer une application avec état. Les pods créés par des StatefulSets ont des identifiants uniques et peuvent être mis à jour de manière sécurisée et ordonnée.

Tâches par lots

Les tâches par lots sont des tâches finies, indépendantes et souvent parallèles qui s'exécutent jusqu'à leur achèvement. Parmi les exemples de tâches par lots, on trouve des tâches automatiques ou planifiées telles que l'envoi d'e-mails, l'affichage de vidéos et la réalisation de calculs coûteux.

Vous pouvez créer une tâche Kubernetes pour exécuter et gérer une tâche par lots sur votre cluster. Vous pouvez spécifier le nombre de pods devant terminer leurs tâches avant la fin de la tâche, ainsi que le nombre maximal de pods devant s'exécuter en parallèle.

Daemons

Les daemons effectuent des tâches continues en arrière-plan sur les nœuds qui leur sont attribués sans intervention de l'utilisateur. Les collecteurs de journaux tels que Fluentd et les services de surveillance constituent des exemples de daemons.

Vous pouvez créer un objet Kubernetes DaemonSet pour déployer un daemon sur votre cluster. Les DaemonSets créent un pod par nœud et vous pouvez choisir un nœud spécifique sur lequel le DaemonSet doit se déployer.

DaemonSets sur GKE Autopilot

GKE administre les nœuds dans les clusters que vous créez à l'aide du mode de fonctionnement Autopilot. Vous ne pouvez pas ajouter, supprimer ni modifier manuellement les nœuds ou les machines virtuelles (VM) Compute Engine sous-jacentes. Cependant, l'objet de nœud Kubernetes est toujours visible et Autopilot accepte les DaemonSets en tant que charges de travail.

GKE Autopilot limite certaines fonctions d'administration qui affectent tous les pods de charge de travail, y compris les pods gérés par des DaemonSets. Les DaemonSets qui effectuent des fonctions d'administration sur des nœuds utilisant des privilèges élevés, tels que le contexte de sécurité privileged, ne s'exécuteront pas sur les clusters Autopilot à moins d'être explicitement autorisés par GKE.

Pour en savoir plus sur les limites appliquées par Autopilot, consultez la section Limites et restrictions sur les charges de travail. Vous pouvez utiliser des DaemonSets avec des charges de travail qui respectent les restrictions définies par Autopilot, ainsi que des DaemonSets de certains partenaires Google Cloud.

Bonnes pratiques pour les DaemonSets sur Autopilot

GKE utilise la taille totale de vos charges de travail déployées pour déterminer la taille des nœuds provisionnés par Autopilot pour le cluster. Si vous ajoutez ou redimensionnez un DaemonSet après le provisionnement d'un nœud par Autopilot, GKE ne redimensionne pas les nœuds existants afin de les adapter à la nouvelle taille totale de la charge de travail. Les objets DaemonSet pour lesquels les requêtes de ressources sont supérieures à la capacité pouvant être allouée aux nœuds existants, après prise en compte des pods système, ne sont pas non plus programmés sur ces nœuds.

À partir de la version 1.27.6-gke.1248000 de GKE, les clusters en mode Autopilot détectent les nœuds qui ne peuvent pas accepter tous les objets DaemonSet et, au fil du temps, ils migrent les charges de travail vers des nœuds plus grands, disposant de la capacité nécessaire pour tous les objets DaemonSet. Ce processus prend un certain temps, en particulier si les nœuds exécutent des pods système. Ceux-ci nécessitent un temps supplémentaire pour s'arrêter normalement afin qu'il n'y ait aucune interruption des fonctionnalités de base du cluster.

Avec les versions 1.27.5-gke.200 ou antérieures de GKE, nous vous recommandons de délimiter un périmètre et de drainer les nœuds qui ne peuvent pas accepter de pods DaemonSet.

Pour toutes les versions de GKE, nous vous recommandons de respecter les bonnes pratiques suivantes lorsque vous déployez des objets DaemonSet sur des clusters Autopilot :

  • Déployez des DaemonSets avant toute autre charge de travail.
  • Définissez une PriorityClass plus élevée sur les DaemonSets que les pods standards. Une PriorityClass plus élevée permet à GKE de supprimer les pods de priorité inférieure pour prendre en charge les pods DaemonSet si le nœud peut les accueillir. Cela permet de garantir que l'objet DaemonSet est présent sur chaque nœud sans déclencher la recréation du nœud.

Gérer les objets de charge de travail

Vous pouvez créer, gérer et supprimer des objets à l'aide de méthodes impératives ou déclaratives. Les sections suivantes décrivent ces méthodes, ainsi que les outils que vous pouvez utiliser pour les appeler, qui sont les suivants :

Commandes impératives

Les commandes impératives vous permettent de créer, d'afficher, de mettre à jour et de supprimer rapidement des objets via l'outil kubectl. Elles sont utiles pour des tâches uniques ou pour apporter des modifications aux objets actifs d'un cluster. Les commandes impératives servent généralement à travailler sur des objets actifs et déployés sur votre cluster.

kubectl propose plusieurs commandes basées sur les verbes pour créer et modifier des objets Kubernetes. Exemple :

  • run : créer un objet dans le cluster. Sauf indication contraire, run crée un objet Déploiement. run est également compatible avec plusieurs autres générateurs.
  • expose : créer un objet Service pour équilibrer la charge du trafic sur un ensemble de pods libellés.
  • autoscale : créer un objet Autoscaler pour assurer la mise à l'échelle horizontale automatique d'un objet contrôleur tel qu'un déploiement.

Les commandes impératives ne nécessitent pas de fichiers de configuration, ni une connaissance approfondie du schéma d'objets.

Configuration d'objet impératif

La configuration d'objet impératif crée, met à jour et supprime des objets à l'aide de fichiers de configuration contenant des définitions complètes d'objets. Vous pouvez stocker les fichiers de configuration d'objets dans des systèmes de gestion des versions et vérifier les modifications plus facilement qu'avec des commandes impératives.

Vous pouvez exécuter les opérations kubectl apply, delete et replace avec des fichiers de configuration ou des répertoires contenant des fichiers de configuration.

Configuration d'objet déclaratif

La configuration d'objet déclaratif utilise des fichiers de configuration stockés localement, mais ne nécessite pas de définition explicite des opérations à exécuter. Au lieu de cela, les opérations sont détectées automatiquement pour chaque objet par kubectl. Ceci est utile si vous travaillez avec un répertoire de fichiers de configuration comportant de nombreuses opérations différentes. La gestion d'objets déclaratifs nécessite des fichiers de configuration ainsi qu'une connaissance approfondie des schémas d'objets.

Vous pouvez exécuter kubectl apply pour créer et mettre à jour des objets de manière déclarative. Appliquez des mises à jour sur les objets avec apply en lisant l'intégralité de l'objet actif, en calculant les différences, puis en fusionnant celles-ci avec un envoi de requêtes correctives au serveur d'API.

Images Docker Hub publiques

Lorsque vous déployez une image de conteneur publique depuis Docker Hub, GKE recherche automatiquement une copie en cache de l'image de conteneur dans le proxy de mise en cache mirror.gcr.io. Si une copie en cache n'est pas disponible, GKE extrait l'image demandée de Docker Hub, qui pourra être mise en cache par le proxy pour une utilisation ultérieure. Pour en savoir plus, consultez la page Extraire des images mises en cache.

Console

Une fois que vous avez déployé une charge de travail à l'aide de kubectl ou de l'API, vous pouvez utiliser le menu des charges de travail de la console Google Cloud pour inspecter, gérer et modifier les charges de travail exécutées sur vos clusters.

Le menu propose les fonctionnalités suivantes :

  • Vous pouvez utiliser l'éditeur de texte basé sur YAML pour modifier des objets actifs depuis votre navigateur Web.
  • Vous pouvez afficher des informations détaillées sur chaque objet, y compris l'historique de ses révisions, ses événements et activités récents, ainsi que les pods qu'il gère.
  • Vous pouvez facilement mettre à l'échelle différents objets : déploiements, tâches et objets StatefulSet.
  • Le menu Actions permet de lancer une mise à l'échelle automatique, une mise à jour progressive, ou une mise à jour manuelle des déploiements.
  • Vous pouvez utiliser Cloud Shell pour inspecter, modifier et supprimer tout objet.

API

Vous pouvez utiliser les API REST GKE et l'API Kubernetes conjointement avec les bibliothèques clientes Google Cloud pour créer et gérer des charges de travail par programmation.

Fichiers de configuration

Lorsque vous déployez une charge de travail à l'aide de l'une des méthodes décrites précédemment, GKE ajoute à votre cluster un fichier de configuration représentant l'objet.

La configuration active d'un objet peut différer de son fichier local. Le plus souvent, on utilise YAML pour créer et représenter des objets Kubernetes. Vous pouvez également utiliser JSON.

Pour en savoir plus sur les spécifications d'objets Kubernetes, les états et l'API Kubernetes, consultez la page Présentation des objets Kubernetes et la documentation de référence de l'API Kubernetes.

Inspecter des configurations actives

Console

Pour inspecter la configuration active d'un objet déployé, procédez comme suit :

  1. Accédez à la page Charges de travail dans la console Google Cloud.

    Accéder à la page Charges de travail

  2. Sélectionnez la charge de travail souhaitée.

  3. Cliquez sur YAML.

gcloud

Pour inspecter la configuration active d'un objet déployé, exécutez la commande suivante :

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] peut être de type deployment, statefulset, job ou autre. Exemple :

kubectl get deployment my-stateless-app -o yaml

Gérer l'utilisation des ressources avec des quotas

Lorsque de nombreux utilisateurs ou équipes partagent les ressources de votre cluster, il y a lieu de craindre que certains utilisent plus que leur juste part. Vous pouvez utiliser l'objet Kubernetes ResourceQuota pour limiter la consommation de ressources dans des espaces de noms spécifiques.

GKE applique également un objet gke-resource-quotas immuable par défaut aux espaces de noms sur les clusters de 100 nœuds ou moins, afin d'éviter toute instabilité.

Étape suivante