Knotenleistung optimieren

Eine Möglichkeit zur Verbesserung der Leistung containerbasierter Anwendungen besteht darin, die Clusterressourcen durch Hinzufügen von Knoten oder durch Hinzufügen von Ressourcen wie CPUs oder Arbeitsspeicher zu Ihren Knoten zu erhöhen. Dieser Ansatz kann jedoch teuer werden. Durch die Abstimmung der Clusterknoten für eine bessere Leistung können Sie die Ressourcennutzung für Ihre Arbeitslasten kostengünstig optimieren. In diesem Dokument wird beschrieben, wie Sie mit dem Operator für die Leistungsoptimierung Worker-Knoten optimieren, um die Arbeitslastleistung für Google Distributed Cloud zu optimieren.

Damit Sie die zugrunde liegende Hardware und Software optimal nutzen können, profitieren verschiedene Arten von Anwendungen, insbesondere Hochleistungsanwendungen, von der folgenden Feinabstimmung der Knoteneinstellungen:

  • Dedizierte CPUs für leistungsempfindliche Arbeitslasten
  • Reservierte CPUs für standardmäßige Kubernetes-Daemons und -Dienste
  • Seiten mit 1 GiB (Gibibyte) oder 2 MiB (Mebibyte) für große Seiten mit erhöhtem Arbeitsspeicher
  • Arbeitslastverteilung basierend auf der Systemarchitektur, z. B. Mehrkernprozessoren und NUMA

Mit dem Operator für die Leistungsoptimierung können Sie Leistungseinstellungen auf Knotenebene konfigurieren. Dazu erstellen Sie benutzerdefinierte Kubernetes-Ressourcen, die Leistungskonfigurationen anwenden. Dies sind die Vorteile:

  • Einzelne, einheitliche Konfigurationsoberfläche: Mit dem Operator für die Leistungsoptimierung aktualisieren Sie ein oder mehrere PerformanceTuningProfile-Manifeste, die auf Worker-Knoten mit Knotenselektoren angewendet werden können. Sie müssen nicht jeden Knoten einzeln mit mehreren Konfigurations- und Richtlinieneinstellungen konfigurieren. Mit diesem Ansatz können Sie Konfigurationen auf Knoten- und Containerebene auf eine einzige, einheitliche Weise verwalten.

  • Persistenz und Zuverlässigkeit: Sie profitieren außerdem von der Zuverlässigkeit, die Kubernetes mit seiner Hochverfügbarkeitsarchitektur bietet. Benutzerdefinierte PerformanceTuningProfile-Ressourcen können jederzeit aktualisiert werden und ihre Einstellungen bleiben bei wichtigen Clustervorgängen erhalten, z. B. bei Upgrades.

Der Operator für die Leistungsoptimierung orchestriert die folgenden leistungsbezogenen Kubernetes- und Betriebssystemfunktionen und -tools:

Zur Vermeidung von Konflikten sollten Sie bei Verwendung des Operators zur Leistungsoptimierung die zuvor erwähnten Kubernetes- und Betriebssystem-Tools und -Features nicht unabhängig voneinander verwenden.

Voraussetzungen und Einschränkungen

