Knotenleistung abstimmen

Eine Möglichkeit, die Leistung von containerbasierten Anwendungen zu verbessern, besteht darin, die Clusterressourcen zu erhöhen. Dazu fügen Sie Knoten hinzu oder fügen Ihren Knoten Ressourcen wie CPUs oder Arbeitsspeicher hinzu. Dieser Ansatz kann jedoch teuer werden. Durch die Abstimmung Ihrer Clusterknoten auf eine bessere Leistung können Sie die Ressourcennutzung für Ihre Arbeitslasten kostengünstig optimieren. In diesem Dokument wird beschrieben, wie Sie mit dem Leistungsoptimierungsoperator Worker-Knoten abstimmen und so die Arbeitslastleistung für GKE on Bare Metal optimieren.

Zur optimalen Nutzung der zugrunde liegenden Hardware und Software profitieren verschiedene Arten von Anwendungen, insbesondere Hochleistungsanwendungen, von der Abstimmung von Knoteneinstellungen wie der folgenden:

  • Dedizierte CPUs für leistungskritische Arbeitslasten
  • Reservierte CPUs für standardmäßige Kubernetes-Daemons und -Dienste
  • Größere Arbeitsspeicherseiten mit 1 GiB (Gibibyte) oder 2 MiB (Mebibyte) Seiten
  • Arbeitslastverteilung auf Grundlage der Systemarchitektur, z. B. Multi-Core-Prozessoren und NUMA

Mit dem Performance Abstimmungsoperator konfigurieren Sie Leistungseinstellungen auf Knotenebene. Dazu erstellen Sie benutzerdefinierte Kubernetes-Ressourcen, die Leistungskonfigurationen anwenden. Dies sind die Vorteile:

  • Einzelne, einheitliche Konfigurationsoberfläche: Mit dem Leistungsoptimierungsoperator 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 einzelne, einheitliche Weise verwalten.

  • Persistenz und Zuverlässigkeit: Außerdem profitieren Sie von der Zuverlässigkeit, die Kubernetes dank seiner Hochverfügbarkeitsarchitektur bietet. Benutzerdefinierte PerformanceTuningProfile-Ressourcen können jederzeit aktualisiert werden und ihre Einstellungen bleiben für wichtige Clustervorgänge wie Upgrades bestehen.

Der Performance Abstimmungsoperator orchestriert durch die Orchestrierung der folgenden leistungsbezogenen Kubernetes- und Betriebssystemfunktionen und -tools:

Wenn Sie den Leistungsoptimierungsoperator verwenden, sollten Sie die zuvor erwähnten Kubernetes- und Betriebssystemtools und -Features nicht unabhängig voneinander verwenden, um Konflikte zu vermeiden.

Voraussetzungen und Einschränkungen

