Kubernetes Interview Fragen und Antworten

Einleitung

Willkommen zu diesem umfassenden Leitfaden, der Ihnen das Wissen und das Selbstvertrauen vermitteln soll, um in Kubernetes-Interviews erfolgreich zu sein. Egal, ob Sie gerade erst mit der Container-Orchestrierung beginnen oder ein erfahrener Profi sind, der seine Expertise vertiefen möchte, dieses Dokument bietet einen strukturierten Ansatz, um Kubernetes-Konzepte zu meistern. Wir haben sorgfältig eine breite Palette von Fragen zusammengestellt, die von grundlegenden Prinzipien und fortgeschrittenen architektonischen Überlegungen bis hin zu praktischer Fehlerbehebung, szenariobasierten Herausforderungen und rollenspezifischen Anfragen für Entwickler, Administratoren und DevOps-Ingenieure reichen. Bereiten Sie sich darauf vor, Ihr Verständnis zu verbessern, Ihre Problemlösungsfähigkeiten zu verfeinern und jedes Kubernetes-Interview souverän zu meistern.

Kubernetes-Grundlagen und Kernkonzepte

Was ist Kubernetes und wofür wird es verwendet?

Antwort:

Kubernetes ist eine Open-Source-Container-Orchestrierungsplattform, die die Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen automatisiert. Sie wird verwendet, um die Komplexität des Betriebs von Anwendungen in der Produktion zu bewältigen und hohe Verfügbarkeit, Skalierbarkeit und effiziente Ressourcennutzung zu gewährleisten.

Erklären Sie den Unterschied zwischen einem Pod und einem Container in Kubernetes.

Antwort:

Ein Container ist ein leichtgewichtiges, ausführbares Softwarepaket, das alles enthält, was zur Ausführung einer Anwendung benötigt wird. Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes und kapselt einen oder mehrere Container, Speicherressourcen, eine eindeutige Netzwerk-IP und Optionen, die steuern, wie die Container ausgeführt werden sollen. Alle Container innerhalb eines Pods teilen sich denselben Netzwerk-Namespace und können über localhost kommunizieren.

Was ist ein Node in Kubernetes?

Antwort:

Ein Node ist eine Arbeitsmaschine in Kubernetes, die eine VM oder eine physische Maschine sein kann. Jeder Node enthält die notwendigen Komponenten zur Ausführung von Pods, einschließlich des Kubelet (Agent für den Master), Kube-proxy (Netzwerk-Proxy) und einer Container-Runtime (z. B. Docker, containerd).

Beschreiben Sie die Hauptkomponenten der Kubernetes Control Plane (Master Node).

Antwort:

Die Control Plane besteht aus dem Kube-API-Server (eksponiert die Kubernetes-API), etcd (konsistenter und hochverfügbarer Key-Value-Store für Clusterdaten), Kube-Scheduler (überwacht neue Pods und weist sie Nodes zu) und Kube-Controller-Manager (führt Controller-Prozesse wie Node-, Replikations-, Endpunkt- und Service-Account-Controller aus).

Was ist ein Deployment in Kubernetes und wofür wird es verwendet?

Antwort:

Ein Deployment ist eine Abstraktion auf höherer Ebene, die den gewünschten Zustand Ihrer Pods und ReplicaSets verwaltet. Es bietet deklarative Updates für Pods und ReplicaSets und ermöglicht es Ihnen zu definieren, wie viele Replikate einer Anwendung ausgeführt werden sollen und wie Updates ausgerollt oder auf frühere Versionen zurückgerollt werden sollen.

Wie verwaltet Kubernetes das Networking für Pods?

Antwort:

Kubernetes weist jedem Pod eine eindeutige IP-Adresse zu. Alle Container innerhalb eines Pods teilen sich diese IP und können über localhost kommunizieren. Pods auf verschiedenen Nodes können über ein CNI (Container Network Interface) Plugin kommunizieren, das das Netzwerk-Overlay implementiert. Kube-proxy verwaltet Netzwerkregeln auf den Nodes, um Service Discovery und Load Balancing zu ermöglichen.

Was ist ein Service in Kubernetes und welche Typen gibt es?

Antwort:

Ein Service ist eine abstrakte Methode, um eine auf einer Reihe von Pods laufende Anwendung als Netzwerkdienst bereitzustellen. Er bietet eine stabile IP-Adresse und einen DNS-Namen für eine Gruppe von Pods. Gängige Typen sind ClusterIP (intern für den Cluster), NodePort (eksponiert den Dienst über einen statischen Port auf der IP jedes Nodes) und LoadBalancer (eksponiert den Dienst extern über den Load Balancer eines Cloud-Anbieters).

Erklären Sie den Zweck eines ReplicaSets.

Antwort:

