Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Charges de travail Kubernetes et pods

Vous pouvez créer n’importe quelle application conteneurisée complexe dans Kubernetes en utilisant deux éléments de base : les pods et les charges de travail. Une fois que vous avez créé une application, vous pouvez l’exposer pour y accéder, que ce soit au sein du même cluster ou sur Internet, en utilisant un troisième élément : les services.

Pods

Les pods sont un ou plusieurs conteneurs qui partagent des espaces de noms réseau et des volumes de stockage. La plupart des pods n’ont qu’un seul conteneur. Par conséquent, lorsque nous discutons des pods, le terme est souvent synonyme de conteneurs. Vous mettez à l’échelle les pods de la même manière que vous mettez à l’échelle les conteneurs—​en ayant plusieurs instances du même pod qui implémente un service. En général, les pods sont mis à l’échelle et gérés par les charges de travail.

Workloads

Les charges de travail sont des objets qui définissent les règles de déploiement pour les pods. Sur la base de ces règles, Kubernetes effectue le déploiement et met à jour les charges de travail avec l’état actuel de l’application. Les charges de travail vous permettent de définir les règles pour la planification, la mise à l’échelle et la mise à niveau des applications.

Types de charges de travail

Kubernetes divise les charges de travail en différents types. Les types les plus populaires pris en charge par Kubernetes sont :

  • Déploiements

    Les déploiements sont mieux utilisés pour les applications sans état (c’est-à-dire lorsque vous n’avez pas à maintenir l’état de la charge de travail). Les pods gérés par des charges de travail de type déploiement sont considérés comme indépendants et jetables. Si un pod rencontre une perturbation, Kubernetes le supprime puis le recrée. Un exemple d’application serait un serveur web Nginx.

  • StatefulSets

    StatefulSets, contrairement aux déploiements, sont mieux utilisés lorsque votre application doit maintenir son identité et stocker des données. Par exemple, une application telle que Zookeeper-- nécessite une base de données pour le stockage.

  • DaemonSets

    DaemonSets garantit que chaque nœud du cluster exécute une copie d’un pod. Pour les cas d’utilisation où vous collectez des journaux ou surveillez les performances des nœuds, cette charge de travail de type daemon fonctionne le mieux.

  • Jobs

    Jobs lancent un ou plusieurs pods et garantissent qu’un nombre spécifié d’entre eux se terminent avec succès. Les jobs sont mieux utilisés pour exécuter une tâche finie jusqu’à son achèvement plutôt que de gérer un état d’application souhaité en cours.

  • CronJobs

    CronJobs sont similaires aux jobs. Les CronJobs, cependant, s’exécutent jusqu’à leur achèvement selon un calendrier basé sur cron.

Services

Dans de nombreux cas d’utilisation, une charge de travail doit être soit :

  • Accédée par d’autres charges de travail dans le cluster.

  • Exposée au monde extérieur.

Vous pouvez atteindre ces objectifs en créant un Service. Les services sont mappés aux pods de la charge de travail sous-jacente en utilisant une approche de sélecteur/étiquette (voir les exemples de code). L’interface utilisateur de Rancher simplifie ce processus de mappage en créant automatiquement un service avec la charge de travail, en utilisant le port et le type de service que vous sélectionnez.

Types de service

Il existe plusieurs types de services disponibles dans Rancher. Les descriptions ci-dessous proviennent de la Documentation Kubernetes.

  • ClusterIP

    Expose le service sur une adresse IP interne au cluster. Choisir cette valeur rend le service uniquement accessible depuis l’intérieur du cluster. Il s’agit de la valeur par défaut ServiceType.

  • NodePort

    Expose le service sur l’adresse IP de chaque nœud à un port statique (le NodePort). Un service ClusterIP, vers lequel le service NodePort va router, est automatiquement créé. Vous pourrez contacter le service NodePort depuis l’extérieur du cluster en demandant <NodeIP>:<NodePort>.

  • LoadBalancer

    Expose le service à l’extérieur en utilisant l’équilibreur de charge d’un fournisseur de cloud. Les services NodePort et ClusterIP, vers lesquels l’équilibreur de charge externe va router, sont automatiquement créés.

Options de charge de travail

Cette section de la documentation contient des instructions pour déployer des charges de travail et utiliser les options de charge de travail.

Liens connexes