Für die Verwendung des Leistungsabstimmungsoperators gelten die folgenden Voraussetzungen und Einschränkungen:

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

  • Nutzer- oder Hybridcluster mit Worker-Knoten: Der Operator zur Leistungsoptimierung wird nur für die Verwendung mit Worker-Knoten in Nutzer- oder Hybridclustern unterstützt. Die Verwendung des Leistungsabstimmungsoperators zum Abstimmen von Knoten der Steuerungsebene wird nicht unterstützt. Der Leistungsabstimmungsoperator verwendet einen Knotenselektor, um zu bestimmen, wie Abstimmungsprofile angewendet werden. Damit Abstimmungsprofile nur auf Worker-Knoten angewendet werden, muss nodeSelector in jeder benutzerdefinierten Profilressource das Standardlabel node-role.kubernetes.io/worker: "" für Worker-Knoten enthalten. Wenn der nodeSelector in einem Abstimmungsprofil mit den Labels eines Knotens der Steuerungsebene übereinstimmt, wird dieser Knoten nicht abgestimmt und eine Fehlerbedingung festgelegt. Weitere Informationen zu Fehlerbedingungen finden Sie unter Status prüfen. Prüfen Sie, ob Ihr Cluster korrekt funktioniert, bevor Sie den Leistungsoptimierungsoperator installieren und Feinabstimmungsprofile anwenden.

  • TuneD 2.22.0: Für den Leistungsoptimierungsoperator muss TuneD Version 2.22.0 auf den Worker-Knoten vorinstalliert sein, die Sie abstimmen möchten. Weitere Informationen zu TuneD, einschließlich einer Installationsanleitung, finden Sie unter Erste Schritte mit TuneD in der Dokumentation zu Red Hat Enterprise Linux. 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 für Arbeitslasten: Damit Sie die Leistungsoptimierung optimal nutzen können, sollten Sie die Arbeitsspeicher- und CPU-Anforderungen (Ressourcenanfragen und -limits) für Ihre Arbeitslasten genau kennen.

  • Verfügbare Knotenressourcen: Suchen Sie die CPU- und Arbeitsspeicherressourcen für Ihre Knoten. Sie können detaillierte CPU- und Arbeitsspeicherinformationen für Ihren Knoten in den Dateien /proc/cpuinfo bzw. /proc/meminfo abrufen. Sie können auch kubectl get nodes verwenden, um die Menge der Rechen- und Arbeitsspeicherressourcen (status.allocatable) abzurufen, die ein Worker-Knoten hat und für Pods verfügbar ist.

  • Draining erforderlich:Im Rahmen des Abstimmungsprozesses nimmt der Leistungsabstimmungsoperator zuerst Knoten ab und wendet dann ein Abstimmungsprofil an. Daher melden Knoten während der Leistungsoptimierung möglicherweise den Status NotReady. Wir empfehlen, anstelle eines Batch-Updates die Strategie für Rolling Updates (spec.updateStrategy.type: rolling) zu verwenden, um die Nichtverfügbarkeit von Arbeitslasten zu minimieren.

  • Neustart erforderlich:Damit die Änderungen an der Knotenabstimmung wirksam werden, startet der Leistungsoptimierungsoperator den Knoten nach Anwenden des Feinabstimmungsprofils neu.

Operator für Leistungsoptimierung installieren

Der Performance Abstimmungsoperator besteht hauptsächlich aus zwei Controllern (einem Deployment und einem DaemonSet), die miteinander interagieren, um Knoten auf der Grundlage Ihrer Profileinstellungen abzustimmen. Der Leistungsoptimierungsoperator ist nicht standardmäßig mit GKE on Bare Metal installiert. Sie laden die Manifeste für den Leistungsoptimierungsoperator aus Cloud Storage herunter und verwenden kubectl apply, um Ressourcen für den Leistungsoptimierungsoperator 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 aus dem Verzeichnis performance-tuning das neueste Paket für den Leistungsabstimmungsoperator 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 performance-tuning-operator-Deployment und das DaemonSet nodeconfig-controller-manager. Manifeste für verwandte Funktionen wie rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und 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

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

Ressourcenanforderungen für Ihre Arbeitslasten überprüfen

Bevor Sie Ihre Knoten optimieren können, müssen Sie die Anforderungen an Rechen- und Arbeitsspeicherressourcen Ihrer Arbeitslasten kennen. Wenn Ihre Worker-Knoten über genügend Ressourcen verfügen, können die Knoten abgestimmt werden, um garantierten Arbeitsspeicher (Standard und riesige Seiten) für Ihre Arbeitslasten in der garantierten Quality of Service-Klasse (QoS) bereitzustellen.

Kubernetes weist jedem Ihrer Pods QoS-Klassen anhand der 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 Ihren Arbeitslasten Ressourcen zugewiesen werden. Damit Sie die Knotenabstimmung für Ihre Arbeitslasten optimal nutzen können, müssen für Ihre Arbeitslasten Einstellungen für CPU- oder Arbeitsspeicherressourcenanforderungen oder -limits festgelegt sein.

Damit Ihre Pods eine garantierte QoS-Klasse zuweisen können, müssen sie 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 des Arbeitsspeicherlimits muss dem Wert der Arbeitsspeicheranfragen entsprechen.
    • Geben Sie Werte für CPU-Ressourcenanfragen (spec.containers[].resources.requests.cpu) und Limits (spec.containers[].resources.limits.cpu) an.
    • Der Wert des CPU-Limits muss dem Wert der CPU-Anfragen entsprechen.

