Workloads

Workloads wirken sich darauf aus, wie groß Ihr Cluster skalieren kann. Workloads, die Kubernetes APIs stark nutzen, begrenzen die Gesamtmenge der Workloads, die Sie in einem einzelnen Cluster haben können. Es gibt jedoch einige Standardeinstellungen, die Sie ändern können, um die Last zu reduzieren.

Workloads in einem Kubernetes-Cluster haben Zugriff auf Funktionen, die in die Kubernetes-API integriert sind (z. B. Secrets und ServiceAccounts). Diese Funktionen sind jedoch nicht immer erforderlich und sollten deaktiviert werden, wenn sie nicht verwendet werden. Durch die Einschränkung des Workload-Zugriffs und der Abhängigkeit von der Kubernetes-Steuerebene wird die Anzahl der Workloads, die Sie im Cluster ausführen können, erhöht und die Sicherheit Ihrer Cluster verbessert, indem unnötiger Zugriff auf Workloads vermieden und Verfahren mit den geringsten Rechten implementiert werden. Weitere Informationen finden Sie in den bewährten Sicherheitsmethoden.

IPv6 Für Pod-Netzwerke verwenden

Sie können eine VPC nicht von IPv4 zu wechseln, IPv6 daher ist es wichtig, IPv6 sie vor der Bereitstellung eines Clusters zu aktivieren. Wenn Sie die Option IPv6 in einer VPC aktivieren, bedeutet das nicht, dass Sie sie verwenden müssen. Wenn Ihre Pods und Dienste sie verwenden, können IPv6 Sie weiterhin Traffic zu und von IPv4 Adressen weiterleiten. Weitere Informationen finden Sie in den Best Practices für EKS-Netzwerke.

Durch die Verwendung IPv6 in Ihrem Cluster werden einige der häufigsten Einschränkungen bei der Cluster- und Workload-Skalierung vermieden. IPv6 vermeidet die Erschöpfung von IP-Adressen, wenn Pods und Knoten nicht erstellt werden können, weil keine IP-Adresse verfügbar ist. Außerdem wird die Leistung pro Knoten verbessert, da Pods IP-Adressen schneller empfangen, da die Anzahl der ENI-Anhänge pro Knoten reduziert wird. Sie können eine ähnliche Knotenleistung erzielen, indem Sie den IPv4 Präfixmodus in der VPC-CNI verwenden. Sie müssen jedoch sicherstellen, dass in der VPC genügend IP-Adressen verfügbar sind.

Beschränken Sie die Anzahl der Dienste pro Namespace

Die maximale Anzahl von Diensten in einem Namespaces ist 5.000 und die maximale Anzahl von Diensten in einem Cluster ist 10.000. Um die Organisation von Workloads und Diensten zu erleichtern, die Leistung zu steigern und um kaskadierende Auswirkungen auf Ressourcen im Namespace-Bereich zu vermeiden, empfehlen wir, die Anzahl der Dienste pro Namespace auf 500 zu beschränken.

Die Anzahl der IP-Tabellenregeln, die pro Knoten mit kube-proxy erstellt werden, wächst mit der Gesamtzahl der Dienste im Cluster. Das Generieren von Tausenden von IP-Tabellenregeln und das Routing von Paketen anhand dieser Regeln wirken sich auf die Leistung der Knoten aus und erhöhen die Netzwerklatenz.

Erstellen Sie Kubernetes-Namespaces, die eine einzige Anwendungsumgebung umfassen, sofern die Anzahl der Dienste pro Namespace unter 500 liegt. Dadurch wird die Serviceerkennung klein genug gehalten, um Einschränkungen bei der Serviceerkennung zu vermeiden, und es kann Ihnen auch helfen, Konflikte bei der Benennung von Diensten zu vermeiden. Anwendungsumgebungen (z. B. dev, test, prod) sollten separate EKS-Cluster anstelle von Namespaces verwenden.

Elastic Load Balancer Balancer-Kontingente verstehen

