Présentation des modèles Kubernetes

Un modèle décrit une solution reproductible à un problème. Les modèles Kubernetes sont des modèles de conception pour les applications et services basés sur des conteneurs.  

Avec Kubernetes, les développeurs peuvent créer des applications cloud-native à l'aide d'une bibliothèque d'interfaces de programmation d'application (API) ainsi que d'outils de création d'applications. 

Kubernetes ne fournit cependant pas aux développeurs et aux architectes les directives pour utiliser ces éléments afin de créer un système complet qui répond aux besoins et objectifs métier. 

Les modèles sont une manière de réutiliser les architectures. Au lieu de créer vous-même l'architecture de bout en bout, vous pouvez utiliser des modèles Kubernetes existants et ainsi vous assurer que tous les éléments fonctionneront comme prévu. 

Lorsque vous devez fournir des services métier importants avec Kubernetes, vous n'avez pas le temps d'apprendre en faisant des essais et des erreurs. Vous vous exposeriez à de trop nombreux temps d'arrêt et perturbations. 

Il faut voir les modèles comme des schémas : ils vous indiquent une façon de résoudre toute une catégorie de problèmes similaires. Un modèle n'est pas qu'une simple liste d'instructions détaillées qui permettent de résoudre un problème spécifique.

L'utilisation d'un modèle peut donner des résultats très différents, car il n'est pas conçu pour fournir une solution toujours identique. Votre système est peut-être différent de celui d'une autre personne qui aura utilisé le même modèle. Cependant, les deux systèmes partageront des caractéristiques communes. 

Avec les modèles Kubernetes, les développeurs peuvent créer des applications cloud-native en utilisant Kubernetes en tant que plateforme d'exécution.

Les modèles sont les outils dont les développeurs Kubernetes ont besoin. Ils leur indiquent comment créer un système.

• Les modèles de base englobent les concepts fondamentaux de Kubernetes. Ils représentent les principes et les pratiques sous-jacents à appliquer pour créer des applications cloud-native basées sur des conteneurs. 
• Les modèles comportementaux se placent au-dessus des modèles de base et détaillent davantage les concepts pour permettre la gestion de nombreux types d'interactions entre les conteneurs et les plateformes. 
• Les modèles structurels permettent d'organiser les conteneurs au sein d'un pod Kubernetes. 
• Les modèles de configuration sont utilisés pour gérer les nombreuses manières de configurer une application dans Kubernetes. Ils comprennent les étapes nécessaires pour connecter les applications à leur configuration. 
• Les modèles avancés concernent les concepts avancés, tels que la manière d'étendre la plateforme ou de créer les images de conteneurs directement dans le cluster.

Modèles prédictifs de demandes

Les modèles prédictifs de demandes sont des modèles Kubernetes de base. Cette catégorie de modèle assure la conformité des applications avec les principes de base des applications conteneurisées, afin de préparer leur automatisation à l'aide de Kubernetes. 

Les modèles prédictifs de demandes permettent d'expliquer pourquoi chaque conteneur doit déclarer les exigences en matière de ressources d'application et leurs dépendances en matière d'environnement d'exécution. La définition de ces exigences permet à Kubernetes de choisir l'emplacement adapté pour déployer une application dans un cluster. 

Ces modèles permettent, par exemple, de définir les dépendances d'environnement d'exécution, les profils de ressources, la priorité des pods et les ressources de projet.

Exemple : profils de ressources

Vous devez spécifier les exigences d'un conteneur en matière de ressources, telles que le processeur et la mémoire, sous la forme d'une demande et d'une limite. La demande fait référence à la quantité minimale de ressources requises, tandis que la limite définit la quantité maximale de ressources qu'un conteneur peut consommer. 

La quantité de demandes est utilisée par le planificateur lors du placement des pods sur les nœuds. Le planificateur place uniquement un pod sur un nœud qui dispose de suffisamment de capacité pour l'héberger.  

Lorsqu'aucune exigence de ressources n'est définie, le planificateur attribue une priorité basse au conteneur qui sera alors supprimé en premier si le nœud arrive à court de ressources.

Modèles de configuration

Toutes les applications requièrent une configuration, et bien qu'il soit facile de stocker des configurations dans le code source, cette option ne permet pas d'adapter la configuration sans recréer son image. Avec une configuration externe, il est possible d'adapter l'application en fonction de l'environnement.

