Dynamic EngineのアフィニティとnodeSelectorルールの設定

Dynamic Engine HelmチャートでnodeSelectorとアフィニティルールを使用することで、Kubernetesクラスター内の異なるノードグループ間でのPodのスケジューリングを制御できます。

Dynamic Engine v1.1.0以降では、セキュリティ、パフォーマンス、リソース最適化などの目的で、特定のノード上でサービスを分離するための特定のアフィニティルールを設定できます。たとえば、大規模なノードグループを確保して、集中的なポッド実行に使用できます。

Dynamic Engine v1.1.0は、Helm値ファイルにおいて、nodeSelector(シンプルなラベルベースの選択)とアフィニティルール(複雑なスケジューリングロジック)の両方をサポートしています。

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

始める前に

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クラスターは、適切なラベルが付与された複数のノードグループ(ノードプール)で構成されている必要があります。この構成の設定方法については、使用中のクラウドプロバイダーが提供する関連ドキュメントを参照してください。例: KubernetesとGKEを使用している場合は、クラスタとノードプールのラベルを作成して管理するを参照してください。
Kubernetesのアフィニティルールに関する基本的な知識が必要です。

このタスクについて

デフォルトでは、Dynamic Engineポッドはクラスター内の利用可能なすべてのノードにスケジュールされます。ノードアフィニティとノードセレクタールールを使用することで、ポッドの配置を制御し、次のような特定の目標を達成できます。

永続的なサービスを小規模な専用ノードに分離する
ジョブ、ルート、データサービスなどのワークロードを、特定のインスタンスタイプを備えた大規模なノードで実行する

使用するノードラベルの例は次のとおりです。

instanceType=large
instanceType=medium
qlik-dynamic-engine-tasks=true

手順

Kubernetesマシンで、ダウンロードしておいたHelmデプロイメントのzipファイルを解凍します。
グローバルスケジューリングルールにnodeSelectorを使用するカスタム値ファイルを作成します。
例
この例では、インフラストラクチャ用の永続的なサービスをミディアムノードで実行するためのグローバルルールが定義されています。このルールは、instanceType=mediumというラベルが付いたノードに、すべてのDynamic Engineおよび環境ポッドをスケジュールします。
```
cat <<EOF > custom-medium-instance-for-infrastructure-values.yaml
global:
  nodeSelector:
    instanceType: medium
EOF
```
nodeSelectorは単純な完全一致に適していますが、論理式はサポートしていません。
または、アフィニティルールを使用してカスタム値ファイルを作成することで、より高度なスケジューリングロジックを用いて同じ結果を実現することもできます。
例
この例は、nodeSelectorを使用した場合と同じ結果を、nodeAffinityを使用して実現しています。
```
cat <<EOF > custom-medium-instance-for-infrastructure-values.yaml
global:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: instanceType
                operator: In
                values: medium
EOF
```
情報メモヒント: nodeSelectorとアフィニティルールは組み合わせることができます。両方を指定した場合、ポッドがそのノードにスケジュールされるには、ノードが両方のルールを満たす必要があります。

グローバルスケジューリングルールを使用して、Dynamic Engine環境とDynamic Engine環境をデプロイします。

helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID -f $DYNAMIC_ENGINE_ID-values.yaml  \
 -f custom-medium-instance-for-infrastructure-values.yaml \
 oci://myregistry.example.com/docker-ghcr-io-remote/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-medium-instance-for-infrastructure-values.yaml \
 oci://myregistry.example.com/docker-ghcr-io-remote/talend/helm/dynamic-engine-environment \
 --version $DYNAMIC_ENGINE_VERSION

ワークロード固有のスケジューリングでは、Podが大規模なノードグループ上で実行されるように制約を設ける別のカスタム値ファイルを作成します。
例
この例では、データ統合タスク、データサービス、およびルートタスクを、qlik-dynamic-engine-tasks=trueというラベルが付いた大規模ノードに限定するための特定のルールが定義されています。
```
cat <<EOF > custom-jobDeployment-dataServiceRouteDeployment-nodeSelector-values.yaml
configuration:
  jobDeployment:
    nodeSelector:
      instanceType: large
      qlik-dynamic-engine-tasks: "true"
  dataServiceRouteDeployment:
    nodeSelector:
      instanceType: large
      qlik-dynamic-engine-tasks: "true"
EOF
```

ワークロード固有のスケジューリングルールを使用してDynamic Engine環境をデプロイします。

例

このワークロードルールはタスク処理サービスに特化したものであり、Dynamic Engine環境でのみ適用されます。

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
 -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml  \
 -f custom-jobDeployment-dataServiceRouteDeployment-nodeSelector-values.yaml \
 oci://myregistry.example.com/docker-ghcr-io-remote/talend/helm/dynamic-engine-environment \
 --version $DYNAMIC_ENGINE_VERSION

タスクの結果

デプロイが正常に完了すると、すべてのDynamic Engineと環境ポッドは、ユーザーが設定したアフィニティおよびnodeSelectorルールに従ってスケジュールされます。インフラストラクチャ向けの永続的なサービスは専用のノード上で実行され、顧客のワークロードはそれぞれのリソース要件に合わせて最適化されたノード上で実行されます。

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

ポッド(または複数のポッド)がノードにスケジュールできない場合は、次の手順に従って問題を診断し、解決してください。

スケジューリングの失敗を特定します。
kubectl describe podコマンドを使用して、スケジューリングエラーに関する詳細情報を取得します。
```
kubectl describe pod <pod-name> -n <namespace>
```
[イベント]セクションを探します。スケジューラが失敗した理由に関する手がかりが記載されています。一般的な原因には次のようなものがあります。
- ルールに一致するノードがない
- 利用可能なノードのCPUまたはメモリリソースが不足している
- ノードに設定されたテイントとトレランスの問題により、Podのスケジューリングが妨げられている
ルールの検証:
ノードに、ルールで指定されている必要なラベルが付いていることを確認します。
```
kubectl get nodes --show-labels
```
ノードに付けられたラベルと、値ファイルで指定されているラベルを比較します。
リソース制約の検証:
スケジューリングの失敗の原因の多くは、リソース(CPU、メモリ)の不足です。ポッドのリソース要求と制限を確認します。
```
kubectl describe nodes
```
クラスターにリソース要求を満たすのに十分なノードがない場合は、ノードを追加してクラスターをスケールアップしてください。
指定されたノード上のテイントおよびトレランスの仕様を確認します。
テイントは、ノードが特定のポッドをスケジュールすることを妨げる可能性があります。ノードにテイントが設定されていて、ポッドに対応するトレランスが設定されていない場合、ポッドはスケジュールされません。Kubernetesのテイントとトレランスに関する詳細については、「Taints and Tolerations」(テイントとトレランス)を参照してください。

Dynamic Engineは現在、Helmチャートにおけるテイントとトレランスをサポートしていません。ノードにテイントがある場合は、テイントを削除するか、Dynamic Engineデプロイメント用に別のノードグループを使用する必要があります。

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

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

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