Tokenlabor

Kubernetes YAML erstellen

Kubernetes YAML erstellen per Formular: Deployment, Service, Ingress und ConfigMap mit Probes, Ressourcen und Sicherheitskontext als ein fertiges Manifest.

Kubernetes-Manifest (app.yaml)
    Alles läuft in Ihrem Browser. Eingaben verlassen Ihr Gerät nicht.
    Vom Image zur erreichbaren Anwendung
    Mit diesem Generator können Sie ein Kubernetes YAML erstellen, ohne die Feldnamen der einzelnen Objekte im Kopf zu haben. Ein typisches Kubernetes Manifest für eine Webanwendung besteht aus vier Teilen: Das Kubernetes Deployment beschreibt, welches Image in wie vielen Replikaten laufen soll; der Kubernetes Service gibt den Pods eine feste Adresse im Cluster; das Ingress YAML leitet Anfragen von außen anhand von Host und Pfad an den Service weiter; eine ConfigMap hält Einstellungen als Umgebungsvariablen bereit. Alle Teile stehen durch --- getrennt in einer Datei.
    Zusammengehalten wird alles über Labels. Der Generator setzt das empfohlene Label app.kubernetes.io/name an Deployment und Pod-Vorlage; der Selector des Deployments und des Service verweisen darauf. Der Service leitet seinen Port an den benannten Container-Port http weiter, der Ingress spricht den Service über Namen und Portnummer an. Readiness- und Liveness-Probe prüfen den angegebenen Pfad: Die erste entscheidet, ob ein Pod Anfragen bekommt, die zweite, ob er neu gestartet wird.
    Ressourcen-Anforderungen helfen dem Scheduler bei der Platzierung, das Speicher-Limit schützt den Knoten vor Ausreißern. Ein CPU-Limit ist bewusst optional, weil es auch bei freier Rechenleistung drosselt. Der Sicherheitskontext verlangt einen Nicht-Root-Nutzer, verbietet Rechteausweitung, entfernt alle Linux-Capabilities und nutzt das Seccomp-Profil RuntimeDefault; das entspricht weitgehend dem Pod-Security-Standard „restricted“. Das Image muss dazu als normaler Nutzer laufen. Häufige kubectl-Befehle zum Anwenden und Prüfen finden Sie unter kubectl-Befehle.
    Anleitung: Kubernetes YAML erstellen in 5 Schritten
    1. „Name“, „Namespace“, „Container-Image“, „Replikate“ und „Container-Port“ eintragen.
    2. Mit den Schaltern wählen, welche Objekte erzeugt werden: Deployment, Service, Ingress und ConfigMap.
    3. Service-Typ, Host, Ingress-Klasse und TLS-Secret sowie Umgebungsvariablen für die ConfigMap angeben.
    4. Ressourcen, Health-Check-Pfad und Sicherheitskontext prüfen; Warnungen unter dem Ergebnis beachten.
    5. YAML kopieren, als Datei speichern und mit kubectl apply -f app.yaml anwenden.
    Typische Anwendungsfälle
    • Eine Anwendung erstmals in einen Cluster bringen, ohne die Feldnamen von Deployment und Ingress nachzuschlagen.
    • Vorlage für Helm-Charts oder Kustomize: Das erzeugte Manifest als Ausgangspunkt nehmen und anschließend parametrisieren.
    • Schulung und Review: Zeigen, wie Labels, Selector und Service zusammenhängen.
    Fragen
    Häufige Fragen
    Welche apiVersion gilt für welches Objekt?
    Deployment: apps/v1, Service und ConfigMap: v1, Ingress: networking.k8s.io/v1. Ältere Versionen wie extensions/v1beta1 für Ingress werden von aktuellen Clustern nicht mehr angenommen.
    Was ist der Unterschied zwischen ClusterIP, NodePort und LoadBalancer?
    ClusterIP ist nur innerhalb des Clusters erreichbar und reicht, wenn ein Ingress davor steht. NodePort öffnet zusätzlich einen Port auf jedem Knoten, LoadBalancer fordert beim Cloud-Anbieter einen externen Load Balancer an.
    Woher kommt das TLS-Zertifikat für den Ingress?
    Aus einem Secret vom Typ kubernetes.io/tls mit dem eingetragenen Namen. Häufig erzeugt es cert-manager automatisch; ohne Secret liefert der Ingress-Controller meist ein selbstsigniertes Ersatzzertifikat aus.
    Welche Namen sind erlaubt?
    Namen von Deployments, Services und Ingress folgen DNS-Regeln: Kleinbuchstaben, Ziffern und Bindestriche, Anfang und Ende alphanumerisch. Service-Namen dürfen höchstens 63 Zeichen lang sein. Der Generator prüft das.
    Werden Änderungen an der ConfigMap sofort übernommen?
    Nicht bei Umgebungsvariablen: Sie werden nur beim Start des Containers gelesen. Nach einer Änderung starten Sie die Pods mit kubectl rollout restart deployment/webapp neu.
    Wie prüfe ich das Manifest, bevor ich es anwende?
    Mit kubectl apply --dry-run=server -f app.yaml prüft der API-Server die Objekte, ohne sie anzulegen. kubectl diff -f app.yaml zeigt, was sich gegenüber dem Cluster ändern würde.
    Warum nutzt das Beispiel nginx-unprivileged statt nginx?
    Das offizielle nginx-Image startet als root und lauscht auf Port 80. Mit runAsNonRoot: true würde der Pod nicht starten. Die Variante nginxinc/nginx-unprivileged läuft als normaler Nutzer auf Port 8080.
    Weitere Werkzeuge
    Das könnte auch helfen
    Alle 558 Werkzeuge 
    Cron-Ausdruck erklären
    Crontab-Zeilen mit 5 oder 6 Feldern auf Deutsch erklärt, mit den nächsten 10 Ausführungen.
    Öffnen 
    Cron-Generator
    Zeitplan im Formular wählen und die fertige Crontab-Zeile kopieren.
    Öffnen 
    Unix-Zeitstempel umrechnen
    Timestamp in Datum und zurück, Sekunden und Millisekunden erkannt, UTC und Berlin.
    Öffnen 
    UUID-Generator
    UUID v4 und v7 erzeugen, bis zu 1.000 auf einmal, und vorhandene UUIDs prüfen.
    Öffnen 
    ULID-Generator
    Sortierbare IDs in Crockford Base32 erzeugen, dekodieren und in UUID umwandeln.
    Öffnen 
    Texte vergleichen (Diff)
    Unterschiede zwischen zwei Texten zeilen-, wort- oder zeichenweise finden.
    Öffnen