Die 44 besten Kubernetes-Interview-Fragen und Antworten im Jahr 2025

Grundlegende Kubernetes Interview Fragen

Beginnen wir nun mit grundlegenden Kubernetes-Interviewfragen. Diese Fragen decken die grundlegenden Kenntnisse ab, die du brauchst, um Kubernetes zu verstehen und damit zu arbeiten. 

Was ist ein Pod in Kubernetes?

Ein Pod ist die kleinste einsetzbare Einheit in Kubernetes. Er repräsentiert einen oder mehrere Container, die in einer gemeinsamen Umgebung laufen. Die Container innerhalb eines Pods teilen sich Netzwerk- und Speicherressourcen.

Hier ist eine einfache YAML-Datei für eine Pod-Definition:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Was ist der Zweck von kubectl?

Kubectl ist das wichtigste CLI-Tool für die Verwaltung von Kubernetes-Ressourcen und die Interaktion mit dem Cluster. Hier sind einige gängige kubectl-Befehle, mit denen du vertraut sein solltest:

kubectl get pods 				 # list all Pods
kubectl get services 			 # list all Services
kubectl logs <pod-name> 	  	 # view logs of a Pod
kubectl exec -it <pod-name> – /bin/sh # open a shell inside a Pod

Was ist ein Deployment in Kubernetes?

Ein Deployment in Kubernetes ist eine übergeordnete Abstraktion, die den Lebenszyklus von Pods verwaltet. Es stellt sicher, dass die gewünschte Anzahl von Replikaten in Betrieb ist und bietet Funktionen wie Rolling Updates, Rollbacks und Selbstheilung. 

So sieht eine einfache YAML-Datei für die Einsatzdefinition aus: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Was ist ein Kubernetes Service und warum wird er benötigt?

Ein Service in Kubernetes stellt eine Gruppe von Pods dar und ermöglicht die Kommunikation zwischen ihnen und mit ihnen. 

Da Pods flüchtig sind, können sich ihre IPs ändern, was bedeutet, dass die Anwendung, die mit den Pods kommuniziert, auch die IP-Adresse ändern muss. Dienste bieten daher einen stabilen Netzwerkendpunkt mit einer festen IP-Adresse.

Eine einfache Service-YAML-Definition:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Der oben genannte Dienst leitet den Verkehr an Pods weiter, die das Label app: my-app haben.

Welche Arten von Diensten sind bei Kubernetes Services verfügbar?

Kubernetes bietet vier Haupttypen von Services, die jeweils einem anderen Netzwerkzweck dienen:

• ClusterIP (default): Ermöglicht die interne Kommunikation von Pods. Nur von innerhalb des Clusters zugänglich.
• NodePort: Dadurch wird der Dienst auf einem statischen Port jedes Knotens zugänglich gemacht, sodass er von außerhalb des Clusters erreichbar ist.
• LoadBalancer: Verwendet den externen Load Balancer eines Cloud-Anbieters. Der Dienst ist dann über eine öffentliche IP erreichbar.
• ExternalName: Ordnet einen Kubernetes-Dienst einem externen Hostnamen zu. 

Was ist die Rolle von ConfigMaps und Secrets in Kubernetes?

ConfigMaps speichert nicht-sensible Konfigurationsdaten, während secrets sensible Daten wie API-Schlüssel und Passwörter speichert.

Durch die Verwendung von Geheimnissen kannst du vermeiden, geheime Informationen in deinen Anwendungscode einzubauen. Im Gegensatz dazu kannst du mit ConfigMaps deine Anwendungen besser konfigurieren, da diese Werte einfach bearbeitet werden können und du sie nicht in deinem Anwendungscode festhalten musst.

Beispiel für eine ConfigMap YAML-Definition:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"

Beispiel für eine geheime YAML-Definition (mit base64-kodierten Daten):

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" encoded in Base64

Was sind Namespaces in Kubernetes?

Ein Namespace ist ein virtueller Cluster innerhalb eines Kubernetes-Clusters. Es hilft bei der Organisation von Workloads in mandantenfähigen Umgebungen, indem es Ressourcen innerhalb eines Clusters isoliert.

Nachfolgend findest du einen kurzen Codeschnipsel, der zeigt, wie du mit kubectl einen Namespace erstellst und wie du Pods in diesem Namespace erstellst und abrufst:

# create a namespace called “dev”
kubectl create namespace dev

# create a Pod in that namespace
kubectl run nginx --image=nginx --namespace=dev

# get Pods in that namespace
kubectl get pods --namespace=dev

Was sind Labels und Selektoren in Kubernetes?

Labels sind Schlüssel/Wertpaare, die an Objekte (z.B. Pods) angehängt werden. Sie helfen dabei, Kubernetes-Objekte zu organisieren. Selektoren filtern Ressourcen auf der Grundlage von Labels. 

Hier ist ein Beispiel für einen Pod, der die Etiketten environment: production und app: nginx hat:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Du könntest nun den folgenden Label-Selektor verwenden, um alle Pods zu finden, denen das Label environment: pod zugewiesen ist:

