7.3. Créer un manifeste Kubernetes pour OpenShift Container Platform
Bien que l'image de conteneur soit l'élément de base d'une application conteneurisée, davantage d'informations sont nécessaires pour gérer et déployer cette application dans un environnement Kubernetes tel qu'OpenShift Container Platform. Après la création d'une image, les étapes suivantes sont généralement les suivantes :
- Comprendre les différentes ressources avec lesquelles vous travaillez dans les manifestes Kubernetes
- Prenez des décisions concernant le type d'application que vous utilisez
- Rassembler les éléments de soutien
- Créez un manifeste et stockez-le dans un dépôt Git afin de pouvoir le stocker dans un système de versionnement des sources, l'auditer, le suivre, le promouvoir et le déployer dans l'environnement suivant, revenir à des versions antérieures, si nécessaire, et le partager avec d'autres
7.3.1. À propos des pods et des services Kubernetes
Alors que l'image du conteneur est l'unité de base de Docker, les unités de base avec lesquelles Kubernetes travaille sont appelées pods. Les pods représentent l'étape suivante dans la construction d'une application. Un pod peut contenir un ou plusieurs conteneurs. L'essentiel est que le pod soit l'unité unique que vous déployez, mettez à l'échelle et gérez.
L'évolutivité et les espaces de noms sont probablement les principaux éléments à prendre en compte pour déterminer ce qu'il faut mettre dans un pod. Pour faciliter le déploiement, vous pouvez vouloir déployer un conteneur dans un pod et y inclure son propre conteneur de journalisation et de surveillance. Plus tard, lorsque vous ferez fonctionner le pod et que vous aurez besoin de mettre à l'échelle une instance supplémentaire, ces autres conteneurs seront mis à l'échelle en même temps que lui. Pour les espaces de noms, les conteneurs d'un module partagent les mêmes interfaces réseau, les mêmes volumes de stockage partagés et les mêmes limites de ressources, telles que la mémoire et l'unité centrale, ce qui facilite la gestion du contenu du module en tant qu'unité unique. Les conteneurs d'un pod peuvent également communiquer entre eux en utilisant des communications inter-processus standard, telles que les sémaphores System V ou la mémoire partagée POSIX.
Alors que les pods individuels représentent une unité évolutive dans Kubernetes, un service permet de regrouper un ensemble de pods pour créer une application complète et stable capable d'effectuer des tâches telles que l'équilibrage de charge. Un service est également plus permanent qu'un pod, car il reste disponible à partir de la même adresse IP jusqu'à ce que vous le supprimiez. Lorsque le service est utilisé, il est demandé par son nom et le cluster OpenShift Container Platform résout ce nom en adresses IP et ports permettant d'atteindre les pods qui composent le service.
Par nature, les applications conteneurisées sont séparées des systèmes d'exploitation sur lesquels elles s'exécutent et, par extension, de leurs utilisateurs. Une partie de votre manifeste Kubernetes décrit comment exposer l'application aux réseaux internes et externes en définissant des stratégies réseau qui permettent un contrôle fin de la communication avec vos applications conteneurisées. Pour connecter des requêtes entrantes pour HTTP, HTTPS et d'autres services provenant de l'extérieur de votre cluster à des services à l'intérieur de votre cluster, vous pouvez utiliser une ressource Ingress ressource.
Si votre conteneur nécessite un stockage sur disque au lieu d'un stockage de base de données, qui peut être fourni par un service, vous pouvez ajouter des volumes à vos manifestes pour mettre ce stockage à la disposition de vos pods. Vous pouvez configurer les manifestes pour créer des volumes persistants (PV) ou créer dynamiquement des volumes qui sont ajoutés à vos définitions Pod.
Après avoir défini un groupe de pods qui composent votre application, vous pouvez définir ces pods dans Deployment et DeploymentConfig objets.
7.3.2. Types d'applications
Ensuite, réfléchissez à la manière dont votre type d'application influe sur la façon de l'exécuter.
Kubernetes définit différents types de charges de travail qui conviennent à différents types d'applications. Pour déterminer la charge de travail appropriée à votre application, déterminez si l'application est.. :
-
Il est destiné à être exécuté jusqu'à son terme et à être terminé. Par exemple, une application qui démarre pour produire un rapport et qui se termine lorsque le rapport est terminé. Il se peut que l'application ne s'exécute plus pendant un mois. Les objets OpenShift Container Platform adaptés à ce type d'applications sont les suivants
JobetCronJobobjets. - Ces applications sont censées fonctionner en continu. Pour les applications à longue durée d'exécution, vous pouvez écrire un déploiement.
-
Nécessaire pour être hautement disponible. Si votre application nécessite une haute disponibilité, vous devez dimensionner votre déploiement de manière à avoir plus d'une instance. Un objet
DeploymentouDeploymentConfigpeut intégrer un ensemble de répliques pour ce type d'application. Avec les ensembles de répliques, les pods s'exécutent sur plusieurs nœuds pour s'assurer que l'application est toujours disponible, même si un travailleur tombe en panne. - Nécessité de s'exécuter sur chaque nœud. Certains types d'applications Kubernetes sont destinés à s'exécuter dans le cluster lui-même sur chaque nœud maître ou travailleur. Les applications DNS et de surveillance sont des exemples d'applications qui doivent s'exécuter en continu sur chaque nœud. Vous pouvez exécuter ce type d'application en tant qu'ensemble de démons. Vous pouvez également exécuter un ensemble de démons sur un sous-ensemble de nœuds, en fonction des étiquettes de nœuds.
- Exiger une gestion du cycle de vie. Lorsque vous souhaitez céder votre application à d'autres personnes, envisagez de créer un opérateur. Les opérateurs vous permettent d'intégrer de l'intelligence, de sorte qu'ils peuvent gérer automatiquement des éléments tels que les sauvegardes et les mises à niveau. Associés au gestionnaire de cycle de vie des opérateurs (OLM), les gestionnaires de grappes peuvent exposer les opérateurs à des espaces de noms sélectionnés afin que les utilisateurs de la grappe puissent les exécuter.
-
Avoir des exigences en matière d'identité ou de numérotation. Une application peut avoir des exigences en matière d'identité ou de numérotation. Par exemple, il peut vous être demandé d'exécuter exactement trois instances de l'application et de les nommer
0,1et2. Un ensemble avec état convient à cette application. Les ensembles avec état sont particulièrement utiles pour les applications qui nécessitent un stockage indépendant, telles que les bases de données et les clusters zookeeper.
7.3.3. Composants de soutien disponibles
L'application que vous écrivez peut avoir besoin de composants de support, comme une base de données ou un composant de journalisation. Pour répondre à ce besoin, vous pourriez être en mesure d'obtenir le composant requis à partir des catalogues suivants qui sont disponibles dans la console web d'OpenShift Container Platform :
- OperatorHub, qui est disponible dans chaque cluster OpenShift Container Platform 4.12. L'OperatorHub met à la disposition de l'opérateur de cluster des opérateurs de Red Hat, des partenaires certifiés de Red Hat et des membres de la communauté. L'opérateur de cluster peut rendre ces opérateurs disponibles dans tous les espaces de noms du cluster ou dans certains d'entre eux, afin que les développeurs puissent les lancer et les configurer avec leurs applications.
-
Les modèles, qui sont utiles pour un type d'application unique, où le cycle de vie d'un composant n'est pas important après son installation. Un modèle fournit un moyen facile de commencer à développer une application Kubernetes avec un minimum de frais généraux. Un modèle peut être une liste de définitions de ressources, qui peuvent être
Deployment,Service,Route, ou d'autres objets. Si vous souhaitez modifier les noms ou les ressources, vous pouvez définir ces valeurs en tant que paramètres dans le modèle.
Vous pouvez configurer les opérateurs et les modèles de support en fonction des besoins spécifiques de votre équipe de développement, puis les rendre disponibles dans les espaces de noms dans lesquels vos développeurs travaillent. De nombreuses personnes ajoutent des modèles partagés à l'espace de noms openshift car il est accessible depuis tous les autres espaces de noms.
7.3.4. Application du manifeste
Les manifestes Kubernetes vous permettent de créer une image plus complète des composants qui constituent vos applications Kubernetes. Vous écrivez ces manifestes sous forme de fichiers YAML et vous les déployez en les appliquant au cluster, par exemple en exécutant la commande oc apply.
7.3.5. Prochaines étapes
À ce stade, envisagez des moyens d'automatiser votre processus de développement de conteneurs. Idéalement, vous avez une sorte de pipeline CI qui construit les images et les pousse vers un registre. En particulier, un pipeline GitOps intègre votre développement de conteneurs avec les dépôts Git que vous utilisez pour stocker les logiciels nécessaires à la création de vos applications.
Le flux de travail jusqu'à ce point peut ressembler à ce qui suit :
-
Jour 1 : Vous écrivez du YAML. Vous exécutez ensuite la commande
oc applypour appliquer ce YAML au cluster et tester son fonctionnement. - Jour 2 : Vous mettez votre fichier de configuration de conteneur YAML dans votre propre dépôt Git. À partir de là, les personnes qui souhaitent installer cette application ou vous aider à l'améliorer peuvent extraire le fichier YAML et l'appliquer à leur cluster pour faire fonctionner l'application.
- Jour 3 : Envisagez de rédiger un opérateur pour votre candidature.
