La plupart des contenus sur Kubernetes s'adressent aux personnes qui administrent les clusters. Pourtant, bien plus de développeurs se contentent de déployer sur un cluster géré par d'autres, et pour eux, quatre-vingt-dix pour cent de Kubernetes n'est que bruit. Vous n'avez pas besoin de comprendre les rouages d'etcd pour livrer un service fiable. Vous devez maîtriser une poignée de choses : les demandes de ressources, les sondes de santé, la configuration et la manière dont le trafic atteint votre application. Ce guide se concentre précisément sur cette tranche, pour le Kubernetes moderne de l'ère 1.36 : ce qu'un développeur d'applications doit réellement savoir, et les concepts durables derrière les numéros de version.
L'essentiel pour le développeur
- Demandes et limites de ressources : le réglage que la plupart des applications ratent
- Sondes de vivacité, de disponibilité et de démarrage bien configurées
- Configuration et secrets sans les intégrer dans les images
- L'API Gateway, la méthode moderne pour acheminer le trafic vers votre service
- Pourquoi « ce qui a changé dans la 1.36 » importe moins que de maîtriser les fondamentaux
Info
Vous n'avez pas besoin d'être opérateur
Si une équipe plateforme gère votre cluster, votre travail consiste à empaqueter votre application en bon citoyen Kubernetes : déclarez ce dont elle a besoin, indiquez au cluster quand elle est en bonne santé, externalisez sa configuration et définissez comment elle reçoit le trafic. Maîtrisez ces points et vous déploierez de manière fiable sans jamais toucher au plan de contrôle.
Avertissement
Traitez les détails spécifiques à une version comme « à vérifier avant d'utiliser »
Kubernetes évolue rapidement et les fonctionnalités passent d'une version à l'autre. Ce guide met l'accent sur les concepts durables dont tout développeur d'applications a besoin ; pour connaître le statut exact d'une fonctionnalité dans la 1.36, consultez les notes de version officielles de Kubernetes et la version de votre cluster, car la disponibilité dépend des deux.
1. Demandes et limites de ressources
C'est la chose la plus impactante que les développeurs d'applications contrôlent, et la plus souvent ratée. Une demande est ce que votre conteneur est garanti d'obtenir (le planificateur l'utilise pour placer votre pod) ; une limite est le plafond qu'il ne peut pas dépasser. Fixez des demandes trop basses et votre application sera affamée et évincée sous pression ; trop hautes et vous gaspillez de la capacité du cluster et de l'argent. Définissez des demandes CPU et mémoire approximativement correctes en vous basant sur l'utilisation réelle, et soyez particulièrement prudent avec les limites mémoire.
resources:
requests: # guaranteed; drives scheduling
cpu: "250m"
memory: "256Mi"
limits: # ceiling; exceeding memory = OOMKilled
cpu: "1000m"
memory: "512Mi"Danger
Les limites mémoire sont un mur infranchissable
Dépassez votre limite CPU et vous serez simplement bridé, gênant mais supportable. Dépassez votre limite mémoire et le noyau tue votre conteneur (OOMKilled), instantanément. Basez les limites mémoire sur l'utilisation réelle observée avec une marge, et traitez les OOMKills soudains comme un signe que votre limite est trop basse ou que votre application a une fuite.
2. Sondes de santé
Kubernetes maintient votre application disponible uniquement si vous lui dites ce que « sain » signifie. Trois sondes remplissent des rôles distincts, et les confondre provoque des pannes.
Sonde de disponibilité
Répond à la question « ce pod peut-il recevoir du trafic en ce moment ? » Si elle échoue, Kubernetes cesse de router les requêtes vers le pod mais le laisse s'exécuter. Indispensable pour ne pas envoyer de trafic à un pod encore en cours de démarrage ou momentanément surchargé.
Sonde de vivacité
Répond à la question « ce pod est-il cassé et a-t-il besoin d'être redémarré ? » Si elle échoue, Kubernetes tue et redémarre le conteneur. Utilisez-la pour récupérer de blocages, mais soyez prudent, car une sonde de vivacité trop agressive provoque des boucles de redémarrage.
Sonde de démarrage
Répond à la question « cette application à démarrage lent a-t-elle fini de démarrer ? » Elle retarde les autres sondes jusqu'à ce que le démarrage soit terminé, afin que les applications avec une longue initialisation ne soient pas tuées avant d'être prêtes.
readinessProbe:
httpGet: { path: /healthz/ready, port: 8080 }
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz/live, port: 8080 }
periodSeconds: 10
failureThreshold: 3 # be tolerant — avoid restart stormsConseil de pro
Rendez votre sonde de disponibilité pertinente : elle doit vérifier que les dépendances dont votre application a vraiment besoin (comme la base de données) sont joignables, afin qu'un pod incapable de servir de vraies requêtes soit retiré de la rotation. Mais gardez votre sonde de vivacité simple et légère : si elle vérifie aussi la base de données, un bref incident de base de données redémarrera tous les pods en même temps et transformera un petit problème en panne.
3. Configuration et secrets
N'intégrez jamais la configuration ou les identifiants dans votre image de conteneur. La même image doit s'exécuter dans tous les environnements, son comportement étant fourni de l'extérieur. Kubernetes propose les ConfigMaps pour la configuration non sensible et les Secrets pour les valeurs sensibles, tous deux injectés dans votre pod sous forme de variables d'environnement ou de fichiers montés. Cela garde les images portables et les identifiants hors de votre registre.
envFrom:
- configMapRef: { name: app-config } # non-sensitive settings
- secretRef: { name: app-secrets } # credentials, tokens, keysAvertissement
Les Secrets Kubernetes ont besoin d'une vraie protection
Par défaut, les Secrets sont seulement encodés en base64, pas chiffrés de manière à les protéger de quiconque ayant accès au cluster. Assurez-vous que votre plateforme chiffre les secrets au repos et contrôle étroitement l'accès, et pour les systèmes sensibles, envisagez un gestionnaire de secrets externe. « C'est un objet Secret » n'est pas la même chose que « c'est sécurisé ».
4. Comment le trafic atteint votre application : l'API Gateway
Pendant des années, Ingress était le moyen par lequel le trafic externe était routé vers les services, mais il était limité et poussait les fournisseurs vers des annotations incompatibles. L'API Gateway est le successeur moderne et plus expressif : une manière standardisée et consciente des rôles de définir le routage (règles d'hôte et de chemin, répartition du trafic, etc.) qui devient l'approche recommandée pour les nouvelles configurations. En tant que développeur d'applications, vous définissez généralement des routes qui s'attachent à une passerelle fournie par l'équipe plateforme.
✓ Avantages
- Routage plus expressif que l'Ingress classique (répartition, en-têtes, etc.)
- Un modèle standard au lieu d'annotations Ingress spécifiques à un fournisseur
- Séparation nette entre les passerelles gérées par la plateforme et les routes gérées par l'application
- La direction recommandée pour le réseau Kubernetes moderne
✕ Inconvénients
- Plus récent, donc certains clusters et outils restent centrés sur Ingress
- Plus de concepts à apprendre qu'avec l'Ingress de base
- Votre cluster doit avoir une implémentation de la Gateway API installée
- La migration depuis Ingress nécessite une planification sur les configurations existantes
Qu'est-ce qui a vraiment changé dans la version 1.36 ?
Honnêtement, pour la plupart des développeurs d'applications, bien moins que ce que la longueur des notes de version laisse penser. Les versions de Kubernetes sont dominées par le plan de contrôle, la sécurité et le travail destiné aux opérateurs : passage de fonctionnalités en stable, dépréciation d'anciennes API, amélioration du planificateur. La surface exposée au développeur (comment demander des ressources, définir des sondes, injecter de la configuration et router le trafic) est remarquablement stable d'une version à l'autre. La bonne approche lors d'une mise à niveau est de parcourir les notes pour repérer les API dépréciées que vos manifestes utilisent, de confirmer que rien de ce dont vous dépendez n'a changé de statut, et pour le reste de continuer à bien faire les bases.
les ressources, les sondes, la configuration et le routage : maîtrisez-les et vous déployez de manière fiable
La checklist du développeur d'applications
✓ Avantages
- Demandes CPU et mémoire réalistes basées sur l'utilisation observée
- Limites mémoire avec marge de sécurité ; attendez-vous à des OOMKills si elles sont trop serrées
- Sondes de readiness, de liveness et (si nécessaire) de startup distinctes
- Configuration et secrets injectés depuis l'extérieur de l'image
- Routes définies via la Gateway API sur une passerelle de la plateforme
✕ Inconvénients
- Pas de configuration ni de secrets intégrés dans les images
- Pas de sonde de liveness qui vérifie des dépendances externes
- Pas de demandes de ressources manquantes (le planificateur doit alors deviner)
- Ne pas considérer les Secrets en base64 comme réellement sécurisés
! Erreurs courantes à éviter
-
✕Omettre les demandes de ressources, ce qui oblige le planificateur à deviner.
✓Définissez des demandes CPU et mémoire réalistes basées sur l'utilisation observée ; fixez des limites mémoire avec une marge de sécurité.
-
✕Une sonde de liveness qui vérifie des dépendances externes.
✓Gardez la liveness légère et autonome ; un incident de base de données ne doit pas redémarrer tous les pods en même temps.
-
✕Intégrer la configuration ou les secrets dans l'image.
✓Injectez la configuration via des ConfigMaps et les secrets via des Secrets depuis l'extérieur de l'image.
-
✕Considérer les Secrets Kubernetes en base64 comme sécurisés.
✓Assurez-vous que les secrets sont chiffrés au repos avec un contrôle d'accès strict, ou utilisez un gestionnaire de secrets externe.
? Questions fréquentes
Dois-je être un expert Kubernetes pour déployer dessus ? +
Non. Si une équipe plateforme gère le cluster, vous devez principalement maîtriser quatre choses : les demandes/limites de ressources, les sondes de santé, la configuration/secrets externalisés et le routage.
Quelle est la différence entre les sondes de liveness, de readiness et de startup ? +
La readiness détermine si un pod reçoit du trafic ; la liveness décide s'il faut redémarrer un pod défaillant ; la startup retarde les autres jusqu'à ce qu'une application à démarrage lent ait fini de s'initialiser.
Pourquoi mon conteneur est-il constamment OOMKilled ? +
Il a dépassé sa limite mémoire : le noyau le tue instantanément (contrairement aux limites CPU, qui ne font que limiter). Basez les limites mémoire sur l'utilisation réelle observée avec une marge, et vérifiez l'absence de fuites.
Qu'est-ce que la Gateway API et dois-je l'utiliser ? +
C'est le successeur moderne et plus expressif d'Ingress, et l'approche recommandée pour le nouveau routage. En tant que développeur d'applications, vous définissez généralement des routes qui s'attachent à une passerelle fournie par l'équipe plateforme.
Qu'est-ce qui a vraiment changé pour les développeurs dans la version 1.36 ? +
Moins que ce que les notes de version suggèrent : l'essentiel du travail concerne le plan de contrôle et les opérateurs. Parcourez les API dépréciées que vos manifestes utilisent, confirmez que rien de ce dont vous dépendez n'a changé de statut, et continuez à bien faire les bases.
Succès
Soyez un bon citoyen du cluster
Vous n'avez pas besoin de maîtriser Kubernetes pour bien déployer dessus. Déclarez ce dont votre application a besoin, indiquez honnêtement au cluster quand elle est saine, gardez la configuration et les secrets en dehors de votre image, et définissez un routage propre. Faites ces quatre choses de manière cohérente et vos services seront fiables sur la version 1.36 et sur toutes les versions à venir, car les fondamentaux changent à peine.
Commentaires
0Aucun commentaire pour l’instant. Soyez la première personne à donner votre avis.