kubectl get pods -l environment=production

Was sind Persistent Volumes (PVs) und Persistent Volume Claims (PVCs)?

Persistent Volumes (PVs) bieten Speicherplatz, der über den Lebenszyklus des Pods hinaus erhalten bleibt. Der PV ist ein Speicherplatz im Cluster, der von einem Cluster-Administrator bereitgestellt oder dynamisch mit Hilfe von Speicherklassen bereitgestellt wurde.

Ein Persistent Volume Claim (PVC) ist eine Anfrage eines Nutzers nach Speicherplatz. 

Hier ist ein Beispiel für eine PV- und PVC-YAML-Definition: 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Kubernetes-Interview-Fragen für Fortgeschrittene

Jetzt, wo du die Grundlagen geübt hast, können wir zu den Fragen der Mittelstufe übergehen. Das Verständnis von Konzepten wie Netzwerken, Sicherheit, Ressourcenmanagement und Fehlerbehebung ist auf dieser Stufe unerlässlich.

Was ist ein Kubernetes-Netzwerk und wie funktioniert es?

Das Kubernetes-Netzwerk ermöglicht die Kommunikation zwischen Pods, Services und externen Clients. Es folgt einer flachen Netzwerkstruktur, was bedeutet, dass standardmäßig alle Pods miteinander kommunizieren können.  

Zu den wichtigsten Netzwerkkonzepten in Kubernetes gehören:

• Pod-zu-Pod-Kommunikation: Jeder Pod bekommt eine eindeutige IP zugewiesen und kann innerhalb des Clusters kommunizieren. 
• Service-to-Pod-Kommunikation: Dienste bieten einen stabilen Netzwerkendpunkt für eine Gruppe von Pods, da Pods flüchtig sind. Jeder Pod bekommt eine neue IP zugewiesen, wenn er erstellt wird.
• Eindringlingskontrolleure: Verwalte den externen HTTP/HTTPS-Verkehr.
• Netzwerkrichtlinien: Definiere Regeln, um die Kommunikation zwischen Pods einzuschränken oder zu erlauben.

Was ist die rollenbasierte Zugriffskontrolle (RBAC) in Kubernetes?

RBAC ist ein Sicherheitsmechanismus, der Benutzer und Dienste auf der Grundlage ihrer Berechtigungen einschränkt. Es besteht aus:

• Rollen und ClusterRollen: Definiere die erlaubten Aktionen für Ressourcen.
• RoleBindings und ClusterRoleBindings: Weisen Sie Benutzern oder Dienstkonten Rollen zu.

Die folgende YAML zeigt eine Beispielrolle, die nur Lesezugriff auf Pods erlaubt:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Diese pod-reader Rolle kann nun mit RoleBinding an einen Benutzer gebunden werden:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Wie funktioniert die Kubernetes-Autoskalierung?

Kubernetes bietet drei Arten der automatischen Skalierung, um die Ressourcennutzung zu optimieren:

1. Horizontaler Pod Autoscaler (HPA): Passt die Anzahl der Pods anhand der CPU-Auslastung, der Speichernutzung oder benutzerdefinierter Metriken an.
2. Vertikaler Pod-Autoscaler (VPA): Passt die CPU- und Speicheranforderungen für einzelne Pods an.
3. Cluster Autoscaler: Passt die Anzahl der Arbeitsknoten im Cluster je nach Ressourcenbedarf an.

Du kannst eine HPA mit kubectl erstellen:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Der obige Befehl erstellt eine HPA für ein Deployment mit dem Namen nginx und versucht, die durchschnittliche CPU-Auslastung über alle Pods hinweg bei 50% zu halten, mit einer minimalen Anzahl von Replikaten von 1 und einer maximalen Anzahl von Replikaten von 10.

Wie kann man Kubernetes Pods debuggen?

Wenn Pods ausfallen, bietet Kubernetes mehrere Möglichkeiten zur Fehlersuche:

• Verwende kubectl logs, um die Container-Logs auf Fehler zu überprüfen.
• Nutze kubectl describe pod, um Ereignisse und aktuelle Zustandsänderungen zu überprüfen.
• Verwende kubectl exec, um eine interaktive Shell zu öffnen und den Container von innen zu untersuchen.
• Verwende kubectl get pods --field-selector=status.phase=Failed, um alle ausgefallenen Pods aufzulisten.

# get logs of a specific Pod
kubectl get logs <pod-name>

# describe the Pod and check events
kubectl describe pod <pod-name>

# open an interactive shell inside the Pod
kubectl exec -it <pod-name> – /bin/sh

# check all failing pods
kubectl get pods --field-selector=status.phase=Failed

Diese Befehle helfen dabei, Fehlkonfigurationen, Ressourcenbeschränkungen oder Anwendungsfehler zu erkennen.

Wie führt man rollende Updates und Rollbacks in Kubernetes durch?

Kubernetes-Einsätze unterstützen rollende Updates, um Ausfallzeiten zu vermeiden. Du kannst ein Rolling Update durchführen, indem du eine Verteilung bearbeitest oder ihr Image explizit auf eine neue Version setzt:

