Knotenleistung optimieren

Eine Möglichkeit, die Leistung containerbasierter Anwendungen zu verbessern, besteht darin, die Clusterressourcen zu erhöhen, indem Sie Knoten hinzufügen oder Ihren Knoten Ressourcen wie CPUs oder Arbeitsspeicher hinzufügen. Dieser Ansatz kann jedoch teuer werden. Wenn Sie die Knoten Ihres Clusters für eine bessere Leistung optimieren, können Sie die Ressourcennutzung für Ihre Arbeitslasten kostengünstig optimieren. In diesem Dokument wird beschrieben, wie Sie mit dem Performance Tuning Operator Worker-Knoten optimieren, um die Arbeitslastleistung für Google Distributed Cloud zu optimieren.

Um die zugrunde liegende Hardware und Software optimal zu nutzen, profitieren verschiedene Arten von Anwendungen, insbesondere leistungsstarke Anwendungen, von der Optimierung von Knoteneinstellungen wie den folgenden:

  • Dedizierte CPUs für leistungsempfindliche Arbeitslasten
  • Reservierte CPUs für standardmäßige Kubernetes-Daemons und ‑Dienste
  • Erhöhte Arbeitsspeicherseitengrößen mit 1 GiB (Gibibyte) oder 2 MiB (Mebibyte) Hugepages
  • Arbeitslastverteilung basierend auf der Systemarchitektur, z. B. Multi-Core-Prozessoren und NUMA

Mit dem Leistungsoptimierungs-Operator konfigurieren Sie Leistungseinstellungen auf Knotenebene, indem Sie benutzerdefinierte Kubernetes-Ressourcen erstellen, die Leistungskonfigurationen anwenden. Hier sind die Vorteile:

  • Einheitliche Konfigurationsoberfläche: Mit dem Leistungsoptimierungs-Operator aktualisieren Sie ein oder mehrere PerformanceTuningProfile-Manifeste, die mithilfe von Knotenauswahlen auf Worker-Knoten angewendet werden können. Sie müssen nicht jeden Knoten einzeln mit mehreren Konfigurations- und Richtlinieneinstellungen konfigurieren. So können Sie Konfigurationen auf Knoten- und Containerebene auf einheitliche Weise verwalten.

  • Dauerhaftigkeit 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 auch nach größeren Cluster-Vorgängen wie Upgrades erhalten.

Der Performance Tuning Operator steuert die folgenden leistungsbezogenen Funktionen und Tools von Kubernetes und Betriebssystemen:

Um Konflikte zu vermeiden, empfehlen wir, die zuvor genannten Kubernetes- und Betriebssystemtools und ‑funktionen nicht unabhängig voneinander zu verwenden, wenn Sie den Leistungsoptimierungsoperator verwenden.

Voraussetzungen und Einschränkungen