Für die Verwendung des Operators zur Leistungsoptimierung gelten die folgenden Voraussetzungen und Einschränkungen:

  • Nur Red Hat Enterprise Linux (RHEL):Der Operator für die Leistungsoptimierung wird nur für Knoten unterstützt, auf denen unterstützte RHEL-Versionen ausgeführt werden.

  • Nutzer- oder Hybridcluster mit Worker-Knoten:Der Operator für die Leistungsoptimierung wird nur für die Verwendung mit Worker-Knoten in Nutzer- oder Hybridclustern unterstützt. Die Verwendung des Operators für die Leistungsoptimierung zum Optimieren von Knoten der Steuerungsebene wird nicht unterstützt. Der Operator für die Leistungsoptimierung verwendet einen Knotenselektor, um zu bestimmen, wie Abstimmungsprofile angewendet werden. Damit Abstimmungsprofile nur auf Worker-Knoten angewendet werden, muss der nodeSelector in jeder benutzerdefinierten Profilressource das Standardlabel node-role.kubernetes.io/worker: "" für Worker-Knoten enthalten. Wenn nodeSelector in einem Abstimmungsprofil mit Labels auf einem Knoten der Steuerungsebene übereinstimmt, wird dieser Knoten nicht optimiert und eine Fehlerbedingung festgelegt. Weitere Informationen zu Fehlerbedingungen finden Sie unter Status prüfen. Achten Sie darauf, dass der Cluster ordnungsgemäß funktioniert, bevor Sie den Operator für die Leistungsoptimierung installieren und Abstimmungsprofile anwenden.

  • TuneD 2.22.0: Der Operator für die Leistungsoptimierung erfordert, dass TuneD Version 2.22.0 in Worker-Knoten vorinstalliert ist, die Sie abstimmen möchten. Weitere Informationen zu TuneD, einschließlich einer Installationsanleitung, finden Sie in der Dokumentation zu Red Hat Enterprise Linux unter Erste Schritte mit TuneD. Der Operator für die Leistungsoptimierung verwendet TuneD mit dem Profil cpu-partitioning. Wenn Sie dieses Profil nicht haben, können Sie es mit dem folgenden Befehl installieren:

    dnf install -y tuned-profiles-cpu-partitioning

  • Anforderungen an Arbeitslastressourcen:Damit Sie die Leistungsoptimierung optimal nutzen können, sollten Sie mit den Arbeitsspeicher- und CPU-Anforderungen (Ressourcenanfragen und -limits) für Ihre Arbeitslasten vertraut sein.

  • Verfügbare Knotenressourcen:Ermitteln Sie die CPU- und Arbeitsspeicherressourcen für Ihre Knoten. In den Dateien /proc/cpuinfo und /proc/meminfo können Sie detaillierte CPU- und Arbeitsspeicherinformationen für Ihren Knoten abrufen. Sie können mit kubectl get nodes auch die Menge an Rechen- und Arbeitsspeicherressourcen (status.allocatable) abrufen, die ein Worker-Knoten für Pods zur Verfügung hat.

  • Erfordert Draining: Im Rahmen der Abstimmung zieht der Operator für die Leistungsoptimierung zuerst Knoten per Drain ab und wendet dann ein Abstimmungsprofil an. Daher melden Knoten während der Leistungsoptimierung möglicherweise den Status NotReady. Wir empfehlen, die Rolling Update-Strategie (spec.updateStrategy.type: rolling) anstelle einer Batch-Aktualisierung zu verwenden, um die Nichtverfügbarkeit von Arbeitslasten zu minimieren.

  • Neustart erforderlich:Damit Änderungen an der Knotenabstimmung wirksam werden, startet der Operator für die Leistungsoptimierung den Knoten nach Anwendung des Abstimmungsprofils neu.

Operator zur Leistungsoptimierung installieren

Der Operator für die Leistungsoptimierung besteht hauptsächlich aus zwei Controllern (einem Deployment und einem DaemonSet), die miteinander interagieren, um Knoten auf der Grundlage Ihrer Profileinstellungen abzustimmen. Der Operator für die Leistungsoptimierung wird standardmäßig nicht mit Google Distributed Cloud installiert. Sie laden die Manifeste für den Leistungsoptimierungsoperator aus Cloud Storage herunter und verwenden kubectl apply, um Ressourcen für den Operator für die Leistungsoptimierung in Ihrem Cluster zu erstellen.

So aktivieren Sie die Leistungsoptimierung mit Standardwerten für Ihren Cluster:

  1. Erstellen Sie ein performance-tuning-Verzeichnis auf Ihrer Administratorworkstation.

  2. Laden Sie im Verzeichnis performance-tuning das neueste Paket mit dem Operator für die Leistungsoptimierung aus dem Cloud Storage-Release-Bucket herunter:

    gsutil cp -r gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 .

    Die heruntergeladenen Dateien enthalten Manifeste für das Deployment performance-tuning-operator und das DaemonSet nodeconfig-controller-manager. Manifeste für verwandte Funktionen wie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und die dynamische Zugangssteuerung sind ebenfalls enthalten.

  3. Wenden Sie als Root-Nutzer alle Manifeste des Leistungsoptimierungsoperators rekursiv auf Ihren Nutzer- oder Hybridcluster an:

    kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG

    Nachdem das Deployment und das DaemonSet erstellt und ausgeführt wurden, besteht Ihre einzige Interaktion darin, PerformanceTuningProfile-Manifeste zu bearbeiten und anzuwenden.

