6.3. Création d’un manifeste Kubernetes pour OpenShift Dedicated

Alors que l’image du conteneur est l’unité de base avec docker, les unités de base avec lesquelles Kubernetes fonctionne sont appelées pods. Les pods représentent la prochaine étape dans la création d’une application. La gousse peut contenir un ou plusieurs contenants. La clé est que le pod est 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 à considérer lors de la détermination de ce qui se passe dans un pod. Afin de faciliter votre déploiement, vous voudrez peut-être déployer un conteneur dans un pod et inclure son propre conteneur d’enregistrement et de surveillance dans le pod. Ensuite, lorsque vous exécutez la pod et que vous devez mettre à l’échelle une instance supplémentaire, ces autres conteneurs sont mis à l’échelle avec elle. Dans le cas des espaces de noms, les conteneurs d’un pod partagent les mêmes interfaces réseau, volumes de stockage partagés et limitations de ressources, tels que la mémoire et le CPU, ce qui facilite la gestion du contenu du pod en tant qu’unité unique. Les conteneurs dans un pod peuvent également communiquer les uns avec les autres en utilisant des communications inter-processus standard, telles que les sémaphores du système V ou la mémoire partagée POSIX.

Alors que les gousses individuelles représentent une unité évolutive dans Kubernetes, un service fournit un moyen de regrouper un ensemble de gousses pour créer une application complète et stable qui peut accomplir des tâches telles que l’équilibrage de charge. Le service est également plus permanent qu’un pod car le service reste disponible à partir de la même adresse IP jusqu’à ce que vous le supprimiez. Lorsque le service est utilisé, il est demandé par nom et le cluster OpenShift Dedicated résout ce nom dans les adresses IP et les ports où vous pouvez atteindre les pods qui composent le service.

De par leur nature, les applications conteneurisées sont séparées des systèmes d’exploitation où elles s’exécutent et, par extension, de leurs utilisateurs. Dans une partie de votre manifeste Kubernetes décrit comment exposer l’application à des réseaux internes et externes en définissant des politiques réseau qui permettent un contrôle fin sur la communication avec vos applications conteneurisées. Afin de connecter les requêtes entrantes pour HTTP, HTTPS et d’autres services de l’extérieur de votre cluster à des services à l’intérieur de votre cluster, vous pouvez utiliser une ressource Ingress.

Lorsque votre conteneur nécessite un stockage sur disque au lieu d’un stockage de base de données, qui peut être fourni via un service, vous pouvez ajouter des volumes à vos manifestes pour que ce stockage soit disponible à vos pods. Configurez 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 les objets Déploiement et DéploiementConfig.

Ensuite, considérez comment votre type d’application influence comment l’exécuter.

Kubernetes définit différents types de charges de travail qui conviennent à différents types d’applications. Afin de déterminer la charge de travail appropriée pour votre demande, considérez si la demande est:

L’application que vous écrivez peut avoir besoin de composants de support, comme une base de données ou un composant de journalisation. Afin de 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édiée OpenShift:

Les opérateurs et les modèles supportés peuvent être configurés selon les besoins spécifiques de votre équipe de développement, puis les rendre disponibles dans les espaces de noms dans lesquels vos développeurs travaillent. Beaucoup de gens ajoutent des modèles partagés à l’espace de noms openshift car il est accessible depuis tous les autres espaces de noms.

Les manifestes de Kubernetes vous permettent de créer une image plus complète des composants qui composent vos applications Kubernetes. Ecrire ces manifestes sous forme de fichiers YAML et les déployer en les appliquant au cluster, par exemple en exécutant la commande oc application.

À 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 le développement de vos conteneurs aux dépôts Git que vous utilisez pour stocker le logiciel nécessaire à la construction de vos applications.

Le flux de travail à ce stade pourrait ressembler à: