Dynamic Engineのtolerationルールの設定

Dynamic Engine Helmチャートでtolerationを使用し、taintが付与されたKubernetesノードにPodがスケジュールされるようにします。

Dynamic Engine v1.4.0 以降、Helmのvaluesファイルにtolerationルールを設定することで、どのtaintされたノードをPodのスケジューリング対象とするかを制御できるようになりました。すべてのPodに一律のルールを適用するか、インフラストラクチャサービスPodと、データ統合ジョブ、データサービスジョブ、ルートなどのカスタマーワークロードPodに対して個別のルールを設定します。

注: このカスタマイズは、チャートの初回インストール時またはアップグレード時に適用できます。

始める前に

dynamic-engine-crdカスタムリソース定義は、oci://ghcr.io/talend/helm/dynamic-engine-crd Helmチャートを使用してインストールされている必要があります。インストールされていない場合は、次のコマンドを実行してインストールしてください。
1. 使用するチャートのバージョンを見つけます。
  - 次のHelmコマンドを実行します:
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Talend Management Consoleから直接バージョンを見るか、自分のDynamic Engineバージョンに含まれているチャートバージョンのDynamic Engine変更ログをチェックしてください。
  - Dynamic EngineバージョンエンドポイントへのAPIコールを使用します。
2. 次のコマンドを実行し、目的のバージョンのHelmチャートをインストールします。
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  <helm_chart_version>を、お使いのDynamic Engineバージョンでサポートされているチャートのバージョンに置換します。
  バージョンを指定しないと、利用可能な最新のdynamic-engine-crdチャートバージョンがインストールされます。
Kubernetesノードには、許容する予定の値でtaintを設定する必要があります。
Kubernetesのtaintとtolerationに関する基本的な知識が必要です。

このタスクについて

デフォルトでは、一致するtolerationルールを設定しない限り、Dynamic Engine Pod はtaintが付与されたノードにはスケジュールされません。ノードに設定されたtaintは、対応するtolerationを持たないPodが配置されるのをスケジューラによって配置されるのを防ぎます。すべてのPodが同じtaint付きノードプールを共有できる場合は、一律のグローバルルールを使用します。インフラストラクチャサービスのPodと顧客ワークロードのPodを異なるtaint付きノードにスケジュールする必要がある場合は、ワークロードごとに個別のルールを設定します。

手順

Kubernetesマシンで、ダウンロードしておいたHelmデプロイメントのzipファイルを解凍します。
すべてのPodがターゲットとなるtaintを持つノードにスケジュールされるよう、global.tolerationsを含むカスタムvaluesファイルを作成します。
例
この例では、ノードにdedicated=dynamic-engine:NoScheduleというtaintが付与されています。次のvaluesファイルは、このtaintに一致するtolerationを作成します。
```
cat <<EOF > custom-tolerations-values.yaml
global:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "dynamic-engine"
      effect: "NoSchedule"
EOF
```

グローバルtolerationルールを使用して、Dynamic EngineおよびDynamic Engine環境をデプロイします。

例

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

デプロイ後、qlik-dynamic-engineおよびqlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_IDの両ネームスペース内のPodは、dedicated=dynamic-engine:NoScheduleというtaintが付与されたノードにスケジュールできるようになります。

インフラストラクチャサービスPodと顧客ワークロードPodに対して個別のtolerationルールを設定するには、ステップ2および3の代わりに、ステップ4および5を実行してください。

インフラストラクチャサービスPodと顧客ワークロードPodに対して、個別のtolerationルールを作成します。
global.tolerationsに設定されたtolerationルールは、チャートによって作成されるすべてのPodに適用されます。configuration.jobDeployment.tolerationsおよびconfiguration.dataServiceRouteDeployment.tolerationsで設定されたルールは、顧客ワークロードPodにのみ適用されます。これらには、データ統合ジョブ、データサービスジョブ、ルートが含まれます。ワークロード固有のルールを定義した場合、そのルールは該当するポッドタイプに対してのみグローバルルールを上書きします。ワークロード固有のルールを定義しない場合、すべてのPodはグローバルのtolerationルールを使用します。

例
この例では、インフラストラクチャサービスのPodはdedicated=dynamic-engine:NoScheduleを許容し、顧客ワークロードのPodはdedicated=dynamic-engine-jobs-and-routes:NoScheduleを許容します。2つのカスタムvaluesファイルを作成します。
```
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
```
分割されたtolerationルールを使用してチャートをデプロイします。
例
グローバルtolerationファイルを両方のチャートに適用します。ワークロード固有のファイルを、環境チャートにのみ適用します。
```
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
```
デプロイ後、qlik-dynamic-engineおよびqlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_IDの両ネームスペース内のインフラストラクチャサービスPodは、dedicated=dynamic-engine:NoScheduleというtaintが付与されたノードにスケジュールできるようになります。qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_IDネームスペース内の顧客ワークロードPodは、dedicated=dynamic-engine-jobs-and-routes:NoScheduleのtaintが付与されたノードにスケジュールできます。

タスクの結果

チャートを正常にデプロイした後:

qlik-dynamic-engineネームスペース内のDynamic Engineサービスは、dedicated=dynamic-engine:NoScheduleのtaintが付与されたノードにスケジュールできます。
qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_IDネームスペース内のDynamic Engine環境サービスは、dedicated=dynamic-engine:NoScheduleのtaintが付与されたノード上でスケジュールできます。
個別のtolerationルールを使用する場合、qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_IDネームスペース内の顧客ワークロードPod (データ統合ジョブ、データサービスジョブ、ルートPod)は、dedicated=dynamic-engine-jobs-and-routes:NoScheduleのtaintが付与されたノードにスケジュールできます。

注: tolerationsをnodeSelectorやアフィニティルールと組み合わせることで、ノードラベルとtaintsの両方を利用してPodの配置を制御できます。Dynamic EngineのアフィニティとnodeSelectorルールの設定を参照してください。

トラブルシューティング:

tolerationsを追加した後もPodが保留中ステータスのままとなる場合は、ノードのtaintsとPodのtolerationsとの間に不一致がないか確認してください。

一般的な状況には次のようなものがあります。

ノードにはdedicated=dynamic-engine:NoScheduleというtaintが付与されていますが、Pod には dedicated(専用)キーに対するtolerationがありません。
Podのtolerationに誤った値、オペレーター、エフェクトが設定されているため、taintと正確に一致しません。
ノードがNoExecuteを使用しており、ポッドがNoScheduleのみを許容している場合、スケジューラーはPodを拒否または退避させる可能性があります。

次のコマンドを使用して、問題を調査:

スケジューリング失敗の詳細について、Podを検査:
```
kubectl describe pod <pod-name> -n <namespace>
```
イベントおよびTolerationsセクションを確認してください。スケジューリングの失敗イベントは、許容されなかった特定のtaintを特定します。
スケジュール失敗イベントを時刻順に検索:
```
kubectl get events -n <namespace> --sort-by=.lastTimestamp
```
対応するtolerationが存在しないtaintを参照しているFailedSchedulingメッセージを確認します。
ノードのtaintsとPodのtolerationsを比較:
```
kubectl describe node <node-name>
```
Taintsセクションを確認します。taintのキー、値、オペレーター、エフェクトは、Podのtolerationと完全に一致している必要があります。
Podがどのノードに配置されたかを特定:
```
kubectl get pods -n <namespace> -o wide
```
このコマンドを使用してノードの割り当てを確認し、次にkubectl describe nodeでそのノードを詳しく調べます。

このページは役に立ちましたか?

このページまたはコンテンツにタイポ、ステップの省略、技術的エラーなどの問題が見つかった場合はお知らせください。

こちらにフィードバックをお寄せください