Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
informatique:kebernetes:kube_pod_deployment [2023/12/11 12:47] benoit [Lancement d'un StatefulSet] |
informatique:kebernetes:kube_pod_deployment [2023/12/11 13:34] (Version actuelle) benoit [Le DaemonSet] |
||
---|---|---|---|
Ligne 8: | Ligne 8: | ||
===== Les pods ===== | ===== Les pods ===== | ||
+ | |||
+ | ==== Définition ==== | ||
+ | |||
+ | C'est l'unité de fonctionnement la plus petite sous Kubernetes pour faire fonctionner les conteneurs. Un pod peut être constitué d'un ou plusieurs conteneur qui partagent la même IP. | ||
+ | |||
+ | ==== Mise en pratique ==== | ||
Nous allons ici juste déployer de simples pods. Pour rappel des pods sont des lots de conteneurs. | Nous allons ici juste déployer de simples pods. Pour rappel des pods sont des lots de conteneurs. | ||
- | ==== Déploiement d'un premier pod avec un conteneur ==== | + | === Déploiement d'un premier pod avec un conteneur === |
Créer un fichier manifeste yaml : | Créer un fichier manifeste yaml : | ||
Ligne 58: | Ligne 64: | ||
kubectl delete pods nginx | kubectl delete pods nginx | ||
- | ==== Déploiement d'un pod avec 2 conteneurs ==== | + | === Déploiement d'un pod avec 2 conteneurs === |
Ci-dessous l'exemple de fichier yaml pour déployer un pod avec 2 Debian (un avec le port 80 exposé et l'autre avec le port 3306) : | Ci-dessous l'exemple de fichier yaml pour déployer un pod avec 2 Debian (un avec le port 80 exposé et l'autre avec le port 3306) : | ||
Ligne 87: | Ligne 93: | ||
Dans le cas présent, les conteneurs seront exécuté avec la commande ''sleep infinity''. C'est pour maintenir le conteneur en fonctionnement. | Dans le cas présent, les conteneurs seront exécuté avec la commande ''sleep infinity''. C'est pour maintenir le conteneur en fonctionnement. | ||
- | ===== Les ReplicaSet ===== | + | ===== Le ReplicaSet ===== |
- | **Définition** : Un ReplicaSet aide à gérer le trafic en faisant évoluer votre application pour avoir plusieurs instances du même pod. Cela permet de réduire le trafic vers une instance particulière et contribue également à équilibrer la charge du trafic entre chacune de ces instances. | + | ==== Définition ==== |
+ | |||
+ | Un ReplicaSet aide à gérer le trafic en faisant évoluer votre application pour avoir plusieurs instances du même pod. Cela permet de réduire le trafic vers une instance particulière et contribue également à équilibrer la charge du trafic entre chacune de ces instances. | ||
+ | |||
+ | ==== Mise en pratique ==== | ||
Ci-dessous un exemple de manifeste Yaml pour lancer un ReplicaSet composé de 2 Debian avec 2 réplicas : | Ci-dessous un exemple de manifeste Yaml pour lancer un ReplicaSet composé de 2 Debian avec 2 réplicas : | ||
Ligne 136: | Ligne 146: | ||
===== Le Deployment ===== | ===== Le Deployment ===== | ||
- | **Definition** : Il offre la même possibilité de mise à l'échelle qu'un ReplicaSet, mais en complément il permet les possibilités suivantes : | + | ==== Definition ==== |
+ | |||
+ | Le contrôleur **Deployment** offre la même possibilité de mise à l'échelle qu'un **ReplicaSet**, mais en complément offre les possibilités suivantes : | ||
* **Mises à jour progressives** : les mises à jour progressives garantissent qu'une application est mise à jour progressivement, une réplique à la fois, tout en garantissant que la disponibilité globale de l'application n'est pas affectée. En comparaison, les ReplicaSets prennent uniquement en charge la mise à l'échelle et la gestion des réplicas. | * **Mises à jour progressives** : les mises à jour progressives garantissent qu'une application est mise à jour progressivement, une réplique à la fois, tout en garantissant que la disponibilité globale de l'application n'est pas affectée. En comparaison, les ReplicaSets prennent uniquement en charge la mise à l'échelle et la gestion des réplicas. | ||
Ligne 145: | Ligne 157: | ||
Du fait que le **Deployment** proposent plus le possibilité en terme de gestion, il est plus utilisé. Le **ReplicaSet** n'est à utiliser que si l'on souhaite un contrôle manuelle de la mise à jour de l'application. **ReplicaSet** sera utilisé préproduction, alors que **Deployment** sera utilisé pour la production. | Du fait que le **Deployment** proposent plus le possibilité en terme de gestion, il est plus utilisé. Le **ReplicaSet** n'est à utiliser que si l'on souhaite un contrôle manuelle de la mise à jour de l'application. **ReplicaSet** sera utilisé préproduction, alors que **Deployment** sera utilisé pour la production. | ||
+ | |||
+ | ==== Mise en pratique ==== | ||
Ci-dessous un exemple de manifeste Yaml pour lancer un **Deployment** composé de 2 Debian avec 2 réplicas : | Ci-dessous un exemple de manifeste Yaml pour lancer un **Deployment** composé de 2 Debian avec 2 réplicas : | ||
Ligne 182: | Ligne 196: | ||
- | ===== Les StatefulSet ===== | + | ===== Le StatefulSet ===== |
+ | |||
+ | ==== Définition ==== | ||
+ | |||
+ | StatefulSet est le contrôleur qui gère le déploiement et la mise à l'échelle d'un ensemble de pods Stateful. Un pod Stateful dans Kubernetes est un pod qui nécessite un stockage persistant et une identité réseau stable pour conserver son état à tout moment, même pendant les redémarrages ou la replanification du pod. Ces pods sont couramment utilisés pour les applications telles que les bases de données ou les systèmes de fichiers distribués, car ceux-ci nécessitent une identité stable et un stockage persistant pour maintenir la cohérence des données. | ||
+ | |||
+ | Un StatefulSet aide à gérer ces pods en offrant certaines caractéristiques uniques clés: | ||
+ | |||
+ | * **Identité unique**: StatefulSets attribue à chaque pod un index unique, qui fournit une identité cohérente et unique même si les Pods sont supprimées ou recréées. Ceci est important pour les applications publiques qui s'appuient sur une identité stable pour maintenir l'état d'application ou communiquer avec d'autres nœuds du cluster. | ||
+ | |||
+ | * **Configuration réseau persistante**: StatefulSets fournit à chaque pod une identité de réseau persistante sous la forme d'un nom d'hôte stable basé sur son index ordinal. Ce nom d'hôte est utilisé pour la résolution DNS au sein du cluster, ce qui permet aux autres services de découvrir et de communiquer facilement avec les autres Pods dans le StatefulSet, même s'ils sont supprimés ou recréés. | ||
+ | |||
+ | * **Stockage persistant** : StatefulSets fourni un stockage persistant aux Pods par l'intermédiaire de Kubernetes PersistentVolumes, qui peuvent être approvisionnés de manière dynamique et attachés aux Pods selon les besoins. Cela permet aux applications de stocker leurs données de manière fiable à travers les redémarrages et le rééchelonnement de la pod. Ce qui est important pour les applications qui ont besoin de maintenir des données en l'état, telles que des bases de données ou des systèmes de fichiers distribués. | ||
+ | |||
+ | ===== Le DaemonSet ===== | ||
+ | |||
+ | ===== Les Jobs et les CronJobs ===== |