Ein ReplicaSet stellt sicher, dass zu jedem Zeitpunkt eine bestimmte Anzahl von Pod-Replikaten ausgeführt wird. Sein Hauptzweck ist die Aufrechterhaltung der Stabilität und Verfügbarkeit einer Reihe von Pods. Obwohl Sie ReplicaSets direkt verwenden können, werden sie typischerweise von Deployments für erweiterte Funktionen wie Rolling Updates verwaltet.

Was ist kubectl und was ist seine Hauptfunktion?

Antwort:

kubectl ist das Kommandozeilenwerkzeug zur Interaktion mit einem Kubernetes-Cluster. Es ermöglicht Benutzern, Befehle gegen Kubernetes-Cluster auszuführen, Anwendungen bereitzustellen, Cluster-Ressourcen zu inspizieren und zu verwalten sowie Logs anzuzeigen. Es kommuniziert mit dem Kubernetes-API-Server.

Welche Rolle spielt etcd in Kubernetes?

Antwort:

etcd ist ein verteilter, konsistenter und hochverfügbarer Key-Value-Store, der von Kubernetes zur Speicherung aller Clusterdaten verwendet wird. Dazu gehören Konfigurationsdaten, Zustandsinformationen, Metadaten und der gewünschte Zustand des Clusters. Er fungiert als einzige Quelle der Wahrheit für den Kubernetes-Cluster.

Fortgeschrittene Kubernetes-Themen und Architektur

Erklären Sie das Konzept eines Kubernetes Operators und geben Sie ein Beispiel, wann Sie einen verwenden würden.

Antwort:

Ein Kubernetes Operator ist eine Methode zur Paketierung, Bereitstellung und Verwaltung einer Kubernetes-nativen Anwendung. Er erweitert die Kubernetes-API, um Instanzen komplexer Anwendungen zu erstellen, zu konfigurieren und zu verwalten. Sie würden einen Operator für zustandsbehaftete Anwendungen wie Datenbanken (z. B. Cassandra, MySQL) verwenden, um Aufgaben wie Backups, Upgrades und Skalierung zu automatisieren.

Beschreiben Sie den Zweck einer Custom Resource Definition (CRD) in Kubernetes.

Antwort:

Eine Custom Resource Definition (CRD) ermöglicht es Ihnen, Ihre eigenen benutzerdefinierten Ressourcen in Kubernetes zu definieren und damit die Kubernetes-API zu erweitern. Dies ermöglicht es Ihnen, strukturierte Daten zu speichern und abzurufen, die Kubernetes verwalten kann. CRDs sind grundlegend für die Erstellung von Operatoren und die Definition anwendungsspezifischer Objekte.

Wie verarbeitet der Kubernetes API Server die Authentifizierung und Autorisierung von Anfragen?

Antwort:

Der API Server verarbeitet die Authentifizierung über verschiedene Methoden wie Client-Zertifikate, Bearer-Tokens oder Service-Account-Tokens. Nach der Authentifizierung erfolgt die Autorisierung über Module wie RBAC (Role-Based Access Control), Node-Autorisierung oder ABAC (Attribute-Based Access Control). RBAC ist die gebräuchlichste Methode, die Rollen mit Berechtigungen definiert und diese an Benutzer oder Service-Accounts bindet.

Was ist der Unterschied zwischen einem DaemonSet und einem Deployment in Kubernetes?

Antwort:

Ein Deployment verwaltet eine Reihe identischer Pods und stellt sicher, dass eine gewünschte Anzahl von Replikaten im gesamten Cluster läuft, typischerweise für zustandslose Anwendungen. Ein DaemonSet stellt sicher, dass alle (oder einige) Nodes eine Kopie eines Pods ausführen, was für Cluster-weite Dienste wie Log-Kollektoren (z. B. Fluentd) oder Monitoring-Agenten (z. B. Node Exporter) nützlich ist, die auf jedem Node laufen müssen.

Erklären Sie das Konzept von Pod Security Policies (PSPs) und warum sie veraltet sind.

Antwort:

Pod Security Policies (PSPs) waren ein Admission Controller, der Sicherheitsstandards für Pods und Container durchsetzte. Sie ermöglichten Cluster-Administratoren die Kontrolle über sicherheitskritische Aspekte wie den privilegierten Modus, den Zugriff auf das Host-Netzwerk und die Volume-Typen. PSPs werden zugunsten von Pod Security Admission (PSA) und Policy-Engines wie OPA Gatekeeper veraltet, die flexiblere und granularere Kontrollen bieten.

Wie erreicht man Hochverfügbarkeit für die Kubernetes Control Plane?

Antwort:

