Konfigurieren von Tolerations-Regeln für Dynamic Engine

Verwenden Sie Tolerations in Dynamic Engine-Helm-Charts, um zuzulassen, dass Pods auf Kubernetes-Knoten mit Taints geplant werden.

Ab Dynamic Engine v1.4.0 können Sie Toleration-Regeln in Helm-Wertedateien festlegen, um zu steuern, welche Knoten mit Taints für die Planung von Pods berechtigt sind. Wenden Sie eine einheitliche Regel auf alle Pods an oder konfigurieren Sie getrennte Regeln für Infrastruktur-Service-Pods und Kunden-Arbeitslast-Pods wie Datenintegrations-Jobs, Datenservices-Jobs und Routen.

Anmerkung: Sie können diese Anpassung während der anfänglichen Chart-Installation oder bei einem Upgrade anwenden.

Vorbereitungen

Die benutzerdefinierten Ressourcendefinitionen dynamic-engine-crd müssen mit dem Helm-Chart oci://ghcr.io/talend/helm/dynamic-engine-crd installiert worden sein. Führen Sie andernfalls die folgenden Befehle für die Installation aus:
1. Suchen Sie die zu verwendende Diagrammversion:
  - Führen Sie den folgenden Helm-Befehl aus:
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Sehen Sie die Version direkt über Talend Management Console ein oder suchen Sie im Dynamic Engine Änderungs-Log nach der in Ihrer Dynamic Engine-Version enthaltenen Diagrammversion.
  - Verwenden Sie einen API-Aufruf an den Dynamic Engine-Versionsendpunkt.
2. Führen Sie den folgenden Befehl aus, um das Helm-Chart einer bestimmten Version zu installieren:
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Ersetzen Sie <helm_chart_version> durch die Chart-Version, die von Ihrer Dynamic Engine-Version unterstützt wird.
  Wenn die Version nicht angegeben wird, installieren Sie die neueste verfügbare dynamic-engine-crd-Diagrammversion.
Ihr Kubernetes-Knoten muss Taints mit den Werten aufweisen, die Sie tolerieren möchten.
Sie benötigen grundlegende Kenntnisse über Kubernetes-Taints und -Tolerations.

Warum und wann dieser Vorgang ausgeführt wird

Standardmäßig werden auf Knoten mit Taints keine Dynamic Engine-Pods geplant, es sei denn, Sie konfigurieren eine entsprechende Toleration-Regel. Ein Taint für einen Knoten verhindert, dass der Planer Pods platziert, die nicht die entsprechende Toleration aufweisen. Verwenden Sie eine einheitliche globale Regel, wenn alle Pods den gleichen Knoten-Pool mit Taints nutzen können. Konfigurieren Sie getrennte arbeitslastspezifische Regeln, wenn Infrastruktur-Service-Pods und Kunden-Arbeitslast-Pods auf verschiedenen Knoten mit Taints geplant werden müssen.

Prozedur

Entpacken Sie auf dem Kubernetes-Rechner die Helm-Implementierungs-ZIP-Datei, die Sie zuvor heruntergeladen haben.
Erstellen Sie eine benutzerdefinierte Wertedatei mit global.tolerations, um zuzulassen, dass alle Pods auf Knoten mit dem Ziel-Taint geplant werden.
Example
In diesem Beispiel weisen Knoten den Taint dedicated=dynamic-engine:NoSchedule auf. Die folgende Wertedatei erstellt eine Toleration, die diesem Taint entspricht:
```
cat <<EOF > custom-tolerations-values.yaml
global:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "dynamic-engine"
      effect: "NoSchedule"
EOF
```

Implementieren Sie Dynamic Engine und die Dynamic Engine-Umgebung mit der globalen Toleration-Regel.

Example

helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
  -f $DYNAMIC_ENGINE_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine \
  --version $DYNAMIC_ENGINE_VERSION

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version $DYNAMIC_ENGINE_VERSION

Nach der Bereitstellung können Pods sowohl im Namespace qlik-dynamic-engine als auch im Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID auf Knoten geplant werden, die den Taint dedicated=dynamic-engine:NoSchedule aufweisen.

Um getrennte Toleration-Regeln für Infrastruktur-Service-Pods und Kunden-Arbeitslast-Pods zu konfigurieren, befolgen Sie die Schritte 4 und 5 statt der Schritte 2 und 3.

Erstellen Sie getrennte Toleration-Regeln für Infrastruktur-Service-Pods und Kunden-Arbeitslast-Pods.
Toleration-Regeln, die unter global.tolerations festgelegt sind, gelten für alle vom Chart erstellten Pods. Regeln, die unter configuration.jobDeployment.tolerations und configuration.dataServiceRouteDeployment.tolerations festgelegt sind, gelten nur für Kunden-Arbeitslast-Pods. Dazu zählen Datenintegrations-Jobs, Datenservices-Jobs und Routen. Wenn Sie arbeitslastspezifische Regeln definieren, überschreiben diese die globalen Regeln nur für diese Pod-Typen. Wenn Sie keine arbeitslastspezifischen Regeln definieren, verwenden alle Pods die allgemeinen Toleration-Regeln.

