Explications Exemple

Définition K8S : Le Pod

Publié le :

Explications

C’est l’objet de base dans Kubernetes. La ou d’autres orchestrateurs pilotent l’exécution de conteneurs directement, Kubernetes interagi avec des pods. Son nom court est po

Un pod regroupe un ou plusieurs conteneurs. Dès lors que des conteneurs sont déclarés dans un pod ils héritent des caractéristiques suivantes:

  • Un niveau de réplication identique. Si votre application nécessite plusieurs conteneurs, mais que tous n’exigent pas le même niveau de réplication, vous ne pourrez pas les associer au sein d’un même pod.
  • Une communication directe. Tous conteneurs qui figurent dans un pod discutent directement entre eux, il n’y a pas de filtrage possible.
  • Une IP interne et un espace de port commun. Deux conteneurs dans un pod ne peuvent donc pas exposer le même port.

Ces trois points sont à considérer lorsque vous vous demandez si vous devez associer plusieurs conteneurs au sein d’un pod.

Illustration des pods

Cliquez sur l'image pour l'agrandir.

Généralement, lorsqu’on débute sous K8S le concept de pod peut être assez déroutant, mais il ne faut pas oublier que rien ne vous oblige à mettre plusieurs conteneurs dans un pod. Dans un premier temps et si vous n’avez pas de besoins particuliers vous pouvez très bien adopter une logique un pod égale = un conteneur

Néanmoins, il se pourrait que vous trouviez rapidement un intérêt au pod, notamment quand vous vous apercevez que certains de vos conteneurs sont si étroitement liés, que de les exécuter dans des contextes différents n’a pas d’intérêt. Par exemple un conteneur applicatif et son conteneur de supervision. Si vous savez qu’à chaque conteneur A, son conteneur B lui est indispensable avec une relation de 1 pour 1, alors autant les déclarer dans un même pod.

Ce besoin apparait dans certains patterns applicatifs.

  • side car: cas d’un conteneur qui permet d’apporter un traitement supplémentaire à un conteneur de base sans que celui-ci soit à modifier. Par exemple, un proxy en charge d’appliquer un certificat avant de relayer la requête vers le conteneur principal.

  • ambassador: type de side car particulier. Si votre conteneur principal nécessite l’accès à des services externes et que ces derniers nécessitent d’être interrogés d’une certaine manière, il peut alors être plus pratique d’appliquer un conteneur « ambassador » dans lequel vous pourrez déléguer la complexité d’accès aux services tiers, mais qui les présentera toujours de la même manière à votre conteneur principal.
  • adapter: type de side car, qui cette fois-ci, facilitera l’interrogation du service hébergé par votre conteneur principal par des applications externes. Si par exemple votre conteneur primaire s’interroge d’une manière un peu spécifique, vous pouvez très bien lui ajouter un conteneur « adapter » qui s’occupera de présenter une interface plus standard aux restes de vos applications.
  • Init: un conteneur init est un conteneur qui peut s’exécuter avant le lancement de votre conteneur principal. Si par exemple, vous avez besoin d’exécuter un certain nombre de taches (application de droits, chargement de cache…) avant chaque lancement de votre conteneur principal, mais qui n’est plus nécessaire une fois celui-ci lancé, vous pouvez utiliser un conteneur « init » . À noter que vous pouvez enchainer les conteneurs init avant votre conteneur principal.
    Illustration du principe de <I>side car</I>

    Cliquez sur l'image pour l'agrandir.

    Exemple

    Voici un exemple d'un fichier décrivant un pod:

      
---
apiVersion: v1
kind: Pod
metadata:
  name: exemple-pod
spec:
  containers:
  - name: conteneur-app-a
    image: app-a
  - name: conteneur-app-b
    image: app-b

    Le pod peut prendre bien d’autres options.

    Chaque containeur peut avoir des paramètres complémentaires, qui sont d’ailleurs le plus souvent les mêmes que pour une exécution directe (port, volume, argument, commande…) (Attention, si certains mots clefs semblent identiques à des usages plus basique comme docker-composer, d'autres peuvent être spécifiques à kubernetes ou avoir un impact différent).

    Vous pouvez consulter toutes les caractéristiques d’un POD via sa définition dans l’API K8S.