Guide

Créer une ConfigMap ou un Secret générique à partir de paires clé-valeur en ligne de commande.

→Utilisez `kubectl create configmap <name> --from-literal=<key>=<value>` ou `kubectl create secret generic <name> --from-literal=<key>=<value>`.

Pourquoi: `--from-literal` est pour l'entrée directe de paires clé-valeur. Utilisez le drapeau plusieurs fois pour plusieurs clés. C'est plus rapide que de créer un fichier YAML pour les cas simples.

Référence↗

Injecter toutes les paires clé-valeur d'une ConfigMap ou d'un Secret en tant que variables d'environnement dans un conteneur.

→Dans la spécification du conteneur, utilisez `envFrom` avec `configMapRef` ou `secretRef`. Exemple : `envFrom: [{configMapRef: {name: my-config}}]`.

Pourquoi: `envFrom` est une opération en bloc qui mappe toutes les clés de la source aux variables d'environnement. Cela évite de lister manuellement chaque clé.

Référence↗

Injecter une valeur unique et spécifique d'une ConfigMap ou d'un Secret en tant que variable d'environnement.

→Utilisez `env.valueFrom`. Exemple : `env: [{name: LOG_LEVEL, valueFrom: {configMapKeyRef: {name: my-config, key: log_level}}}]`.

Pourquoi: `valueFrom` fournit une injection sélective et permet de mapper la clé source à un nom de variable d'environnement différent.

Monter une ConfigMap ou un Secret sous forme de fichiers dans un Pod, permettant des mises à jour en direct.

→Définissez un `volume` de type `configMap` ou `secret`. Montez-le dans le conteneur en utilisant `volumeMounts`. Les fichiers seront nommés d'après les clés.

Pourquoi: Les fichiers montés à partir de ConfigMaps/Secrets sont mis à jour automatiquement lorsque la source change. Les variables d'environnement ne le sont pas, nécessitant un redémarrage du Pod.

Référence↗

Appliquer les meilleures pratiques de sécurité : empêcher l'exécution en tant que root, rendre le système de fichiers root en lecture seule, ou spécifier un ID utilisateur.

→Utilisez `securityContext` au niveau du Pod ou du conteneur. Définissez `runAsNonRoot: true`, `readOnlyRootFilesystem: true` et/ou `runAsUser: <UID>`.

Pourquoi: SecurityContext offre un contrôle déclaratif et granulaire sur les privilèges des conteneurs, essentiel pour renforcer les applications et respecter les politiques de sécurité.

Référence↗

Accorder à un Pod des permissions minimales pour accéder à l'API Kubernetes.

→1. Créez un `ServiceAccount` personnalisé. 2. Créez un `Role` avec uniquement les permissions API nécessaires (par exemple, lister les pods). 3. Créez un `RoleBinding` pour lier le ServiceAccount et le Role. 4. Assignez le ServiceAccount au Pod via `spec.serviceAccountName`.

Pourquoi: Suit le principe du moindre privilège, minimisant la surface d'attaque si un Pod est compromis.

Empêcher le montage automatique d'un jeton ServiceAccount dans un Pod qui n'a pas besoin d'accès API.

→Définissez `automountServiceAccountToken: false` dans la spécification du Pod ou sur le ServiceAccount lui-même.

Pourquoi: Réduit la surface d'attaque en ne fournissant pas de identifiants API aux conteneurs qui n'en ont pas besoin.

Créer un Secret pour l'utilisation dans la terminaison TLS pour un Ingress ou un autre service sécurisé.

→Utilisez `kubectl create secret tls <secret-name> --cert=<path/to/cert.pem> --key=<path/to/key.pem>`.

Pourquoi: Ceci crée un Secret du type correct `kubernetes.io/tls` avec les clés de données standard `tls.crt` et `tls.key` attendues par les contrôleurs Ingress.

Exposer les métadonnées de Pod (comme le nom, l'espace de noms, les étiquettes ou l'IP du nœud) à un conteneur.

→Utilisez l'API Downward pour projeter les métadonnées en tant que variables d'environnement ou fichiers dans un volume `downwardAPI`. Exemple : `valueFrom: {fieldRef: {fieldPath: metadata.name}}`.

Pourquoi: Permet aux conteneurs d'être auto-conscients sans avoir besoin d'interroger l'API Kubernetes, simplifiant la configuration et réduisant les exigences RBAC.

Référence↗

Définir les requêtes et limites par défaut de CPU/mémoire pour tous les Pods dans un espace de noms.

→Créez un objet `LimitRange` dans l'espace de noms. Définissez les valeurs `default` et `defaultRequest` pour les ressources.

Pourquoi: Garantit que tous les Pods ont des contraintes de ressources, améliorant l'ordonnancement et la stabilité, même si les développeurs oublient de les spécifier. Fonctionne de concert avec ResourceQuota.