Example
In diesem Beispiel tolerieren Infrastruktur-Service-Pods dedicated=dynamic-engine:NoSchedule und Kunden-Arbeitslast-Pods tolerieren dedicated=dynamic-engine-jobs-and-routes:NoSchedule. Erstellen Sie zwei benutzerdefinierte Wertedateien:
```
cat <<EOF > custom-tolerations-values.yaml
global:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "dynamic-engine"
      effect: "NoSchedule"
EOF

cat <<EOF > custom-jobDeployment-dataServiceRouteDeployment-tolerations-values.yaml
configuration:
  jobDeployment:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "dynamic-engine-jobs-and-routes"
        effect: "NoSchedule"
  dataServiceRouteDeployment:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "dynamic-engine-jobs-and-routes"
        effect: "NoSchedule"
EOF
```
Implementieren Sie die Charts mit den geteilten Toleration-Regeln.
Example
Wenden Sie die globale Toleration-Datei auf beide Charts an. Wenden Sie die arbeitslastspezifische Datei nur auf den Umgebungs-Chart an:
```
helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
  -f $DYNAMIC_ENGINE_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine \
  --version $DYNAMIC_ENGINE_VERSION

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  -f custom-jobDeployment-dataServiceRouteDeployment-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version $DYNAMIC_ENGINE_VERSION
```
Nach der Bereitstellung können Infrastruktur-Service-Pods sowohl im Namespace qlik-dynamic-engine als auch im Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID auf Knoten geplant werden, die den Taint dedicated=dynamic-engine:NoSchedule aufweisen. Kunden-Arbeitslast-Pods im Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID können auf Knoten mit dem Taint dedicated=dynamic-engine-jobs-and-routes:NoSchedule geplant werden.

Ergebnisse

Nachdem Sie die Charts erfolgreich implementiert haben:

Dynamic Engine-Services im Namespace qlik-dynamic-engine können auf Knoten mit dem Taint dedicated=dynamic-engine:NoSchedule geplant werden.
Dynamic Engine-Umgebungsservices im Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID können auf Knoten mit dem Taint dedicated=dynamic-engine:NoSchedule geplant werden.
Wenn getrennte Toleration-Regeln verwendet werden, können Kunden-Arbeitslast-Pods (Datenintegrations-Jobs, Datenservices-Jobs und Routen-Pods) im Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID auf Knoten mit dem Taint dedicated=dynamic-engine-jobs-and-routes:NoSchedule geplant werden.

Anmerkung: Sie können Tolerations mit nodeSelector- und affinity-Regeln kombinieren, um die Pod-Platzierung sowohl mit Knotenbezeichnungen als auch mit Taints zu steuern. Weitere Informationen finden Sie unter Konfigurieren der affinity- und nodeSelector-Regeln für Dynamic Engine.

Troubleshooting:

Wenn Pods nach dem Hinzufügen von Tolerations im Status Pending (Ausstehend) bleiben, prüfen Sie, ob eine Nichtübereinstimmung zwischen Knoten-Taints und Tolerations vorliegt.

Zu häufigen Situationen zählen:

Der Knoten weist den Taint dedicated=dynamic-engine:NoSchedule auf, aber der Pod hat keine Toleration für den Schlüssel dedicated.
Die Pod-Toleration verwendet den falschen value, operator oder effect, sodass sie nicht genau mit dem Taint übereinstimmt.
Der Knoten verwendet NoExecute und der Pod toleriert nur NoSchedule, sodass der Planer den Pod dennoch ablehnen oder auslagern kann.

Verwenden Sie die folgenden Befehle, um das Problem zu prüfen:

Prüfen Sie den Pod auf Planungsfehlerdetails:
```
kubectl describe pod <pod-name> -n <namespace>
```
Schauen Sie sich die Abschnitte Events und Tolerations an. Ein fehlgeschlagenes Planungsevent benennt den spezifischen Taint, der nicht toleriert wurde.
Suchen Sie nach Uhrzeit sortiert nach Planungsfehlerevents:
```
kubectl get events -n <namespace> --sort-by=.lastTimestamp
```
Suchen Sie nach Meldungen mit FailedScheduling, die Taints ohne übereinstimmende Toleration referenzieren.
Vergleichen Sie Knoten-Taints mit Pod-Tolerations:
```
kubectl describe node <node-name>
```
Prüfen Sie den Abschnitt Taints. Die Taint-Werte key, value, operator und effect müssen alle genau mit der Pod-Toleration übereinstimmen.
Identifizieren Sie, auf welchem Knoten ein Pod platziert wurde:
```
kubectl get pods -n <namespace> -o wide
```
Verwenden Sie diesen Befehl, um die Knotenzuweisung anzuzeigen, und prüfen Sie diesen Knoten dann mit kubectl describe node.

Hat diese Seite Ihnen geholfen?

Wenn Sie ein Problem mit dieser Seite oder ihrem Inhalt feststellen, sei es ein Tippfehler, ein ausgelassener Schritt oder ein technischer Fehler, informieren Sie uns bitte!

Geben Sie hier Ihr Feedback ab