Überprüfen Sie die Ressourcenanforderungen für Ihre Arbeitslasten

Bevor Sie Ihre Knoten optimieren können, müssen Sie die Anforderungen Ihrer Arbeitslasten an Rechen- und Arbeitsspeicherressourcen verstehen. Wenn Ihre Worker-Knoten über ausreichende Ressourcen verfügen, können Knoten optimiert werden, um für Ihre Arbeitslasten in der Klasse für garantierte Dienstqualität (Qualitätssicherung) garantierten Arbeitsspeicher (Standard- und riesige Seiten) bereitzustellen.

Kubernetes weist jedem Ihrer Pods Dienstqualitätsklassen basierend auf den Ressourceneinschränkungen zu, die Sie für die zugehörigen Container angeben. Kubernetes verwendet dann QoS-Klassen, um zu bestimmen, wie Ihre Pods und Container geplant und den Arbeitslasten Ressourcen zugewiesen werden. Damit Sie die Vorteile der Knotenabstimmung für Ihre Arbeitslasten voll ausschöpfen können, müssen für Ihre Arbeitslasten CPU- oder Arbeitsspeicherressourcenanfragen oder -limits festgelegt sein.

Damit Ihnen die Dienstqualitätsklasse garantiert zugewiesen werden kann, müssen Ihre Pods die folgenden Anforderungen erfüllen:

  • Führen Sie für jeden Container im Pod folgende Schritte aus:
    • Geben Sie Werte für Arbeitsspeicherressourcenanfragen (spec.containers[].resources.requests.memory) und Limits (spec.containers[].resources.limits.memory) an.
    • Der Wert der Arbeitsspeicherlimits muss mit dem Wert der Arbeitsspeicheranfragen übereinstimmen.
    • Geben Sie Werte für CPU-Ressourcenanfragen (spec.containers[].resources.requests.cpu) und Limits (spec.containers[].resources.limits.cpu) an.
    • Der Wert für die CPU-Limits muss mit dem Wert für die CPU-Anfragen übereinstimmen.

Der folgende Auszug aus der Pod-Spezifikation zeigt CPU-Ressourceneinstellungen, die die Anforderungen an die garantierte QoS-Klasse erfüllen:

spec:
  containers:
  - name: sample-app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "128Mi"
        cpu: "2"
      limits:
        memory: "128Mi"
        cpu: "2"
  ...

Wenn Sie Pod-Details mit kubectl get pods abrufen, sollte der Abschnitt status die zugewiesene Dienstqualitätsklasse enthalten, wie im folgenden Beispiel gezeigt:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-09-22T21:05:23Z"
  generateName: my-deployment-6fdd69987d-
  labels:
    app: metrics
    department: sales
    pod-template-hash: 6fdd69987d
  name: my-deployment-6fdd69987d-7kv42
  namespace: default
  ...
spec:
  containers:
  ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-09-22T21:05:23Z"
    status: "True"
    type: Initialized
  ...
  qosClass: BestEffort
  startTime: "2023-09-22T21:05:23Z"

Weitere Informationen zu den QoS-Klassen finden Sie in der Kubernetes-Dokumentation unter Pod-Qualität von Dienstklassen. Eine Anleitung zum Konfigurieren von Pods und Containern, damit ihnen eine Dienstqualitätsklasse zugewiesen wird, finden Sie unter Dienstqualität für Pods konfigurieren.

CPU-Anforderungen

Bei der Abstimmung eines Knotens können Sie eine Reihe von reservierten CPU-Kernen (spec.cpu.reservedCPUs) zum Ausführen von Kubernetes-System-Daemons wie dem Kubelet und der Containerlaufzeit angeben. Derselbe Satz reservierter CPUs führt auch Betriebssystem-Daemons wie sshd und udev aus. Der Rest der CPU-Kerne wird als isoliert zugewiesen. Die isolierten CPUs sind für CPU-gebundene Anwendungen vorgesehen, die dedizierte CPU-Zeit ohne Störungen durch andere Anwendungen oder Unterbrechungen durch Netzwerke oder andere Geräte benötigen.