kubectl set image deployment/my-deployment nginx=nginx:1.21

Du kannst dann den Einsatzstatus überprüfen:

kubectl rollout status deployment my-deployment

Wenn du zur vorherigen Version zurückkehren willst, kannst du das tun:

kubectl rollout undo deployment my-deployment

Was ist ein Ingress in Kubernetes, und wie funktioniert er?

Ein Ingress ist ein API-Objekt, das den externen HTTP/HTTPS-Zugriff auf Dienste innerhalb eines Kubernetes-Clusters verwaltet.  Sie ermöglicht die Weiterleitung von Anfragen auf Basis von Hostnamen und Pfaden und fungiert als Reverse Proxy für mehrere Anwendungen.

Beispiel einer Ingress YAML-Definition:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

Wie geht Kubernetes mit Ressourcenlimits und Anfragen um?

Mit Kubernetes kannst du Ressourcenanforderungen und -grenzen für Pods festlegen, um gerechte Zuteilung zu gewährleisten und die Überbeanspruchung von Cluster-Ressourcen zu vermeiden.

• Die Anforderungen sind die Mindestmenge an CPU und Speicher, die ein Pod benötigt. Sie sind dauerhaft einem Pod zugewiesen. 
• Limits sind das Maximum, das ein Pod nutzen kann. Sie werden dem Pod nicht zugewiesen, aber wenn er mehr Ressourcen benötigt, kann er wachsen, bis das Limit erreicht ist.

Beispiel für eine YAML-Pod-Definition, die Ressourcenanforderungen und -grenzen festlegt:

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"

Was passiert, wenn eine Pod-Ressource über die zugewiesenen Grenzen hinaus wachsen muss?

Wenn der Speicherverbrauch eines Pods das ihm zugewiesene Speicherlimit überschreitet, beendetKubernetes den Containersofort mit einem OOM-Fehler (Out of Memory). Der Container wird neu gestartet, wenn eine Neustartrichtlinie definiert ist.

Im Gegensatz zum Speicher wird ein Pod, der das ihm zugewiesene CPU-Limit überschreitet, nicht beendet. Stattdessen drosselt Kubernetes die CPU-Nutzung, wodurch die Anwendung langsamer wird.

Was sind Init-Container und wann solltest du sie verwenden?

Init-Container sind spezielle Container, die laufen, bevor die primären Containerstarten. Sie helfen dabei, die Umgebung vorzubereiten, indem sie Abhängigkeiten prüfen, Konfigurationsdateien laden oder Daten einrichten.

Ein Beispiel könnte ein Init-Container sein, der darauf wartet, dass eine Datenbank in Betrieb genommen wird:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image

Wie geht Kubernetes mit Pod-Unterbrechungen und hoher Verfügbarkeit um?

Kubernetes sorgt für hohe Verfügbarkeit durch Pod Disruption Budgets (PDBs), Anti-Affinitätsregeln und Selbstheilungsmechanismen. So funktionieren diese Mechanismen:

• Pod Disruption Budget (PDB): Stellt sicher, dass eine Mindestanzahl von Pods bei freiwilligen Unterbrechungen verfügbar bleibt (z. B. bei Cluster-Updates, bei denen die Knoten verkleinert werden müssen).
• Pod-Affinität und Anti-Affinität: Steuert, welche Pods zusammen oder getrennt geplant werden können.
• Knotenpunktselektoren und Taints/Toleranzen: Kontrolliere, wie die Arbeitslasten auf die Knotenpunkte verteilt werden.

Hier ist ein Beispiel für eine PDB YAML-Definition, die sicherstellt, dass mindestens zwei Pods während einer Unterbrechung weiterlaufen:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Kubernetes Interview Fragen für Fortgeschrittene

In diesem Abschnitt werden fortgeschrittene Kubernetes-Interviewfragen behandelt, die sich auf Stateful-Anwendungen, Multi-Cluster-Management, Sicherheit, Leistungsoptimierung und Fehlerbehebung konzentrieren. Wenn du dich für eine Führungsposition bewirbst, solltest du dir das unbedingt ansehen.

Was sind StatefulSets, und wie unterscheiden sie sich von Deployments?

Ein StatefulSet wird für zustandsabhängige Anwendungen verwendet , die stabile Netzwerkidentitäten, eine dauerhafte Speicherung und eine geordnete Bereitstellung erfordern. Im Gegensatz zu Deployments stellen StatefulSets sicher, dass:

• Pods haben stabile und eindeutige Netzwerk-Identitäten, wobei Pods Namen wie pod-0, pod-1 usw. haben.
• Pods werden der Reihe nach erstellt, aktualisiert und gelöscht.
• Jeder Pod behält seinen Speicherplatz über Neustarts hinweg bei. Persistente Speicherung wird als Teil der StatefulSet YAML-Definition definiert.

Was ist ein Service Mesh und warum wird es in Kubernetes verwendet?