Hier finden Sie die Voraussetzungen und Einschränkungen für die Verwendung des Leistungsoptimierungsoperators:

  • Nur Red Hat Enterprise Linux (RHEL): Der Befehl „Performance Tuning Operator“ wird nur für Knoten unterstützt, auf denen unterstützte Versionen von RHEL ausgeführt werden.

  • Nutzer- oder Hybridcluster mit Worker-Knoten:Der Befehl „Leistungsoptimierung“ wird nur für Worker-Knoten in Nutzer- oder Hybridclustern unterstützt. Die Verwendung des Leistungsoptimierungsoperators zum Optimieren von Knoten der Steuerungsebene wird nicht unterstützt. Der Leistungsoptimierungsoperator verwendet eine Knotenauswahl, um zu bestimmen, wie Optimierungsprofile angewendet werden. Damit die Optimierungsprofile nur auf Worker-Knoten angewendet werden, muss die nodeSelector in jeder benutzerdefinierten Ressourcendatei des Profils das Standardlabel für Worker-Knoten node-role.kubernetes.io/worker: "" enthalten. Wenn die nodeSelector in einem Optimierungsprofil mit Labels auf einem Knoten der Steuerungsebene übereinstimmt, wird dieser Knoten nicht optimiert und eine Fehlerbedingung wird festgelegt. Weitere Informationen zu Fehlerbedingungen finden Sie unter Status prüfen. Prüfen Sie, ob Ihr Cluster ordnungsgemäß funktioniert, bevor Sie den Leistungsoptimierungsoperator installieren und Optimierungsprofile anwenden.

  • TuneD 2.22.0:Für den Befehl „Performance Tuning Operator“ muss TuneD 2.22.0 auf den zu optimierenden Arbeitsknoten vorinstalliert sein. Weitere Informationen zu TuneD, einschließlich einer Installationsanleitung, finden Sie in der Red Hat Enterprise Linux-Dokumentation unter Erste Schritte mit TuneD. Der Leistungsoptimierungsoperator 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

  • Ressourcenanforderungen der Arbeitslast: Damit Sie die Leistung optimal optimieren können, sollten Sie die Arbeitsspeicher- und CPU-Anforderungen (Ressourcenanforderungen und ‑limits) für Ihre Arbeitslasten genau kennen.

  • Verfügbare Knotenressourcen:Hier finden Sie die CPU- und Arbeitsspeicherressourcen Ihrer Knoten. Detaillierte CPU- und Speicherinformationen für Ihren Knoten finden Sie in den Dateien /proc/cpuinfo und /proc/meminfo. Mit kubectl get nodes können Sie auch die Menge der Rechen- und Arbeitsspeicherressourcen (status.allocatable) abrufen, die einem Worker-Knoten für Pods zur Verfügung stehen.

  • Erfordert das Leeren des Arbeitsspeichers:Im Rahmen der Optimierung leeren Sie zuerst die Knoten und wenden dann ein Optimierungsprofil an. Daher melden Knoten während der Leistungsoptimierung möglicherweise den Status NotReady. Wir empfehlen, die Rolling-Update-Strategie (spec.updateStrategy.type: rolling) anstelle eines Batch-Updates zu verwenden, um die Nichtverfügbarkeit der Arbeitslast zu minimieren.

  • Neustart erforderlich:Damit die Änderungen an der Knotenoptimierung wirksam werden, startet der Performance Tuning Operator den Knoten nach dem Anwenden des Optimierungsprofils neu.

Leistungsoptimierungs-Operator installieren

Der Performance Tuning Operator besteht hauptsächlich aus zwei Controllern (einem Deployment und einem DaemonSet), die miteinander interagieren, um Knoten basierend auf Ihren Profileinstellungen zu optimieren. Der Performance Tuning Operator wird nicht standardmäßig mit Google Distributed Cloud installiert. Sie laden die Manifeste des Leistungsoptimierungs-Operators aus Cloud Storage herunter und erstellen mit kubectl apply Ressourcen des Leistungsoptimierungs-Operators in Ihrem Cluster.

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

  1. Erstellen Sie auf Ihrer Administrator-Workstation ein performance-tuning-Verzeichnis.

  2. Laden Sie im Verzeichnis performance-tuning das neueste Paket des Leistungsoptimierungs-Operators aus dem Cloud Storage-Release-Bucket herunter:

    gcloud storage cp gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 . --recursive

    Die heruntergeladenen Dateien enthalten Manifeste für das performance-tuning-operator-Deployment und das nodeconfig-controller-manager-DaemonSet. Außerdem sind Manifeste für zugehörige Funktionen wie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und die dynamische Zulassungssteuerung enthalten.

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

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

    Sobald die Bereitstellung und das DaemonSet erstellt und ausgeführt werden, müssen Sie nur noch PerformanceTuningProfile-Manifeste bearbeiten und anwenden.

Ressourcenanforderungen für Ihre Arbeitslasten prüfen

Bevor Sie Ihre Knoten optimieren können, müssen Sie die Rechen- und Arbeitsspeicheranforderungen Ihrer Arbeitslasten kennen. Wenn Ihre Worker-Knoten über ausreichende Ressourcen verfügen, können sie so konfiguriert werden, dass sie garantierten Arbeitsspeicher (Standard- und Hugepages) für Ihre Arbeitslasten in der garantierten QoS-Klasse (Quality of Service) bereitstellen.

Kubernetes weist jedem Ihrer Pods QoS-Klassen zu, die auf den Ressourceneinschränkungen basieren, die Sie für die zugehörigen Container angeben. Kubernetes verwendet dann QoS-Klassen, um zu bestimmen, wie Pods und Container geplant und Ressourcen Ihren Arbeitslasten zugewiesen werden. Damit Sie die Knotenoptimierung für Ihre Arbeitslasten optimal nutzen können, müssen Ihre Arbeitslasten CPU- oder Arbeitsspeicherressourcenanforderungen oder -limits haben.

Damit Ihren Pods eine QoS-Klasse vom Typ „Gewährleistet“ zugewiesen werden kann, müssen sie die folgenden Anforderungen erfüllen:

  • Für jeden Container im Pod:
    • Geben Sie Werte sowohl für Arbeitsspeicheranfragen (spec.containers[].resources.requests.memory) als auch für Arbeitsspeicherlimits (spec.containers[].resources.limits.memory) an.
    • Der Wert für Arbeitsspeicherlimits muss dem Wert für Arbeitsspeicheranfragen entsprechen.
    • Geben Sie Werte sowohl für CPU-Ressourcenanfragen (spec.containers[].resources.requests.cpu) als auch für Limits (spec.containers[].resources.limits.cpu) an.
    • Der Wert für die CPU-Limits muss dem Wert für die CPU-Anfragen entsprechen.

Der folgende Auszug aus einer Pod-Spezifikation zeigt Einstellungen für CPU-Ressourcen, die den Anforderungen der Klasse „Guaranteed QoS“ entsprechen:

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 Bereich status die zugewiesene QoS-Klasse 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 Dienstqualitätsklassen finden Sie in der Kubernetes-Dokumentation unter Pod-Dienstqualitätsklassen. Eine Anleitung zum Konfigurieren Ihrer Pods und Container, damit ihnen eine QoS-Klasse zugewiesen wird, finden Sie unter Dienstqualität für Pods konfigurieren

CPU-Anforderungen

Beim Optimieren eines Knotens können Sie eine Reihe von reservierten CPU-Kernen (spec.cpu.reservedCPUs) für das Ausführen von Kubernetes-System-Daemons wie dem Kubelet und der Container-Laufzeit angeben. Auf diesen reservierten CPUs werden auch Betriebssystem-Daemons wie sshd und udev ausgeführt. Die übrigen CPU-Kerne auf dem Knoten werden als isoliert zugewiesen. Die isolierten CPUs sind für CPU-intensive Anwendungen gedacht, die dedizierte CPU-Zeit ohne Störungen durch andere Anwendungen oder Unterbrechungen durch das Netzwerk oder andere Geräte erfordern.

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

  • Konfigurieren Sie den Pod für eine garantierte Dienstqualität (Quality of Service, QoS).

  • Die CPU-Anforderungen und -Limits müssen als Ganzzahlen angegeben werden. Wenn Sie in Ihrer Pod-Spezifikation teilweise CPU-Ressourcen angeben, z. B. cpu: 0.5 oder cpu: 250m (250 Millicores), kann die Planung nicht garantiert werden.

Speicheranforderungen

Wenn Sie einen Knoten mit dem Performance Tuning Operator optimieren, können Sie Hugepages erstellen und mit den NUMA-Knoten (Non-Uniform Memory Access) auf dem Computer verknüpfen. Basierend auf den Pod- und Knoteneinstellungen können Pods mit NUMA-Knotenaffinität geplant werden.

Profil für die Leistungsoptimierung erstellen

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

