Dezember 21, 2025
14 Min. Lesezeit

Interviewfragen für Senior DevOps Engineers: Der umfassende Leitfaden

interview
career-advice
job-search
Interviewfragen für Senior DevOps Engineers: Der umfassende Leitfaden
MB

Milad Bonakdar

Autor

Meistern Sie fortgeschrittene DevOps-Konzepte mit umfassenden Interviewfragen zu Kubernetes, Terraform, Cloud-Architektur, GitOps, Sicherheit, SRE-Praktiken und Hochverfügbarkeit für Senior DevOps Engineers.


Einführung

Von erfahrenen DevOps-Ingenieuren wird erwartet, dass sie skalierbare Infrastrukturen entwerfen, fortschrittliche Automatisierung implementieren, Sicherheit und Compliance gewährleisten und die DevOps-Kultur in Unternehmen vorantreiben. Diese Rolle erfordert fundierte Fachkenntnisse in den Bereichen Container-Orchestrierung, Infrastructure as Code, Cloud-Architektur und Site Reliability Engineering.

Dieser umfassende Leitfaden behandelt wichtige Interviewfragen für erfahrene DevOps-Ingenieure mit Schwerpunkt auf fortgeschrittenen Konzepten, Produktionssystemen und strategischem Denken. Jede Frage enthält detaillierte Erklärungen und praktische Beispiele.


Fortgeschrittenes Kubernetes

1. Erläutern Sie die Kubernetes-Architektur und die Rolle der Schlüsselkomponenten.

Antwort: Kubernetes folgt einer Master-Worker-Architektur:

Komponenten der Steuerungsebene:

  • API-Server: Frontend für die Kubernetes-Steuerungsebene, verarbeitet alle REST-Anfragen
  • etcd: Verteiltes Schlüsselwert-Speicher für den Clusterstatus
  • Scheduler: Weist Pods basierend auf Ressourcenanforderungen Knoten zu
  • Controller Manager: Führt Controller-Prozesse aus (Replikation, Endpunkte usw.)
  • Cloud Controller Manager: Integration mit Cloud-Provider-APIs

Knotenkomponenten:

  • kubelet: Agent, der sicherstellt, dass Container in Pods ausgeführt werden
  • kube-proxy: Verwaltet Netzwerkregeln für die Pod-Kommunikation
  • Container Runtime: Führt Container aus (Docker, containerd, CRI-O)
Loading diagram...

Funktionsweise:

  1. Benutzer übermittelt Deployment über kubectl
  2. API-Server validiert und speichert in etcd
  3. Scheduler weist Pods Knoten zu
  4. kubelet auf dem Knoten erstellt Container
  5. kube-proxy konfiguriert die Vernetzung

Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer


2. Wie beheben Sie einen Pod, der in CrashLoopBackOff feststeckt?

Antwort: Systematischer Debugging-Ansatz:

# 1. Pod-Status und Ereignisse prüfen
kubectl describe pod <pod-name>
# Suchen nach: Image-Pull-Fehlern, Ressourcenbeschränkungen, fehlgeschlagenen Integritätsprüfungen

# 2. Protokolle prüfen
kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # Vorherige Container-Protokolle

# 3. Ressourcenbeschränkungen prüfen
kubectl top pod <pod-name>
kubectl describe node <node-name>

# 4. Liveness/Readiness-Probes prüfen
kubectl get pod <pod-name> -o yaml | grep -A 10 livenessProbe

# 5. Exec in Container (wenn er kurzzeitig aktiv bleibt)
kubectl exec -it <pod-name> -- /bin/sh

# 6. Image prüfen
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].image}'
docker pull <image>  # Lokal testen

# 7. ConfigMaps/Secrets prüfen
kubectl get configmap
kubectl get secret

# 8. Deployment-/Pod-Spezifikation überprüfen
kubectl get deployment <deployment-name> -o yaml

Häufige Ursachen:

  • Anwendung stürzt beim Start ab
  • Fehlende Umgebungsvariablen
  • Falsche Liveness-Probe-Konfiguration
  • Unzureichende Ressourcen (OOMKilled)
  • Image-Pull-Fehler
  • Fehlende Abhängigkeiten

Beispielhafte Fehlerbehebung:

# Ressourcenbeschränkungen erhöhen
resources:
  limits:
    memory: "512Mi"
    cpu: "500m"
  requests:
    memory: "256Mi"
    cpu: "250m"