Ein Dienstnetz verwaltet Dienst-zu-Dienst Kommunikationund bietet:

• Verkehrsmanagement (Lastverteilung, Canary-Einsätze).
• Sicherheit (mTLS-Verschlüsselung zwischen Diensten).
• Beobachtbarkeit (Tracing, Metriken, Logging)

All diese Funktionen sind in der Infrastrukturebene enthalten, sodass keine Änderungen am Code erforderlich sind. 

Beliebte Kubernetes-Service-Mesh-Lösungen sind u. a: Istio, Linkerd und Consul.

Wie kannst du einen Kubernetes-Cluster sichern?

Folge dem 4C-Sicherheitsmodell, um einen Kubernetes-Cluster zu sichern:

1. Sicherheit der Cloud-Anbieter: Verwende IAM-Rollen und Firewall-Regeln.
2. Cluster-Sicherheit: Aktiviere RBAC, Audit-Logs und API-Server-Sicherheit.
3. Container-Sicherheit: Scanne Bilder und verwende Nicht-Root-Benutzer.
4. Code-Sicherheit: Setze die Verwaltung von Geheimnissen um und verwende Netzwerkrichtlinien.

Was sind Taints und Toleranzen in Kubernetes?

Taints und Toleranzen steuern, wo Pods laufen:

• Beflecken: Markiere Knotenpunkte, um Pods abzulehnen.
• Toleranzen: Erlaube Pods, bestimmte Taints zu ignorieren.

Hier ist ein Beispiel dafür, wie du einen Node so einstellst, dass er nur bestimmte Workloads akzeptiert:

kubectl taint nodes node1 key1=value1:NoSchedule

Das bedeutet, dass kein Pod auf node1 geplant werden kann, solange er nicht die erforderliche Duldung hat.

Im Abschnitt PodSpec wird eine Duldung wie die folgende hinzugefügt:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: “value1”
    effect: "NoSchedule"

Der Pod kann auf node1 geplant werden.

Was sind Kubernetes-Sidecar-Container und wie werden sie verwendet?

Ein Sidecar-Container läuft neben dem Hauptanwendungscontainer innerhalb desselben Pods. Es wird üblicherweise verwendet für:

• Logging und Überwachung (z.B. das Sammeln von Protokollen mit Fluentd).
• Sicherheits-Proxys (z.B. mit dem Envoy-Proxy von Istio für Service Mesh).
• Konfigurationsmanagement (z. B. Synchronisierung von Anwendungseinstellungen).

Beispiel für einen Sidecar-Container für die Log-Verarbeitung:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}

Auf dem Sidecar-Container läuft Fluentd, das die Logs des Hauptcontainers über ein Shared Volume sammelt.

Nenne drei typische Ursachen für Pod-Fehler und wie sie behoben werden können.

Pods können stecken bleiben in Anhängig, CrashLoopBackOffoder ImagePullBackOff Zustände:

• Pod steckt fest in Anhängig: Überprüfe die Verfügbarkeit der Knoten und die Ressourcengrenzen. Weitere Informationen findest du bei den Veranstaltungen des Pods.
• CrashLoopBackOff: Untersuche die App-Protokolle und prüfe Fehlkonfigurationen.
• ImagePullBackOff: Achte auf den korrekten Bildnamen und die Zugangsdaten. Auch hier solltest du die Veranstaltungen des Pods für weitere Informationen untersuchen.

Du kannst die Ereignisse des Pods mit dem Befehl describe überprüfen:

kubectl describe pod <pod-name>

Was ist ein Kubernetes Mutating Admission Webhook, und wie funktioniert er?

Ein Mutating Admission Webhook ermöglicht Echtzeitänderungen von Kubernetes-Objekten, bevor sie auf den Cluster angewendet und persistiert werden. Sie betreibt einen dynamischen Admission Controller in Kubernetes, der API-Anfragen abfängt, bevor Objekte in etcd persistiert werden. Er kann die Nutzdaten der Anfrage modifizieren, indem er Felder einfügt, ändert oder entfernt, bevor er die Anfrage weiterleitet.

Sie werden üblicherweise verwendet für:

• Seitenwagen einspritzen.
• Festlegen von Standardwerten für Pods, Einsätze oder andere Ressourcen.
• Durchsetzung von Best Practices (z. B. automatische Zuweisung von Ressourcenlimits).
• Hinzufügen von Sicherheitskonfigurationen (z. B. Kennzeichnungen für den Lernpfad).

Wie kann man Zero-Downtime Deployments in Kubernetes implementieren?

Zero-Downtime-Deployments stellen sicher, dass Updates den Live-Verkehr nicht unterbrechen. Kubernetes erreicht das mit:

• Rolling Updates (Standard, alte Pods werden nach und nach durch neue ersetzt).
• Canary-Einsätze (Tests mit einer Untergruppe von Nutzern).
• Blau-grüne Einsätze (Wechsel zwischen Produktions- und Testumgebungen).

Readiness Probes helfen Kubernetes dabei, zu verhindern, dass Datenverkehr zu nicht bereiten Pods gesendet wird.