Die nodeSelector in der Ressource bestimmt die Knoten, auf die das Optimierungsprofil angewendet wird. Wenn Sie ein Profil auf einen Knoten anwenden möchten, platzieren Sie das entsprechende Schlüssel/Wert-Paar-Label auf dem Knoten. Ein Optimierungsprofil wird auf Knoten angewendet, die alle im Feld nodeSelector angegebenen Labels haben.

Sie können mehrere PerformanceTuningProfile-Ressourcen in einem Cluster erstellen. Wenn mehr als ein Profil mit einem bestimmten Knoten übereinstimmt, wird in der status der benutzerdefinierten Ressource PerformanceTuningProfile eine Fehlerbedingung festgelegt. Weitere Informationen zum Bereich status finden Sie unter Status prüfen.

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

So optimieren Sie einen oder mehrere Worker-Knoten:

  1. PerformanceTuningProfile Manifest bearbeiten.

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

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

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

  3. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

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

Tuning-Profil entfernen

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

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

  2. Aktualisieren oder entfernen Sie die Labels am Knoten, damit er nicht mehr vom Optimierungsprofil ausgewählt wird.

Wenn dem Knoten mehrere Tuningprofile zugewiesen sind, wiederholen Sie die vorherigen Schritte bei Bedarf.

Ein Optimierungsprofil pausieren

Wenn Sie Wartungsarbeiten an Ihrem Cluster ausführen müssen, können Sie die Optimierung vorübergehend pausieren, indem Sie die benutzerdefinierte Ressource PerformanceTuningProfile bearbeiten. Wir empfehlen, die Optimierung zu pausieren, bevor Sie wichtige Clustervorgänge wie ein Clusterupgrade ausführen.

Wenn die Profilanwendung fehlgeschlagen ist, können Sie die Optimierung auch pausieren. Wenn die Optimierung fehlschlägt, versucht der Controller möglicherweise weiter, den Knoten zu optimieren, was dazu führen kann, dass der Knoten immer wieder neu gestartet wird. Wenn der Knotenstatus zwischen „Bereit“ und „Nicht bereit“ wechselt, unterbrechen Sie die Optimierung, damit Sie den fehlerhaften Zustand beheben können.

So pausieren Sie die Suche:

  1. Bearbeiten Sie das Manifest der benutzerdefinierten Ressource PerformanceTuningProfile, um spec.paused auf true festzulegen.

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

Wenn die Leistungsoptimierung pausiert wird, beendet der Performance Tuning Operator-Controller alle seine Vorgänge. Durch das Pausieren wird das Risiko verhindert, dass Controller-Vorgänge der Leistungsoptimierung mit Controller-Vorgängen von Google Distributed Cloud in Konflikt stehen.

PerformanceTuningProfile Ressourcenreferenz

In diesem Abschnitt werden die einzelnen Felder in der benutzerdefinierten Ressource PerformanceTuningProfile beschrieben. Mit dieser Ressource wird ein Optimierungsprofil für einen oder mehrere Ihrer Clusterknoten erstellt. Alle Felder in der Ressource sind nach der Profilerstellung veränderbar. Profile müssen sich im Namespace kube-system befinden.

Im folgenden Beispielmanifest für ein numa-Profil für Knoten mit 8 CPU-Kernen sind die folgenden Ressourcenzuweisungen angegeben:

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

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

  • Der Knotenspeicher wird standardmäßig in 2-MiB-Seiten anstelle der standardmäßigen 4-Ki-Seiten aufgeteilt.

  • 10 Arbeitsspeicherseiten mit einer Größe von 1 GiB werden für NUMA-Knoten 0 reserviert.

  • Für NUMA-Knoten 1 werden 5 Arbeitsspeicherseiten mit einer Größe von 2 MiB reserviert.

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

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 Definition der benutzerdefinierten PerformanceTuningProfile-Ressource aus der Gruppe anthos.gke.io in Ihrem Cluster abrufen. Die benutzerdefinierte Ressourcendefinition wird installiert, sobald der benutzerverwalteten Clusterressource die Anmerkung für die Vorschaufunktion 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 den kubelet, die Containerlaufzeit und den Node Problem Detector. Diese CPU-Kerne werden auch für Betriebssystem-Systemdaemons wie sshd und udev verwendet.