Hochverfügbarkeit für die Control Plane wird durch den Betrieb mehrerer Instanzen des API Servers, etcd, Controller Manager und Scheduler erreicht. etcd läuft typischerweise als quorum-basierter Cluster (z. B. 3 oder 5 Nodes). Ein Load Balancer wird vor die API Server geschaltet, um den Datenverkehr zu verteilen und Failover zu ermöglichen.

Was ist ein mutating admission webhook und wie kann er verwendet werden?

Antwort:

Ein mutating admission webhook ist ein HTTP-Callback, der Anfragen an den Kubernetes API Server modifizieren kann, bevor sie gespeichert werden. Er kann Sidecar-Container injizieren, Labels/Annotationen hinzufügen oder Standardwerte für Felder festlegen. Zum Beispiel kann er automatisch einen istio-proxy Sidecar in Pods für die Service-Mesh-Integration injizieren.

Beschreiben Sie die Rolle von etcd in einem Kubernetes-Cluster.

Antwort:

etcd dient als konsistenter und hochverfügbarer Key-Value-Store von Kubernetes. Er speichert alle Clusterdaten, einschließlich Konfiguration, Zustand und Metadaten für alle Kubernetes-Objekte (Pods, Deployments, Services usw.). Er ist entscheidend für den Betrieb des Clusters, und seine Verfügbarkeit wirkt sich direkt auf die Gesundheit des Clusters aus.

Wie erzwingt Kubernetes Netzwerkrichtlinien (Network Policies)?

Antwort:

Kubernetes Network Policies sind Spezifikationen, die definieren, wie Gruppen von Pods miteinander und mit externen Endpunkten kommunizieren dürfen. Sie werden von einem Netzwerk-Plugin (CNI) implementiert, das NetworkPolicy unterstützt, wie z. B. Calico, Cilium oder Weave Net. Das CNI-Plugin übersetzt diese Richtlinien in Firewall-Regeln.

Was sind Taints und Tolerations und wie werden sie für die Pod-Planung verwendet?

Antwort:

Taints werden auf Nodes angewendet und markieren sie als "ungeeignet" für bestimmte Pods, es sei denn, diese Pods haben passende Tolerations. Tolerations werden auf Pods angewendet und erlauben es ihnen, auf getainteten Nodes geplant zu werden. Dieser Mechanismus wird verwendet, um Nodes für bestimmte Workloads zu reservieren (z. B. GPU-Nodes) oder um Pods von fehlerhaften Nodes zu verdrängen.

Scenario-Based and Design Questions

Your application pods are frequently restarting. How would you troubleshoot this issue in Kubernetes?

Answer:

I would start by checking kubectl describe pod <pod-name> for events and status. Then, I'd use kubectl logs <pod-name> to review application logs for errors. Finally, I'd inspect kubectl logs <pod-name> -p for logs from previous container instances to understand the cause of the crash.

You need to deploy a new version of your application with zero downtime. How would you achieve this in Kubernetes?

Answer:

I would use a RollingUpdate strategy for the Deployment. This allows Kubernetes to gradually replace old pods with new ones, ensuring that a minimum number of pods are always available. Health checks (readiness probes) are crucial to ensure new pods are ready before traffic is routed to them.

Describe a scenario where you would use a StatefulSet instead of a Deployment.

Answer:

I would use a StatefulSet for applications that require stable, unique network identifiers, stable persistent storage, and ordered, graceful deployment/scaling/deletion. Examples include databases like PostgreSQL or distributed systems like Apache Kafka, where each replica needs its own persistent volume and predictable hostname.

Your Kubernetes cluster is running out of resources (CPU/Memory). What steps would you take to diagnose and mitigate this?

Answer:

First, I'd use kubectl top nodes and kubectl top pods to identify resource hogs. Then, I'd check resource requests and limits on pods to ensure they are appropriately set. Mitigation steps include optimizing application resource usage, scaling the cluster horizontally, or adjusting resource requests/limits.

How would you expose a web application running in Kubernetes to the internet securely?

Answer:

I would use a Kubernetes Service of type LoadBalancer or NodePort to expose the application within the cluster or to external traffic. For secure HTTP/HTTPS access, I'd deploy an Ingress controller (e.g., Nginx Ingress) and define Ingress resources with TLS termination, often integrating with Cert-Manager for automated certificate provisioning.

You need to run a one-off batch job that processes data and then exits. What Kubernetes object would you use?

Answer:

I would use a Kubernetes Job object. A Job ensures that a specified number of pods successfully complete their tasks. For recurring tasks, I would use a CronJob, which creates Job objects on a defined schedule.

Design a high-availability strategy for a critical microservice in Kubernetes.

Answer:

I would deploy the microservice as a Deployment with multiple replicas (e.g., 3 or more) spread across different nodes using anti-affinity rules. I'd implement robust readiness and liveness probes. For data persistence, I'd use a distributed database or a StatefulSet with persistent volumes. Finally, I'd ensure proper resource requests/limits and autoscaling.