Was sind Kubernetes Custom Resource Definitions (CRDs), und wann solltest du sie verwenden?

Eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) erweitert die Kubernetes-APIs und ermöglicht es Nutzern, benutzerdefinierte Ressourcen zu definieren und zu verwalten. Sie werden für bestimmte Anwendungsfälle verwendet, in denen die Kubernetes-API weiterhin für die Verwaltung dieser Ressourcen genutzt werden sollte, z. B:

• Verwalten von benutzerdefinierten Anwendungen (z. B. Modelle für maschinelles Lernen).
• Befähigung von Kubernetes-Betreibern für selbstheilende Anwendungen.

Beispiel CRD YAML Definition:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Du könntest jetzt zum Beispiel das shirt Objekt mit kubectl abrufen:

kubectl get shirts

Indiesem praktischen Tutorial zur Containerisierungerfährst du, wie du Docker und Kubernetes für Workflows zum maschinellen Lernen nutzen kannst.

Was sind Kubernetes-Operatoren und wie funktionieren sie?

Ein Kubernetes-Operator erweitert die Funktionalität von Kubernetes, indem er die Bereitstellung, Skalierung und Verwaltung komplexer Anwendungen automatisiert. Sie wird mit CRDs und benutzerdefinierten Controllern aufgebaut, um anwendungsspezifische Logik zu verarbeiten.

Operatoren arbeiten, indem sie benutzerdefinierte Ressourcen in Kubernetes definieren und auf Veränderungen im Cluster achten, um bestimmte Aufgaben zu automatisieren. 

Dies sind die wichtigsten Komponenten eines Betreibers:

• Benutzerdefinierte Ressourcendefinition (CRD): Definiert eine neue Kubernetes-API-Ressource.
• Benutzerdefinierter Controller: Überwacht das CRD und wendet die Automatisierungslogik auf der Grundlage des gewünschten Zustands an.
• Versöhnungsschleife: Stellt kontinuierlich sicher, dass der Zustand der Anwendung mit dem erwarteten Zustand übereinstimmt.

Kubernetes Interviewfragen für Administratoren

Kubernetes-Administratoren warten, sichern und optimieren Cluster für Produktionsworkloads. In diesem Abschnitt geht es um Kubernetes-Interviewfragen mit Schwerpunkt auf dem Cluster-Management.

Wie kann man einen etcd-Cluster in Kubernetes sichern und wiederherstellen?

Etcd ist der Key-Value-Store, der den gesamten Status des Clusters enthält. Regelmäßige Backups sind wichtig, um Datenverluste zu vermeiden.

Du kannst ein Backup mit dem folgenden Befehl erstellen:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

Wenn du jetzt von einem Backup wiederherstellen willst, kannst du das ausführen:

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

Wie kann man einen Kubernetes-Cluster sicher upgraden?

Das Upgrade eines Kubernetes-Clusters ist ein mehrstufiger Prozess, der nur minimale Ausfallzeiten erfordert und die Stabilität des Clusters erhält. Administratoren sollten einen strukturierten Ansatz verfolgen, um Probleme während des Upgrades zu vermeiden:

1. Entleere und sichere etcd vor dem Upgrade, um sicherzustellen, dass du es wiederherstellen kannst, falls das Upgrade fehlschlägt.
2. Aktualisiere den Knoten der Steuerungsebene.
3. Aktualisiere kubelet und kubectl auf den Knoten der Steuerungsebene.
4. Aktualisiere die Arbeitsknoten einen nach dem anderen. Vor dem Upgrade muss jeder Worker Node entleert werden, um eine Unterbrechung der Arbeitslast zu vermeiden.
5. Upgrade von Cluster-Add-ons (z.B. Ingress-Controller, Monitoring-Tools, ...).

Wie überwacht man einen Kubernetes-Cluster?

Kubernetes-Administratoren müssen den Zustand von CPU, Speicher, Festplatte, Netzwerk und Anwendung überwachen. Die folgenden Werkzeuge werden für diese Aufgaben empfohlen:

• Prometheus + Grafana: Sammle und visualisiere Clustermetriken. Erstelle Echtzeit-Warnungen, um benachrichtigt zu werden, wenn es Probleme gibt.
• Loki + Fluentd: Sammle und analysiere Logs.
• Kubernetes Dashboard: UI-basierte Cluster-Überwachung.
• Jaeger/OpenTelemetry: Verteiltes Tracing.

Wie sichert man einen Kubernetes-Cluster?

Sicherheit ist ein zentraler Aspekt, und jeder Administrator sollte die Best Practices zur Sicherung eines Kubernetes-Clusters befolgen:

• Aktiviere RBAC: Schränke den Benutzerzugang mit Rollen und RoleBindings ein.
• Pod Sicherheitszulassung: Verwende Zutrittskontrollen, um die Pod-Sicherheitsstandards durchzusetzen.
• Enforce NetworkPolicies: Schränke die Pod-Kommunikation ein, da standardmäßig alle Pods miteinander kommunizieren können.
• Wechsle die API-Tokens und Zertifikate regelmäßig.
• Verwende die Verwaltung von Geheimnissen: Verwende Tools wie Vault, AWS Secrets Manager, etc. 