Das Feld cpu.reservedCPUs kann eine Liste von CPU-Zahlen oder CPU-Bereichen enthalten. Die Liste der CPUs darf sich nicht mit der Liste überschneiden, die mit cpu.isolatedCPUs angegeben ist. Die Vereinigung 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 Reihe von CPUs, die ausschließlich für leistungsintensive Anwendungen verwendet werden. Der CPU-Manager plant Container gemäß den Kubernetes-QoS-Klassen (Quality of Service) nur auf den nicht reservierten CPUs. Damit Arbeitslasten auf den isolierten CPUs ausgeführt werden, konfigurieren Sie Pods mit der Klasse „Guaranteed QoS“ und weisen Sie dem Pod oder Container eine CPU-Ressource zu. Für eine garantierte Pod-Planung müssen Sie ganze CPU-Einheiten angeben, keine teilweisen CPU-Ressourcen (cpu: "0.5"). 
apiVersion: v1
kind: Pod
...
spec:
  containers:
  ...
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "1"
  ...

Die maximale Auslastung isolierter CPUs für Arbeitslasten bietet den größten Leistungsvorteil. Dieses Feld nimmt eine Liste von CPU-Zahlen oder CPU-Bereichen an. Die Liste der CPUs darf sich nicht mit der Liste überschneiden, die mit cpu.reservedCPUs angegeben wurde, und die Vereinigung der Listen in diesen beiden Feldern muss alle CPUs für den Knoten enthalten.
cpu.balanceIsolated Optional. Veränderlich. Boolescher Wert. Standardeinstellung: true. In diesem Feld wird angegeben, ob der isolierte CPU-Satz für die automatische Lastverteilung von Arbeitslasten auf CPUs infrage kommt. Wenn Sie dieses Feld auf false setzen, müssen Sie in Ihren Arbeitslasten jedem Thread explizit eine bestimmte CPU zuweisen, um die Last auf die CPUs zu verteilen. Mit expliziten CPU-Zuweisungen erhalten Sie die bestmögliche Leistung für garantierte Arbeitslasten. Die Arbeitslasten werden dadurch jedoch komplexer.
cpu.globallyEnableIRQLoadBalancing Erforderlich. Veränderlich. Boolescher Wert. Standardeinstellung: true. Dieses Feld gibt an, ob das Load Balancing für Interruptanfragen (IRQ) für den isolierten CPU-Satz aktiviert werden soll.

Arbeitsspeicherkonfiguration

Attribut Beschreibung
defaultHugePageSize Optional. Veränderlich. Aufzählung: 1G oder 2M. Dieses Feld definiert die Standardgröße von Hugepages in den Kernel-Bootparametern. Hugepages werden beim Starten zugewiesen, bevor der Arbeitsspeicher fragmentiert wird. Wenn Sie die Standardgröße von Hugepages auf 1 GB festlegen, werden alle zugehörigen Ordner vom Typ „2M“ vom Knoten entfernt. Eine Standardgröße von Hugepages von 1 Gigabyte verhindert, dass Sie 2 Millionen Hugepages auf dem Knoten konfigurieren.
pages Optional. Veränderlich. Integer. Dieses Feld gibt die Anzahl der Hugepages an, die beim Starten erstellt werden sollen. In dieses Feld kann ein Array von Seiten eingegeben werden. Prüfen Sie den verfügbaren Arbeitsspeicher Ihrer Knoten, bevor Sie Hugepages angeben. Fordern Sie nicht mehr Hugepages an, als benötigt werden, und reservieren Sie auch nicht den gesamten Arbeitsspeicher für Hugepages. Ihre Arbeitslasten benötigen auch Standardspeicher.

Knotenauswahl

