mardi , 19 juin 2018
Home » Articles » Les objets et autres composants Kubernetes

Les objets et autres composants Kubernetes

Les objets Kubernetes et les charges de travail

Alors que les conteneurs sont le mécanisme sous-jacent utilisé pour déployer des applications, Kubernetes utilise des couches d’abstraction supplémentaires sur l’interface du conteneur pour fournir des fonctionnalités de mise à l’échelle, de résilience et de gestion du cycle de vie. Au lieu de gérer directement les conteneurs, les utilisateurs définissent et interagissent avec des instances composées de diverses primitives fournies par le modèle d’objet Kubernetes. Nous passerons en revue les différents types d’objets pouvant être utilisés pour définir ces charges de travail ci-dessous.

Pods

Un pod est l’unité la plus élémentaire avec laquelle Kubernetes traite. Les conteneurs eux-mêmes ne sont pas affectés aux hôtes. Au lieu de cela, un ou plusieurs conteneurs étroitement couplés sont encapsulés dans un objet appelé un pod.

Un pod représente généralement un ou plusieurs conteneurs qui devraient être contrôlés comme une seule application. Les modules sont constitués de conteneurs qui fonctionnent étroitement ensemble, partagent un cycle de vie et doivent toujours être planifiés sur le même nœud. Ils sont entièrement gérés en tant qu’unité et partagent leur environnement, leurs volumes et leur espace IP. En dépit de leur implémentation conteneurisée, vous devriez généralement considérer les pods comme une application monolithique unique pour mieux conceptualiser la manière dont le cluster gérera les ressources et la planification de pod.

Habituellement, les pods sont constitués d’un conteneur principal qui satisfait l’objectif général de la charge de travail et, éventuellement, de certains conteneurs auxiliaires qui facilitent les tâches étroitement liées. Ce sont des programmes qui bénéficient d’être exécutés et gérés dans leurs propres conteneurs, mais sont étroitement liés à l’application principale. Par exemple, un pod peut avoir un conteneur exécutant le serveur d’applications principal et un conteneur d’assistance qui transfère des fichiers vers le système de fichiers partagé lorsque des modifications sont détectées dans un référentiel externe. La mise à l’échelle horizontale est généralement déconseillée au niveau de pod, car il existe d’autres objets de niveau supérieur plus adaptés à la tâche.

Généralement, les utilisateurs ne doivent pas gérer les pods eux-mêmes, car ils ne fournissent pas certaines des fonctionnalités généralement requises dans les applications (comme la gestion et la mise à l’échelle sophistiquées du cycle de vie). Au lieu de cela, les utilisateurs sont encouragés à utiliser des objets de niveau supérieur qui utilisent des pods ou des modèles de pod en tant que composants de base, mais qui implémentent des fonctionnalités supplémentaires.

Les contrôleurs de réplication et les ensembles de réplication

Souvent, lorsque vous travaillez avec Kubernetes, plutôt que de travailler avec des pods individuels, vous gérez plutôt des groupes de pods identiques et répliqués. Ils sont créés à partir de modèles de pod et peuvent être mis à l’échelle horizontalement par des contrôleurs connus sous le nom de contrôleurs de réplication et d’ensembles de réplication.

Un contrôleur de réplication est un objet qui définit un modèle de pod et des paramètres de contrôle pour mettre à l’échelle horizontalement les répliques identiques d’un pod en augmentant ou en diminuant le nombre de copies en cours d’exécution. C’est un moyen facile de distribuer la charge et d’augmenter la disponibilité de manière native au sein de Kubernetes. Le contrôleur de réplication sait comment créer de nouveaux pods si nécessaire, car un gabarit ressemblant étroitement à une définition de pod est intégré dans la configuration du contrôleur de réplication.

Le contrôleur de réplication est chargé de s’assurer que le nombre de pods déployés dans le cluster correspond au nombre de pods dans sa configuration. Si un pod ou un hôte sous-jacent tombe en panne, le contrôleur démarrera de nouveaux pods pour compenser. Si le nombre de réplicas dans la configuration d’un contrôleur change, le contrôleur démarre ou élimine les conteneurs pour qu’ils correspondent au nombre souhaité. Les contrôleurs de réplication peuvent également effectuer des mises à jour tournantes pour faire passer un ensemble de pods vers une nouvelle version une par une, en minimisant l’impact sur la disponibilité des applications.

Les ensembles de réplication sont une itération sur la conception du contrôleur de réplication avec une plus grande flexibilité dans la façon dont le contrôleur identifie les pods qu’il est censé gérer. Les ensembles de réplication commencent à remplacer les contrôleurs de réplication en raison de leurs capacités de sélection de réplique supérieures, mais ils ne sont pas en mesure de faire des mises à jour tournantes pour exécuter des backends vers une nouvelle version comme les contrôleurs de réplication. Au lieu de cela, les ensembles de réplication sont destinés à être utilisés à l’intérieur d’unités supplémentaires de niveau supérieur qui fournissent cette fonctionnalité.

Comme les pods, les contrôleurs de réplication et les ensembles de réplication sont rarement les unités avec lesquelles vous travaillerez directement. Bien qu’ils s’appuient sur la conception de pod pour ajouter des garanties de mise à l’échelle horizontale et de fiabilité, ils ne disposent pas des capacités de gestion du cycle de vie à grain fin que l’on trouve dans des objets plus complexes.

À lire aussi

Les pièges courants de l’intégration des microservices – comment les éviter ?

Comment surmonter les défis de la communication à distance, de l’asynchronicité et des transactions dans …