In diesem Leitfaden zur Container-Orchestrierung mit AWS Elastic Kubernetes Service (EKS)erfährst du, wie Kubernetes in der Cloud implementiert wird.

Wie richtest du die Kubernetes-Protokollierung ein?

Die zentrale Protokollierung ist für die Fehlersuche und Prüfung erforderlich. Zwei verschiedene Logging-Stack-Optionen:

• Loki + Fluentd + Grafana (Leichtgewichtig und schnell).
• ELK Stack (Elastic, Logstash, Kibana) (skalierbar und unternehmenstauglich).

Wie implementierst du Hochverfügbarkeit in Kubernetes?

Hochverfügbarkeit ist wichtig, um Ausfälle von Anwendungen zu vermeiden, die in deinem Kubernetes-Cluster laufen. Du kannst eine hohe Verfügbarkeit sicherstellen, indem du:

• Verwendung mehrerer Knotenpunkte der Steuerungsebene. Mehrere API-Server verhindern Ausfallzeiten, wenn einer ausfällt.
• Aktivieren des Cluster-Autoscalers. Dadurch werden je nach Bedarf automatisch Knotenpunkte hinzugefügt oder entfernt.

Wie implementierst du die Mandantenfähigkeit von Kubernetes-Clustern?

Multi-Tenancy ist ziemlich wichtig, wenn du Kubernetes für dein Unternehmen einrichtest. Es ermöglicht mehreren Teams oder Anwendungen, einen Kubernetes-Cluster sicher zu teilen, ohne sich gegenseitig zu stören.

Es gibt zwei Arten der Mehrfachvermietung:

1. Sanfte Mehrmandantenfähigkeit: Verwendet Namespaces, RBAC und NetworkPolicies, um auf der Ebene der Namespaces zu isolieren.
2. Harte Mehrmandantenfähigkeit: Verwendet virtuelle Cluster oder separate Kontrollebenen, um einen physischen Cluster zu isolieren (z. B. KCP).

Wie verschlüsselt man Kubernetes-Geheimnisse in etcd?

Etcd speichert den kompletten Zustand des Clusters, d.h. kritische Informationen werden dort gespeichert. 

Standardmäßigspeichert KubernetesGeheimnisse unverschlüsselt in etcd, was sie anfällig für Kompromisse macht. Daher kann es entscheidend sein, die Verschlüsselung von Geheimnissen bei REST zu aktivieren, damit Geheimnisse gespeichert und verschlüsselt werden.

In einem ersten Schritt musst du eine Konfigurationsdatei für die Verschlüsselung erstellen und einen Verschlüsselungs-/Entschlüsselungsschlüssel in dieser Datei speichern:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}

Die obige Konfiguration legt fest, dass Kubernetes den Anbieter aescbc für die Verschlüsselung von Secret-Ressourcen verwendet, wobei für unverschlüsselte Daten auf identity zurückgegriffen wird.

Als Nächstes musst du die Konfigurationsdatei kube-apiserver anpassen, die du normalerweise unter /etc/kubernetes/manifests/kube-apiserver.yaml auf einem Control Plane Node findest, und das Flag -- encryption-provider-config einfügen, das auf die von dir erstellte Verschlüsselungskonfigurationsdatei verweist:

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml

Speichere die Änderungen und starte die kube-apiserver neu, um die neue Konfiguration anzuwenden.

Wie verwaltet man Kubernetes-Ressourcenkontingente in mandantenfähigen Umgebungen?

Ressourcenkontingente verhindern, dass ein einzelner Tenant (Namespace) zu viele Clusterressourcen verbraucht und andere Tenants bei der Arbeit stört.

Du kannst ResourceQuotas für Namespaces definieren, um dem jeweiligen Namespace eine bestimmte Menge an Ressourcen zuzuweisen. Die Nutzer dieses Namensraums können dann Ressourcen erstellen, die so viele Ressourcen verbrauchen, wie in der ResourceQuota dieses Namensraums festgelegt sind.

Beispiel für eine ResourceQuota YAML-Definition:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Du kannst die ResourceQuota eines Namespaces überprüfen, indem du:

kubectl describe resourcequota namespace-quota -n team-a

Was ist CoreDNS? Wie konfigurierst und verwendest du es?

CoreDNS ist der standardmäßige DNS-Anbieter für Kubernetes-Cluster. Sie ermöglicht die Erkennung von Diensten und erlaubt es Pods, über interne DNS-Namen statt über IP-Adressen zu kommunizieren.

Merkmale von CoreDNS:

• Verwaltet die interne DNS-Auflösung (my-service.default.svc.cluster.local).
• Unterstützt die benutzerdefinierte DNS-Konfiguration.
• Verteilt die Last der DNS-Anfragen auf mehrere Pods.
• Ermöglicht das Zwischenspeichern für eine bessere Leistung.

