Lors du déploiement d’une application Kubernetes, plusieurs ressources sont nécessaires pour assurer son bon fonctionnement, sa disponibilité, sa sécurité, et sa gestion. La distinction entre Deployment et StatefulSet joue également un rôle important selon la nature de l’application.
Différence entre Deployment et StatefulSet
| Deployment | StatefulSet |
|---|---|
| Utilisé pour les applications stateless (sans état). | Utilisé pour les applications stateful (avec état), nécessitant des identifiants persistants. |
| Ne garantit pas l’ordre de démarrage ou de suppression des pods. | Les pods sont démarrés et supprimés dans un ordre précis. |
| Les pods sont interchangeables, identifiés uniquement par un label commun. | Chaque pod possède un nom unique et stable (ex. : pod-0, pod-1). |
| Utilisé pour les API, services web, workers sans stockage local persistant. | Utilisé pour les bases de données, caches, ou applications avec stockage persistant. |
Liste des ressources associées à un Deployment ou StatefulSet
Ressources de base
Ce sont les ressources indispensables pour qu’un déploiement fonctionne.
- Pod
- Le composant de base exécutant un ou plusieurs conteneurs.
- Géré dynamiquement par le Deployment ou le StatefulSet.
- ReplicaSet (associé à un Deployment)
- Maintient le nombre spécifié de répliques du pod.
- Il est automatiquement créé par le Deployment et mis à jour lors de changements.
- PersistentVolumeClaim (PVC) (relié au StatefulSet ou à certains Deployments)
- Utilisé pour demander de l’espace de stockage persistant.
- Le StatefulSet peut associer chaque pod à un volume dédié.
- Service
- Expose l’application et permet aux autres ressources de communiquer avec les pods via un DNS interne.
- Plusieurs types de services :
- ClusterIP (communication interne).
- NodePort (exposition directe sur les nœuds).
- LoadBalancer (utilisé avec des fournisseurs cloud).
Ressources réseau et sécurité
Ces ressources protègent et organisent la communication entre les composants.
- Ingress
- Définit des règles pour exposer des services via HTTP/HTTPS.
- Utilisé pour le routage basé sur les URL.
- NetworkPolicy
- Contrôle le trafic réseau entre pods.
- Permet de définir des règles de communication (par exemple, interdire tout trafic entrant sauf celui d’un service spécifique).
- ConfigMap
- Contient des configurations non sensibles (fichiers de configuration, variables d’environnement).
- Injecté dans les pods sous forme de fichiers ou de variables.
- Secret
- Contient des données sensibles (mots de passe, clés API, certificats).
- Peut être monté comme volume ou injecté dans des variables d’environnement.
Ressources liées au monitoring et à l’observabilité
Ces ressources permettent de superviser les performances et la santé de l’application.
- HorizontalPodAutoscaler (HPA)
- Ajuste automatiquement le nombre de réplicas en fonction de la charge (CPU, mémoire ou métriques personnalisées).
- PodDisruptionBudget (PDB)
- Définit le nombre minimal de pods qui doivent rester disponibles lors d’opérations de maintenance (ex. : mise à jour, redémarrage de nœuds).
- LivenessProbe et ReadinessProbe
- Vérifient l’état des pods.
- LivenessProbe : Redémarre le pod si l’application est en panne.
- ReadinessProbe : Indique si le pod est prêt à recevoir du trafic.
- ServiceMonitor (Prometheus)
- Utilisé pour intégrer des métriques de pods dans un système de monitoring (Prometheus, Grafana).
Ressources liées à la gestion et la politique
Ces ressources définissent des règles de gestion ou de sécurité au niveau du cluster.
- Role / RoleBinding ou ClusterRole / ClusterRoleBinding
- Contrôle les permissions au sein du namespace ou du cluster.
- ResourceQuota
- Limite la consommation de ressources (CPU, mémoire, stockage) dans un namespace.
- LimitRange
- Définit des limites par défaut pour les ressources (CPU, mémoire) utilisées par les pods et conteneurs.
Autres ressources complémentaires
Ces ressources sont souvent utilisées pour les besoins spécifiques de certaines applications.
- Job et CronJob
- Utilisés pour exécuter des tâches ponctuelles (Job) ou récurrentes (CronJob).
- DaemonSet
- Déploie un pod sur chaque nœud du cluster.
- Utilisé pour des services tels que des agents de monitoring ou de logs.
- Volume
- Peut être utilisé pour monter des fichiers locaux ou distants (ex. : NFS, AWS EBS, Ceph).
Comparaison des scénarios typiques
- Application web stateless (API, site web) :
- Utilise un Deployment.
- Configuration minimale : pods, services, ingress, autoscaling.
- Application avec stockage persistant (base de données, cache) :
- Utilise un StatefulSet.
- Configuration avec PVCs, services stables, probes et monitoring renforcé.
Synthèse
Le déploiement d'une application Kubernetes ne se limite pas au pod lui-même. Il est entouré d'un écosystème de ressources garantissant la sécurité, la résilience, la scalabilité et la gestion de la configuration. Le choix entre un Deployment et un StatefulSet dépend principalement de la nature de l'application (stateless ou stateful).