Der folgende Auszug der Pod-Spezifikation zeigt Einstellungen für CPU-Ressourcen, die die garantierten Anforderungen der 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 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-Qualität von Dienstklassen. 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 Abstimmen eines Knotens können Sie eine Reihe von reservierten CPU-Kernen (spec.cpu.reservedCPUs) zum Ausführen von Kubernetes-System-Daemons wie Kubelet und Containerlaufzeit angeben. Auf demselben Satz reservierter CPUs werden auch Betriebssystem-Daemons wie sshd und udev ausgeführt. Der Rest der CPU-Kerne auf dem Gerät wird isoliert zugewiesen. Die isolierten CPUs sind für CPU-gebundene Anwendungen vorgesehen, die eine dedizierte CPU-Zeit ohne Störungen durch andere Anwendungen oder Unterbrechungen durch Netzwerke 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.

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

Speicheranforderungen

Wenn Sie einen Knoten mit dem Performance Abstimmungsoperator abstimmen, können Sie große Seiten erstellen und sie mit den NUMA-Knoten (Non-Uniform Memory Access) auf dem Computer verknüpfen. Je nach Pod- und Knoteneinstellungen können Pods mit NUMA-Knotenaffinität geplant werden.

Profil zur Leistungsoptimierung erstellen

Nachdem Sie den Performance Abstimmungsoperator installiert haben, interagieren Sie nur mit dem Cluster, auf dem Ihre Arbeitslasten ausgeführt werden. PerformanceTuningProfile benutzerdefinierte Ressourcen werden direkt in Ihrem Nutzercluster oder Hybridcluster erstellt, nicht in Ihrem Administratorcluster. Jede Ressource PerformanceTuningProfile 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. Platzieren Sie das entsprechende Schlüssel/Wert-Paar-Label auf dem Knoten, um ein Profil auf einen Knoten anzuwenden. Ein Abstimmungsprofil 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 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 PerformanceTuningProfile-Ressource 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 finden Sie in der Ressourcenreferenz PerformanceTuningProfile.

  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: der Pfad der Manifestdatei für die benutzerdefinierte Ressource PerformanceTuningProfile.
    • KUBECONFIG: der Pfad der kubeconfig-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, 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 den Cluster warten müssen, können Sie die Abstimmung vorübergehend anhalten, indem Sie die benutzerdefinierte Ressource PerformanceTuningProfile bearbeiten. Wir empfehlen, die Abstimmung anzuhalten, bevor Sie wichtige Clustervorgänge wie ein Clusterupgrade ausführen.

Eine fehlgeschlagene Profilanwendung ist ein weiterer Fall, in dem Sie die Abstimmung pausieren können. Wenn die Abstimmung 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 Sie beobachten, dass der Knotenstatus zwischen dem Status „Bereit“ und „Nicht bereit“ wechselt, halten Sie die Feinabstimmung an, damit Sie den 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 ist, stoppt der Performance Abstimmung Operator-Controller alle Vorgänge. Durch das Pausieren wird das Risiko von Controller-Vorgängen des Performance Tuning Operator, die mit GKE on Bare Metal-Controller-Vorgängen in Konflikt stehen, verhindert.

PerformanceTuningProfile-Ressourcenreferenz

In diesem Abschnitt werden alle Felder in der benutzerdefinierten Ressource PerformanceTuningProfile beschrieben. Diese Ressource wird verwendet, um ein Abstimmungsprofil für einen oder mehrere 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 Beispielprofilmanifest für numa 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 Seiten mit 2 MiB und nicht in die standardmäßigen 4-Ki-Seiten aufgeteilt.

  • 10 Seiten Arbeitsspeicher mit einer Größe von 1 GiB werden für die Verwendung durch NUMA-Knoten 0 reserviert.

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

  • Topologie Manager verwendet die Best-Effort-Richtlinie zum Planen 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 benutzerdefinierte Ressourcendefinition PerformanceTuningProfile aus der Gruppe anthos.gke.io in Ihrem Cluster abrufen. Die benutzerdefinierte Ressourcendefinition wird installiert, nachdem der selbstverwalteten Clusterressource die Annotation der Vorschaufunktion hinzugefügt wurde.

