Kubernetes Deployment YAML Generator & Manifest Builder

Kubernetes Deployment YAML Generator & Manifest Builder

Erstellen Sie produktionsreife Kubernetes-Deployment-Manifeste mit Pod-Replikaten, Ressourcenlimits (Requests/Limits), Health-Probes und unterbrechungsfreien Rolling-Update-Strategien.

Voreinstellungen:
Eingabe
Maximale Anzahl an Pods über der Soll-Replikazahl
Auf 0 setzen für unterbrechungsfreie Rollouts ohne Ausfallzeit
:
:
:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api-gateway
  namespace: production
  labels:
    app: "web-api-gateway"
    tier: "backend"
    env: "production"
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"
    prometheus.io/path: "/metrics"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: "web-api-gateway"
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: "web-api-gateway"
        tier: "backend"
        env: "production"
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "/metrics"
    spec:
      serviceAccountName: web-api-sa
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
      containers:
      - name: api-server
        image: ghcr.io/acme-corp/api-gateway:v2.4.1
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        - name: metrics
          containerPort: 9090
          protocol: TCP
        securityContext:
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
            ephemeral-storage: "50Mi"
          limits:
            cpu: "1000m"
            memory: "512Mi"
            ephemeral-storage: "200Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 2
        env:
        - name: NODE_ENV
          value: "production"
        - name: PORT
          value: "8080"
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
        - name: CONFIG_JSON
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: settings.json
        volumeMounts:
        - name: tmp-cache
          mountPath: /tmp
      volumes:
      - name: tmp-cache
        emptyDir: {}
      nodeSelector:
        kubernetes.io/os: "linux"
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - "web-api-gateway"
              topologyKey: "kubernetes.io/hostname"
Replicas & Rollout StrategyRollingUpdate
3 Pod-Replikate

Surge: 25% | Max. nicht verfügbar: 0

Resource Quotas & AllocationGarantiert
CPU: 250m / 1000m

Speicher: 256Mi / 512Mi

SicherheitseinstellungenGrad A+
100 / 100 Bereitschaft

Probes: 2 /3 aktiv

Zero-Knowledge Lokale Ausführung

Alle Datenverarbeitungen, Parsen und Generierungen laufen streng im lokalen Browserspeicher ab. Keine externen Server-Uploads.

Sub-Millisekunden AST-Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technische Referenz & Architektur-Leitfaden

Kubernetes Deployment YAML-Generator & Manifest-Builder — Referenz-Leitfaden

Erstellen Sie produktionsreife Kubernetes-Deployment-Manifeste mit Pod-Replikaten, Ressourcenlimits (Requests/Limits), Health-Probes und unterbrechungsfreien Rolling-Update-Strategien.

Wichtige Parameter & Steuerelemente

spec.replicasinteger

Anzahl der gewünschten gleichzeitig auf Worker-Knoten ausgeführten Pod-Instanzen.

Standard: 1
spec.template.spec.containers[*].imagestring

Container-Image-Repository und -Tag aus der OCI/Docker-Registry (z. B. 'nginx:1.25-alpine').

Standard: Erforderlich
spec.template.spec.containers[*].resourcesobject

CPU- und Speicherkontingente: Requests (garantierte Zuweisung) und Limits (harte Obergrenze vor Drosselung oder OOMKill).

Standard: Optional (Dringend empfohlen)
spec.strategyobject

Bereitstellungsstrategie für Releases: unterbrechungsfreies 'RollingUpdate' oder vollständiges 'Recreate'.

Standard: RollingUpdate
spec.template.spec.containers[*].livenessProbeobject

Integritätsprüfung, die einen automatischen Container-Neustart auslöst, wenn Deadlocks oder Abstürze auftreten.

Standard: Optional

Profi-Tipps & Best Practices

Definieren Sie requests für

Definieren Sie requests für zuverlässiges Scheduling und limits, um Nachbar-Pods vor Speichererschöpfung zu schützen. Setzen Sie Speicher-Requests und -Limits identisch, um die Guaranteed-QoS-Klasse zu erreichen.

Konfigurieren Sie maxUnavailable

Konfigurieren Sie maxUnavailable: 0 und maxSurge: '25%' (oder 1) bei produktiven Webdiensten, um sicherzustellen, dass während des Updates niemals Kapazität unterschritten wird.

Nutzen Sie Readiness-Probes für

Nutzen Sie Readiness-Probes für Startverzögerungen und Datenbankprüfungen zur Traffic-Steuerung; beschränken Sie Liveness-Probes streng auf echte Deadlocks, um kaskadierende Neustart-Schleifen zu vermeiden.

Pinnen Sie Container-Images immer auf

Pinnen Sie Container-Images immer auf semantische Versionen oder unveränderliche SHA-256-Digests, um deterministische Rollouts und sofortige Rollbacks zu gewährleisten.

Häufige Fallstricke & Fehlerbehebung

CrashLoopBackOff oder OOMKilled (Exit-Code 137)

Der Container stürzt beim Start ab oder überschreitet das definierte Speicherlimit (limits.memory), woraufhin der Linux-Kernel-OOM-Killer den Prozess beendet. Führen Sie kubectl describe pod <name> und kubectl logs <name> --previous aus; erhöhen Sie resources.limits.memory.

Rolling-Update blockiert im Status 'Pending'

Neue Pods können nicht geschedult werden, weil die Ressourcen-Requests (resources.requests) die verfügbare Kapazität der Worker-Knoten übersteigen. Überprüfen Sie die Knotenlast via kubectl describe nodes oder aktivieren Sie den Cluster-Autoscaler.

Fehler bei unveränderlichem Selektor (Selector Immutability)

Kubernetes verbietet das Ändern von spec.selector bei bestehenden Deployments. Löschen Sie das Deployment ohne Pod-Verlust (kubectl delete deploy <name> --cascade=orphan) und rollen Sie das neue Manifest aus.

Häufig gestellte Fragen (FAQ)

Was unterscheidet ein Deployment von einem StatefulSet oder DaemonSet?▼

Ein Deployment verwaltet zustandslose (stateless) Workloads, deren Pods austauschbar auf beliebigen Knoten laufen. StatefulSets bieten stabile Netzwerkidentitäten und persistente Speicherbindung für Datenbanken. DaemonSets stellen sicher, dass auf jedem Cluster-Knoten exakt ein Pod läuft.

Warum ist RollingUpdate gegenüber Recreate die bevorzugte Strategie?▼

RollingUpdate startet neue Pod-Instanzen schrittweise und leitet Traffic erst nach erfolgreicher Readiness um, wodurch Null-Ausfallzeiten garantiert werden. Recreate stoppt alle alten Pods gleichzeitig vor dem Neubeginn, was zwingend zu Downtime führt.

Wie ordnet Kubernetes Pods einem Deployment zu?▼

Über Label-Selektoren (spec.selector.matchLabels). Der Deployment-Controller prüft kontinuierlich, ob die Pod-Labels (spec.template.metadata.labels) übereinstimmen, und gleicht die Anzahl der laufenden Pods mit der gewünschten Replikazahl ab.

Wie ergänzen Pod Disruption Budgets (PDB) ein Deployment?▼

Während das Deployment die gewünschte Replikazahl vorgibt, definiert ein PDB die minimale Anzahl oder den Mindestprozentsatz an Pods, die bei geplanten Wartungsarbeiten (z. B. Node-Drains oder Kubernetes-Upgrades) stets verfügbar bleiben müssen.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →