Bewährte Methoden zur Optimierung der Leistung von Kubernetes-Clustern

Probleme mit der Leistung von Kubernetes-Clustern äußern sich normalerweise in langsamen Rollouts, ausstehenden Pods, lauten Nachbarn oder überraschenden Cloud-Rechnungen. Die Lösung ist selten eine einzige magische Einstellung; Sie benötigen eine genaue Ressourcendimensionierung, Skalierungsregeln, die der Nachfrage entsprechen, und ausreichende Beobachtbarkeit, um zu erkennen, wo der Druck beginnt.

Verwenden Sie diese Checkliste, um Ihren Cluster ohne Rätselraten zu optimieren.

Beginnen Sie mit Requests und Limits

Der Scheduler verwendet CPU- und Speicher-requests, um zu entscheiden, wo Pods platziert werden. Wenn die Requests zu niedrig sind, wirken die Knoten leerer, als sie sind, und Workloads kämpfen um Ressourcen. Wenn die Requests zu hoch sind, verschwendet der Scheduler Kapazität und Pods bleiben möglicherweise ausstehend.

Setzen Sie Requests basierend auf tatsächlichen Nutzungsdaten. Wenn beispielsweise ein API-Container bei normalem Traffic etwa 300 Millicores verbraucht und während des Deploy-Warmups Spitzenwerte von etwa 700 Millicores erreicht, könnten Sie mit Folgendem beginnen:

resources:
  requests:
    cpu: "300m"
    memory: "512Mi"
  limits:
    memory: "1Gi"

Seien Sie vorsichtig mit CPU-Limits. Ein strenges CPU-Limit kann latenzempfindliche Dienste drosseln, selbst wenn der Knoten freie CPU hat. Speicherlimits sind weiterhin nützlich, da ein Container, der sein Speicherlimit überschreitet, beendet werden kann, bevor er den gesamten Knoten unter Speicherdruck setzt.

Verwenden Sie Autoscaling mit klaren Signalen

Der Horizontal Pod Autoscaler funktioniert gut, wenn Ihre Metrik die Benutzernachfrage verfolgt. CPU kann für einfache zustandslose Dienste ausreichen, aber die Warteschlangentiefe, die Anforderungsrate oder benutzerdefinierte Anwendungsmetriken sind oft bessere Skalierungssignale.

kubectl autoscale deployment api \
  --cpu-percent=70 \
  --min=3 \
  --max=20

Cluster Autoscaler, Karpenter oder die Knoten-Autoskalierungsschicht Ihres Cloud-Anbieters sollten Platz haben, um Knoten hinzuzufügen, bevor Pods längere Zeit ausstehend bleiben. Überprüfen Sie, ob die Knotengruppen die Instanzgrößen, Zonen, GPU-Anforderungen oder Taints abdecken, die Ihre Workloads benötigen.

Halten Sie die Planung vorhersehbar

Die Leistung sinkt, wenn kritische Pods auf überlasteten oder ungeeigneten Knoten landen. Verwenden Sie Topology Spread Constraints für Dienste mit hohem Traffic, Node Affinity für hardware-spezifische Workloads und Taints für Knoten, die nur eine enge Klasse von Pods ausführen sollen.

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app: api

Dies verhindert, dass sich Replikate auf einem Knoten stapeln, wenn der Cluster bessere Platzierungsoptionen hat.

Optimieren Sie die Vernetzung dort, wo es wirklich wehtut

Die meisten Cluster benötigen keine exotische Netzwerkoptimierung. Beginnen Sie damit, den langsamen Pfad zu finden: DNS-Auflösungszeit, Service-Mesh-Overhead, zonenübergreifender Traffic, überlastetes Ingress oder Pod-zu-Datenbank-Latenz.

Nützliche Überprüfungen umfassen:

kubectl top pods -A
kubectl get endpointslices -A
kubectl describe ingress <name>
kubectl logs -n kube-system -l k8s-app=kube-dns

Halten Sie für gesprächige Dienste Pods und ihre Hauptabhängigkeiten in derselben Region und, wenn möglich, in derselben Zone. Wenn Sie ein Service Mesh verwenden, messen Sie die p95- und p99-Latenz mit und ohne Sidecar-Injektion für einen Workload, bevor Sie Mesh-Änderungen breit rollen.

Passen Sie den Speicher an den Workload an

Speicheroptionen können die Leistung für Datenbanken, Warteschlangen und CI-Workloads dominieren. Wählen Sie Volumes basierend auf Latenz, IOPS, Durchsatz und Fehlerverhalten, nicht nur auf Kapazität.

Beispielsweise benötigt ein PostgreSQL-Pod eine persistente Volume-Klasse mit vorhersagbarer Latenz und klarem Backup-Verhalten. Ein Build-Cache legt möglicherweise mehr Wert auf Durchsatz und toleriert möglicherweise Neuerstellungen. Ein zustandsloser Webdienst sollte persistente Volumes vollständig vermeiden, es sei denn, er hat einen triftigen Grund.

Achten Sie auf diese Symptome:

• Pods bleiben in ContainerCreating stecken, weil Volumes langsam bereitgestellt werden.
• Die Anwendungslatenz steigt, während die CPU normal bleibt.
• Knoten-Speicherdruck führt zur Vertreibung von Pods.
• StatefulSets werden blockiert, weil ein Volume an eine Zone gebunden ist.

Beobachten Sie den Cluster, bevor Sie ihn ändern

Optimierung ohne Basislinienmetriken ist nur unnötige Aktivität. Verfolgen Sie mindestens CPU, Speicher, Neustarts, ausstehende Pods, Knotendruckbedingungen, API-Server-Latenz und p95-Latenz des Workloads.

kubectl get nodes
kubectl describe node <node-name>
kubectl get pods -A --field-selector=status.phase=Pending
kubectl top nodes

Wenn Sie Prometheus ausführen, fügen Sie Alarme für anhaltenden Knotendruck, hohe Neustartraten, HPA bei maximalen Replikaten und nicht verfügbare Replikate bei kritischen Deployments hinzu.

Fazit

Optimieren Sie Kubernetes von außen nach innen. Dimensionieren Sie Requests richtig, vermeiden Sie unnötige CPU-Drosselung, skalieren Sie basierend auf Nachfragesignalen, halten Sie Replikate verteilt und wählen Sie Speicher, der zum Workload passt. Messen Sie dann nach jeder Änderung, ob der Cluster schneller, günstiger oder einfach anders geworden ist.