Limiter la quantité totale de ressources (CPU, mémoire, nombre d'objets) pouvant être consommées dans un espace de noms.

→Créez un objet `ResourceQuota`. Définissez des limites strictes dans `spec.hard`, par exemple, `requests.cpu: "4"`, `pods: "10"`.

Pourquoi: Empêche un espace de noms ou une équipe de consommer toutes les ressources du cluster, garantissant une allocation équitable des ressources.

Exécuter des tâches prérequises (par exemple, attendre une base de données, exécuter des migrations, récupérer des données) avant le démarrage de l'application principale.

→Définissez un ou plusieurs `initContainers` dans la spécification du Pod. Ils s'exécutent séquentiellement jusqu'à leur achèvement avant le démarrage des conteneurs de l'application principale.

Pourquoi: Découple la logique de configuration du conteneur d'application et garantit que les dépendances sont satisfaites avant le lancement de l'application.

Référence↗

Étendre un conteneur d'application principal avec des fonctionnalités d'aide comme la journalisation, la surveillance ou le proxying.

→Ajoutez un second conteneur (le sidecar) à la spécification du Pod. Les deux conteneurs partagent des ressources comme le réseau et les volumes.

Pourquoi: Améliore les fonctionnalités sans modifier le code de l'application principale, favorisant la séparation des préoccupations.

Partager un répertoire pour la lecture/écriture entre des conteneurs dans le même Pod.

→Définissez un volume `emptyDir` dans la spécification du Pod et montez-le dans tous les conteneurs requis.

Pourquoi: `emptyDir` fournit un volume de stockage simple et éphémère qui existe pendant la durée de vie du Pod, parfait pour le partage de données intra-Pod.

Remplacer l'ENTRYPOINT et/ou le CMD par défaut d'une image de conteneur.

→Dans la spécification du conteneur, utilisez `command` pour remplacer ENTRYPOINT et `args` pour remplacer CMD. `command: ["/bin/sh"], args: ["-c", "echo hello"]`.

Pourquoi: Offre un contrôle total sur la commande de démarrage du conteneur depuis la définition du Pod, utile pour adapter des images génériques.

Exécuter une tâche finie jusqu'à son achèvement, en contrôlant le parallélisme et le nombre d'achèvements réussis.

→Utilisez une ressource `Job`. Définissez `spec.completions` pour le nombre de succès ciblés et `spec.parallelism` pour le nombre de Pods concurrents. Utilisez `spec.backoffLimit` pour contrôler les tentatives.

Pourquoi: Les Jobs sont conçus pour les tâches à exécution unique, contrairement aux Deployments de longue durée. Ces paramètres sont essentiels pour gérer les charges de travail par lots.

Planifier une tâche récurrente en utilisant la syntaxe cron et contrôler la gestion des tâches qui se chevauchent.

→Utilisez une ressource `CronJob`. Définissez la `spec.schedule` au format cron (par exemple, `*/5 * * * *`). Définissez `spec.concurrencyPolicy` à `Allow`, `Forbid` ou `Replace`.

Pourquoi: Automatise les tâches planifiées. `concurrencyPolicy` est essentielle pour empêcher les exécutions qui se chevauchent (`Forbid`) ou pour remplacer les anciennes (`Replace`).

Générer rapidement un manifeste YAML pour une ressource sans la créer dans le cluster.

→Utilisez les drapeaux `--dry-run=client -o yaml` avec des commandes impératives. Exemple : `kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml`.

Pourquoi: Gagne du temps en échafaudant un manifeste valide qui peut être personnalisé puis appliqué de manière déclarative.

Mettre à jour, redimensionner, vérifier le statut, afficher l'historique et annuler un Deployment de manière impérative.

→Utilisez `kubectl set image`, `kubectl scale`, `kubectl rollout status`, `kubectl rollout history` et `kubectl rollout undo`.

Pourquoi: Ce sont les commandes impératives essentielles pour gérer le cycle de vie d'une application déployée pendant le développement et le dépannage.

Contrôler la vitesse et la sécurité d'une mise à jour de Deployment pour garantir la disponibilité.

→Dans `spec.strategy.rollingUpdate`, configurez `maxSurge` (combien de Pods supplémentaires peuvent être créés) et `maxUnavailable` (combien peuvent être indisponibles).

Pourquoi: L'équilibrage de `maxSurge` et `maxUnavailable` est essentiel pour gérer la capacité par rapport à l'utilisation des ressources pendant les mises à jour. Pour un temps d'arrêt nul, `maxUnavailable` doit être inférieur à `replicas`.

Assurer qu'aucune version d'une application ne s'exécute simultanément en terminant tous les anciens Pods avant d'en créer de nouveaux.

→Définissez `spec.strategy.type: Recreate` dans le Deployment.

Pourquoi: Garantit que les anciennes et nouvelles versions ne coexistent pas, ce qui est nécessaire pour les applications qui ne peuvent pas gérer deux versions différentes accédant aux mêmes données. Cette stratégie entraîne des temps d'arrêt.

Apporter plusieurs modifications à un Deployment en direct sans déclencher de déploiement intermédiaire pour chaque modification.

→Utilisez `kubectl rollout pause deployment/<name>`, appliquez les modifications, puis `kubectl rollout resume deployment/<name>`.

Pourquoi: Consolide plusieurs mises à jour en un seul événement de déploiement, évitant le brassage et les conditions de concurrence.

Limiter le nombre d'anciens ReplicaSets conservés pour un Deployment afin d'économiser le stockage etcd.

→Définissez `spec.revisionHistoryLimit` au nombre souhaité de révisions à conserver (par exemple, 3). La valeur par défaut est 10.

Pourquoi: Définir une limite inférieure réduit l'encombrement d'etcd. La définir à `0` désactive entièrement la capacité de restauration.

Documenter la raison d'une mise à jour de Deployment afin qu'elle apparaisse dans l'historique des révisions.

→Ajoutez une annotation `kubernetes.io/change-cause` au manifeste du Deployment. Exemple : `kubectl annotate deployment/nginx kubernetes.io/change-cause="update to 1.20"`.

Pourquoi: Fournit un contexte précieux lors de la visualisation de l'historique de déploiement (`kubectl rollout history`), facilitant l'identification de la révision à restaurer.

Déployer une nouvelle version d'application en parallèle de l'ancienne et basculer le trafic instantanément sans interruption de service.

→Utilisez deux Deployments (par exemple, `app-blue`, `app-green`) avec des étiquettes de version différentes. Un seul Service sélectionne la version active via son `selector`. Pour basculer, utilisez `kubectl patch service` pour mettre à jour le sélecteur vers la nouvelle étiquette de version.

Pourquoi: Offre des livraisons instantanées et à faible risque ainsi qu'une capacité de restauration immédiate en patchant simplement le sélecteur du Service.

acheminer un petit pourcentage de trafic vers une nouvelle version d'application pour des tests en production.

→Utilisez deux Deployments (stable, canary) partageant la même étiquette de sélecteur. Un Service cible les deux. Contrôlez le pourcentage de trafic par le ratio de réplicas (par exemple, 9 réplicas stables, 1 canary pour 10% du trafic).

Pourquoi: Un moyen simple d'effectuer des déploiements canary sans service mesh, permettant des tests contrôlés et à faible risque de nouvelles fonctionnalités. La distribution du trafic est approximative.

Exposer un ensemble de Pods pour une communication uniquement depuis l'intérieur du cluster.

→Utilisez un Service avec `type: ClusterIP`. C'est le type par défaut.

Pourquoi: `ClusterIP` fournit une adresse IP interne stable et un nom DNS pour un service, masquant les IPs de Pods individuels.

Exposer un service sur un port statique sur l'adresse IP de chaque nœud.

→Utilisez un Service avec `type: NodePort`. K8s alloue un port à partir d'une plage (par défaut : 30000-32767).

Pourquoi: Utile pour le développement ou lorsqu'un équilibreur de charge externe n'est pas disponible. Le trafic vers `<NodeIP>:<NodePort>` est transféré au Service.

Acheminer le trafic HTTP/S externe vers des services internes en fonction du nom d'hôte ou du chemin d'URL.

→Créez une ressource `Ingress`. Définissez des `rules` pour les hôtes et des `http.paths` pour mapper aux services backend. Configurez TLS avec `spec.tls` pointant vers un Secret TLS.

Pourquoi: Ingress fournit un routage L7, consolidant plusieurs services sous une seule IP externe et déchargeant la terminaison TLS.

Restreindre le trafic réseau vers et depuis les Pods en fonction des étiquettes, des espaces de noms ou des blocs IP.

→Créez une `NetworkPolicy` ciblant les Pods avec `podSelector`. Définissez des règles `ingress` et/ou `egress` pour autoriser un trafic spécifique. Par défaut, l'application d'une politique à un pod refuse tout trafic non explicitement autorisé.

Pourquoi: Les NetworkPolicies sont fondamentales pour la segmentation du réseau et l'implémentation d'un modèle de sécurité "zero-trust" dans Kubernetes.

Référence↗

Bloquer tout le trafic entrant et sortant pour tous les pods d'un espace de noms par défaut.

→Créez une NetworkPolicy avec un `podSelector: {}` vide et des règles d'entrée/sortie vides. Exemple : `podSelector: {}, policyTypes: [Ingress, Egress]`.

Pourquoi: Établit une base de sécurité où tout le trafic est refusé, sauf s'il est explicitement autorisé par d'autres NetworkPolicies plus spécifiques.

Fournir une entrée DNS stable qui résout directement vers toutes les IP de Pod, sans IP virtuelle pour l'équilibrage de charge.

→Créez un Service avec `spec.clusterIP: None`.

Pourquoi: Essentiel pour les applications avec état (comme les StatefulSets) ou les systèmes peer-to-peer qui ont besoin de découvrir et de communiquer directement avec des Pods spécifiques.

Assurer que les Pods backend voient l'IP client d'origine pour le trafic provenant d'un Service NodePort ou LoadBalancer.

→Définissez `spec.externalTrafficPolicy: Local` sur le Service.

Pourquoi: La politique par défaut (`Cluster`) obscurcit l'adresse IP source via la traduction d'adresses réseau. `Local` la préserve mais peut entraîner une distribution de trafic inégale si les Pods ne sont pas sur tous les nœuds.

Assurer que toutes les requêtes d'un client spécifique sont envoyées au même Pod.

→Sur le Service, définissez `spec.sessionAffinity: ClientIP`.

Pourquoi: Fournit des 'sessions persistantes', ce qui est nécessaire pour les applications héritées qui stockent l'état de session en mémoire sur un Pod spécifique.

Un Pod dans un espace de noms doit communiquer avec un Service dans un autre espace de noms.

→Utilisez le nom DNS étendu : `<service-name>.<namespace-name>.svc.cluster.local` ou la forme courte `<service-name>.<namespace-name>`.

Pourquoi: Les noms de service simples ne se résolvent que dans le même espace de noms. La communication inter-espaces de noms nécessite de spécifier l'espace de noms cible dans la requête DNS.

Définir des vérifications de santé pour gérer le cycle de vie du Pod : redémarrer en cas d'échec ou retirer du service.

→`livenessProbe` : Redémarre le conteneur si la sonde échoue. `readinessProbe` : Retire le Pod des points de terminaison du Service si la sonde échoue. `startupProbe` : Désactive les autres sondes jusqu'à ce que le conteneur termine son démarrage.

Pourquoi: Des sondes correctement configurées sont essentielles pour l'auto-réparation des applications et pour réaliser des déploiements sans interruption de service.

Référence↗

Diagnostiquer pourquoi un Pod est bloqué dans un état non-Running (par exemple, Pending, ContainerCreating, CrashLoopBackOff).

→Utilisez `kubectl describe pod <pod-name>`. La section `Events` fournit des indices cruciaux du scheduler (problèmes de ressources), du kubelet (erreurs de tirage d'image) ou du runtime du conteneur.

Pourquoi: `describe` est la commande la plus importante pour comprendre les problèmes de cycle de vie des Pods qui surviennent avant que l'application ne démarre ou n'enregistre quoi que ce soit.

Inspecter les journaux d'un conteneur qui a planté et est maintenant dans une boucle de redémarrage (CrashLoopBackOff).

→Utilisez `kubectl logs <pod-name> --previous`.

Pourquoi: Le drapeau `--previous` affiche les journaux de la dernière instance terminée du conteneur, qui contient l'erreur ayant provoqué le crash.

Afficher et suivre les journaux de tous les Pods correspondant à un sélecteur d'étiquettes en temps réel.

→Utilisez `kubectl logs -l <label-selector> -f`. Ajoutez `--prefix` pour voir de quel pod provient chaque ligne.

Pourquoi: Agrège les journaux d'une application distribuée, offrant une vue unifiée de son comportement.

Exécuter une commande ou obtenir un shell interactif à l'intérieur d'un conteneur en cours d'exécution pour le débogage.

→Utilisez `kubectl exec -it <pod-name> -- /bin/sh` (ou `/bin/bash`). Le `--` sépare les drapeaux kubectl de la commande.

Pourquoi: Fournit un accès direct à l'environnement du conteneur pour le débogage en direct, l'inspection des fichiers ou la vérification de la connectivité réseau.

Afficher la consommation actuelle de CPU et de mémoire d'un Pod en cours d'exécution.

→Utilisez `kubectl top pod <pod-name>`. Utilisez `--containers` pour voir l'utilisation de chaque conteneur dans le Pod.

Pourquoi: Nécessite l'installation du Metrics Server. Il est essentiel pour identifier les applications gourmandes en ressources, les fuites de mémoire ou les goulots d'étranglement du CPU.

Dépanner un conteneur en cours d'exécution qui manque d'un shell ou d'outils de débogage.

→Utilisez `kubectl debug <pod-name> -it --image=busybox --share-processes --copy-to=debug-pod`. Cela crée un nouveau Pod avec un conteneur de débogage partageant le même espace de noms de processus.

Pourquoi: `kubectl debug` est le moyen moderne d'attacher un "conteneur éphémère" temporaire avec des outils de débogage à un Pod en cours d'exécution sans modifier la spécification originale du Pod.