Kubernetes / Helm
Choisissez un type : la sortie contient une ressource ou un fragment de sonde à insérer dans un conteneur.
Les paramètres restent dans ce navigateur, sans envoi à un cluster ni à un serveur.
Modèles Kubernetes 1.34 : apps/v1, v1, networking.k8s.io/v1, batch/v1. Probe est un fragment de conteneur.
Les exemples sont des points de départ. Ajoutez ressources, sécurité et stockage. Aucune vérification du cluster ou de l’image.
Nom commençant par une minuscule, 63 caractères maximum (CronJob 52). Ports 1–65535, réplicas 0–1000. Délais de sonde ≤86400 secondes, seuil d’échecs ≤1000.
Jusqu’à 50 lignes KEY=value ; ConfigMap et Secret référencent des noms existants. Texte : 20000 caractères. Commande : 32 chaînes de 4096 caractères maximum chacune.
Génération…
Le Générateur YAML Kubernetes sert à préparer un point de départ lisible pour une nouvelle application. Dans un Deployment, le sélecteur et les labels des Pods viennent du même nom. Changer de type conserve les autres valeurs du formulaire, mais seule la ressource sélectionnée apparaît dans la sortie.
Vous pouvez générer Deployment, contrôler un Service ou préparer des manifestes Kubernetes pour une tâche planifiée. Ingress YAML et variables d’environnement font également partie du formulaire. Les références entre fichiers restent à vérifier : la prévisualisation ne décrit pas des objets déjà présents dans le cluster.
Le Générateur YAML Kubernetes distingue le modèle de Pod du Deployment, la correspondance des ports du Service et le backend de l’Ingress. Il n’ajoute pas de ressources voisines non configurées. La relecture porte donc sur le seul objet demandé, sans dépendances créées implicitement.
Une sonde n’est pas une ressource autonome. Le mode dédié produit readinessProbe, livenessProbe ou startupProbe sans kind inventé. Vous pouvez aussi insérer une sonde dans un Deployment. Son port est indépendant, car le point de contrôle peut différer du port applicatif.
Le Deployment donne la valeur de son nom au label app des Pods. Reprenez cette valeur dans le sélecteur du Service. Le backend Ingress désigne ensuite le Service et son port, pas nécessairement le targetPort du conteneur.
La génération automatique attend 350 ms après la dernière modification. Désactivez-la pour régler plusieurs valeurs puis utilisez Générer ou Ctrl/Cmd+Enter. La copie et le téléchargement restent bloqués tant que le résultat ne correspond pas au formulaire actuel.
Exemple et Effacer affichent d’abord le nombre de champs modifiés et leurs nouvelles valeurs. Après application, une annulation restaure le formulaire et le résultat ensemble. L’exemple CronJob exécute date, une commande qui se termine, au lieu d’un serveur permanent.
Deployment utilise apps/v1, Service v1, Ingress networking.k8s.io/v1 et CronJob batch/v1. La référence des modèles est Kubernetes 1.34. Aucun sélecteur de version ne promet une compatibilité sans changer réellement les champs générés.
Les lignes KEY=value sont séparées au premier signe égal. Les signes suivants et les valeurs vides sont conservés. Les noms répétés sont refusés. Les chaînes YAML sont citées pour que yes, null ou une suite de chiffres ne changent pas de type dans un lecteur YAML 1.1.
envFrom accepte les noms de ConfigMap et Secret. Ingress propose un hôte, un chemin, Prefix ou Exact, une classe et un Secret TLS. Ces références ne créent ni certificats ni objets dépendants et ne configurent pas le contrôleur.
CronJob écrit cinq champs horaires, Etc/UTC, un tableau de commande et une politique de concurrence. Les sondes HTTP ou TCP exposent leur port et leurs délais ; successThreshold vaut 1. Aucun appel au point de contrôle ni calcul de prochaine exécution n’est effectué.
Les modèles suivent Kubernetes 1.34 : apps/v1, v1, networking.k8s.io/v1 et batch/v1 selon le type. Un fragment Probe n’a pas d’apiVersion. Le nom d’API ne remplace pas la validation dans le cluster visé.
Le Service sélectionne les labels des Pods, pas le nom de l’objet Deployment. Le formulaire utilise app: NOM. Reprenez NOM dans le sélecteur et dirigez targetPort vers le port réellement écouté par l’application.
Chaque génération porte sur le type choisi. Pour Deployment et Service, produisez deux fichiers puis vérifiez noms, sélecteurs et espaces de noms. Une modification du formulaire ne met pas à jour les fichiers déjà téléchargés.
Saisissez KEY=value pour les valeurs directes ou des noms ConfigMap et Secret pour envFrom. Les valeurs vides ou d’apparence numérique restent des chaînes. Une référence ne lit pas et ne crée pas l’objet désigné.
Relisez le fichier puis validez-le dans l’environnement cible. Ingress nécessite un contrôleur et un backend ; CronJob, une commande qui peut finir. Complétez ressources et sécurité. Le tag d’image de l’exemple n’est pas une garantie de disponibilité ou de sécurité.
Un problème dans le manifeste généré ?
Le Générateur YAML Kubernetes prépare un changement limité et facile à relire. Vérifiez le type et chaque référence, puis complétez les paramètres de votre application avant toute application.