How would you handle sensitive information like API keys or database credentials for your applications in Kubernetes?

Answer:

I would use Kubernetes Secrets to store sensitive information. These secrets can be mounted as files into pods or exposed as environment variables. For enhanced security, I would integrate with external secret management systems like HashiCorp Vault or cloud provider KMS services.

Your application needs to access a database running outside the Kubernetes cluster. How would you configure this securely?

Answer:

I would create a Kubernetes Service of type ExternalName or a headless Service with Endpoints to represent the external database within the cluster. This allows pods to resolve the database by a Kubernetes service name. Network policies would be used to restrict egress traffic only to the database's IP and port, and credentials would be managed via Kubernetes Secrets.

You observe that your application's response time is increasing under heavy load. How would you scale your application in Kubernetes to handle this?

Answer:

I would implement Horizontal Pod Autoscaling (HPA) for the Deployment, configured to scale based on CPU utilization or custom metrics like request per second. This automatically adds more pod replicas when demand increases. I'd also ensure the underlying cluster has sufficient node capacity or implement Cluster Autoscaler.

Rollenspezifische Fragen (Entwickler, Administrator, DevOps)

Entwickler: Wie würden Sie einen Pod beheben, der im Status "Pending" feststeckt?

Antwort:

Ich würde zuerst kubectl describe pod <pod-name> auf Ereignisse überprüfen, die auf Probleme wie unzureichende Ressourcen (CPU/Speicher), Node-Affinität/Taint-Probleme oder nicht gebundene Persistent Volume Claims hinweisen. Als Nächstes würde ich die Bedingungen und die Ressourcenverfügbarkeit des Nodes mit kubectl describe node <node-name> überprüfen.

Entwickler: Sie müssen eine neue Version Ihrer Anwendung bereitstellen. Was ist der sicherste Weg, dies in Kubernetes zu tun, um Ausfallzeiten zu minimieren?

Antwort:

Ich würde eine RollingUpdate-Strategie für das Deployment verwenden. Dies ersetzt schrittweise alte Pods durch neue und gewährleistet so eine kontinuierliche Verfügbarkeit. Ich würde auch Readiness-Probes definieren, um sicherzustellen, dass neue Pods fehlerfrei sind, bevor der Datenverkehr zu ihnen geleitet wird.

Administrator: Ein Benutzer meldet, dass er auf einen im Cluster laufenden Dienst nicht zugreifen kann. Welche Schritte würden Sie zur Diagnose des Problems unternehmen?

Antwort:

Ich würde zunächst den Service mit kubectl describe service <service-name> überprüfen, um seine Konfiguration und die Bereitschaft der Endpunkte zu verifizieren. Dann würde ich die Pods, die den Dienst unterstützen, auf ihre Gesundheit überprüfen (kubectl get pods -o wide) und ihre Logs auf Anwendungsfehler untersuchen. Netzwerkrichtlinien oder Firewall-Regeln könnten ebenfalls eine Rolle spielen.

Administrator: Wie stellen Sie sicher, dass nur autorisierte Benutzer auf bestimmte Ressourcen innerhalb eines Kubernetes-Clusters zugreifen können?

Antwort:

Ich würde Role-Based Access Control (RBAC) implementieren. Dies beinhaltet die Definition von Roles (Berechtigungen innerhalb eines Namespaces) oder ClusterRoles (clusterweite Berechtigungen) und deren anschließende Bindung an Benutzer oder Service-Accounts mittels RoleBindings oder ClusterRoleBindings.

Administrator: Beschreiben Sie ein Szenario, in dem Sie eine NetworkPolicy verwenden würden.

Antwort:

Ich würde eine NetworkPolicy verwenden, um den Datenverkehr zwischen Pods oder zwischen Pods und externen Endpunkten zu steuern. Zum Beispiel, um einen Datenbank-Pod zu isolieren, sodass nur bestimmte Anwendungs-Pods eine Verbindung zu ihm herstellen können, oder um den ausgehenden Datenverkehr aus einem Entwicklungs-Namespace einzuschränken.

DevOps: Wie verwalten Sie Secrets (z. B. API-Schlüssel, Datenbankanmeldeinformationen) sicher in Kubernetes?

Antwort:

Während Kubernetes Secrets eine grundlegende Kodierung bieten, würde ich für echte Sicherheit externe Secret-Management-Lösungen wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault integrieren. Diese Lösungen können Secrets direkt in Pods injizieren oder CSI-Treiber für dynamisches Mounting verwenden, um die Speicherung sensibler Daten direkt in Git zu vermeiden.