Du kannst CoreDNS mit der ConfigMap konfigurieren, die im Namespace kube-system gespeichert ist. Du kannst die aktuellen Einstellungen mit anzeigen:

kubectl get configmap coredns -n kube-system -o yaml

Aktualisiere einfach diese ConfigMap und wende die Änderungen an, um die CoreDNS-Konfiguration anzupassen.

Szenariobasierte und problemlösende Kubernetes-Interview-Fragen

Ingenieure stehen in realen Kubernetes-Umgebungen regelmäßig vor komplexen Herausforderungen in den Bereichen Skalierbarkeit, Netzwerk, Sicherheit, Leistung und Fehlerbehebung, und die Interviewer wissen das. In diesem Abschnitt werden szenariobasierte Interviewfragen vorgestellt, die deine Fähigkeit testen, praktische Kubernetes-Probleme zu lösen.

Debugging einer langsamen Kubernetes-Anwendung

"Dein Team berichtet, dass eine Anwendung, die in Kubernetes läuft, langsam geworden ist und die Nutzer/innen hohe Antwortzeitenerleben . Wie löst man dieses Problem?"

Du kannst das Problem mit den folgenden Schritten angehen:

1. Prüfe die Auslastung der Pod-Ressourcen. Erhöhe die Ressourcen, wenn sie an ihre Grenzen stoßen.

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

2. Beschreibe den langsamen Pod, um mehr Informationen zu erhalten. Achte auf die Drosselung von Ressourcen, die Anzahl der Neustarts oder das Versagen von Liveness-Tests.

kubectl describe pod <pod-name>

3. Überprüfe die Containerprotokolle auf Fehler. Achte auf Zeitüberschreitungen, Fehler oder Verbindungsabbrüche.

kubectl logs <pod-name>

4. Teste die Netzwerklatenz, da sie die Anwendungen verlangsamen kann.

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service

5. Überprüfe den Zustand der Kubernetes-Knoten und prüfe, ob die Ressourcen auf den Knoten erschöpft sind.

kubectl get nodes
kubectl describe node <node-name>

Ein Nginx-Webserver läuft, aber die angezeigte URL kann keine Verbindung herstellen

"Du hast einen Nginx-Webserver in Kubernetes implementiert, und der Pod läuft einwandfrei, aber die Anwendung ist nicht über die exponierte URLerreichbar. Was kannst du dagegen tun?"

Schritte zur Lösung des obigen Problems:

1. Überprüfe, ob der Nginx Pod läuft und in Ordnung ist.

kubectl get pods -o wide
kubectl describe pod nginx-web

2. Überprüfe die Dienst- und Portzuordnung. Vergewissere dich, dass der richtige Port freigelegt ist und mit dem Container-Port des Pods übereinstimmt. Prüfe, ob der Dienst die richtigen Pods findet.

kubectl describe service nginx-service

3. Überprüfe die Netzwerkrichtlinien. Wenn eine Netzwerkrichtlinie den eingehenden Verkehr blockiert, ist der Dienst nicht erreichbar.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

4. Überprüfe die Ingress- und externe DNS-Konfiguration.

kubectl describe ingress nginx-ingress

Kubernetes-Bereitstellung schlägt nach einem Upgrade fehl

"Du hast eine neue Version deiner Anwendung bereitgestellt, aber sie lässt sich nicht starten, was zu Ausfallzeiten für deine Nutzer führt. Wie kannst du das Problem lösen?"

Ansatz, um das Problem anzugehen:

1. Gehe zurück zur vorherigen Arbeitsversion.

kubectl rollout undo deployment my-app

2. Überprüfe den Einsatzverlauf und finde heraus, was sich in der neuen Version geändert hat.

kubectl rollout history deployment my-app

3. Überprüfe die Logs des neuen Pods auf Fehler.

kubectl logs -l app=my-app

4. Überprüfe die Bereitschafts- und Aktivitätssonden.

5. Überprüfe, ob es Probleme mit dem Ziehen von Bildern gibt. Manchmal ist das neue Bild falsch oder nicht verfügbar.

Die Anwendung kann sich nicht mit einer externen Datenbank verbinden

"Ein in Kubernetes laufender Microservice kann sich nicht mit einer externen Datenbankverbinden, die außerhalb des Clusters gehostet wird. Wie kannst du das Problem beheben?"

Schritte zur Lösung des Problems:

1. Überprüfe die externe Konnektivität von einem Pod aus. Überprüfe, ob die Datenbank über das Kubernetes-Netzwerk erreichbar ist.

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432

2. Überprüfe die DNS-Auflösung innerhalb des Pods. Wenn er fehlschlägt, ist CoreDNS möglicherweise falsch konfiguriert.

kubectl exec -it <pod-name> -- nslookup my-database.example.com

3. Prüfe, ob es Netzwerkrichtlinien gibt, die den externen Zugriff blockieren, da sie den ausgehenden Datenverkehr verhindern können.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

Die Cluster-Ressourcen sind erschöpft, so dass neue Pods in einem ausstehenden Status verbleiben