So planen Sie einen Pod auf den isolierten CPUs eines Worker-Knotens:

  • Konfigurieren Sie den Pod für eine garantierte Dienstqualität.

  • Die CPU-Anforderungen und -Limits müssen in Ganzzahlen angegeben werden. Wenn Sie in der Pod-Spezifikation partielle CPU-Ressourcen wie cpu: 0.5 oder cpu: 250m (250 Millicore) angeben, kann die Planung nicht garantiert werden.

Speicheranforderungen

Wenn Sie einen Knoten mit dem Operator für die Leistungsoptimierung abstimmen, können Sie riesigen Seiten erstellen und sie den NUMA-Knoten (nicht einheitlichem Arbeitsspeicherzugriff) auf der Maschine zuordnen. Basierend auf Pod- und Knoteneinstellungen können Pods mit einer NUMA-Knotenaffinität geplant werden.

Profil für die Leistungsoptimierung erstellen

Nachdem Sie den Operator zur Leistungsoptimierung installiert haben, interagieren Sie nur mit dem Cluster, auf dem Ihre Arbeitslasten ausgeführt werden. Benutzerdefinierte PerformanceTuningProfile-Ressourcen werden direkt in Ihrem Nutzercluster oder Hybridcluster erstellt, nicht in Ihrem Administratorcluster. Jede PerformanceTuningProfile-Ressource enthält eine Reihe von Parametern, die die Leistungskonfiguration angeben, die auf einen Knoten angewendet wird.

Der nodeSelector in der Ressource bestimmt die Knoten, auf die das Abstimmungsprofil angewendet wird. Um ein Profil auf einen Knoten anzuwenden, platzieren Sie das entsprechende Schlüssel/Wert-Paar-Label auf dem Knoten. Ein Abstimmungsprofil wird auf Knoten angewendet, für die alle Labels im Feld nodeSelector angegeben sind.

Sie können mehrere PerformanceTuningProfile-Ressourcen in einem Cluster erstellen. Wenn mehrere Profile mit einem bestimmten Knoten übereinstimmen, wird im status der benutzerdefinierten Ressource PerformanceTuningProfile eine Fehlerbedingung festgelegt. Weitere Informationen zum Abschnitt status finden Sie unter Status prüfen.

Legen Sie den Namespace für Ihre benutzerdefinierte Ressource PerformanceTuningProfile auf kube-system fest.

So stimmen Sie einen oder mehrere Worker-Knoten ab:

  1. Bearbeiten Sie das Manifest PerformanceTuningProfile.

    Informationen zu den einzelnen Feldern im Manifest und ein Beispielmanifest findest du in der PerformanceTuningProfile-Ressourcenreferenz.

  2. (Optional) Fügen Sie den Worker-Knoten, auf die Sie ein Profil anwenden, Labels hinzu, die dem Schlüssel/Wert-Paar spec.nodeSelector entsprechen.

    Wenn in der benutzerdefinierten Ressource PerformanceTuningProfile kein Schlüssel/Wert-Paar spec.nodeSelector angegeben ist, wird das Profil auf alle Worker-Knoten angewendet.

  3. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • PROFILE_MANIFEST: Pfad der Manifestdatei für die benutzerdefinierte Ressource PerformanceTuningProfile.
    • KUBECONFIG: Pfad der kubectl-Datei des Clusters.

Abstimmungsprofil entfernen

So setzen Sie einen Knoten auf seinen ursprünglichen, nicht abgestimmten Zustand zurück:

  1. Löschen Sie die benutzerdefinierte Ressource PerformanceTuningProfile aus dem Cluster.

  2. Aktualisieren oder entfernen Sie die Labels auf dem Knoten noch einmal, damit er nicht noch einmal vom Abstimmungsprofil ausgewählt wird.

Wenn dem Knoten mehrere Abstimmungsprofile zugeordnet sind, wiederholen Sie die vorherigen Schritte nach Bedarf.

Abstimmungsprofil pausieren

Wenn Sie eine Wartung Ihres Clusters ausführen müssen, können Sie die Abstimmung vorübergehend anhalten. Bearbeiten Sie dazu die benutzerdefinierte Ressource PerformanceTuningProfile. Wir empfehlen, die Abstimmung zu pausieren, bevor Sie kritische Clustervorgänge wie ein Clusterupgrade ausführen.

