ZikossWiki

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Kubernetes - Workloads/Controllers ======

La méthode la plus pratique pour déployer des objets dans Kubernetes comme des pods par exemples est d'utiliser un fichier de manifeste YAML. C'est dans ce fichier que l'on indique toutes les instructions à traiter par Kubernetes.

Une fois le fichier manifeste créé, il suffit à chaque fois de lancer la commande : 

  kubectl apply -f <mon_fichier.yml>

===== 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.

=== Déploiement d'un premier pod avec un conteneur ===

Créer un fichier manifeste yaml :
  vim create-pod.yml

Insérer le contenu suivant :

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
      - containerPort: 80

Explication : 
  * **apiVersion**: indique la verions de l'API Kubernetes. Requis dans chaque fichier YAML.
  * **kind**: indique le type d'objet à déployer. Ici nous déployons des objets de type pod.
  * **metadata**: Informations complémentaire concernant notre déploiement.
  * **spec**: Permet de spécifier les caractéristiques de notre déploiement et notamment les conteneurs à déployer.
      * **containers**: On défini le nom, l'image et les ports pour notre conteneur.
          * **name**: Nom du conteneur
          * **image**: Image à utiliser pour créer le conteneur
          * **ports**: Ports d'écoute à prévoir pour le conteneur.

Nous allons déployer le pod  :
  kubectl apply -f create-pod.yml

Résultat attendu: 
  pod/nginx created

Nous allons lister les pods ainsi : 
  kubectl get pods

Résultat attendu :
  NAME    READY   STATUS    RESTARTS   AGE
  nginx   1/1     Running   0          6m4s

Pour obtenir des informations sur notre pod lancé :
  kubectl describe pods nginx

Pour supprimer le pod :
  kubectl delete pods nginx

=== 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) :

  apiVersion: v1
  kind: Pod
  metadata:
    name: mydebs
  spec:
    containers:
    - name: mydeb-web
      image: debian:latest
      command: ["sleep"]
      args: ["infinity"]
      ports:
      - containerPort: 80
    - name: mydeb-bdd
      image: debian:latest
      command: ["sleep"]
      args: ["infinity"]
      ports:
      - containerPort: 3306

Explications complémentaires :
  * **command**: C'est la commande a exécuter au lancement du conteneur
  * **args**: Ce sont les arguments de la commande.

Dans le cas présent, les conteneurs seront exécuté avec la commande ''sleep infinity''. C'est pour maintenir le conteneur en fonctionnement.

===== 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.

==== Mise en pratique ====

Ci-dessous un exemple de manifeste Yaml pour lancer un ReplicaSet composé de 2 Debian avec 2 réplicas : 

  apiVersion: apps/v1
  kind: ReplicaSet
  metadata:
    name: mydeploy01
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: web-bdd-app
    template:
      metadata:
        labels:
          app: web-bdd-app
      spec:
        containers:
        - name: mydeb-web
          image: debian:latest
          command: ["sleep"]
          args: ["infinity"]
          ports:
          - containerPort: 80
        - name: mydeb-bdd
          image: debian:latest
          command: ["sleep"]
          args: ["infinity"]
          ports:
          - containerPort: 3306

Quelques explications : 
  * **apiVersion**: Attention il faut utiliser une autre version API différente de celle utilisé pour le déploiement de pods.
  * **metadata.name**: Requis pour donner un nom au déploiement.
  * **spec.replicas**: Indiquer le nombre de réplicas à lancer.
  * **selector.matchLabels.app**: Obligatoire pour sélectionner le template de pod.
  * **template.metadata.labels.app**: Défini le nom du template. Il doit correspondre à **selector.matchLabels.app**
  * **spec.template.spec**: On défini les spécificités de nos pods. Notamment en indiquant les conteneurs à créer dans chacun des réplicas de pods.

Au final, nous aurons déployé 2 pods identique contenant chacun 2 conteneurs. 

Pour supprimer un ReplicaSet et donc arrêter les Pods et ses conteneurs :
  kubectl delete replicaset mydeploy01

===== Le Deployment =====

==== 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.
  
  * **Restauration** : les déploiements reviennent automatiquement à une version précédente d'une application en cas d'échec d'une mise à jour. Pour les ReplicaSets, ce processus doit être effectué manuellement.
    
  * **Contrôle de version** : Semblable à la fonctionnalité précédente, les déploiements implémentent le contrôle de version, permettant ainsi la possibilité de revenir à une version spécifique précédente.

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 : 

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: mydeploy01
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: web-bdd-app
    template:
      metadata:
        labels:
          app: web-bdd-app
      spec:
        containers:
        - name: mydeb-web
          image: debian:latest
          command: ["sleep"]
          args: ["infinity"]
          ports:
          - containerPort: 80
        - name: mydeb-bdd
          image: debian:latest
          command: ["sleep"]
          args: ["infinity"]
          ports:
          - containerPort: 3306

On retrouve dans ce fichier YAML exactement les mêmes définitions que pour un **ReplicaSet**.

Pour supprimer un déploiement et donc arrêter les Pods et ses conteneurs :
  kubectl delete deployment mydeploy01


===== 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 =====
ZikossWiki

Outils pour utilisateurs

Outils du site

Outils de la page