"Neue Schoten bleiben in dem Zustand bis. Wenn wir uns die Pods genauer ansehen, sehen wir, dass die Meldung "0/3 Nodes sind verfügbar: nicht genügend CPU und Speicher" erscheint. Wie gehst du bei der Fehlersuche vor und löst das Problem?"

Schritte zur Lösung des Problems:

1. Prüfe die Verfügbarkeit von Cluster-Ressourcen. Achte auf eine hohe CPU-/Speichernutzung, die eine Planung verhindert.

kubectl describe node <node-name>
kubectl top nodes

2. Prüfe, welche Pods die meisten Ressourcen verbrauchen. Lege Ressourcen und Grenzen für Pods fest, um sicherzustellen, dass sie nicht zu viel verbrauchen. Du kannst das auch für alle Namespaces im Cluster erzwingen.

kubectl top pods --all-namespaces

3. Reduziere unwichtige Arbeitslasten, um Ressourcen freizusetzen.

kubectl scale deployment <deployment-name> --replicas=0

4. Erhöhe die Anzahl der verfügbaren Knoten, um die Cluster-Ressourcen zu erhöhen. Du kannst auch weitere Knoten zum Cluster-Autoscaler hinzufügen, wenn einer verwendet wird.

Tipps zur Vorbereitung auf ein Kubernetes-Interview

Durch meine eigenen Erfahrungen mit Kubernetes-Interviews habe ich gelernt, dass es für den Erfolg mehr braucht als nur das Auswendiglernen von Konzepten. Du musst dein Wissen in realen Szenarien anwenden, Fehler effizient beheben und deine Lösungen klar erklären.

Wenn du bei Kubernetes-Interviews erfolgreich sein willst, befolge die folgenden Tipps:

1. Beherrsche die wichtigsten Kubernetes-Konzepte. Stelle sicher, dass du Pods, Deployments, Services, Persistent Volumes, ConfigMaps, Secrets usw. verstehst.
2. Mach praktische Erfahrungen mit Kubernetes. Als ich mich auf meine Vorstellungsgespräche vorbereitete, fand ich, dass das Einrichten meines eigenen Minikube-Clusters und das Bereitstellen von Microservices dazu beitrug, mein Verständnis zu vertiefen. Du kannst auch einen verwalteten Kubernetes-Dienst eines Cloud-Anbieters nutzen, um in großem Maßstab zu üben.
3. Lerne, wie du Kubernetes-Probleme debuggen kannst, denn die Fehlersuche ist ein wichtiger Teil der Arbeit mit Kubernetes in der realen Welt. Wahrscheinlich verbringst du die meiste Zeit mit der Fehlersuche in Anwendungen bei der Arbeit.
• Typische Probleme sind steckengebliebene Pods, Netzwerkausfälle, nicht korrekt gemountete persistente Volumes und Knotenausfälle.
4. Kubernetes-Netzwerk und Lastausgleich verstehen. Der Schwerpunkt liegt darauf, wie Netzwerke implementiert werden, wie Pods kommunizieren, welche Service-Typen es gibt und wie man Anwendungen offenlegt.
5. Du weißt, wie du Kubernetes-Workloads skalieren und optimieren kannst. Interviewer fragen oft nach Skalierungsstrategien und Kostenoptimierung. Beherrsche HPA, Cluster-Autoscaler, Ressourcenanforderungen und Limits. 
6. Verstehe die Best Practices für Kubernetes-Sicherheit. Du bist mit RBAC, dem Pod-Sicherheitskontext, Netzwerkrichtlinien und der Verwaltung von Geheimnissen vertraut.
7. Studiere die Architektur und die Interna von Kubernetes. Du kennst die Komponenten der Steuerungsebene und weißt, wie Kubelet und Container-Laufzeitumgebung zusammenwirken.

Indem du theoretisches Wissen mit praktischer Übung kombinierst und von der Fehlerbehebung in der Praxis lernst, wirst du jedes Kubernetes-Interview meistern!

Fazit

Kubernetes ist ein leistungsstarkes, aber komplexes Container-Orchestrierungssystem. Vorstellungsgespräche für Kubernetes-Positionen erfordern ein tiefes Verständnis der Theorie und der Problemlösung in der Praxis. Egal, ob du als Junior-Ingenieur deinen ersten Job suchst oder als Senior-Ingenieur fortgeschrittenere Aufgaben anstrebst, Vorbereitung ist immer der Schlüssel.

Ich kann nicht genug betonen, wie wichtig die Praxis ist. Es hilft dir, Probleme in deinen Bewerbungen schneller zu finden und mehr Vertrauen in deine Fähigkeiten zu gewinnen.

Wenn du deine Grundlagen vertiefen möchtest, empfehle ich dir Kurse wie "Containerization and Virtualization Concepts ", um eine solide Basis zu schaffen, und anschließend "Introduction to Kubernetes ", um praktische Erfahrungen mit Kubernetes zu sammeln.

Ich wünsche dir alles Gute für deine Vorstellungsgespräche!