Ein weiterer Fall, in dem Sie die Abstimmung anhalten können, wenn die Profilanwendung nicht erfolgreich ist. Wenn der Abstimmungsprozess fehlschlägt, versucht der Controller möglicherweise weiterhin, den Knoten abzustimmen, was dazu führen kann, dass der Knoten immer wieder neu gestartet wird. Wenn der Knotenstatus zwischen dem Status „Bereit“ und „Nicht bereit“ wechselt, halten Sie die Abstimmung an, damit Sie den fehlerhaften Zustand wiederherstellen können.

So pausieren Sie die Abstimmung:

  1. Bearbeiten Sie das benutzerdefinierte Ressourcenmanifest PerformanceTuningProfile, um spec.paused auf true festzulegen.

  2. Verwenden Sie kubectl apply, um die Ressource zu aktualisieren.

Wenn die Leistungsoptimierung pausiert wird, stoppt der Controller für den Leistungsoptimierungsoperator alle zugehörigen Vorgänge. Durch das Pausieren wird das Risiko verringert, dass Controllervorgänge des Operators für die Leistungsoptimierung mit Google Distributed Cloud-Controller-Vorgängen in Konflikt stehen.

PerformanceTuningProfile-Ressourcenreferenz

In diesem Abschnitt werden die einzelnen Felder der benutzerdefinierten Ressource PerformanceTuningProfile beschrieben. Diese Ressource wird verwendet, um ein Abstimmungsprofil für einen oder mehrere Ihrer Clusterknoten zu erstellen. Alle Felder in der Ressource können nach der Profilerstellung geändert werden. Profile müssen sich im Namespace kube-system befinden.

Das folgende numa-Beispielprofilmanifest für Knoten mit 8 CPU-Kernen gibt die folgenden Ressourcenzuweisungen an:

  • 4 CPU-Kerne (0-3) sind für den Kubernetes-System-Overhead reserviert.

  • 4 CPU-Kerne (4-7) werden nur für Arbeitslasten reserviert.

  • Der Knotenarbeitsspeicher wird standardmäßig in 2‐MiB-Seiten anstelle der Standardseiten mit 4 Ki unterteilt.

  • 10 Seiten des Arbeitsspeichers mit einer Größe von 1 GiB sind für die Verwendung durch NUMA-Knoten 0 vorgesehen.

  • 5 Seiten des Arbeitsspeichers mit einer Größe von 2 MiB werden für die Verwendung durch NUMA-Knoten 1 reserviert.

  • Topology Manager verwendet für die Planung von Arbeitslasten die Best-Effort-Richtlinie.

apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
  name: numa
  namespace: kube-system
spec:
  cpu:
    isolatedCPUs: 4-7
    reservedCPUs: 0-3
  defaultHugepagesSize: 2M
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  pages:
  - count: 10
    numaNode: 0
    size: 1G
  - count: 5
    numaNode: 1
    size: 2M
  topologyManagerPolicy: best-effort

Sie können die zugehörige benutzerdefinierte Ressourcendefinition PerformanceTuningProfile aus der Gruppe anthos.gke.io in Ihrem Cluster abrufen. Die benutzerdefinierte Ressourcendefinition wird installiert, sobald die Annotation des Vorschaufeatures der selbstverwalteten Clusterressource hinzugefügt wurde.

CPU-Konfiguration

Attribut Beschreibung
cpu.reservedCPUs Erforderlich. Veränderlich. String. In diesem Feld wird eine Reihe von CPU-Kernen definiert, die für Kubernetes-System-Daemons reserviert werden sollen, z. B. für das Kubelet, die Containerlaufzeit und den Knotenproblemerkennung. Diese CPU-Kerne werden auch für Betriebssystem-Daemons (Betriebssystem-Daemons) wie sshd und udev verwendet.