# Probe-Timing anpassen
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # App Zeit zum Start geben
  periodSeconds: 10
  failureThreshold: 3

Seltenheit: Sehr häufig Schwierigkeitsgrad: Mittel


3. Erläutern Sie die Kubernetes-Vernetzung: Services, Ingress und Netzwerkrichtlinien.

Antwort: Kubernetes-Netzwerkschichten:

Services: Arten der Service-Exponierung:

# ClusterIP (nur intern)
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

# NodePort (externer Zugriff über Knoten-IP)
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

# LoadBalancer (Cloud Load Balancer)
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

Ingress: HTTP/HTTPS-Routing:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls

Netzwerkrichtlinien: Steuern der Pod-zu-Pod-Kommunikation:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer


4. Wie implementieren Sie Autoscaling in Kubernetes?

Antwort: Mehrere Autoscaling-Strategien:

Horizontal Pod Autoscaler (HPA):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

Vertical Pod Autoscaler (VPA):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: "Auto"  # or "Recreate", "Initial", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2
        memory: 2Gi

Cluster Autoscaler: Passt die Clustergröße automatisch basierend auf ausstehenden Pods an:

# AWS-Beispiel
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  min-nodes: "2"
  max-nodes: "10"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"

Seltenheit: Häufig Schwierigkeitsgrad: Mittel


Fortgeschrittenes Terraform

5. Erläutern Sie das Terraform-State-Management und die Best Practices.

Antwort: Terraform-State verfolgt die Infrastruktur und ist entscheidend für den Betrieb.

Remote-State-Konfiguration:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

State-Locking:

# DynamoDB-Tabelle für State-Locking
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

Bewährte Verfahren:

1. Niemals State-Dateien in Git committen

# .gitignore
*.tfstate
*.tfstate.*
.terraform/

2. Workspaces für Umgebungen verwenden

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

terraform workspace select dev
terraform apply

3. Vorhandene Ressourcen importieren

# Vorhandene EC2-Instanz importieren
terraform import aws_instance.web i-1234567890abcdef0

# Verifizieren
terraform plan

4. State-Manipulation (vorsichtig verwenden)

# Ressourcen im State auflisten
terraform state list

# Spezifische Ressource anzeigen
terraform state show aws_instance.web

# Ressource im State verschieben
terraform state mv aws_instance.old aws_instance.new

# Ressource aus dem State entfernen (nicht löschen)
terraform state rm aws_instance.web

5. State vor größeren Änderungen sichern

terraform state pull > backup.tfstate

Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer


6. Wie strukturieren Sie Terraform-Code für große Projekte?

Antwort: Modulare Struktur für Wartbarkeit:

Verzeichnisstruktur:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── eks/
│   ├── rds/
│   └── s3/
└── global/
    ├── iam/
    └── route53/

Modulbeispiel:

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-vpc"
    }
  )
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.environment}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# modules/vpc/variables.tf
variable "vpc_cidr" {
  description = "CIDR-Block für VPC"
  type        = string
}

variable "environment" {
  description = "Umgebungsname"
  type        = string
}

variable "private_subnet_cidrs" {
  description = "CIDR-Blöcke für private Subnetze"
  type        = list(string)
}

variable "availability_zones" {
  description = "Verfügbarkeitszonen"
  type        = list(string)
}

variable "tags" {
  description = "Allgemeine Tags"
  type        = map(string)
  default     = {}
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Verwendung von Modulen:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr             = "10.0.0.0/16"
  environment          = "prod"
  private_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  availability_zones   = ["us-east-1a", "us-east-1b", "us-east-1c"]

  tags = {
    Project   = "MyApp"
    ManagedBy = "Terraform"
  }
}

module "eks" {
  source = "../../modules/eks"

  cluster_name    = "prod-cluster"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnet_ids
  node_group_size = 3
}

Seltenheit: Häufig Schwierigkeitsgrad: Schwer


Cloud-Architektur

7. Entwerfen Sie eine hochverfügbare Multi-Region-Architektur auf AWS.

Antwort: Multi-Region-Architektur für hohe Verfügbarkeit:

Loading diagram...

Schlüsselkomponenten:

1. DNS und Traffic-Management:

# Route 53 mit Integritätsprüfungen
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

2. Datenbankreplikation:

# RDS mit Cross-Region-Lesereplikat
resource "aws_db_instance" "primary" {
  identifier           = "prod-db-primary"
  engine               = "postgres"
  instance_class       = "db.r5.xlarge"
  multi_az             = true
  backup_retention_period = 7

  provider = aws.us-east-1
}