Les modèles de configuration permettent de personnaliser et d'adapter les applications à l'aide de configurations externes pour différents environnements de développement, d'intégration et de production. 

Exemple : configuration EnVar

Le modèle de configuration EnVar est particulièrement adapté aux petits ensembles de variables de configuration, où il est possible d'utiliser des variables environnementales universellement prises en charge pour externaliser la configuration. 

En externalisant la configuration d'une application, vous pouvez la modifier même une fois l'application créée, alors que si vous intégrez la configuration au code, vous devez ensuite recréer l'application.

Les variables environnementales fonctionnent bien pour externaliser la configuration, puisque tout système d'exploitation peut les définir et que tout langage de programmation permet d'y accéder. 

Avec les variables environnementales, les valeurs intégrées par défaut au code sont généralement définies pendant la création, puis remplacées pendant l'exécution.

Dans Kubernetes, il est possible de définir des variables directement dans la spécification des pods d'un contrôleur tel que Deployment ou ReplicaSet. Vous pouvez attribuer des valeurs directement aux variables environnementales, qui peuvent être gérées séparément de la définition des pods.

Vous pouvez également utiliser les secrets Kubernetes (pour les données sensibles) et ConfigMaps (pour les configurations non sensibles).

Modèles avancés

Ces modèles comprennent des domaines complexes et les dernières mises en œuvre de modèles. Dans cette catégorie, on retrouve les modèles de contrôleur, d'opérateur, de mise à l'échelle élastique et de créateur d'image.

Exemple : mise à l'échelle élastique

Le modèle de mise à l'échelle élastique permet de mettre à l'échelle une application de manière horizontale, en adaptant le nombre de réplicas de pods, et de manière verticale, en adaptant les exigences de ressources des pods. Il permet également de mettre à l'échelle le cluster lui-même en modifiant le nombre de nœuds de cluster.

Bien qu'il soit possible de gérer la mise à l'échelle manuellement, le modèle de mise à l'échelle élastique permet à Kubernetes de mettre à l'échelle automatiquement l'application en fonction de la charge. 

Avec Kubernetes, vous pouvez modifier les ressources d'un conteneur, le nombre de réplicas pour un service ou le nombre de nœuds dans le cluster. Kubernetes peut également surveiller la charge externe et les événements liés à la capacité, analyser l'état des conteneurs et mettre à l'échelle l'application pour obtenir les performances souhaitées. 

La mise à l'échelle automatique et horizontale du pod permet de définir une capacité d'application qui n'est pas fixe, mais qui est suffisante pour gérer une charge variable. Les pods sont redimensionnés à l'aide d'une fonction de mise à l'échelle automatique horizontale. 

Afin d'utiliser cette fonction, il faut activer le serveur d'indicateurs de mesure et un agrégateur de données d'utilisation des ressources au niveau du cluster, ainsi que définir des limites de ressources pour le processeur. Vous pouvez créer une définition pour cette fonction à partir de la ligne de commande. 

Le contrôleur de la fonction de mise à l'échelle automatique horizontale recueille en continu des données sur les pods, liées à la mise à l'échelle et basées sur la définition que vous aurez déterminée à partir de la ligne de commande. 

Le contrôleur calcule également le nombre requis de réplicas, en fonction de la valeur actuelle et de la valeur souhaitée. Il modifie ensuite les réplicas déclarés pour conserver le nouvel état souhaité.

Red Hat® OpenShift® est une plateforme Kubernetes conçue pour les entreprises. Elle offre aux développeurs des environnements en libre-service pour la création des applications, ainsi que des fonctions pour automatiser l'exploitation de l'ensemble de la pile sur tout type d'infrastructure.

Red Hat OpenShift inclut de nombreuses technologies supplémentaires qui font de Kubernetes un outil puissant et viable pour les entreprises, notamment : les registres, la mise en réseau, la télémétrie, la sécurité, l'automatisation et les services.

Avec Red Hat OpenShift, les développeurs peuvent créer des applications conteneurisées, les héberger et les déployer dans le cloud tout en bénéficiant d'une évolutivité, d'un contrôle et d'une orchestration d'une efficacité telle que vos idées pourront vite devenir réalité.