CPU-Konfiguration

Attribut Beschreibung
cpu.reservedCPUs Erforderlich. Kann geändert werden. String. Dieses Feld definiert eine Reihe von CPU-Kernen, die für Kubernetes-System-Daemons wie Kubelet, Containerlaufzeit und Knotenproblemerkennung reserviert werden sollen. Diese CPU-Kerne werden auch für Betriebssystem-System-Daemons wie sshd und udev verwendet.

Das Feld cpu.reservedCPUs enthält eine Liste von CPU-Nummern oder Bereichen von CPU-Nummern. Die Liste der CPUs darf sich nicht mit der mit cpu.isolatedCPUs angegebenen Liste überschneiden. Die in diesen beiden Feldern aufgeführten CPUs müssen alle CPUs für den Knoten enthalten.
cpu.isolatedCPUs Optional. Kann geändert werden. String. Im Feld cpu.isolatedCPUs wird eine Gruppe von CPUs definiert, die ausschließlich für leistungsempfindliche Anwendungen verwendet werden. CPU Manager plant Container nur auf den nicht reservierten CPUs gemäß den QoS-Klassen (Quality of Service) von Kubernetes. Damit Arbeitslasten auf den isolierten CPUs ausgeführt werden, sollten Sie Pods mit der garantierten QoS-Klasse konfigurieren und dem Pod oder Container eine CPU-Ressource zuweisen. Für eine garantierte Pod-Planung müssen Sie ganzzahlige CPU-Einheiten angeben, keine partiellen CPU-Ressourcen (cpu: "0.5"). 

apiVersion: v1
kind: Pod
...
spec:
  containers:
  ...
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "1"
  ...

Das Maximieren isolierter CPUs für Arbeitslasten bietet den größten Leistungsvorteil. In diesem Feld wird eine Liste von CPU-Nummern oder CPU-Bereichen angegeben. Die Liste der CPUs darf sich nicht mit der mit cpu.reservedCPUs angegebenen Liste überschneiden. Außerdem muss die Zusammenführung der Listen in diesen beiden Feldern alle CPUs für den Knoten umfassen.
cpu.balanceIsolated Optional. Kann geändert werden. 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 die CPUs zu verteilen. Mit expliziten CPU-Zuweisungen erhalten Sie die vorhersehbarste Leistung für garantierte Arbeitslasten, erhöhen jedoch die Komplexität Ihrer Arbeitslasten.
cpu.globallyEnableIRQLoadBalancing Erforderlich. Kann geändert werden. Boolescher Wert. Standardeinstellung: true. Dieses Feld gibt an, ob das Load-Balancing von Interrupt-Anfragen (IRQ) für die isolierte CPU-Gruppe aktiviert wird oder nicht.

Arbeitsspeicherkonfiguration

Attribut Beschreibung
defaultHugePageSize Optional. Kann geändert werden. Aufzählung: 1G oder 2M. In diesem Feld wird die Standardgröße für Riesenseite in Kernel-Bootparametern definiert. Riesige Seiten werden beim Booten zugewiesen, bevor der Arbeitsspeicher fragmentiert wird. Wichtig: Wenn Sie die Standardgröße von großen Seiten auf 1 G festlegen, werden alle 2 Millionen zugehörigen Ordner aus dem Knoten entfernt. Die Standardgröße für enorme Seiten von 1 GB verhindert, dass 2 Millionen große Seiten im Knoten konfiguriert werden können.
pages Optional. Kann geändert werden. Ganze Zahl. Dieses Feld gibt die Anzahl der großen Seiten an, die beim Booten erstellt werden sollen. Für dieses Feld ist ein Array mit Seiten zulässig. Überprüfen Sie den verfügbaren Arbeitsspeicher für Ihre Knoten, bevor Sie VAST-Seiten angeben. Fordere nicht mehr große Seiten als nötig an und reserviere auch nicht den gesamten Speicher für große Seiten. Ihre Arbeitslasten benötigen auch Standardarbeitsspeicher.

