Ressources de base de kubernetes: Les Pods et les commandes de debug

Ressources de Base: pod

• Pod : unité de base de déploiement, contenant un ou plusieurs conteneurs.
• Labels et Annotations : méthodes de marquage pour l’organisation, la sélection, et l’ajout de métadonnées aux objets.
• Creation de pod multi container 2 pods
• Creation de pod multi container 3 pods

 

---

Le Pod:

Un pod est l'unité de base dans Kubernetes. C'est la plus petite unité déployable qui peut contenir un ou plusieurs containers.

Certaines ressources partagées pour ces conteneurs.:

• • Stockage partagé, en tant que Volumes
  • Mise en réseau, en tant qu'adresse IP d'un unique cluster
  • Informations sur l'exécution de chaque conteneur, telles que la version de l'image du conteneur ou les ports spécifiques à utiliser

 

• Les labels sont des paires clé-valeur qui sont attachées aux objets Kubernetes pour les catégoriser et les organiser.

• Les annotations sont des métadonnées supplémentaires attachées à un objet Kubernetes pour fournir des informations supplémentaires.

Exemple avec le nginx:

• • Exemples de pods Kubernetes avec des labels et des annotations en mode imperatif:

# créer un pod nginx en mode imperatif
kubectl run nginx-pod-imp --image=nginx:latest --labels=app=web,env=production

# ces deux commandes permettent de rediriger la sortie dans un fichier.
kubectl run redis-pod --image=redis:latest --labels=app=database,tier=backend --dry-run=client -o yaml > redis-pod.yaml
kubectl run nginx-pod --image=nginx:latest --labels=app=web,env=production --dry-run=client -o yaml > nginx-pod.yaml

• • Le meme pode nginx en mode declaratif: Copier le continu dans le ficher nginx-pod-decla.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-decla
  labels:
    app: web
    env: production
spec:
  containers:
  - name: nginx-container
    image: nginx:latest

 

# executer le fichier nginx-pod-decla.yaml

kubectl apply -f nginx-pod-decla.yaml

 

 

Pour acceder à notre nginx-pod-imp pour faire des debug, on peut faire un port forward:

kubectl port-forward nginx-pod-imp 8088:80

 

Acceder à : http://127.0.0.1:8088 

 

Parcourt de la commande kubectl:

Quand on execute kubectl apply -f nginx-prod-decla.yaml, Kubernetes suit plusieurs étapes pour créer le pod ou la resoruce demandé. Voici le déroulement de la communication entre les composants Kubernetes, de l'application de la déclaration jusqu'à la création du pod :

1. kubectl :

   • L'outil kubectl transmet la ressource définie dans le fichier YAML (nginx-prod-decla.yaml) à l'API Server.
   • kubectl envoie une requête HTTP à l'API Server (via REST) pour créer ou mettre à jour la ressource dans etcd.

2. API Server :

   • L'API Server reçoit la requête et vérifie que la ressource YAML est valide.
   • Elle authentifie et autorise la requête (en fonction des contrôles RBAC configurés) avant de la traiter.
   • Une fois validée, l'API Server enregistre la configuration de la ressource dans la base de données etcd.

3. etcd :

   • etcd est la base de données distribuée dans Kubernetes où toutes les configurations et l'état des ressources sont stockés.
   • Quand l'API Server enregistre la nouvelle ressource (ici le Pod), etcd conserve cette information. C'est ici que la "source de vérité" de l'état du cluster est maintenue.

4. Scheduler :

   • Le Scheduler (planificateur) est continuellement à l'écoute des ressources non assignées dans etcd.
   • Quand il détecte que le Pod doit être créé mais n'a pas encore été associé à un nœud, il analyse les critères de planification (ressources disponibles, affinités, tolérances, etc.).
   • Le Scheduler choisit alors le nœud le plus approprié pour exécuter le Pod et met à jour etcd pour l'assigner au nœud sélectionné.

5. Kubelet (sur le nœud sélectionné) :

   • Le kubelet du nœud choisi par le Scheduler interroge périodiquement l’API Server pour vérifier les nouvelles ressources qui lui sont assignées.
   • Il détecte le nouveau Pod et se charge de le créer.
   • Kubelet interagit avec le runtime de conteneur (Docker, containerd, etc.) pour télécharger les images nécessaires et lancer le conteneur du Pod.