Denken Sie bei der Erstellung Ihrer Dienste darüber nach, welche Art von Load Balancing Sie verwenden werden (z. B. Network Load Balancer (NLB) oder Application Load Balancer (ALB)). Jeder Load Balancer-Typ bietet unterschiedliche Funktionen und hat unterschiedliche Kontingente. Einige der Standardkontingente können angepasst werden, es gibt jedoch einige Kontingentobergrenzen, die nicht geändert werden können. Um Ihre Kontokontingente und Ihre Nutzung einzusehen, rufen Sie das Service-Kontingents-Dashboard in der AWS-Konsole auf.

Die ALB-Standardziele sind beispielsweise 1000. Wenn Sie einen Dienst mit mehr als 1000 Endpunkten haben, müssen Sie das Kontingent erhöhen oder den Dienst auf mehrere aufteilen oder Kubernetes ALBs Ingress verwenden. Die Standard-NLB-Ziele sind 3000, sind jedoch auf 500 Ziele pro AZ begrenzt. Wenn Ihr Cluster mehr als 500 Pods für einen NLB-Dienst ausführt, müssen Sie mehrere Pods verwenden AZs oder eine Erhöhung des Kontingentlimits beantragen.

Eine Alternative zur Verwendung eines an einen Dienst gekoppelten Load Balancers ist die Verwendung eines Ingress-Controllers. Der AWS Load Balancer-Controller kann ALBs für eingehende Ressourcen erstellen, Sie können jedoch erwägen, einen dedizierten Controller in Ihrem Cluster auszuführen. Ein Incluster-Ingress-Controller ermöglicht es Ihnen, mehrere Kubernetes-Services von einem einzigen Load Balancer aus verfügbar zu machen, indem Sie einen Reverse-Proxy in Ihrem Cluster ausführen. Controller verfügen über unterschiedliche Funktionen, z. B. Unterstützung für die Gateway-API, was je nach Anzahl und Umfang Ihrer Workloads Vorteile haben kann.

Verwenden Sie Route 53, Global Accelerator oder CloudFront

Um einen Service, der mehrere Load Balancer verwendet, als einen einzigen Endpunkt verfügbar zu machen, müssen Sie Amazon CloudFront, AWS Global Accelerator oder Amazon Route 53 verwenden, um alle Load Balancer als einen einzigen, kundenorientierten Endpunkt verfügbar zu machen. Jede Option bietet unterschiedliche Vorteile und kann je nach Bedarf separat oder zusammen verwendet werden.

Route 53 kann mehrere Load Balancer unter einem gemeinsamen Namen verfügbar machen und je nach zugewiesener Gewichtung Traffic an jeden von ihnen weiterleiten. Weitere Informationen zu DNS-Gewichtungen finden Sie in der Dokumentation. Wie Sie diese mit dem externen Kubernetes-DNS-Controller implementieren, können Sie in der Dokumentation zum AWS Load Balancer Controller nachlesen.

Global Accelerator kann Workloads auf der Grundlage der angeforderten IP-Adresse an die nächstgelegene Region weiterleiten. Dies kann für Workloads nützlich sein, die in mehreren Regionen bereitgestellt werden, verbessert jedoch nicht das Routing zu einem einzelnen Cluster in einer einzelnen Region. Die Verwendung von Route 53 in Kombination mit dem Global Accelerator bietet zusätzliche Vorteile wie Zustandsprüfung und automatisches Failover, falls keine AZ verfügbar ist. Ein Beispiel für die Verwendung von Global Accelerator mit Route 53 finden Sie in diesem Blogbeitrag.

CloudFront kann mit Route 53 und Global Accelerator oder alleine verwendet werden, um den Verkehr an mehrere Ziele weiterzuleiten. CloudFront speichert Ressourcen, die von den ursprünglichen Quellen bereitgestellt werden, wodurch die Bandbreitenanforderungen je nach dem, was Sie bereitstellen, reduziert werden können.

Verwenden Sie EndpointSlices anstelle von Endpunkten