Attribut Beschreibung
nodeSelector Erforderlich. Veränderlich. Für dieses Feld ist immer das Kubernetes-Label für Worker-Knoten, node-role.kubernetes.io/worker:"", erforderlich. So wird sichergestellt, dass die Leistungsoptimierung nur auf Worker-Knoten erfolgt. Dieses Feld nimmt ein optionales Knotenlabel als Schlüssel/Wert-Paar an. Mit den Schlüssel/Wert-Paar-Labels werden bestimmte Worker-Knoten mit übereinstimmenden Labels ausgewählt. Wenn die nodeSelector-Labels mit Labels auf einem Arbeitsknoten übereinstimmen, wird das Leistungsprofil auf diesen Knoten angewendet. Wenn Sie in Ihrem Profil kein Schlüssel/Wert-Label angeben, wird es auf alle Worker-Knoten im Cluster angewendet.

Im folgenden nodeSelector wird beispielsweise angegeben, dass das Optimierungsprofil 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. In diesem Feld wird die Kubernetes-Richtlinie für den Topologiemanager angegeben, die zum Zuweisen von Ressourcen für Ihre Arbeitslasten verwendet wird, basierend auf der zugewiesenen Dienstqualitätsklasse (Quality of Service, QoS). Weitere Informationen zur Zuweisung von QoS-Klassen 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 optimieren.
updateStrategy Optional. Veränderlich. Gibt die Strategie an, mit der Konfigurationsänderungen für die Optimierung auf ausgewählte Knoten angewendet werden.
updateStrategy.rollingUpdateMaxUnavailalble Optional. Veränderlich. Integer. Standardeinstellung: 1. Gibt die maximale Anzahl von Knoten an, die gleichzeitig optimiert 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 Profilupdates auf ausgewählte Knoten angewendet werden sollen. Wenn Sie die Aktualisierung gleichzeitig auf alle ausgewählten Knoten anwenden möchten, setzen Sie type auf batch. Standardmäßig werden Updates nacheinander auf einzelne Knoten angewendet.

Status prüfen

Nachdem die benutzerdefinierte PerformanceTuningProfile-Ressource erstellt oder aktualisiert wurde, passt ein Controller die ausgewählten Knoten anhand der in der Ressource angegebenen Konfiguration an. Um den Status des PerformanceTuningProfile zu prüfen, geben wir das folgende Feld in Status preis:

Attribut Beschreibung
conditions „Zustand“ entspricht den neuesten verfügbaren Beobachtungen zum aktuellen Status der Profilressource.
conditions.lastTransitionTime Wird immer zurückgegeben. String (im Datums-/Uhrzeitformat). Die letzte Statusänderung des Zustands. Dieser Zeitpunkt gibt in der Regel an, wann sich die zugrunde liegende Bedingung geändert hat. Wenn diese Zeit nicht bekannt ist, gibt die Uhrzeit 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. Integer. Wenn dieses Feld festgelegt ist, entspricht es dem metadata.generation, anhand dessen die Bedingung festgelegt wurde. Wenn beispielsweise metadata.generation 12 ist, status.condition[x].observedGeneration aber 9, ist die Bedingung im Hinblick auf den aktuellen Status der Instanz nicht mehr aktuell.
conditions.reason Erforderlich. String. Der Grund für die letzte Statusänderung der Bedingung.
conditions.status Erforderlich. Status der Bedingung: True, False oder Unknown.
conditions.type Erforderlich. „Typ“ ist der Bedingungstyp: Stalled oder Reconciling.
readyNodes Die Anzahl der Knoten, auf die das Optimierungsprofil erfolgreich angewendet wurde.
reconcilingNodes Die Anzahl der ausgewählten (oder zuvor ausgewählten) Knoten, die derzeit vom nodeconfig-controller-manager-DaemonSet mit dem neuesten Tuning-Profil abgeglichen werden.
selectedNodes Die Anzahl der ausgewählten Notizen. Das ist die Anzahl der Knoten, die mit dem Knotenselektor für diese benutzerdefinierte PerformanceTuningProfile-Ressource übereinstimmen.

Nächste Schritte