Knotenauswahl

Attribut Beschreibung
nodeSelector Erforderlich. Kann geändert werden. Für dieses Feld ist immer das Label für Kubernetes-Worker-Knoten (node-role.kubernetes.io/worker:"") erforderlich. Dieses sorgt dafür, dass die Leistungsoptimierung nur für Worker-Knoten durchgeführt wird. Für dieses Feld wird ein optionales Knotenlabel als Schlüssel/Wert-Paar verwendet. Die Labels der Schlüssel/Wert-Paare werden verwendet, um bestimmte Worker-Knoten mit übereinstimmenden Labels auszuwählen. Wenn die Labels nodeSelector mit den Labels eines Worker-Knotens ü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.

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. Kann geändert werden. 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 anhand der zugewiesenen QoS-Klasse (Quality of Service) verwendet wird. Weitere Informationen zur Zuweisung von QoS-Klassen finden Sie unter Servicequalität für Pods konfigurieren.

Profilvorgänge

Attribut Beschreibung
paused Optional. Kann geändert werden. Boolescher Wert. Legen Sie paused auf true fest, um vorübergehend zu verhindern, dass die DaemonSet-Controller ausgewählte Knoten abstimmen.
updateStrategy Optional. Kann geändert werden. Gibt die Strategie zum Anwenden von Änderungen der Abstimmungskonfiguration auf ausgewählte Knoten an.
updateStrategy.rollingUpdateMaxUnavailalble Optional. Kann geändert werden. 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. Kann geändert werden. Aufzählung: batch oder rolling. Standardeinstellung: rolling. Gibt an, wie Profilaktualisierungen auf ausgewählte Knoten angewendet werden. Wenn Sie das Update gleichzeitig auf alle ausgewählten Knoten anwenden möchten, setzen Sie type auf batch. Standardmäßig werden Aktualisierungen nacheinander auf einzelnen Knoten eingeführt.

Status prüfen

Nachdem die benutzerdefinierte Ressource PerformanceTuningProfile erstellt oder aktualisiert wurde, stimmt ein Controller die ausgewählten Knoten anhand der in der Ressource bereitgestellten Konfiguration ab. Um den Status von PerformanceTuningProfile zu prüfen, wird das folgende Feld in Status verfügbar gemacht:

Attribut Beschreibung
conditions Die Bedingung stellt die neuesten verfügbaren Beobachtungen zum aktuellen Status der Profilressource dar.
conditions.lastTransitionTime Wird immer zurückgegeben. String (im Datum-/Uhrzeitformat). Das letzte Mal, dass die Bedingung von einem Status auf einen anderen übergegangen ist. Diese Zeit zeigt in der Regel an, wann sich die zugrunde liegende Bedingung geändert hat. Ist dieser Zeitpunkt nicht bekannt, gibt die Zeit an, wann sich das API-Feld geändert hat.
conditions.message Optional. String. Eine menschenlesbare Meldung mit Details zum Übergang. Dieses Feld ist möglicherweise leer.
conditions.observedGeneration Optional. Ganze Zahl. Wenn dieses Feld festgelegt ist, stellt es den metadata.generation dar, auf dem die Bedingung festgelegt wurde. Wenn metadata.generation beispielsweise 12 ist, status.condition[x].observedGeneration aber 9 ist, ist die Bedingung in Bezug auf den aktuellen Status der Instanz veraltet.
conditions.reason Erforderlich. String. Der Grund für den letzten Bedingungsübergang.
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 Abstimmungsprofil erfolgreich angewendet wurde.
reconcilingNodes Die Anzahl der ausgewählten (oder zuvor ausgewählten) Knoten, die gerade mit dem letzten Abstimmungsprofil durch das DaemonSet nodeconfig-controller-manager abgeglichen werden.
selectedNodes Die Anzahl der ausgewählten Notizen. Das ist die Anzahl der Knoten, die dem Knotenselektor für diese benutzerdefinierte PerformanceTuningProfile-Ressource entsprechen.

Nächste Schritte