DevOps: Erklären Sie den Zweck eines Helm-Charts und wie es CI/CD-Pipelines zugutekommt.

Antwort:

Ein Helm-Chart ist ein Paketmanager für Kubernetes, der alle notwendigen Kubernetes-Ressourcen (Deployments, Services, ConfigMaps usw.) in einer einzigen, versionierbaren Einheit bündelt. In CI/CD ermöglicht es konsistente, wiederholbare Bereitstellungen über Umgebungen hinweg, einfache Versions-Upgrades/-Rollbacks und die Parametrisierung von Konfigurationen.

DevOps: Wie würden Sie Continuous Deployment für eine Microservices-Anwendung auf Kubernetes implementieren?

Antwort:

Ich würde einen GitOps-Ansatz mit einem Tool wie Argo CD oder Flux verwenden. Nachdem der Code zusammengeführt und getestet wurde, erstellt eine CI-Pipeline das Docker-Image und aktualisiert das Image-Tag in der Kubernetes-Manifest (z. B. in einem Git-Repository). Der GitOps-Operator erkennt dann die Änderung in Git und wendet sie automatisch auf den Cluster an, um die Synchronisierung des gewünschten Zustands sicherzustellen.

DevOps: Welche Schlüsselmetriken würden Sie für einen Kubernetes-Cluster und seine Anwendungen überwachen?

Antwort:

Für den Cluster würde ich die Ressourcenauslastung der Nodes (CPU, Speicher, Festplatte), die Latenz des API-Servers und den Zustand von etcd überwachen. Für Anwendungen sind wichtige Metriken die CPU-/Speicherauslastung der Pods, Anfrageraten, Fehlerraten, Latenz und anwendungsspezifische Geschäftsmetriken. Prometheus und Grafana sind gängige Werkzeuge dafür.

DevOps: Beschreiben Sie, wie Sie persistenten Speicher für zustandsbehaftete Anwendungen in Kubernetes handhaben würden.

Antwort:

Ich würde PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs) verwenden. Ein PVC fordert Speicher von einem PV an, der von einer StorageClass bereitgestellt wird. Dies abstrahiert die zugrunde liegende Speicherinfrastruktur und ermöglicht es Anwendungen, Speicher anzufordern, ohne dessen Spezifika zu kennen, und stellt die Datenpersistenz sicher, auch wenn Pods neu geplant werden.

Fehlerbehebung und Debugging in Kubernetes

Ihr Pod steckt im Status "Pending". Was sind die häufigsten Gründe und wie würden Sie das Problem beheben?

Antwort:

Häufige Gründe sind unzureichende Ressourcen (CPU/Speicher), Node-Taints/Tolerations oder Probleme mit persistenten Volumes. Ich würde kubectl describe pod <pod-name> verwenden, um Ereignisse für Planungsfehler, Ressourcenanforderungen und den Status der Volume-Bindung zu überprüfen.

Ein Pod befindet sich im Status "CrashLoopBackOff". Was bedeutet das und wie debuggen Sie es?

Antwort:

Dies bedeutet, dass der Container innerhalb des Pods wiederholt startet und abstürzt. Ich würde zuerst kubectl logs <pod-name> auf Anwendungsfehler überprüfen. Wenn die Logs nicht hilfreich sind, würde ich kubectl describe pod <pod-name> verwenden, um nach OOMKilled-Ereignissen oder Fehlern bei Readiness-/Liveness-Probes zu suchen.

Wie überprüfen Sie die Logs eines bestimmten Containers in einem Pod mit mehreren Containern?

Antwort:

Sie können den Containernamen mit dem Flag -c bei kubectl logs angeben. Zum Beispiel: kubectl logs <pod-name> -c <container-name>. Dies ermöglicht die Isolierung von Logs eines bestimmten Dienstes.

Ein Dienst ist von außerhalb des Clusters nicht erreichbar. Welche Schritte würden Sie zur Diagnose unternehmen?

Antwort:

Ich würde den Diensttyp (z. B. NodePort, LoadBalancer) und seine externe IP/Port überprüfen. Dann würde ich Firewall-Regeln, Sicherheitsgruppen und Netzwerkrichtlinien verifizieren. Schließlich würde ich prüfen, ob die Selektoren des Dienstes korrekt mit den Pod-Labels übereinstimmen und ob die Pods laufen und fehlerfrei sind.

Sie vermuten, dass eine Netzwerkrichtlinie den Datenverkehr zu Ihrer Anwendung blockiert. Wie würden Sie dies bestätigen?

Antwort:

Ich würde kubectl describe networkpolicy <policy-name> verwenden, um seine Regeln zu verstehen. Dann würde ich die Labels und Namespaces des Pods überprüfen, um zu sehen, ob sie von Richtlinien betroffen sind. Tools wie kube-no-trouble oder netshoot innerhalb eines Debug-Pods können ebenfalls helfen, die Konnektivität zu testen.