resource "aws_db_instance" "replica" {
  identifier             = "prod-db-replica"
  replicate_source_db    = aws_db_instance.primary.arn
  instance_class         = "db.r5.xlarge"
  auto_minor_version_upgrade = false

  provider = aws.us-west-2
}

3. Datenreplikation:

# S3 Cross-Region-Replikation
resource "aws_s3_bucket_replication_configuration" "replication" {
  bucket = aws_s3_bucket.source.id
  role   = aws_iam_role.replication.arn

  rule {
    id     = "replicate-all"
    status = "Enabled"

    destination {
      bucket        = aws_s3_bucket.destination.arn
      storage_class = "STANDARD"
    }
  }
}

Designprinzipien:

  • Aktiv-Aktiv- oder Aktiv-Passiv-Setup
  • Automatisches Failover mit Integritätsprüfungen
  • Datenreplikation mit minimaler Verzögerung
  • Konsistentes Deployment über Regionen hinweg
  • Überwachung und Alarmierung für beide Regionen

Seltenheit: Häufig Schwierigkeitsgrad: Schwer


GitOps & CI/CD

8. Erläutern Sie GitOps und wie man es mit ArgoCD implementiert.

Antwort: GitOps verwendet Git als Single Source of Truth für deklarative Infrastruktur und Anwendungen.

Prinzipien:

  1. Deklarative Konfiguration in Git
  2. Automatisierte Synchronisation
  3. Versionskontrolle für alle Änderungen
  4. Kontinuierliche Abstimmung

ArgoCD-Implementierung:

# Anwendungsmanifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/app-manifests
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
    - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Verzeichnisstruktur:

app-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patches/
    ├── staging/
    └── production/
        ├── kustomization.yaml
        ├── replicas.yaml
        └── resources.yaml

Kustomization:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- ../../base

replicas:
- name: myapp
  count: 5

resources:
- ingress.yaml

patches:
- path: resources.yaml
  target:
    kind: Deployment
    name: myapp

Vorteile:

  • Git als Audit-Trail
  • Einfache Rollbacks (git revert)
  • Deklarativer Soll-Zustand
  • Automatisierte Drift-Erkennung
  • Multi-Cluster-Management

Seltenheit: Häufig Schwierigkeitsgrad: Mittel


Sicherheit & Compliance

9. Wie implementieren Sie Sicherheitsbest Practices in Kubernetes?

Antwort: Mehrschichtiger Sicherheitsansatz:

1. Pod-Sicherheitsstandards:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. RBAC (Role-Based Access Control):

# Rolle für Entwickler
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: production
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

3. Netzwerkrichtlinien:

# Standardmäßig alle Ingress verweigern
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

4. Geheimnismanagement:

# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
    creationPolicy: Owner
  data:
  - secretKey: database-password
    remoteRef:
      key: prod/database
      property: password

5. Sicherheitskontext:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}

6. Image-Scanning:

# Admission Controller mit OPA
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: |
    package kubernetes.admission
    
    deny[msg] {
      input.request.kind.kind == "Pod"
      image := input.request.object.spec.containers[_].image
      not startswith(image, "registry.company.com/")
      msg := sprintf("Image %v ist nicht aus der genehmigten Registry", [image])
    }

Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer


Observability & SRE

10. Entwerfen Sie einen umfassenden Observability-Stack.

Antwort: Drei Säulen der Observability: Metriken, Protokolle, Traces

Architektur:

Loading diagram...

1. Metriken (Prometheus + Grafana):

# ServiceMonitor für App-Metriken
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

2. Protokollierung (Loki):

# Promtail-Konfiguration für die Protokollerfassung
apiVersion: v1
kind: ConfigMap
metadata:
  name: promtail-config
data:
  promtail.yaml: |
    server:
      http_listen_port: 9080
    
    clients:
      - url: http://loki:3100/loki/api/v1/push
    
    scrape_configs:
      - job_name: kubernetes-pods
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_label_app]
            target_label: app
          - source_labels: [__meta_kubernetes_namespace]
            target_label: namespace

3. Tracing (Jaeger):

# Anwendungsinstrumentierung
from opentelemetry import trace
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Tracing einrichten
trace.set_tracer_provider(TracerProvider())
jaeger_exporter = JaegerExporter(
    agent_host_name="jaeger-agent",
    agent_port=6831,
)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(jaeger_exporter)
)