Wenn Sie Pods finden, die einem Service-Label entsprechen, sollten Sie EndpointSlicesanstelle von Endpoints verwenden. Endpunkte waren eine einfache Möglichkeit, Dienste in kleinem Umfang verfügbar zu machen, aber große Dienste, die automatisch skaliert werden oder über Updates verfügen, verursachen eine Menge Traffic auf der Kubernetes-Steuerebene. EndpointSlices verfügen über eine automatische Gruppierung, die beispielsweise Hinweise auf Topologie ermöglicht.

Nicht alle Controller verwenden EndpointSlices standardmäßig. Sie sollten Ihre Controller-Einstellungen überprüfen und sie bei Bedarf aktivieren. Für den AWS Load Balancer Controller sollten Sie das --enable-endpoint-slices optionale Flag zur Verwendung EndpointSlices aktivieren.

Verwenden Sie nach Möglichkeit unveränderliche und externe Geheimnisse

Das Kubelet speichert die aktuellen Schlüssel und Werte für die Secrets, die in Volumes für Pods auf diesem Knoten verwendet werden. Das Kubelet überwacht die Secrets, um Änderungen zu erkennen. Wenn der Cluster skaliert wird, kann sich die wachsende Anzahl von Watches negativ auf die Leistung des API-Servers auswirken.

Es gibt zwei Strategien, um die Anzahl der Zugriffe auf Secrets zu reduzieren:

• Für Anwendungen, die keinen Zugriff auf Kubernetes-Ressourcen benötigen, können Sie das automatische Mounten von Dienstkontogeheimnissen deaktivieren, indem Sie Token: false festlegen automountServiceAccount

• Wenn die Geheimnisse Ihrer Anwendung statisch sind und in future nicht geändert werden, markieren Sie das Geheimnis als unveränderlich. Das Kubelet überwacht die API nicht nach unveränderlichen Geheimnissen.

Um das automatische Mounten eines Dienstkontos auf Pods zu deaktivieren, können Sie die folgende Einstellung in Ihrem Workload verwenden. Sie können diese Einstellungen überschreiben, wenn für bestimmte Workloads ein Dienstkonto erforderlich ist.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
automountServiceAccountToken: true

Überwachen Sie die Anzahl der Secrets im Cluster, bevor sie das Limit von 10.000 überschreitet. Mit dem folgenden Befehl können Sie die Gesamtzahl der Geheimnisse in einem Cluster anzeigen. Sie sollten dieses Limit mit Ihren Cluster-Überwachungstools überwachen.

kubectl get secrets -A | wc -l

Sie sollten die Überwachung so einrichten, dass ein Cluster-Administrator benachrichtigt wird, bevor dieses Limit erreicht wird. Erwägen Sie die Verwendung externer Secrets-Management-Optionen wie AWS Key Management Service (AWS KMS) oder Hashicorp Vault mit dem Secrets Store CSI-Treiber.

Beschränken Sie den Bereitstellungsverlauf

Pods können beim Erstellen, Aktualisieren oder Löschen langsam sein, da alte Objekte immer noch im Cluster nachverfolgt werden. Sie können die Anzahl revisionHistoryLimit der Bereitstellungen reduzieren, um ältere Versionen zu bereinigen ReplicaSets , wodurch die Gesamtanzahl der vom Kubernetes Controller Manager verfolgten Objekte reduziert wird. Das Standardlimit für den Verlauf von Bereitstellungen beträgt 10.

Wenn Ihr Cluster viele Auftragsobjekte durch CronJobs oder andere Mechanismen erstellt, sollten Sie diese ttlSecondsAfterFinishedEinstellung verwenden, um alte Pods im Cluster automatisch zu bereinigen. Dadurch werden erfolgreich ausgeführte Jobs nach einer bestimmten Zeit aus dem Jobverlauf entfernt.

enableServiceLinks Standardmäßig deaktivieren

