Passer au contenu principal

Fondamentaux (Kubernetes)

Pods et cycle de vie

Le pod est l'unité atomique de Kubernetes. Ce n'est pas un conteneur — c'est un groupe de conteneurs qui partagent le même réseau et les mêmes volumes, co-schedulés sur le même noeud. Un pod mono-conteneur est le cas le plus courant. Un pod multi-conteneurs répond à des patterns précis : sidecar, init container, ambassador.

Anatomie d'un pod

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: default
  labels:
    app: web
    version: "1.0"
spec:
  containers:
  - name: nginx
    image: nginx:1.27-alpine
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"
    env:
    - name: ENV
      value: production
  restartPolicy: Always  # Always (default) | OnFailure | Never
kubectl apply -f pod.yaml
kubectl get pods -o wide          # noeud assigné, IP
kubectl describe pod web          # events, conditions, ressources
kubectl logs web -f               # logs temps réel
kubectl exec -it web -- bash      # shell interactif

Cycle de vie

Un pod passe par plusieurs phases :

  • Pending : créé, en attente de scheduling ou de pull d'image
  • Running : au moins un conteneur en cours d'exécution
  • Succeeded : tous les conteneurs terminés avec code 0 (Jobs)
  • Failed : au moins un conteneur terminé avec code non-zéro
  • Unknown : état indéterminable (noeud unreachable)

Les conditions (PodScheduled, ContainersReady, Initialized, Ready) donnent plus de granularité. Un pod en Running peut ne pas être Ready si ses health checks échouent.

Init containers

Les init containers s'exécutent séquentiellement avant le démarrage des conteneurs principaux. Usages typiques : attendre qu'une dépendance soit disponible, préparer le filesystem, migrer une base de données.

spec:
  initContainers:
  - name: wait-db
    image: busybox:1.36
    command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
  - name: app
    image: myapp:1.0

Sidecar containers (v1.29+)

En Kubernetes 1.29+, les sidecars sont un type de conteneur de première classe (restartPolicy: Always dans les init containers). Ils démarrent avant les conteneurs principaux et restent actifs pendant toute la durée de vie du pod. Pattern courant : agent de logs, proxy Envoy, agent de métriques.

spec:
  initContainers:
  - name: log-agent          # Sidecar v1.29+
    image: fluent-bit:3.2
    restartPolicy: Always    # Le distingue d'un vrai init container
  containers:
  - name: app
    image: myapp:1.0

Ce qu'on ne fait pas avec les pods

On ne crée pas de pods "nus" en production. Un pod nus mort n'est pas recréé. On utilise systématiquement des Deployments, StatefulSets, DaemonSets ou Jobs selon le cas. Les pods nus servent uniquement au debugging ponctuel.

Sources