Wie erhalten Sie eine Shell in einem laufenden Container zu Debugging-Zwecken?

Antwort:

Sie können kubectl exec -it <pod-name> -- /bin/bash (oder /bin/sh, falls Bash nicht verfügbar ist) verwenden. Dies ermöglicht es Ihnen, das Dateisystem des Containers zu inspizieren, Befehle auszuführen und Probleme direkt in seiner Umgebung zu diagnostizieren.

Was sind häufige Ursachen für "ImagePullBackOff" und wie beheben Sie diese?

Antwort:

Häufige Ursachen sind falscher Image-Name/-Tag, Probleme bei der Authentifizierung an privaten Registries oder Netzwerkverbindungsprobleme zur Registry. Ich würde kubectl describe pod <pod-name> auf Image-Pull-Fehler überprüfen und Image-Namen, Registry-Anmeldeinformationen (Secrets) und Netzwerkzugriff verifizieren.

Ihre Anwendung weist eine hohe Latenz auf, aber die Pods scheinen fehlerfrei zu sein. Was könnte das Problem sein?

Antwort:

Dies könnte auf Ressourcenkonflikte (CPU-Drosselung), ineffizienten Anwendungscode oder Probleme mit externen Abhängigkeiten hindeuten. Ich würde die Metriken zur Ressourcenauslastung (CPU/Speicher) für die Pods überprüfen, die Anwendungsprotokolle auf langsame Abfragen überprüfen und die Netzwerklatenz zu externen Diensten untersuchen.

Wie würden Sie einen Fehler bei einem Liveness- oder Readiness-Probe debuggen?

Antwort:

Ich würde kubectl describe pod <pod-name> auf Probe-Fehlerereignisse und den verwendeten Befehl/Pfad überprüfen. Dann würde ich kubectl logs <pod-name> verwenden, um zu sehen, ob die Anwendung abstürzt oder nicht auf den Endpunkt der Probe reagiert. Die Ausführung des Probe-Befehls manuell im Container kann ebenfalls helfen.

Ein Node befindet sich im Status "NotReady". Was sind die typischen Gründe und wie untersuchen Sie das?

Antwort:

Typische Gründe sind, dass kubelet nicht läuft, Netzwerkprobleme die Kommunikation mit der Steuerungsebene verhindern oder unzureichende Node-Ressourcen. Ich würde mich per SSH mit dem Node verbinden, systemctl status kubelet überprüfen, die kubelet-Logs überprüfen (journalctl -u kubelet) und die Netzwerkkonnektivität zum API-Server verifizieren.

Kubernetes Best Practices und Sicherheit

Was sind einige wichtige Best Practices zur Sicherung von Kubernetes-Clustern?

Antwort:

Zu den wichtigsten Praktiken gehören die Implementierung von Role-Based Access Control (RBAC) mit dem Prinzip der geringsten Rechte (least privilege), die regelmäßige Aktualisierung von Kubernetes und seinen Komponenten, das Scannen von Container-Images auf Schwachstellen, die Netzwerksegmentierung mittels Network Policies und die Sicherung des API-Server-Zugriffs.

Erklären Sie das Prinzip der "geringsten Rechte" (least privilege) in Kubernetes RBAC.

Antwort:

Das Prinzip der geringsten Rechte bedeutet, Benutzern und Service-Accounts nur die minimal notwendigen Berechtigungen zur Ausführung ihrer Aufgaben zu gewähren. Dies minimiert die potenziellen Auswirkungen, falls ein Konto kompromittiert wird, und reduziert die Angriffsfläche innerhalb des Clusters.

Wie verbessern Network Policies die Sicherheit in einem Kubernetes-Cluster?

Antwort:

Network Policies definieren, wie Pods miteinander und mit externen Endpunkten kommunizieren dürfen. Sie fungieren als Firewalls auf Pod-Ebene und ermöglichen die Netzwerksegmentierung und die Isolierung sensibler Workloads, um unbefugte Kommunikation zu verhindern.

Welche Bedeutung hat das Image-Scanning in einer CI/CD-Pipeline für Kubernetes-Deployments?

Antwort:

Image-Scanning identifiziert bekannte Schwachstellen (CVEs) und Fehlkonfigurationen in Container-Images vor der Bereitstellung. Die Integration in CI/CD stellt sicher, dass nur sichere, konforme Images in Registries gepusht und im Cluster bereitgestellt werden, wodurch die Ausführung anfälliger Software verhindert wird.

Beschreiben Sie eine gängige Methode zur sicheren Verwaltung von Secrets in Kubernetes.

Antwort:

