DevOps & Cloud

Mikroservice-Architektur mit Kubernetes: Pod, Service & Deployment

15 Min. Lesezeit17. März 2026
Kubernetes rehberiKubernetes tutorialMikroservisMicroservicesKubernetes podKubernetes deploymentKubernetes serviceHelm chartContainer orchestrationKubernetes .NET

Kubernetes (K8s) ist eine Open-Source-Plattform, die zum De-facto-Standard fuer Container-Orchestrierung geworden ist. Sie automatisiert Deployment, Skalierung und Verwaltung von Anwendungen in Microservice-Architekturen. In diesem Artikel untersuche ich die Kernkomponenten von Kubernetes, Deployment-Strategien und Paketverwaltung mit Helm.

Kubernetes Kernkomponenten

Pod: Die kleinste Deployment-Einheit

Ein Pod ist die kleinste und grundlegendste Einheit in Kubernetes. Er enthaelt einen oder mehrere Container, gemeinsamen Speicher und Netzwerkressourcen.

yaml
# pod.yaml - Grundlegende Pod-Definition
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: myapi
    environment: production
spec:
  containers:
    - name: api
      image: ghcr.io/myorg/myapi:1.0.0
      ports:
        - containerPort: 8080
      env:
        - name: ASPNETCORE_ENVIRONMENT
          value: "Production"
        - name: ConnectionStrings__DefaultConnection
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"
      livenessProbe:
        httpGet:
          path: /health/live
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20
      readinessProbe:
        httpGet:
          path: /health/ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
  restartPolicy: Always

Deployment: Deklarative Update-Verwaltung

Ein Deployment definiert den gewuenschten Zustand von Pods und verwaltet Update-Strategien mit Rolling Updates fuer Zero-Downtime-Deployments.

yaml
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapi-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapi
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: myapi
    spec:
      containers:
        - name: api
          image: ghcr.io/myorg/myapi:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: myapi-service
spec:
  selector:
    app: myapi
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapi-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-cert
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapi-service
                port:
                  number: 80

ConfigMap und Secret-Verwaltung

Die Trennung von Anwendungskonfiguration und sensiblen Daten vom Container-Image ist ein Kernprinzip von Kubernetes:

yaml
# configmap.yaml - Anwendungskonfiguration
apiVersion: v1
kind: ConfigMap
metadata:
  name: myapi-config
  namespace: production
data:
  ASPNETCORE_ENVIRONMENT: "Production"
  Logging__LogLevel__Default: "Information"
  Cache__DefaultExpirationMinutes: "30"
---
# secret.yaml - Sensible Daten
apiVersion: v1
kind: Secret
metadata:
  name: myapi-secrets
  namespace: production
type: Opaque
data:
  ConnectionStrings__DefaultConnection: SG9zdD1wb3N0Z3Jlczt...
  Redis__ConnectionString: cmVkaXM6NjM3OQ==

Fuer eine professionelle Secret-Verwaltung empfehle ich External Secrets Operator mit Vault-Integration, um Secrets zentral und sicher zu verwalten.

PersistentVolumeClaim fuer Datenpersistenz

Fuer zustandsbehaftete Anwendungen wie Datenbanken verwenden Sie PersistentVolumeClaim:

yaml
# StatefulSet mit persistentem Speicher
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
          resources:
            requests:
              cpu: "500m"
              memory: "1Gi"
  volumeClaimTemplates:
    - metadata:
        name: postgres-storage
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: gp3
        resources:
          requests:
            storage: 50Gi

Namespace-Verwaltung und Isolation

Namespaces trennen Cluster-Ressourcen logisch und bieten Isolation fuer verschiedene Umgebungen:

bash
# Namespaces erstellen
kubectl create namespace production
kubectl create namespace staging

# Ressourcenkontingente pro Namespace
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    pods: "50"
EOF

Mit ResourceQuota koennen Sie die verfuegbaren Ressourcen pro Namespace begrenzen und mit NetworkPolicy den Netzwerkverkehr zwischen Namespaces steuern.

Monitoring mit Prometheus

Prometheus ist die Standardloesung fuer Metrikerfassung und Ueberwachung in Kubernetes:

yaml
# servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapi-monitor
  namespace: production
spec:
  selector:
    matchLabels:
      app: myapi
  endpoints:
    - port: http
      path: /metrics
      interval: 30s
---
# Alarmregeln
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: myapi-alerts
spec:
  groups:
    - name: myapi.rules
      rules:
        - alert: HighErrorRate
          expr: |
            rate(http_requests_total{status=~"5..", app="myapi"}[5m])
            / rate(http_requests_total{app="myapi"}[5m]) > 0.05
          for: 5m
          labels:
            severity: critical

Die Kombination aus Prometheus und Grafana ermoeglicht die Visualisierung von CPU, Speicher, HTTP-Anfragen, Fehlerraten und Antwortzeiten.

Helm Paketverwaltung

Helm ist ein Paketmanager fuer Kubernetes-Anwendungen.

yaml
# values.yaml
replicaCount: 3

image:
  repository: ghcr.io/myorg/myapi
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilization: 70
bash
# Chart installieren
helm install myapi ./charts/myapi -f values-production.yaml -n production

# Aktualisieren
helm upgrade myapi ./charts/myapi -f values-production.yaml -n production

# Rollback
helm rollback myapi 1 -n production

Microservice-Kommunikationsmuster

  • ClusterIP Service: Synchrone HTTP/gRPC-Kommunikation innerhalb des Clusters
  • Headless Service: DNS-basierte Loesung fuer Service Discovery
  • Service Mesh (Istio/Linkerd): mTLS, Traffic-Management, Observability
  • Message Queue: Asynchrone Kommunikation mit RabbitMQ oder Kafka

Praktische Tipps

  1. Ressourcenlimits: CPU- und Speicherlimits fuer jeden Container definieren
  2. Health Probes: Liveness-, Readiness- und Startup-Probes korrekt konfigurieren
  3. Pod Anti-Affinity: Pods auf verschiedene Nodes verteilen
  4. Namespace-Isolation: Umgebungen mit Namespaces trennen
  5. GitOps: Deklaratives Deployment-Management mit ArgoCD oder Flux

Bei korrekter Konfiguration loest Kubernetes die Skalierungs-, Zuverlaessigkeits- und Verwaltungsherausforderungen von Microservice-Architekturen weitgehend. Klein anfangen und nach Bedarf skalieren ist der gesuendeste Ansatz.

Verwandte Artikel

Microservices-Architektur mit .NET: Design und Umsetzung

Entwerfen Sie Microservices-Architektur mit .NET. Service-Kommunikation und Orchestrierung.

Docker Container Leitfaden: Dockerfile, Compose & Multi-Stage Builds

Docker Containerisierung Leitfaden. Dockerfiles schreiben, Multi-Service Docker Compose, Multi-Stage Build Optimierung und Production Deployment.

CI/CD Pipeline: Automatisierte Tests & Deployment mit GitHub Actions

CI/CD Pipeline Einrichtung mit GitHub Actions. Automatisierte Tests, Builds, Docker Image Erstellung und AWS Deployment.

Haben Sie ein Flutter-Projekt?

Ich entwickle hochleistungsfähige Flutter-Anwendungen für iOS, Android und Web.

Kontakt aufnehmen