Das Feld cpu.reservedCPUs enthält eine Liste von CPU-Nummern oder -Bereichen. Die Liste der CPUs darf sich nicht mit der Liste mit cpu.isolatedCPUs überschneiden. Die Kombination der in diesen beiden Feldern aufgeführten CPUs muss alle CPUs für den Knoten enthalten.
cpu.isolatedCPUs Optional. Veränderlich. String. Das Feld cpu.isolatedCPUs definiert eine Gruppe von CPUs, die ausschließlich für leistungsempfindliche Anwendungen verwendet werden. CPU Manager plant Container nur auf den nicht reservierten CPUs gemäß den Dienstqualitätsklassen (QoS) von Kubernetes. Damit Arbeitslasten auf den isolierten CPUs ausgeführt werden, konfigurieren Sie Pods mit der garantierten Dienstqualitätsklasse und weisen Sie dem Pod oder Container eine CPU-Ressource zu. Für eine garantierte Pod-Planung müssen Sie ganzzahlige CPU-Einheiten und keine Teil-CPU-Ressourcen angeben (cpu: "0.5"). 
apiVersion: v1
kind: Pod
...
spec:
  containers:
  ...
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "1"
  ...

Die Maximierung der isolierten CPUs für Arbeitslasten bietet den besten Leistungsvorteil. In diesem Feld wird eine Liste von CPU-Nummern oder -Bereichen angegeben. Achten Sie darauf, dass sich die Liste der CPUs nicht mit der Liste mit cpu.reservedCPUs überschneidet und dass die Zusammenführung der Listen in diesen beiden Feldern alle CPUs für den Knoten enthält.
cpu.balanceIsolated Optional. Veränderlich. Boolescher Wert. Standardeinstellung: true. Dieses Feld gibt an, ob die isolierte CPU-Gruppe für das automatische Load-Balancing von Arbeitslasten auf CPUs infrage kommt. Wenn Sie dieses Feld auf false setzen, müssen Ihre Arbeitslasten jeden Thread explizit einer bestimmten CPU zuweisen, um die Last auf CPUs zu verteilen. Explizite CPU-Zuweisungen liefern die am besten vorhersehbare Leistung für garantierte Arbeitslasten. Allerdings erhöht dies die Komplexität Ihrer Arbeitslasten.
cpu.globallyEnableIRQLoadBalancing Erforderlich. Veränderlich. Boolescher Wert. Standardeinstellung: true. In diesem Feld wird angegeben, ob IHR-Load-Balancing (Interrupt Request) für den isolierten CPU-Satz aktiviert werden soll.

Arbeitsspeicherkonfiguration

Attribut Beschreibung
defaultHugePageSize Optional. Veränderlich. Aufzählung: 1G oder 2M. In diesem Feld wird die Standardgröße der großen Seite in den Kernel-Bootparametern definiert. ManyPages werden beim Booten zugewiesen, bevor der Arbeitsspeicher fragmentiert wird. Beachten Sie, dass durch das Festlegen der Standardgröße von VastPages alle 2 Millionen zugehörigen Ordner vom Knoten entfernt werden. Eine Standard-große Seitengröße von 1 G verhindert, dass 2 Millionen große Seiten im Knoten konfiguriert werden können.
pages Optional. Veränderlich. Ganze Zahl. Dieses Feld gibt die Anzahl der großen Seiten an, die beim Booten erstellt werden sollen. In dieses Feld kann ein Array von Seiten eingegeben werden. Prüfen Sie den verfügbaren Arbeitsspeicher für Ihre Knoten, bevor Sie riesigen Seiten angeben. Fordern Sie nicht mehr riesigen Seiten als nötig an und reservieren Sie auch nicht den gesamten Arbeitsspeicher für große Seiten. Ihre Arbeitslasten benötigen auch Standardarbeitsspeicher.

Knotenauswahl

Attribut Beschreibung
nodeSelector Erforderlich. Veränderlich. Für dieses Feld ist immer das Label node-role.kubernetes.io/worker:"" für Kubernetes-Worker-Knoten erforderlich. Dadurch wird sichergestellt, dass die Leistungsoptimierung nur auf Worker-Knoten erfolgt. In diesem Feld wird ein optionales Knotenlabel als Schlüssel/Wert-Paar verwendet. Die Labels für Schlüssel/Wert-Paare werden verwendet, um bestimmte Worker-Knoten mit übereinstimmenden Labels auszuwählen. Wenn die nodeSelector-Labels mit Labels auf einem Worker-Knoten übereinstimmen, wird das Leistungsprofil auf diesen Knoten angewendet. Wenn Sie in Ihrem Profil kein Schlüssel/Wert-Paar-Label angeben, wird es auf alle Worker-Knoten im Cluster angewendet.