Während Kubernetes Secrets eine grundlegende Speicherung bieten, sind sie standardmäßig base64-kodiert und nicht im Ruhezustand verschlüsselt. Best Practices beinhalten die Verwendung externer Secret-Management-Lösungen wie HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault, die oft über CSI-Treiber oder externe Secret-Operatoren integriert werden, um sensible Daten zu verschlüsseln und zu verwalten.

Was sind Pod Security Standards (PSS) und warum sind sie wichtig?

Antwort:

Pod Security Standards sind integrierte Sicherheitskontrollen, die verschiedene Isolationsstufen für Pods definieren (Privileged, Baseline, Restricted). Sie helfen bei der Durchsetzung von Sicherheits-Best-Practices, indem sie verhindern, dass Pods mit übermäßig permissiven Einstellungen ausgeführt werden, wie z. B. Root-Zugriff oder Host-Path-Mounts.

Wie können Sie Angriffe zur Eskalation von Berechtigungen innerhalb eines Kubernetes-Clusters verhindern?

Antwort:

Die Verhinderung von Privilege Escalation umfasst mehrere Maßnahmen: Durchsetzung von Pod Security Standards, Verwendung von unveränderlichen Containern (immutable containers), Einschränkung des Host-Zugriffs, Implementierung strenger RBAC und regelmäßige Überprüfung von Cluster-Konfigurationen und Benutzeraktivitäten. Die Einschränkung von Capabilities und das Verbot von privilegierten Containern sind entscheidend.

Welche Rolle spielt ein Service Mesh (z. B. Istio, Linkerd) für die Sicherheit in Kubernetes?

Antwort:

Ein Service Mesh verbessert die Sicherheit durch Funktionen wie mTLS (mutual TLS) für verschlüsselte Kommunikation zwischen Diensten, feingranulare Zugriffssteuerungsrichtlinien und Verkehrsverschlüsselung. Es zentralisiert Sicherheitskonfigurationen und Beobachtbarkeit für die Kommunikation von Microservices.

Erklären Sie das Konzept der "unveränderlichen Infrastruktur" (immutable infrastructure) in Kubernetes.

Antwort:

Unveränderliche Infrastruktur bedeutet, dass eine Komponente (wie ein Container-Image oder eine bereitgestellte Anwendung) nach dem Erstellen und Bereitstellen niemals geändert wird. Jede Änderung erfordert das Erstellen eines neuen Images und das Ersetzen der alten Instanz, was die Konsistenz, Zuverlässigkeit und Sicherheit durch Reduzierung von Konfigurationsdrift verbessert.

Wie tragen Resource Quotas und Limit Ranges zur Stabilität und Sicherheit des Clusters bei?

Antwort:

Resource Quotas begrenzen die Gesamtmenge an CPU, Speicher und anderen Ressourcen, die von einem Namespace verbraucht werden können, und verhindern so eine Ressourcenerschöpfung. Limit Ranges definieren Standard- und Maximalwerte für Ressourcenanforderungen/Limits für Pods innerhalb eines Namespaces und stellen sicher, dass Anwendungen keine übermäßigen Ressourcen verbrauchen, was die Cluster-Stabilität und Fairness verbessert.

Praktische und praxisnahe Kubernetes-Herausforderungen

Sie haben einen Pod, der ständig abstürzt. Wie würden Sie dieses Problem beheben?

Antwort:

Ich würde zunächst kubectl describe pod <pod-name> auf Ereignisse und Status überprüfen. Dann würde ich kubectl logs <pod-name> verwenden, um die Anwendungsprotokolle zu überprüfen. Wenn es sich um eine Crash-Schleife handelt, würde ich kubectl logs --previous <pod-name> für die Protokolle des zuletzt beendeten Containers prüfen.

Ein Deployment hängt im Status "Pending". Was sind die häufigsten Gründe und wie diagnostizieren Sie diese?

Antwort:

Häufige Gründe sind unzureichende Ressourcen (CPU/Speicher), Node-Taints/Tolerations oder Probleme mit Node-Selektoren/Affinität. Ich würde kubectl describe pod <pod-name> verwenden, um Planungsereignisse zu sehen, und kubectl get events --field-selector involvedObject.kind=Node, um Node-Bedingungen zu überprüfen.

Wie würden Sie eine zustandslose Anwendung, die in einem Deployment läuft, für externen Traffic verfügbar machen?

Antwort:

Ich würde einen Service vom Typ LoadBalancer oder NodePort erstellen, um das Deployment verfügbar zu machen. Für fortgeschrittenere Routing- und SSL-Terminierungsfunktionen würde ich eine Ingress-Ressource verwenden, die einen Ingress Controller benötigt.

Sie müssen ein Rolling Update für ein Deployment ohne Ausfallzeit durchführen. Wie handhabt Kubernetes dies und was sind die wichtigsten Überlegungen?