Wenn ein Pod auf einem Knoten ausgeführt wird, fügt das Kubelet für jeden aktiven Dienst eine Reihe von Umgebungsvariablen hinzu. Linux-Prozesse haben eine maximale Größe für ihre Umgebung, die erreicht werden kann, wenn Sie zu viele Dienste in Ihrem Namespace haben. Die Anzahl der Dienste pro Namespace sollte 5.000 nicht überschreiten. Danach überschreitet die Anzahl der Dienstumgebungsvariablen die Shell-Limits, was dazu führt, dass Pods beim Start abstürzen.

Es gibt noch andere Gründe, warum Pods keine Dienstumgebungsvariablen für die Diensterkennung verwenden sollten. Namenskonflikte bei Umgebungsvariablen, undichte Dienstnamen und die Gesamtgröße der Umgebung sind nur einige Beispiele. Sie sollten CoreDNS verwenden, um Service-Endpunkte zu erkennen.

Beschränken Sie Webhooks mit dynamischer Zulassung pro Ressource

Zu den Webhooks mit dynamischer Zulassung gehören Webhooks für die Zulassung und Webhooks mit mutierender Zulassung. Sie sind API-Endpunkte, die nicht Teil der Kubernetes Control Plane sind und nacheinander aufgerufen werden, wenn eine Ressource an die Kubernetes-API gesendet wird. Jeder Webhook hat ein Standard-Timeout von 10 Sekunden und kann die Dauer einer API-Anfrage verlängern, wenn Sie mehrere Webhooks oder einen Timeout für einen dieser Webhooks haben.

Stellen Sie sicher, dass Ihre Webhooks hochverfügbar sind — insbesondere während eines AZ-Vorfalls — und dass die FailurePolicy so eingestellt ist, dass sie die Ressource ablehnt oder den Fehler ignoriert. Rufen Sie Webhooks nicht auf, wenn sie nicht benötigt werden, indem Sie zulassen, dass --dry-run kubectl-Befehle den Webhook umgehen.

apiVersion: admission.k8s.io/v1
kind: AdmissionReview
request:
  dryRun: False

Durch das Mutieren von Webhooks können Ressourcen häufig hintereinander verändert werden. Wenn Sie 5 mutierende Webhooks haben und 50 Ressourcen bereitstellen, speichert etcd alle Versionen jeder Ressource, bis die Komprimierung ausgeführt wird — alle 5 Minuten —, um alte Versionen der geänderten Ressourcen zu entfernen. In diesem Szenario, wenn etcd veraltete Ressourcen entfernt, werden 200 Ressourcenversionen von etcd entfernt. Je nach Größe der Ressourcen kann dies beträchtlichen Speicherplatz auf dem etcd-Host beanspruchen, bis die Defragmentierung alle 15 Minuten ausgeführt wird.

Diese Defragmentierung kann zu Pausen in etcd führen, die andere Auswirkungen auf die Kubernetes-API und die Controller haben könnten. Sie sollten häufige Änderungen großer Ressourcen oder die Änderung von Hunderten von Ressourcen in schneller Folge vermeiden.

Vergleichen Sie Workloads in mehreren Clustern

Wenn Sie zwei Cluster haben, die eine ähnliche Leistung haben sollten, dies aber nicht tun, versuchen Sie, die Metriken zu vergleichen, um den Grund zu ermitteln.

Beispielsweise ist der Vergleich der Cluster-Latenz ein häufiges Problem. Dies wird normalerweise durch einen Unterschied im Volumen der API-Anfragen verursacht. Sie können die folgende CloudWatch LogInsight Abfrage ausführen, um den Unterschied zu verstehen.

filter @logStream like "kube-apiserver-audit"
| stats count(*) as cnt by objectRef.apiGroup, objectRef.apiVersion, objectRef.resource, userAgent, verb, responseStatus.code
| sort cnt desc
| limit 1000

Sie können zusätzliche Filter hinzufügen, um es einzugrenzen. Sie können sich z. B. auf alle Listenanfragen von konzentrierenfoo.

filter @logStream like "kube-apiserver-audit"
| filter verb = "list"
| filter user.username like "foo"
| stats count(*) as cnt by objectRef.apiGroup, objectRef.apiVersion, objectRef.resource, responseStatus.code
| sort cnt desc
| limit 1000