Unterstützung für die Verbesserung dieser Seite beitragen
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Erweiterte Konfiguration der Kubernetes-Steuerungsebene
-Übersicht
Amazon EKS verwaltet die Kubernetes-Steuerungsebene für Ihren Cluster, einschließlich des API-Servers, des Schedulers und des Controller-Managers. EKS führt diese Komponenten mit standardmäßigen Upstream-Kubernetes-Einstellungen aus, die für die meisten Workloads gut funktionieren, und Sie müssen sie für die meisten Cluster nicht ändern. Einige Workloads profitieren jedoch von unterschiedlichen Einstellungen der Steuerungsebene. Vielleicht möchten Sie, dass der Scheduler Pods auf weniger Knoten packt, um die Rechenkosten zu senken, Kubernetes-Ereignisse für einen kürzeren Zeitraum speichert, um das Wachstum der Cluster-Datenbank (etcd) zu begrenzen, oder Autoscaling-Entscheidungen häufiger evaluiert.
Mit der erweiterten Konfiguration der Kubernetes-Steuerungsebene legen Sie diese Parameter direkt in Ihrem Cluster fest. EKS wendet sie auf die Steuerungsebene an, und Ihr Cluster arbeitet weiterhin mit den gleichen Verfügbarkeits- und Leistungsmerkmalen.
Dies sind erweiterte Konfigurationen. Jeder Konfigurationsparameter ändert, wie sich eine zentrale Kubernetes-Steuerungsebenenkomponente für Workloads verhält, die auf dem Cluster ausgeführt werden. Der richtige Wert hängt von Ihrer Arbeitslast ab. Bevor Sie einen Parameter ändern, lesen Sie die entsprechenden Überlegungen in den folgenden Abschnitten und testen Sie die Änderung in einem Nicht-Produktionscluster.
Sie können erweiterte Konfigurationsparameter für die Steuerungsebene festlegen, wenn Sie einen Cluster erstellen, oder sie auf einem vorhandenen Cluster jederzeit aktualisieren. Diese Funktion verwendet die vorhandenen Parameter CreateCluster und UpdateClusterConfig Operationen mit neuen Parametern, sodass Sie sie über AWS CLI AWS-Managementkonsole, AWS SDKs oder AWS CloudFormation festlegen können. EKS validiert jede Konfiguration, bevor sie angewendet wird, und zeichnet Änderungen auf. AWS CloudTrail
Erweiterte Parameter der Steuerungsebene gelten für den gesamten Cluster und für alle darauf ausgeführten Workloads. Sie können sie nicht auf einzelne Namespaces oder Workloads beschränken. EKS beschränkt jeden Parameter auf einen validierten Bereich. Die unterstützten Werte für jeden Parameter sind zusammen mit diesem Parameter im folgenden Abschnitt aufgeführt.
Parameter der Kubernetes-Steuerungsebene werden unterstützt
Amazon EKS unterstützt die folgenden Parameter. Jeder Parameter gehört zu einer Steuerungsebenenkomponente und wird über das Konfigurationsfeld für diese Komponente festgelegt: kubeSchedulerConfigkubeControllerManagerConfig, oderkubeApiServerConfig.
| Komponente | Parameter | Unterstützte Werte | Standard | Erfordert eine bereitgestellte Steuerungsebene |
|---|---|---|---|---|
|
Kube-Scheduler |
|
|
|
Nein |
|
Kube-Controller-Manager |
|
|
|
Ja |
|
Kube-Controller-Manager |
|
|
|
Ja |
|
Kube-Api-Server |
|
|
|
Nein |
|
kube-apiserver |
|
|
|
Nein |
Die Standardwerte und unterstützten Werte in diesem Thema gelten für die Kubernetes-Version (EKS v1.31 und höher), die bei der Veröffentlichung verfügbar ist, und können sich in späteren Versionen ändern. Der DescribeClusterVersions Vorgang meldet die aktuellen Standardwerte und unterstützten Werte für jeden Parameter und jede Kubernetes-Version. Verwenden Sie sie daher als Informationsquelle, wenn Sie Cluster über mehrere Versionen hinweg verwalten oder die Cluster-Konfiguration automatisieren. Weitere Informationen finden Sie unter Konfigurieren Sie erweiterte Parameter der Kubernetes-Steuerungsebene.
In den folgenden Abschnitten wird jeder Parameter beschrieben, wann er geändert werden muss und was vorher zu beachten ist.
Scheduler: Die Knotenressourcen passen
Der Scheduler weist den Knoten in zwei Phasen Pods zu. Er filtert zuerst die Knoten, auf denen ein Pod ausgeführt werden kann, bewertet dann die verbleibenden Kandidaten und platziert den Pod auf dem Knoten mit der höchsten Bewertung. Das nodeResourcesFit Plugin prüft, ob ein Knoten über die Ressourcen verfügt, die ein Pod anfordert, und bewertet die Knoten gemäß einer Bewertungsstrategie.
| Feld | Description | Unterstützte Werte | Standard |
|---|---|---|---|
|
|
Die Strategie, mit der Knoten anhand der Ressourcenzuweisung bewertet werden. |
|
|
|
|
Die bei der Bewertung berücksichtigten Ressourcen, jede mit einem relativen Gewicht. |
|
|
LeastAllocatedbevorzugt Knoten mit geringerer Ressourcenzuweisung, wodurch die Pods auf die Knoten in Ihrem Cluster verteilt werden und auf jedem Knoten mehr Spielraum bleibt. Dies ist das Standardverhalten von Kubernetes und eine gute Wahl, wenn Sie möchten, dass auf jedem Knoten Kapazität verfügbar ist, um das Wachstum vorhandener Pods abzufangen.
MostAllocatedbevorzugt Knoten, die bereits eine höhere Ressourcenzuweisung haben, wodurch die Pods auf weniger Knoten gepackt werden. Da Ihre Workloads weniger Gesamtkapazität beanspruchen, können Sie sie auf einer geringeren Anzahl von Knoten ausführen und die Rechenausgaben reduzieren. Im Laufe der Zeit hält dieses Packverhalten wenig genutzte Knoten von neuen Workloads fern, sodass Node-Pools, die die Konsolidierung unterstützen, diese entfernen können.
EKS unterstützt die LeastAllocated und MostAllocated -Strategien. Die RequestedToCapacityRatio Upstream-Kubernetes-Strategie wird nicht unterstützt.
Gewichte der Ressourcen
Sie können optional ein resources Array mit benutzerdefinierten Gewichtungen angeben, um zu beeinflussen, welche Ressourcen bei Bewertungsentscheidungen am wichtigsten sind. Dies ist nützlich, wenn eine bestimmte Ressource die Einschränkung in Ihrem Cluster darstellt. Beispielsweise konzentriert sich bei Clustern, in denen Beschleuniger (GPU) die knappe Ressource sind, bei einer Gewichtung nvidia.com/gpu über CPU und Arbeitsspeicher die Pods, die den Beschleuniger anfordern, auf Knoten, die bereits teilweise belegt sind.
Die Gewichtungen sind relativ, nicht absolut. Wird gesetzt cpu: 100 und führt memory: 1 nicht dazu, dass der Scheduler den Speicher ignoriert. In der Bewertungsformel wird die CPU 100-mal schwerer belastet als der Arbeitsspeicher. Wenn alle Kandidatenknoten die gleiche CPU-Verfügbarkeit haben, unterscheidet die CPU sie nicht mehr, und die Bewertung wird effektiv auf den Arbeitsspeicher übertragen.
Das Weglassen einer Ressource ist etwas anderes, als ihr ein niedriges Gewicht zuzuweisen. Wenn Sie ein resources Array angeben, werden nur die von Ihnen aufgelisteten Ressourcen bewertet. Eine Ressource, die Sie auslassen, wird vollständig von der Berechnung ausgeschlossen. Wenn beispielsweise kein memory Eintrag vorhanden ist, cpu: 100 werden Knoten nur auf der CPU bewertet, und die Speicherverfügbarkeit hat keinen Einfluss auf das Ergebnis. Um eine Ressource in der Berechnung beizubehalten und gleichzeitig ihren Einfluss zu reduzieren, sollten Sie sie mit einer niedrigen Gewichtung auflisten, anstatt sie wegzulassen.
Die Gewichtung einer Beschleuniger-Ressource wirkt sich beispielsweise nvidia.com/gpu nur auf die Bewertung von Pods aus, die sich tatsächlich für diese Ressource deklarierenresources.requests. Pods, die keine Beschleuniger anfordern, werden nicht vom Gewicht des Beschleunigers beeinflusst.
Bei den drei Accelerator-Ressourcen handelt es sich um erweiterte Kubernetes-Ressourcen, d. h. Ressourcen auf Knotenebene, die Kubernetes über ein Plugin beworben und nicht eingebaut werden. Sie werden nur bewertet, wenn ein Geräte-Plugin sie über die Geräte-Plugin-API beim Kubelet ankündigt. Ressourcen, die allein von einem Gerätetreiber auf einem Knoten zur Verfügung gestellt werden, sind für das nodeResourcesFit Plugin nicht sichtbar und werden nicht bewertet. Ressourcen, die über die dynamische Ressourcenzuweisung (DRA) verwaltet werden, werden von einem separaten Plugin geplant und sind nicht Teil nodeResourcesFit der Bewertung. Die Aktivierung von DRA ändert also nichts am Verhalten dieses Parameters. Weitere Informationen zur Konfiguration von NVIDIA-Geräte-Plug-ins finden Sie unter NVIDIA DRA und Geräte-Plug-In. Weitere Informationen zur Konfiguration von Neuron-Geräten finden Sie unter Neuron-Geräteverwaltung.
Die Bewertungsstrategie ist eine von mehreren Eingaben, die der Scheduler verwendet, um eine Punktzahl für jeden Knoten zu berechnen. Weitere Informationen darüber, wie der Scheduler Knoten filtert und bewertet, finden Sie unter Scheduling Framework
Überlegungen zur Bewertungsstrategie
-
Laufende Pods werden nicht verschoben. Der Kubernetes-Scheduler verschiebt niemals einen Pod, der bereits läuft. Eine Änderung der Bewertungsstrategie wirkt sich nur auf zukünftige Planungsentscheidungen aus, und die bestehende Pod-Platzierung ist dauerhaft. Um bereits laufende Pods wieder ins Gleichgewicht zu bringen, müssen Sie sie entfernen oder neu starten.
-
Das Filterverhalten ändert sich nicht. Die Bewertungsstrategie wirkt sich nur auf die Bewertungsphase aus, in der der Scheduler die Knoten nach Präferenz sortiert. Die Filterphase, die bestimmt, ob ein Pod überhaupt auf einem Knoten ausgeführt werden kann, ist unverändert. Ein Pod, der nicht auf einen Knoten passt, ist dort im Rahmen einer der beiden Strategien immer noch nicht eingeplant.
-
MostAllocatedkonzentriert den Explosionsradius. Das Packen von Workloads auf weniger Knoten bedeutet, dass mehr Pods gleichzeitig betroffen sind, wenn ein Knoten defekt wird, eine Instance außer Betrieb genommen wird oder eine Availability Zone unterbrochen wird. Bei hoher Pod-Abwanderung füllen sich dicht gepackte Knoten auch schneller, sodass die Pods möglicherweise imPendingZustand bleiben, während neue Kapazitäten bereitgestellt werden. -
Der Scheduler und das Node-Management arbeiten auf verschiedenen Ebenen. Die Bewertungsstrategie beeinflusst, wo Pods zwischen den Knoten platziert werden, auf denen sie bereits ausgeführt werden können. Es ändert nichts daran, wie EKS Auto Mode oder Karpenter Knoten bereitstellen oder entfernen. Überprüfen Sie das kombinierte Verhalten für Ihre Arbeitslast, bevor Sie die Konfiguration ändern.
Controller-Manager: Synchronisierungszeitraum für den horizontalen Pod Autoscaler
Der Controller-Manager führt die Kubernetes-Controller aus, die den Cluster-Status in den gewünschten Zustand bringen, einschließlich des Horizontal Pod Autoscaler (HPA) -Controllers. In jedem Zyklus ruft der HPA-Controller Metriken für jedes HorizontalPodAutoscaler Objekt ab, berechnet die gewünschte Replikatanzahl und aktualisiert den Ziel-Workload, wenn sich die Anzahl geändert hat.
| Feld | Description | Unterstützte Werte | Standard |
|---|---|---|---|
|
|
Wie oft der HPA-Controller Skalierungsentscheidungen auswertet. |
|
|
Die Verkürzung des Synchronisierungszeitraums bedeutet, dass Ihre Workloads nach Lasterhöhungen früher skaliert werden, anstatt einen ganzen Zyklus abzuwarten, bevor Kapazität hinzugefügt wird.
Um diesen Parameter zu konfigurieren, muss sich Ihr Cluster auf Amazon EKS Provisioned Control Plane befinden. Eine Verkürzung des Intervalls erhöht die Geschwindigkeit, mit der der HPA-Controller jedes HorizontalPodAutoscaler Objekt im Cluster abgleicht, wodurch mehr API-Anfragen generiert werden. Für jeden Abgleich wird mindestens eine API-Anfrage benötigt, und für einen Abgleich, der die Anzahl der Replikate ändert, werden zwei weitere benötigt. Bereitgestellte Control Plane-Cluster weisen vorab die Kapazität der Kontrollebene zu, die immer für anspruchsvolle Workloads bereit ist. Sie sind so dimensioniert, dass sie diese zusätzliche Last aufnehmen können. Weitere Informationen finden Sie unter Von Amazon EKS bereitgestellte Steuerungsebene.
Auswirkung auf die Anzahl der HPA-Objekte, die Ihr Cluster unterstützt
-
Durch die Verkürzung des Synchronisierungszeitraums verringert sich die Anzahl der
HorizontalPodAutoscalerObjekte, die Ihre Steuerungsebene termingerecht abgleichen kann, da der Controller weniger Zeit hat, dieselbe Warteschlange abzuarbeiten. Wenn Sie den Zeitraum von15sbis verkürzen, wird die Anzahl der unterstützten Objekte um etwa ein Drittel10sgesenkt. Bevor Sie den Synchronisierungszeitraum verkürzen, zählen Sie dieHorizontalPodAutoscalerObjekte in Ihrem Cluster und stellen Sie sicher, dass der kürzere Zeitraum diese Anzahl auf Ihrer Skalierungsstufe noch unterstützt:kubectl get hpa --all-namespaces --no-headers | wc -l -
EKS validiert den Synchronisierungszeitraum nicht anhand Ihrer HPA-Objektanzahl. Die Konfigurationsänderung ist auch dann erfolgreich, wenn Ihr Cluster bereits mehr
HorizontalPodAutoscalerObjekte enthält, als der kürzere Zeitraum unterstützt. Überprüfen Sie die Anzahl selbst, bevor Sie die Änderung vornehmen. -
Wenn Sie den unterstützten Zähler überschreiten, wird die automatische Skalierung im Hintergrund beeinträchtigt. Wenn der Controller nicht alle Objekte innerhalb des Zeitraums abarbeiten kann, werden einige Objekte nicht termingerecht abgeglichen. EKS gibt für diesen Zustand weder einen Alarm noch ein Kubernetes-Ereignis aus, und das Symptom ist eine automatische Skalierung, die langsamer als erwartet reagiert — das Gegenteil des beabsichtigten Effekts. Wenn Sie nach der Verkürzung des Synchronisierungszeitraums eine verzögerte Skalierung feststellen, setzen Sie den Parameter auf die Standardeinstellung von zurück.
15s -
Der Synchronisierungszeitraum gilt für jedes HPA-Objekt im Cluster. Sie können keine unterschiedlichen Synchronisierungszeiträume für verschiedene Objekte oder Namespaces festlegen.
Controller-Manager: Schwellenwert für die Speicherbereinigung von Pods wurde beendet
Der Controller-Manager führt den beendeten Pod-Garbage-Collector (den Pod-GC-Controller) aus. Dieser Controller löscht terminierte Pods — Pods in der Failed OR-Phase —, nachdem die Succeeded Anzahl der terminierten Pods im Cluster einen Schwellenwert überschritten hat. terminatedPodGcThresholdDer Parameter legt diesen Schwellenwert fest.
| Feld | Description | Unterstützte Werte | Standard |
|---|---|---|---|
|
|
Die Anzahl der beendeten Pods, die existieren können, bevor der Garbage Collector mit dem Löschen beendeter Pods beginnt. |
|
|
Der Garbage Collector läuft in einem festen 20-Sekunden-Zyklus. Wenn Sie den Schwellenwert senken, beginnt der Collector im nächsten Zyklus mit dem erzwungenen Löschen der ältesten beendeten Pods, bis die Anzahl den neuen Schwellenwert erreicht.
Um diesen Parameter zu konfigurieren, muss sich Ihr Cluster auf der Amazon EKS Provisioned Control Plane befinden. Wenn Sie den Schwellenwert senken, erhöht sich die Garbage-Collection-Arbeit, die der Controller mit der Cluster-Datenbank (etcd) durchführt. Mit jedem Sammeldurchlauf können weitere terminierte Pods abgefragt, verarbeitet und gelöscht werden. Bereitgestellte Control Plane-Cluster weisen vorab die Kapazität der Kontrollebene zu, die immer für anspruchsvolle Workloads bereit ist, sodass sie diese zusätzliche Last aufnehmen können. Weitere Informationen finden Sie unter Von Amazon EKS bereitgestellte Steuerungsebene.
Überlegungen zum Schwellenwert für die Garbage-Collection bei Terminierung
-
Wenn Sie den Schwellenwert senken, werden überschüssige terminierte Pods sofort gelöscht. Wenn Sie den Schwellenwert senken (z. B. von
12500bis10000), beginnt der Garbage Collection-Controller im nächsten Zyklus mit dem erzwungenen Löschen der ältesten beendeten Pods. Der Controller fährt fort, bis die Anzahl der beendeten Pods den neuen Schwellenwert erreicht. Die Reduzierung erfolgt nicht schrittweise. -
Der Schwellenwert gilt für alle beendeten Pods, unabhängig vom Besitzer. Es wirkt sich auf Pods in der
SucceededFailedOR-Phase aus, unabhängig davon CronJob, ob sie einem Job oder einem Deployment gehören oder ob sie eigenständig sind. In der Praxis tragen Job und CronJob Pods am häufigsten zur Anzahl der beendeten Pods bei. -
Wenn Sie den Schwellenwert senken, wird das Debugging-Fenster reduziert. Abgeschlossene und fehlgeschlagene Pods verschwinden von
kubectl get podsundkubectl logsfrüher. Die Automatisierung, die Exit-Codes oder Logs abgeschlossener Job-Pods überprüft, hat ein kleineres Bedienfenster. -
Der Schwellenwert ist eine globale Cluster-Einstellung. Sie können es nicht pro Namespace oder pro Job konfigurieren. Um den Lebenszyklus der Pods eines einzelnen Jobs zu steuern, verwenden Sie „
ttlSecondsAfterFinishedon this Job“.
API-Server: Aufbewahrung von Ereignissen
Der API-Server ist das Frontend für die Kubernetes-Steuerungsebene. Er dient der Kubernetes-API und speichert den Clusterstatus in der Cluster-Datenbank (etcd). Kubernetes zeichnet Ereignisse auf, um zu beschreiben, was in Ihrem Cluster vor sich geht, z. B. Entscheidungen zur Pod-Planung, Image-Pulls, fehlgeschlagene Integritätsprüfungen und Skalierungsaktionen.
| Feld | Description | Unterstützte Werte | Standard |
|---|---|---|---|
|
|
Wie lange der API-Server Kubernetes-Ereignisse aufbewahrt, bevor sie gelöscht werden. |
|
|
Cluster, in denen Workloads mit hoher Abwanderungsrate ausgeführt werden, wie z. B. umfangreiche Batch-Jobs, KI-Workloads, CI/CD Pipelines usw., sammeln sich schnell Tausende von Ereignissen an. CronJobs Jedes gespeicherte Ereignis verbraucht Speicherplatz in der Cluster-Datenbank, der mit den Objekten konkurriert, die Ihr Cluster für die Ausführung benötigt, und eine große Sammlung von Ereignissen macht die Bereitstellung von API-Serverlisten teurer.
Durch eine Verkürzung der Aufbewahrung von Ereignissen werden diese kurzlebigen Diagnosedaten früher gelöscht, wodurch der Speicherdruck in der Cluster-Datenbank reduziert und die Antwortzeiten des API-Servers bei ereignisintensiven Abfragen verbessert werden.
Eine kürzere Aufbewahrungsfrist ist gut geeignet, wenn:
-
Ihr Cluster führt Batch- CI/CD, KI- oder CronJob Workloads aus, die ein hohes Volumen an Ereignissen generieren.
-
Sie beobachten, wie der Cluster-Datenbankspeicher an sein Limit heranwächst.
-
Sie verlassen sich auf ein externes System, um Ereignisse dauerhaft aufzuzeichnen, und Sie sind nicht darauf angewiesen, wenn es
kubectl get eventsum historische Debugging geht.
Überlegungen zur Aufbewahrung von Ereignissen
-
Eine Änderung gilt nur für neue Ereignisse. Kubernetes legt den Ablauf eines Ereignisses fest, wenn das Ereignis erstellt wird. Bereits existierende Ereignisse behalten die Aufbewahrungsfrist bei, die bei ihrer Erstellung galt, und laufen nach diesem Zeitplan ab. Durch die Verkürzung wird die Lebensdauer von Ereignissen, die sich bereits in der Cluster-Datenbank befinden,
eventTtlnicht verkürzt, sodass die Reduzierung des Speichers schrittweise wirksam wird, wenn bestehende Ereignisse ablaufen. -
Gelöschte Ereignisse können nicht wiederhergestellt werden. Nachdem Kubernetes ein Ereignis entfernt hat, ist es dauerhaft weg. Wenn Sie die Aufbewahrung weiter als beabsichtigt verkürzen und den Eventverlauf verlieren, gibt es keine Möglichkeit, ihn wiederherzustellen. Stellen Sie sicher, dass alles, worauf Sie bei der Problembehandlung angewiesen sind, außerhalb des Clusters erfasst wird, bevor Sie diesen Wert verkürzen.
-
Ereignisse können leicht über den konfigurierten Zeitraum hinaus andauern. Unter bestimmten Bedingungen kann der Ablauf eines Ereignisses über den von Ihnen konfigurierten Wert hinaus verlängert werden, da die etcd-Leasingverlängerung während der Wahl zum Anführer der Kontrollebene erfolgen kann.
-
Reduziertes Debugging-Fenster. Eine kürzere Aufbewahrungsfrist verengt das mit
kubectl get eventsundkubectl describeangezeigte Fenster. Bei Überwachungstools, die Ereignisse aus dem Cluster entfernen, sind weniger Daten verfügbar. Wählen Sie einen Wert, der die Speichereffizienz mit Ihrem Debugging-Workflow in Einklang bringt. -
Die Einstellung gilt für den gesamten Cluster. Die Aufbewahrung gilt für alle Ereignisse, einschließlich Pod-Planung, Knotenbedingungen und Skalierungsereignisse, in jedem Namespace. Sie können nicht für jeden Namespace unterschiedliche Aufbewahrungsfristen festlegen.
API-Server: Portbereich des Dienstknotens
Kubernetes weist jedem Dienst, der einen benötigt, auf jedem Knoten einen Port aus diesem Bereich zu. Dazu gehören Dienste des Typs NodePort und standardmäßig Dienste des Typs. LoadBalancer
| Feld | Description | Unterstützte Werte | Standard |
|---|---|---|---|
|
|
Der niedrigste Port im Bereich. |
|
|
|
|
Der höchste Port im Bereich. |
|
|
minPortmuss kleiner oder gleich seinmaxPort. Amazon EKS lehnt eine Konfiguration ab, deren Wert größer als minPort maxPort ist.
Indem Sie den Bereich ändern, können Sie die Node-Portzuweisung an die Netzwerk- und Firewall-Richtlinien anpassen, die Ihr Unternehmen bereits durchsetzt. Durch die Erweiterung des Bereichs erhöht sich auch die Anzahl der Dienste, die ein einzelner Cluster unterstützen kann. Dieser Parameter ist besonders bei Migrationen nützlich. Anwendungen, die zu Amazon EKS migrieren, und die Clients, die sie aufrufen, erwarten häufig Dienste an bestimmten festen Ports. Wenn diese Ports außerhalb des Standardbereichs liegen, besteht die übliche Option darin, die Anwendung zu modifizieren oder einen Proxy davor zu platzieren. Wenn Sie den Bereich an den Ports ausrichten, die Ihre Anwendungen bereits verwenden, entfällt diese Arbeit, sodass Sie Workloads auf EKS verschieben können, ohne sie neu schreiben oder zu wartende Netzwerkkomponenten hinzufügen zu müssen.
Warum ist der Bereich auf 10260 und 32767 begrenzt
10260Durch die Untergrenze von werden Ports, die Kubernetes-Systemkomponenten auf Ihren Knoten bereits verwenden, bei der NodePort Zuweisung ausgeschlossen, einschließlich des Kubelet-Health-Ports (10248) und des Kube-Proxy-Health-Check-Ports (). 10256
Die Obergrenze von 32767 hält den Bereich vom kurzlebigen Linux-Port-Bereich fern, der normalerweise bei beginnt. 32768 Wenn a in den kurzlebigen Bereich NodePort fällt, könnte der Kernel diesen Port für eine ausgehende Verbindung vom Knoten auswählen und einen Konflikt mit dem Dienst verursachen.
Überlegungen zum Portbereich des Serviceknotens
-
Bestehende Dienste behalten ihre zugewiesenen Ports. Wenn Sie den Bereich einschränken, funktionieren Dienste, die bereits einen Port außerhalb des neuen Bereichs haben, weiterhin, und Kube-Proxy leitet den Verkehr weiterhin an sie weiter. Amazon EKS weist den vorhandenen Diensten keine neuen Ports zu, wenn sich der Bereich ändert.
-
Wenn Sie einen Dienst neu erstellen, wird sein Port neu zugewiesen. Wenn ein Dienst, der einen Port außerhalb des zulässigen Bereichs enthält, gelöscht und neu erstellt wird, kann dieser Port nicht mehr zugewiesen werden. Planen Sie dies ein, bevor Sie einen Bereich einschränken, von dem bestehende Dienste abhängen, insbesondere wenn Ihr Bereitstellungsprozess Dienste neu erstellt, anstatt sie zu aktualisieren.
-
Neue Zuweisungen außerhalb des Bereichs werden abgelehnt. Das Erstellen oder Aktualisieren eines Dienstes, der einen Port außerhalb des konfigurierten Bereichs benötigt, schlägt mit einem Validierungsfehler vom API-Server fehl.
-
Explizit angegebene Ports werden ebenfalls validiert. Wenn ein Dienst einen
nodePortWert direkt angibt, anstatt Kubernetes einen Wert zuweisen zu lassen, muss dieser Port innerhalb des konfigurierten Bereichs liegen. Eine statische Port-Anfrage außerhalb des Bereichs wird abgelehnt, auch wenn derselbe Port in einem größeren Bereich gültig war, den Sie zuvor konfiguriert haben. -
Der Bereich ist clusterweit. Sie können keine unterschiedlichen Bereiche für verschiedene Namespaces konfigurieren.
Bevor Sie diesen Parameter ändern, stellen Sie sicher, dass Ihre Sicherheitsgruppen und Netzwerk-ACLs den Verkehr im neuen Bereich zulassen und dass der Bereich nicht mit Ports in Konflikt steht, die von anderer Software auf Ihren Knoten verwendet werden.
Überlegungen
Überprüfen Sie die folgenden Punkte, bevor Sie erweiterte Parameter für die Steuerungsebene konfigurieren.
-
Cluster-wide Umfang — Die Parameter der Steuerungsebene gelten für den gesamten Cluster und für alle Workloads, die darauf ausgeführt werden. Sie können sie nicht auf einzelne Namespaces oder Workloads beschränken. Testen Sie Parameteränderungen in einem Nicht-Produktionscluster, bevor Sie sie auf die Produktion anwenden.
-
Provisioned Control Plane ist für den Synchronisierungszeitraum mit horizontalem Pod Autoscaler und Schwellenwert für die Garbage-Collection bei beendetem Pod erforderlich — Die
terminatedPodGcThresholdParameterhorizontalPodAutoscalerSyncPeriodund sind nur auf Clustern verfügbar, die Amazon EKS Provisioned Control Plane verwenden. Amazon EKS beschränkt Parameter, die den Ressourcenverbrauch der Kontrollebene erheblich erhöhen, auf Cluster mit vorab zugewiesener Kapazität auf der Kontrollebene. Das Einstellen eines der Parameter auf einem Cluster im Standardmodus der Steuerungsebene schlägt fehl. Um sie zu verwenden, verschieben Sie zuerst Ihren Cluster auf eine Skalierungsstufe für die bereitgestellte Kontrollebene. Weitere Informationen finden Sie unter Von Amazon EKS bereitgestellte Steuerungsebene. -
Ausgangsbeschränkung für den Horizontal-Pod-Autoscaler-Synchronisierungszeitraum und Schwellenwert für die Speicherbereinigung bei beendetem Pod — Wenn
horizontalPodAutoscalerSyncPeriododer auf einen anderen Wert als den Standardwert gesetztterminatedPodGcThresholdist, können Sie die Steuerungsebene Ihres Clusters nicht vom Bereitstellungsmodus zurück in den Standardmodus verschieben. Um zum Standardmodus zurückzukehren, setzen Sie zunächst beide Parameter auf ihre Standardwerte (15sund12500) zurück und ändern Sie dann die Skalierungsstufe der Steuerungsebene auf.standard -
Zurück zu den Standardwerten — Amazon EKS bietet keinen speziellen Reset-Vorgang, und wenn ein Feld bei einer Aktualisierung weggelassen wird, bleibt der aktuelle Wert erhalten, anstatt ihn zu löschen. Um einen Parameter auf seinen Standardwert zurückzusetzen, setzen Sie ihn explizit auf den Standardwert. Rufen Sie den Standardwert
DescribeClusterVersionsfür die Kubernetes-Version ab, die Ihr Cluster ausführt. Weitere Informationen finden Sie unter Konfigurieren Sie erweiterte Parameter der Kubernetes-Steuerungsebene. -
Semantik aktualisieren — Updates werden mit Ihrer vorhandenen Konfiguration zusammengeführt. Nur die Felder, die Sie angeben, ändern sich, und Felder, die Sie weglassen, behalten ihre aktuellen Werte. Dies gilt sowohl für alle Komponenten als auch für eine einzelne Komponente. Beispielsweise lässt ein Update, das nur die Scheduler-Konfiguration angibt, Ihre Controller-Manager- und API-Serverkonfiguration unverändert.
-
Aktuelle Konfiguration anzeigen — Der
describe-clusterVorgang gibt die vollständige Konfiguration zurück, die auf Ihrer Steuerungsebene ausgeführt wird, einschließlich der Parameter, die Sie nicht angepasst haben, und ihrer Standardwerte. -
Standardwerte und unterstützte Werte können sich zwischen den Kubernetes-Versionen ändern — Die in diesem Thema dokumentierten Werte gelten für die Kubernetes-Versionen, die bei der Veröffentlichung verfügbar sind. Wird verwendet
DescribeClusterVersions, um die aktuellen Standardwerte und unterstützten Werte für jeden Parameter und jede Kubernetes-Version abzurufen. Siehe Konfigurieren Sie erweiterte Parameter der Kubernetes-Steuerungsebene. -
Bestehende Cluster sind unverändert — Amazon EKS ändert das Verhalten vorhandener Cluster nicht. Alle Cluster werden weiterhin mit Standardparameterwerten ausgeführt, bis Sie explizit einen Parameter festlegen.
-
Änderungen werden nicht sofort übernommen — Eine Konfigurationsänderung wird nicht wirksam, wenn sie
UpdateClusterConfigzurückkehrt. Amazon EKS wendet die neue Konfiguration im Rahmen einer fortlaufenden Aktualisierung Ihrer Steuerungsebene an. Rechnen Sie also mit einigen Minuten, bis die Änderung vollständig wirksam wird. Der Cluster kehrt zumACTIVEStatus zurück, wenn das Update abgeschlossen ist. Sie können den Fortschritt mithilfe des DescribeUpdate Vorgangs verfolgen oder blockieren, bis die Änderung abgeschlossen ist, indem Sie Folgendes verwendenaws eks wait cluster-active. -
Überprüfbarkeit — Amazon EKS validiert jede Konfiguration, bevor sie angewendet wird, und zeichnet Konfigurationsänderungen auf. AWS CloudTrail
-
Tooling-Unterstützung — Die erweiterte Konfiguration der Kubernetes-Steuerungsebene ist beim Start über eksctl AWS-Managementkonsole, AWS CLI, Amazon EKS-API und CDK verfügbar. AWS CloudFormation AWS Unterstützung für AWS Controller for Kubernetes (ACK) und Terraform ist in Kürze verfügbar.
-
Kubernetes-Versionsunterstützung — Die erweiterte Konfiguration der Kubernetes-Steuerungsebene wird auf neuen und vorhandenen Clustern unterstützt, auf denen Kubernetes Version 1.31 oder höher ausgeführt wird.
-
AWS Regionsunterstützung — Die erweiterte Konfiguration der Kubernetes-Steuerungsebene ist in allen AWS Handelsregionen, AWS GovCloud (USA) und Regionen Chinas verfügbar, in denen Amazon EKS verfügbar ist. AWS
-
Preisgestaltung — Für die Konfiguration der Parameter der Steuerungsebene fallen keine zusätzlichen Kosten an. Für die Verwendung ist Provisioned Control Plane
horizontalPodAutoscalerSyncPerioderforderlich, das zum Stundensatz für Ihre Skalierungsstufe abgerechnet wird. Weitere Informationen finden Sie unter Amazon EKS – Preise.
Nächste Schritte
-
Konfigurieren Sie erweiterte Parameter der Kubernetes-Steuerungsebene— Legen Sie die Parameter der Steuerungsebene mithilfe der AWS CLI fest und zeigen Sie sie an. AWS-Managementkonsole
-
Von Amazon EKS bereitgestellte Steuerungsebene— Kapazität der Pre-allocate Steuerungsebene für vorhersehbare, hohe Leistung.
