Kubernetes / Helm
Wähle einen Typ. Die Vorschau enthält eine Ressource oder ein Probe-Fragment für einen Container.
Die Eingaben bleiben in diesem Browser und werden an keinen Cluster oder Server gesendet.
Kubernetes-1.34-Vorlagen: apps/v1, v1, networking.k8s.io/v1, batch/v1. Probe liefert ein Container-Fragment.
Beispiele sind Ausgangspunkte. Ressourcen-, Sicherheits- und Speichereinstellungen ergänzen. Keine Cluster- oder Image-Prüfung.
Name beginnt klein, höchstens 63 Zeichen (CronJob 52). Ports 1–65535, Replikate 0–1000. Probe-Zeiten höchstens 86400 Sekunden, Fehlerschwelle höchstens 1000.
Höchstens 50 KEY=value-Zeilen; ConfigMap und Secret referenzieren vorhandene Namen. Textfelder: 20000 Zeichen. Befehl: 32 Zeichenketten mit je höchstens 4096 Zeichen.
Wird erzeugt…
Ein Kubernetes-YAML-Generator ist hilfreich, wenn du einen überschaubaren Ausgangspunkt für eine neue Anwendung brauchst. Beim Deployment entstehen Pod-Labels und Selektor aus demselben Namen. Du kannst den Ressourcentyp wechseln, ohne die übrigen Formularwerte zu verlieren; ausgegeben wird jeweils nur der aktive Typ.
Damit kannst du ein Kubernetes Manifest erstellen, ein Kubernetes Deployment generieren oder einen Service-Selektor prüfen. Auch Ingress YAML und geplante Jobs sind möglich. Namen und Namensräume in getrennt gespeicherten Dateien musst du selbst abgleichen. Die Vorschau beschreibt keine bereits vorhandenen Clusterobjekte.
Der Kubernetes-YAML-Generator zeigt die Unterschiede direkt: Ein Deployment enthält ein Pod-Template, ein Service bildet Ports ab und ein Ingress verweist auf einen Service. Nicht ausgewählte Ressourcen gelangen nicht versehentlich in die Datei. So bleibt der Umfang eines Reviews nachvollziehbar.
Eine Probe ist ein Containerfeld, kein eigener Kubernetes-Ressourcentyp. Der separate Modus liefert readinessProbe, livenessProbe oder startupProbe ohne erfundene Metadaten. Alternativ lässt sich eine Probe in ein Deployment einfügen. Ihr Port wird getrennt angegeben, da der Prüfendpunkt anderswo lauschen kann.
Das Deployment setzt app auf seinen Namen. Verwende diesen Wert im Service-Selektor. Im Ingress steht dagegen der Name des Service mit dessen Service-Port; der targetPort des Containers ist nicht automatisch derselbe Port.
Automatisch wird nach 350 ms ohne weitere Eingabe neu erzeugt. Schalte die Automatik aus, wenn du mehrere Werte ändern möchtest, und nutze Erzeugen oder Ctrl/Cmd+Enter. Veraltete Ergebnisse lassen sich bis zur erneuten Erzeugung nicht exportieren.
Beispiel und Leeren zeigen zuerst Anzahl und neue Werte der geänderten Felder. Nach Anwenden stellt Rückgängig Formular und Ergebnis gemeinsam wieder her. Das CronJob-Beispiel führt einen endenden date-Befehl aus, keinen dauerhaft laufenden Webserver.
Deployment verwendet apps/v1, Service v1, Ingress networking.k8s.io/v1 und CronJob batch/v1. Die Vorlagen sind auf Kubernetes 1.34 bezogen. Ein Versionsschalter ohne tatsächliche Ausgabeänderung ist bewusst nicht vorhanden.
KEY=value wird am ersten Gleichheitszeichen getrennt. Weitere Gleichheitszeichen und leere Werte bleiben erhalten; doppelte Namen werden abgewiesen. Zeichenketten werden in YAML zitiert, damit etwa yes, null und Ziffernfolgen auch bei YAML-1.1-Verarbeitung ihren Typ behalten.
envFrom kann vorhandene ConfigMaps und Secrets über ihren Namen referenzieren. Ingress unterstützt einen Host und Pfad, Prefix oder Exact, eine Klasse und ein TLS-Secret. Damit werden weder Zertifikate noch Controller oder Zielobjekte erstellt.
CronJob enthält fünf Zeitplanfelder, Etc/UTC, ein Befehlsarray und eine Parallelitätsrichtlinie. HTTP- und TCP-Probes haben eigene Ports und Zeitwerte. successThreshold bleibt 1. Es findet weder ein Verbindungsversuch noch eine Berechnung kommender Ausführungen statt.
Die Vorlagen verwenden die stabilen API-Formen von Kubernetes 1.34: apps/v1, v1, networking.k8s.io/v1 und batch/v1. Probe-Fragmente haben keine apiVersion. Das passende API-Feld ersetzt keine Prüfung im Zielcluster.
Ein Service selektiert Pod-Labels und nicht das Deployment-Objekt. Die Vorlage nutzt app: NAME. Trage denselben Wert im Service-Selektor ein und stelle targetPort auf den Port, an dem deine Anwendung tatsächlich lauscht.
Jeder Durchlauf erzeugt nur den ausgewählten Typ. Für Deployment und Service exportierst du zwei Dateien. Prüfe deren Namen, Selektoren und Namensräume selbst; bereits gespeicherte Dateien werden bei späteren Änderungen nicht synchronisiert.
Nutze KEY=value-Zeilen für direkte Werte oder die Referenzfelder für envFrom. Leere und numerisch aussehende Werte bleiben Zeichenketten. ConfigMap- und Secret-Felder schreiben nur Namen; sie lesen und erzeugen keine Abhängigkeiten.
Prüfe die Datei und validiere sie in der vorgesehenen Umgebung. Ingress benötigt Controller und Backend, CronJob einen geeigneten endenden Befehl. Ressourcen- und Sicherheitseinstellungen fehlen absichtlich. Das Beispiel-Image ist keine Zusage zu Verfügbarkeit oder Sicherheit.
Ein Problem im erzeugten Manifest gefunden?
Der Kubernetes-YAML-Generator liefert einen kleinen Ausgangspunkt für dein Review. Kontrolliere Typ und Referenzen und ergänze die Einstellungen deiner Anwendung, bevor du die Datei anwendest.