tracer = trace.get_tracer(__name__)

# Im Code verwenden
with tracer.start_as_current_span("process_request"):
    # Ihr Code hier
    pass

4. Alarmierungsregeln:

# PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
spec:
  groups:
  - name: app
    interval: 30s
    rules:
    - alert: HighErrorRate
      expr: |
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
        > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Hohe Fehlerrate erkannt"
        description: "Die Fehlerrate beträgt {{ $value | humanizePercentage }}"
    
    - alert: HighLatency
      expr: |
        histogram_quantile(0.95,
          rate(http_request_duration_seconds_bucket[5m])
        ) > 1
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Hohe Latenz erkannt"

5. SLO-Überwachung:

# SLO-Definition
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: api-availability
spec:
  service: "api"
  labels:
    team: "platform"
  slos:
    - name: "requests-availability"
      objective: 99.9
      description: "API-Anfragen sollten erfolgreich sein"
      sli:
        events:
          errorQuery: sum(rate(http_requests_total{status=~"5.."}[{{.window}}]))
          totalQuery: sum(rate(http_requests_total[{{.window}}]))
      alerting:
        pageAlert:
          labels:
            severity: critical
        ticketAlert:
          labels:
            severity: warning

Seltenheit: Häufig Schwierigkeitsgrad: Schwer


Disaster Recovery

11. Wie implementieren Sie Disaster Recovery für einen Kubernetes-Cluster?

Antwort: Umfassende DR-Strategie:

1. Backup-Strategie:

# Velero-Backup-Zeitplan
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"  # 2 Uhr täglich
  template:
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    storageLocation: aws-s3
    volumeSnapshotLocations:
    - aws-ebs
    ttl: 720h  # 30 Tage

2. etcd-Backup:

#!/bin/bash
# Automatisiertes etcd-Backup-Skript

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# In S3 hochladen
aws s3 cp /backup/etcd-snapshot-*.db s3://etcd-backups/

# Alte Backups bereinigen
find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete

3. Wiederherstellungsprozedur:

# etcd aus Snapshot wiederherstellen
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
  --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-0=https://10.0.1.10:2380 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Anwendung mit Velero wiederherstellen
velero restore create --from-backup daily-backup-20231125
velero restore describe <restore-name>

4. Multi-Region-Failover:

# Terraform für Multi-Region-Setup
module "primary_cluster" {
  source = "./modules/eks"
  region = "us-east-1"
  # ... Konfiguration
}

module "dr_cluster" {
  source = "./modules/eks"
  region = "us-west-2"
  # ... Konfiguration
}

# Route 53 Integritätsprüfung und Failover
resource "aws_route53_health_check" "primary" {
  fqdn              = module.primary_cluster.endpoint
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
}

5. RTO/RPO-Ziele:

  • RTO (Recovery Time Objective): < 1 Stunde
  • RPO (Recovery Point Objective): < 15 Minuten
  • Regelmäßige DR-Übungen (monatlich)
  • Dokumentierte Runbooks
  • Automatisches Failover, wo möglich

Seltenheit: Häufig Schwierigkeitsgrad: Schwer


Service Mesh

12. Erläutern Sie die Service-Mesh-Architektur und wann sie verwendet werden sollte.

Antwort: Ein Service Mesh bietet eine Infrastrukturschicht für die Service-zu-Service-Kommunikation.

Kernkomponenten:

Loading diagram...

Istio-Implementierung:

# Virtual Service für Traffic-Routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20

# Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
  subsets:
  - name: v1
    labels:
      version
Newsletter subscription

Wöchentliche Karrieretipps, die wirklich funktionieren

Erhalten Sie die neuesten Einblicke direkt in Ihr Postfach

Decorative doodle

Ihr nächstes Vorstellungsgespräch ist nur einen Lebenslauf entfernt

Erstellen Sie in wenigen Minuten einen professionellen, optimierten Lebenslauf. Keine Designkenntnisse erforderlich—nur bewährte Ergebnisse.

Meinen Lebenslauf erstellen

Diesen Beitrag teilen

Verdoppeln Sie Ihre Vorstellungsgespräch-Rückrufe

Kandidaten, die ihre Lebensläufe auf die Stellenbeschreibung zuschneiden, erhalten 2,5-mal mehr Vorstellungsgespräche. Nutzen Sie unsere KI, um Ihren Lebenslauf sofort für jede Bewerbung anzupassen.