6. Pod en cours d'exécution :

   • Une fois le Pod créé et le conteneur en cours d'exécution, Kubelet surveille son état et maintient la communication avec l’API Server pour informer de tout changement d'état.
   • Si le Pod tombe en panne, Kubelet peut, selon la stratégie de redémarrage, essayer de redémarrer le conteneur pour respecter l'état désiré défini dans le manifeste YAML.

Ainsi, la communication entre les composants Kubernetes – du kubectl au kubelet – s'assure que la ressource demandée passe par plusieurs validations et processus avant que le Pod ne soit effectivement créé et rendu disponible dans le cluster.

 

Exemple avec le pod prometheus node-exporter:

• • Pod simple avec des labels et des annotations mode imperative

kubectl run monitoring-pod --image=prometheus/node-exporter:latest --labels=app=monitoring --annotations=prometheus.io/scrape=true,prometheus.io/port=8080,team=ops
kubectl run monitoring-pod --image=prometheus/node-exporter:latest --labels=app=monitoring --annotations=prometheus.io/scrape=true,prometheus.io/port=8080,team=ops --dry-run=client -o yaml > monitoring-pod.yaml

L'utilisation de fichiers de configuration YAML est une pratique courante pour décrire les ressources Kubernetes. Voici un exemple de fichier YAML pour déployer un pod simple :

apiVersion: v1
kind: Pod
metadata:
  annotations:
    prometheus.io/scrape: true
    prometheus.io/port: 8080
    team: ops
  labels:
    app: monitoring
  name: monitoring-pod
spec:
  containers:
  - image: prometheus/node-exporter:latest
    name: monitoring-pod

Dans cet exemple, le pod "monitoring-pod" est étiqueté avec "app: monitoring". Il comporte également deux annotations spécifiques à Prometheus ("prometheus.io/scrape" et "prometheus.io/port") qui indiquent que ce pod doit être scrappé par le serveur Prometheus pour collecter des métriques. L'annotation "team" fournit des informations supplémentaires sur l'équipe responsable du pod.

 

Exemple avec le Pod redis:

apiVersion: v1
kind: Pod
metadata:
  name: redis-pod
  labels:
    app: database
    tier: backend
  annotations:
    description: "This pod runs a Redis database."
spec:
  containers:
  - name: redis-container
    image: redis:latest

Dans cet exemple, le pod "redis-pod" a les labels "app: database" et "tier: backend". Ces labels peuvent être utilisés pour sélectionner des pods spécifiques à l'aide de sélecteurs lors de la création de services ou de déploiements.

 

Exemple de Pod avec 2 ou 3 containers:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: busybox-container
    image: busybox:latest
    command: ['sh', '-c', 'while true; do echo "Hello from BusyBox"; sleep 3600; done']

Dans cet exemple, nous avons un pod nommé "multi-container-pod" avec deux containers. Le premier container est basé sur l'image NGINX et expose le port 80. Le deuxième container est basé sur l'image BusyBox et exécute une commande qui imprime "Hello from BusyBox" toutes les heures.

 

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod-3
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: busybox-container
    image: busybox:latest
    command: ['sh', '-c', 'while true; do echo "Hello from BusyBox"; sleep 3600; done']
  - name: alpine-container
    image: alpine:latest
    command: ['sh', '-c', 'while true; do echo "Hello from Alpine"; sleep 3600; done']

Dans cet exemple, nous avons un pod nommé "multi-container-pod-3" avec trois containers. Le premier container est basé sur l'image NGINX, le deuxième sur l'image BusyBox, et le troisième sur l'image Alpine. Chacun des containers exécute une commande qui imprime un message toutes les heures.

Ces exemples illustrent comment vous pouvez définir plusieurs containers au sein d'un même pod. Chaque container dans le pod peut avoir des responsabilités différentes et partager des ressources et de l'espace de stockage, ce qui est utile pour divers scénarios d'application et de microservices.

Ces exemples illustrent comment vous pouvez utiliser des labels pour organiser et catégoriser vos pods, ainsi que comment utiliser des annotations pour fournir des informations supplémentaires sur vos pods, telles que des descriptions, des configurations spécifiques ou des métriques à collecter.

Commandes de debug:

kubectl get pod/pod_name
kubectl describe pod/pod_name
kubectl logs pod/pod_name

# si le pod contient plusieurs containers
kubectl exec -it pod_name -c my-container -- /bin/bash

# si le pod contient un seul container
kubectl exec -it pod_name -- /bin/bash

 

Pour supprimer le pod:

kubectl delete pod nginx-pod-imp
kubectl delete -f nginx-pod.yaml