Gains :
- Capacité à comprendre les objets de base (Pod, Deployment, Service, ConfigMap, Secret, Namespace) et la philosophie déclarative de Kubernetes et à produire des manifestes solides pour l'intelligence artificielle
- Possibilité de préparer des manifestes pour la production et de les sécuriser avec des limites de ressources, des contrôles de santé (sondes), des balises d'image fixes et un RBAC étroit
- Capacité à vérifier le contexte correct avant l'exécution et à appliquer la discipline de simulation avec simulation/diff
Il est facile de gérer un seul conteneur. Mais établir un système qui répartit des centaines de conteneurs sur des dizaines de serveurs, redémarre automatiquement lorsque l'un d'eux tombe en panne, le réplique lorsque la charge augmente et le met à jour sans aucun temps d'arrêt ? C'est l'orchestration, et l'outil standard de l'industrie est Kubernetes (K8s en abrégé) — la plate-forme qui déploie, met à l'échelle et gère automatiquement les conteneurs sur un cluster. Kubernetes est puissant mais complexe : tout est défini par de longs fichiers YAML sensibles à l'indentation, appelés manifestes. C’est là que l’IA donne une bouffée d’air frais ; Avec le bon contexte, il produit rapidement ces manifestes et décode leurs mystérieuses erreurs.
Mais dans Kubernetes, un mauvais manifeste signifie ne pas réussir à mettre en place un service entier, à évoluer de manière incorrecte ou à laisser une vulnérabilité. Il est de votre responsabilité de comprendre et de vérifier chaque manifeste produit par l'IA, en particulier avant l'application de kubectl.
Objets principaux de Kubernetes
Pour auditer Kubernetes, vous devez connaître les principaux concepts :
- Pod : plus petite unité de travail ; Il contient un ou plusieurs conteneurs. Généralement, le Pod n'est pas utilisé directement, mais les objets parents qui le gèrent le sont.
- Déploiement : définit le nombre de copies d'une application qui seront exécutées, quelle image elle utilisera et comment elle sera mise à jour. Si un Pod plante, il le recréera automatiquement.
- Service : fournit une adresse réseau fixe et un équilibrage de charge aux pods ; Même si les pods vont et viennent, l’adresse d’accès ne change pas.
- ConfigMap et Secret : conserve les valeurs de configuration et les informations secrètes séparées des pods. ConfigMap est destiné aux paramètres explicites, Secret est destiné aux valeurs sensibles.
- Espace de noms : zone qui divise et isole logiquement les ressources (par exemple, dev, prod).
- Ingress : ensemble de règles qui dirige le trafic HTTP du monde extérieur vers les services du cluster.
Helm est le « gestionnaire de packages » de Kubernetes : il permet de modéliser des manifestes récurrents (graphiques) et de les installer avec différentes valeurs dans différents environnements avec une seule commande. L'IA produit à la fois un manifeste brut et un graphique Helm.
Pourquoi y a-t-il tant d'objets ? Parce que la philosophie de base de Kubernetes est déclarative : vous définissez "à quoi vous voulez que le système ressemble finalement" (par exemple "toujours 3 copies de cette application en cours d'exécution"), tandis que Kubernetes rapproche continuellement l'état actuel de l'état souhaité. Si un Pod meurt, il en crée un nouveau ; si un nœud tombe en panne, il déplace la charge de travail vers un autre nœud. C'est pourquoi les manifestes ne sont pas des commandes « faire », mais des recettes « qu'il en soit ainsi ». Comprendre cette distinction est essentiel lors de la lecture des manifestes produits par l’IA : chaque domaine décrit une partie de l’état souhaité du système. Un mauvais domaine signifie que Kubernetes travaille vers un mauvais objectif – et cet objectif est appliqué de manière silencieuse et persistante.
Astuce : Dans Kubernetes, l'outil de test sécurisé le plus important est kubectl apply --dry-run=server -f file.yaml : il indique si le serveur acceptera et que faire sans appliquer réellement le manifeste. Assurez-vous d'exécuter un essai à sec et kubectl diff avant d'appliquer un manifeste à prod.
Étape par étape : créer des manifestes avec l'IA
- Décrivez l'application et le besoin. Nom de l'image, port, nombre de répliques, limites de ressources (CPU/mémoire).
- Demander un déploiement + un service. Habituellement, les deux sont nécessaires ensemble.
- Séparez la configuration et le secret. Paramètres sur ConfigMap, valeurs sensibles sur Secret.
- Ajoutez des contrôles de santé. livenessProbe (est-il en direct) et readinessProbe (est-il prêt pour le trafic) sont essentiels.
- Fixez une limite de ressources. Sans requêtes/limites, un pod peut consommer l'intégralité du nœud.
- Vérifiez avec `--dry-run` et `diff`, puis appliquez. D'abord dans l'espace de noms de test.
Sécurité : risques spécifiques à Kubernetes
- Le secret n'est pas vraiment secret, c'est juste du base64. L'objet Kubernetes Secret en base64 encode les valeurs ; Il ne s’agit pas d’un cryptage, il se déchiffre facilement. Pour une véritable confidentialité, le cryptage etcd et un coffre-fort externe (Vault, gestionnaire de secrets cloud) sont requis. Ne validez jamais de manifestes secrets directement dans Git (il existe des solutions pour cela, telles que les secrets scellés/les secrets externes).
- Fixez une limite de ressources. Un Pod sans limites peut faire planter tout le nœud avec une fuite de mémoire.
- Autorité minimale (RBAC). Avec le contrôle d'accès basé sur les rôles, chaque service/utilisateur dispose uniquement des autorisations dont il a besoin. L'IA donne parfois de gros administrateurs de cluster ; affinez cela.
- N'utilisez pas la balise d'image « latest ». Vous ne savez pas quelle version est en cours d'exécution et vous ne pouvez pas la restaurer.
Attention : kubectl delete ou une application incorrecte peut détruire un déploiement en direct. Assurez-vous de vérifier dans quel espace de noms vous vous trouvez (kubectl config current-context) avant d'exécuter les commandes ; Le travail accidentel est un désastre courant dans le contexte de la production.
Manifeste brut par rapport à la table Helm
critère
Manifeste YAML brut
Tableau de barre
Mise en place
kubectl appliquer -f
installation de la barre
Multimédia (dév/production)
Copier-coller, sujet aux erreurs
Graphique unique, valeurs différentes.yaml
Version/restauration
à la main
facile avec le recul de la barre
Courbe d'apprentissage
faible
moyen
quand
Petit environnement unique
Service multimédia et répétitif
trois mini-cases
Cas 1 — le secret du service en panne. Un Pod redémarrait constamment (CrashLoopBackOff). L'équipe a remis les journaux et le manifeste à l'IA ; L'IA a montré que le Pod n'a jamais été considéré comme "prêt" car la readinessProbe regardait le mauvais port. Ils ont réparé le port, le service est devenu stable en 10 minutes. L'établissement manuel de cette relation peut prendre des heures.
Cas 2 : le fait de ne pas fixer de limites a brisé le nœud. Il n'y avait aucune limite dans un déploiement ; Une fuite de mémoire a gonflé le Pod et fait planter l'ensemble du nœud, entraînant également la panne des services voisins. Après l'incident, ils ont fait dire à l'IA "ajouter des demandes et des limites raisonnables en matière de CPU/mémoire à tous les déploiements" et l'ont rendu standard. Une ligne manquante a coûté des heures d’arrêt.
Cas 3 : grand RBAC capturé. Au cours d'une enquête, un manifeste ServiceAccount généré par AI s'est avéré lié au rôle d'administrateur de cluster, ce qui signifie que le service pouvait gérer l'ensemble du cluster. L'équipe a limité l'autorisation à la lecture uniquement des pods dans leur espace de noms. Le principe du moindre privilège a comblé une faille de sécurité.
Quatre modèles copiables
1) Déploiement + Production de services :
Rédigez un manifeste de déploiement et de service pour Kubernetes. Application : [AD], image : [image : version fixe], port : [X], réplique : [N]. Règles : - Ajouter des demandes et des limites de CPU/mémoire.- Définir livenessProbe et readinessProbe.- Lire la configuration à partir de ConfigMap, le secret à partir de l'objet Secret ; N'intégrez pas de valeurs dans le manifeste, utilisez des espaces réservés. - N'utilisez PAS la balise d'image ":latest". Donnez avec description.
2) Résolution des erreurs manifestes :
Le pod actuel est dans l'état [CrashLoopBackOff / Pending / ImagePullBackOff]. Selon le manifeste suivant et le résultat « kubectl décrire », répertoriez les causes profondes possibles par ordre de probabilité et exécutez la commande verify pour chacune. Manifeste : [YAML] Décrire : [OUTPUT]
3) Contrôle de sécurité/intégrité :
Vérifiez ce manifeste Kubernetes : la limite de ressources est-elle manquante, est-ce qu'il manque un problème, y a-t-il une balise :latest, y a-t-il un RBAC/autorisation trop large, le secret est-il intégré dans le manifeste ? Écrivez les résultats par ordre d’importance et avec correction. Manifeste : [YAML]
4) Conversion en carte Helm :
Convertissez les manifestes bruts suivants en un graphique Helm réutilisable : quelles valeurs doivent être envoyées à values.yaml (image, réplique, source, environnement) ? Afficher la structure du graphique et des exemples de valeurs.yaml.Manifests : [YAML]
Invite faible/Invite forte
Faible : "Écrivez Kubernetes YAML pour mon application."
Résultat : un déploiement sans sonde et sans limite avec la balise :latest, intégrant la plaine secrète ; Peu sûr et fragile en prod.
Strong : "Écrivez le déploiement et le service Kubernetes. Image myapp : 1.4.2, 3 répliques, 8080 ports. CPU 100 m-500 m, mémoire 128Mi-512Mi ajouter des requêtes/limites. Mettez une sonde d'activité pour /healthz, une sonde de préparation pour /ready. Lisez le secret à partir de l'objet Secret, ne l'intégrez pas dans le manifeste. Donnez avec une description."
Différence : la deuxième version d'invite indique l'échelle, les limites de ressources, les contrôles de santé et la règle secrète ; La sortie est proche de la production et sûre.
Erreurs courantes
- Ne pas fixer de limites de ressources. Un seul pod peut consommer l'intégralité du nœud.
- Ne pas ajouter de bilan de santé (sonde). Kubernetes ne peut pas détecter un pod en panne/non prêt.
- Balise `:latest`. On ne sait plus quelle version est en cours d'exécution, elle ne peut pas être restaurée.
- Envoi du secret directement à Git. Base64 n'est pas un cryptage ; tout le monde le résout.
- Exécution de commandes dans un mauvais contexte/espace de noms. La façon la plus courante de planter en prod.
- sauter `--dry-run`/`diff`. Ne pas voir ce qui se passera avant la mise en œuvre.
En résumé
Kubernetes est un orchestrateur puissant mais complexe qui déploie, met à l'échelle et optimise automatiquement les conteneurs sur un cluster ; Tout est défini par des YAML manifestes, que Helm modélise. L'IA produit rapidement des manifestes de déploiement/service et des graphiques Helm, résout des bugs mystérieux, mais vous devez demander explicitement une limite de ressources, un contrôle de santé, une balise d'image immuable, un RBAC étroit et des règles de sécurité secrètes. --dry-run, diff et la vérification correcte du contexte sont des habitudes qui évitent les plantages de production.
Tâche de candidature
Demandez à AI de générer un manifeste pour un exemple d'application avec le modèle « Déploiement + Génération de service ». Ensuite : (1) Faites-lui vérifier la limite de ressources, la sonde, :latest et le secret avec le modèle "Contrôle de sécurité/sanité" ; (2) exécutez kubectl apply --dry-run=server sur un cluster/minikube de test si possible et lisez le résultat ; (3) notez les deux éléments de sécurité/robustesse les plus critiques qui vous manquent.
liste de contrôle
- [ ] J'ai ajouté la version de l'image, le nombre de répliques, les limites de port et de ressources à ma demande.
- [ ] J'ai ajouté une sonde de vivacité et de préparation au manifeste.
- [ ] Balise d'image corrigée ; Je n'ai pas utilisé :latest.
- [ ] Le secret n'est pas intégré dans le manifeste ; J'ai utilisé un objet secret/un coffre-fort externe.
- [ ] J'ai réduit RBAC/autorisations à des autorisations minimales.
- [ ] Avant de postuler, j'ai vérifié que j'étais dans le bon contexte et que --dry-run/diff sortait.