Der folgende nodeSelector gibt beispielsweise an, dass das Abstimmungsprofil nur auf Worker-Knoten mit übereinstimmenden app: database-Labels angewendet wird:

...
spec:
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  ...

Kubelet-Konfiguration

Attribut Beschreibung
topologyManagerPolicy Optional. Veränderlich. Aufzählung: none, best-effort, restricted oder single-numa-node. Standard: best-effort. Dieses Feld gibt die Topology Manager-Richtlinie von Kubernetes an, die zum Zuweisen von Ressourcen für Ihre Arbeitslasten basierend auf der zugewiesenen Dienstqualitätsklasse (QoS) verwendet wird. Weitere Informationen zur Zuweisung von Dienstqualitätsklassen finden Sie unter Dienstqualität für Pods konfigurieren.

Profilvorgänge

Attribut Beschreibung
paused Optional. Veränderlich. Boolescher Wert. Legen Sie paused auf true fest, um vorübergehend zu verhindern, dass die DaemonSet-Controller ausgewählte Knoten abstimmen.
updateStrategy Optional. Veränderlich. Gibt die Strategie zum Anwenden von Änderungen der Abstimmungskonfiguration auf ausgewählte Knoten an.
updateStrategy.rollingUpdateMaxUnavailalble Optional. Veränderlich. Ganze Zahl. Standardeinstellung: 1. Gibt die maximale Anzahl von Knoten an, die gleichzeitig abgestimmt werden können. Dieses Feld gilt nur, wenn type auf rolling gesetzt ist.
updateStrategy.type Optional. Veränderlich. Aufzählung: batch oder rolling. Standardeinstellung: rolling. Gibt an, wie Profilaktualisierungen auf ausgewählte Knoten angewendet werden. Wenn Sie das Update auf alle ausgewählten Knoten gleichzeitig anwenden möchten, setzen Sie type auf batch. Standardmäßig werden Updates nacheinander für einzelne Knoten bereitgestellt, eine nach der anderen.

Status prüfen

Nachdem die benutzerdefinierte Ressource PerformanceTuningProfile erstellt oder aktualisiert wurde, stimmt ein Controller die ausgewählten Knoten anhand der in der Ressource angegebenen Konfiguration ab. Zum Prüfen des Status von PerformanceTuningProfile steht das folgende Feld in Status zur Verfügung:

Attribut Beschreibung
conditions Die Bedingung stellt die letzten verfügbaren Beobachtungen des aktuellen Zustands der Profilressource dar.
conditions.lastTransitionTime Immer zurückgegeben. String (im Datums-/Uhrzeitformat). Letzter Zeitpunkt, zu dem die Bedingung von einem Status in einen anderen übergegangen ist. Diese Zeit gibt normalerweise an, wann sich die zugrunde liegende Bedingung geändert hat. Wenn dieser Zeitpunkt nicht bekannt ist, gibt die Zeit an, wann sich das API-Feld geändert hat.
conditions.message Optional. String. Eine menschenlesbare Nachricht mit Details zur Umstellung. Dieses Feld ist möglicherweise leer.
conditions.observedGeneration Optional. Ganze Zahl. Wenn festgelegt, stellt dieses Feld die metadata.generation dar, auf der die Bedingung basiert. Beispiel: Wenn metadata.generation den Wert 12 hat, status.condition[x].observedGeneration aber 9, ist die Bedingung in Bezug auf den aktuellen Status der Instanz veraltet.
conditions.reason Erforderlich. String. Der Grund für den letzten Bedingungswechsel.
conditions.status Erforderlich. Status der Bedingung: True, False oder Unknown.
conditions.type Erforderlich. „Type“ ist der Bedingungstyp: Stalled oder Reconciling.
readyNodes Die Anzahl der Knoten, auf die das Abstimmungsprofil erfolgreich angewendet wurde.
reconcilingNodes Die Anzahl der ausgewählten (oder zuvor ausgewählten) Knoten, die gerade mit dem neuesten Abstimmungsprofil vom DaemonSet nodeconfig-controller-manager abgeglichen werden.
selectedNodes Die Anzahl der ausgewählten Notizen. Dies ist die Anzahl der Knoten, die der Knotenauswahl für diese benutzerdefinierte PerformanceTuningProfile-Ressource entsprechen.

Nächste Schritte