YAML für Kubernetes: Wesentliche Manifest-Muster

Kubernetes wird vollständig über YAML-Manifeste konfiguriert. Jeder Pod, jedes Deployment, jeder Service und jedes Ingress wird in YAML definiert. Das Beherrschen dieser Muster ist für jeden unerlässlich, der mit Container-Orchestrierung arbeitet. Dieser Leitfaden behandelt die wichtigsten Ressourcentypen mit produktionsreifen Beispielen.

Die vier Pflichtfelder

Jedes Kubernetes-Manifest benötigt:

apiVersion: apps/v1      # API-Version für diesen Ressourcentyp
kind: Deployment          # Ressourcentyp
metadata:                 # Ressourcen-Identifikation
  name: my-app
  namespace: production
  labels:
    app: my-app
spec:                     # Gewünschte Zustandsspezifikation
  # ... ressourcentypspezifische Konfiguration

Deployment

Die häufigste Ressource — verwaltet eine Gruppe identischer Pods:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api-server
    environment: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: myapp/api:v1.2.3
          ports:
            - containerPort: 8080
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Wichtige Muster

Immer Ressourcenanforderungen und -limits setzen: Ohne sie kann ein einzelner Pod alle Knotenressourcen verbrauchen.

Immer Health Probes konfigurieren:

livenessProbe: Den Pod neu starten, wenn er nicht mehr reagiert
readinessProbe: Keinen Traffic senden, bis der Pod bereit ist

Spezifische Image-Tags verwenden: Verwenden Sie niemals latest in der Produktion — es macht Rollbacks unmöglich.

Service

Macht Pods für Netzwerkverkehr zugänglich:

apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  type: ClusterIP
  selector:
    app: api-server
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP

Service-Typen:

ClusterIP (Standard): Nur interner Cluster-Zugriff
NodePort: Auf jeder Knoten-IP an einem statischen Port erreichbar
LoadBalancer: Erstellt einen Cloud-Load-Balancer
ExternalName: Verweist auf einen DNS-Namen

ConfigMap und Secret

ConfigMap (nicht-sensible Daten)

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
  config.yaml: |
    server:
      port: 8080
      timeout: 30s

Secret (sensible Daten)

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  url: "postgres://user:password@db:5432/myapp"
  api-key: "sk-1234567890"

Verwendung in Pods

# Als Umgebungsvariablen
env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: LOG_LEVEL

# Als eingehängte Datei
volumes:
  - name: config
    configMap:
      name: app-config

Ingress

Leitet externen HTTP-Traffic an Services weiter:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: tls-secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-server
                port:
                  number: 80

Horizontal Pod Autoscaler

Pods basierend auf CPU oder benutzerdefinierten Metriken skalieren:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Häufige Fehler

1. Einrückungsfehler

YAML-Einrückung ist in Kubernetes kritisch. Ein falsch platziertes Leerzeichen ändert die gesamte Struktur. Validieren Sie Ihre Manifeste mit unserem YAML Validator.

2. Label-Unstimmigkeiten

Der Service-Selektor muss exakt mit den Pod-Labels übereinstimmen. Eine Unstimmigkeit bedeutet, dass der Service keine Pods findet, an die er Traffic weiterleiten kann.

3. Fehlende Ressourcenlimits

Pods ohne Ressourcenlimits können andere Workloads aushungern. Schließen Sie immer sowohl Requests (garantiertes Minimum) als auch Limits (erlaubtes Maximum) ein.

4. Veränderliche Image-Tags

Die Verwendung von latest oder anderen veränderlichen Tags macht Rollbacks unmöglich und Deployments unvorhersehbar. Fixieren Sie auf bestimmte Versionen oder verwenden Sie unveränderliche Digests.

Multi-Dokument-Manifeste

Verwandte Ressourcen in einer Datei kombinieren, mit --- als Dokumenttrenner:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  # ... Deployment-Spezifikation
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  # ... Service-Spezifikation

Mehr über YAML-Syntaxmuster erfahren Sie in unserem YAML-Syntax-Tutorial.

FAQ

Sollte ich Kubernetes-YAML manuell schreiben oder Generatoren verwenden?

Beginnen Sie damit, YAML manuell zu schreiben, um die Struktur zu verstehen. Für die Produktion verwenden Sie Werkzeuge wie Helm (Template-basierte Manifeste), Kustomize (Overlay-basierte Anpassung) oder CDK8s (Code-basierte Generierung). Diese Werkzeuge reduzieren Wiederholungen und ermöglichen umgebungsspezifische Konfigurationen, ohne Manifeste zu duplizieren.

Wie debugge ich Kubernetes-YAML-Fehler?

Verwenden Sie kubectl apply --dry-run=client -f manifest.yaml zur Validierung ohne Anwendung. Für Syntaxfehler zeigt kubectl explain deployment.spec.template.spec.containers die erwartete Struktur. Die Werkzeuge kubeval und kubeconform validieren gegen Kubernetes-API-Schemas vor dem Deployment.