Antwort:

Kubernetes Deployments handhaben Rolling Updates standardmäßig, indem sie neue Pods erstellen, bevor sie alte beenden, basierend auf den Einstellungen maxUnavailable und maxSurge. Wichtige Überlegungen sind ordnungsgemäße Readiness-Probes, ausreichende Ressourcenzuweisung und das Testen der neuen Version vor dem vollständigen Rollout.

Beschreiben Sie ein Szenario, in dem Sie einen ConfigMap im Gegensatz zu einem Secret verwenden würden.

Antwort:

Ich würde einen ConfigMap für nicht-sensible Konfigurationsdaten verwenden, wie z. B. Anwendungsumgebungsvariablen oder Konfigurationsdateien. Ich würde ein Secret für sensible Daten verwenden, wie z. B. API-Schlüssel, Datenbankanmeldeinformationen oder TLS-Zertifikate, die standardmäßig verschlüsselt gespeichert werden.

Wie stellen Sie sicher, dass ein Pod nur auf Nodes mit spezifischer Hardware (z. B. GPUs) läuft?

Antwort:

Ich würde Node Selectors oder Node Affinity verwenden. Node Selectors sind einfacher für exakte Übereinstimmungen (nodeSelector: {gpu: 'true'}). Node Affinity bietet mehr Flexibilität mit Regeln wie requiredDuringSchedulingIgnoredDuringExecution oder preferredDuringSchedulingIgnoredDuringExecution.

Ein Service leitet keinen Traffic an seine Pods weiter. Welche Schritte würden Sie zur Fehlersuche unternehmen?

Antwort:

Zuerst würde ich kubectl describe service <service-name> überprüfen, um zu verifizieren, dass sein Selektor mit den Pod-Labels übereinstimmt. Dann würde ich kubectl get endpoints <service-name> überprüfen, um zu sehen, ob Pod-IPs aufgelistet sind. Schließlich würde ich sicherstellen, dass die Pods fehlerfrei sind und ihre Readiness-Probes erfolgreich sind.

Sie müssen eine einmalige Aufgabe, wie eine Datenbankmigration, innerhalb Ihres Clusters ausführen. Welche Kubernetes-Ressource würden Sie verwenden?

Antwort:

Ich würde eine Kubernetes Job-Ressource verwenden. Ein Job erstellt einen oder mehrere Pods und stellt sicher, dass eine bestimmte Anzahl davon erfolgreich beendet wird. Für geplante Aufgaben würde ich einen CronJob verwenden.

Erklären Sie den Zweck eines PersistentVolume (PV) und eines PersistentVolumeClaim (PVC).

Antwort:

Ein PersistentVolume (PV) ist ein Speicherbereich im Cluster, der von einem Administrator bereitgestellt wird. Ein PersistentVolumeClaim (PVC) ist eine Speicheranforderung eines Benutzers. Der PVC bindet sich an ein geeignetes PV und ermöglicht es Pods, dauerhaften Speicher unabhängig von ihrem Lebenszyklus zu nutzen.

Wie würden Sie ein Deployment manuell und automatisch skalieren?

Antwort:

Manuell würde ich kubectl scale deployment <deployment-name> --replicas=<number> verwenden. Automatisch würde ich einen Horizontal Pod Autoscaler (HPA) verwenden, der die Anzahl der Pods in einem Deployment oder ReplicaSet basierend auf der beobachteten CPU-Auslastung oder anderen benutzerdefinierten Metriken skaliert.

Zusammenfassung

Die Navigation durch ein Kubernetes-Interview kann eine herausfordernde, aber lohnende Erfahrung sein. Dieses Dokument hat einen umfassenden Überblick über häufige Fragen und aufschlussreiche Antworten gegeben, der darauf abzielt, Sie mit dem Wissen und dem Selbstvertrauen auszustatten, das Sie für Spitzenleistungen benötigen. Denken Sie daran, dass eine gründliche Vorbereitung von größter Bedeutung ist; das Verständnis der Kernkonzepte, praktischen Anwendungen und Fehlerbehebungsszenarien wird Ihre Leistung erheblich verbessern.

Über das Interview hinaus ist die Reise mit Kubernetes eine des kontinuierlichen Lernens und der Anpassung. Die Landschaft entwickelt sich rasant weiter, und Neugier zu bewahren, mit neuen Funktionen zu experimentieren und sich mit der Community zu beschäftigen, wird sicherstellen, dass Ihre Fähigkeiten scharf und relevant bleiben. Nehmen Sie die Herausforderungen an, feiern Sie Ihre Erfolge und bauen Sie Ihre Expertise in dieser dynamischen und wesentlichen Technologie weiter aus.