従来のKubectlデプロイメント

最終更新日時: 2026/08/07

重要: 今後の変更点:

次期リリースであるv1.7.0において、Dynamic EngineはこのKubectlデプロイメントのサポートを終了します。v1.7.0以降、Helmのみが提供およびサポートされます。デフォルトのHelmデプロイメントをご覧ください

これは、Dynamic Engineサービスをデプロイするクラシックな方法です。Helmとは異なり、Kubectlではカスタムデプロイメントは設定できません。

既にデプロイされているDynamic Engineサービスでは、KubernetesマニフェストからHelmチャートへのアップグレードはサポートされていません。

始める前に

エンジンにDynamic Engine環境を少なくとも1つ割り当てており、Kubectlデプロイメントタイプを選択し、zipファイルをダウンロード済みであること。この手順については、Dynamic Engineに環境を割り当てをご覧ください。

このタスクについて

デプロイメントファイルを適用する前に選択済みのデプロイメントタイプを変更する必要がある場合は、Dynamic Engineの[管理]を開き、[デプロイメントを編集]を使用してHelmとKubectlを切り替えます。

この変更は、ファイルが適用される前、またはデプロイに失敗した後でのみサポートされます。デプロイ済みのサービスを、KubernetesマニフェストからHelmチャートへアップグレードすることはサポートされていません。

手順

先ほどダウンロードしたファイルを解凍します。
このファイルが手元にない場合は、Dynamic Engineの詳細パネルにある[Manage] (管理)ボタンを使用して再度ダウンロードし、[Edit deployment] (デプロイメントを編集)ダイアログにアクセスします。この詳細パネルへのアクセス方法については、Dynamic Engineを編集を参照してください。
情報メモヒント: ファイルを一度正常に適用していれば、[Processing] (処理中)ページにあるDynamic EngineタブのDynamic Engine名の横にあるボタンを使ってファイルをダウンロードすることもできます。
デフォルトでは、推奨されるHelmデプロイメントファイルのみをこの方法でダウンロードできます。Kubectlデプロイメントを一度正常に適用すると、このボタンから提供されるアクセス先がKubectlのダウンロードに切り替わります。

デフォルトの動作が変更された後、このボタンをクリックすると、最後に正常に適用されたデプロイメントファイルタイプにアクセスできるようになります。
Kubernetesターミナルで以下のコマンドを順番に実行し、Dynamic Engineインスタンスをセットアップします:
1. ```
kubectl apply -f custom-resource-definitions.yaml
```
  このマニフェストファイルによって、クラスターにカスタムのKubernetesリソース定義が2つ(Dynamic Engineリソース用にdynamicengines.apps.qlik.com、Dynamic Engine環境リソース用にdynamicengineenvs.apps.qlik.com)が作成されます。
2. ```
kubectl apply -f resources.yaml
```
  このマニフェストファイルは、クラスターを登録するDynamic Engineリソースを作成し、Dynamic Engineをデプロイして、Talend Management Consoleでエンジンを論理エンティティに割り当てます。これらのリソースは、DynamicEngineの種類に属しています。
3. 2回目の実行が終了したら、次のコマンドを実行してデプロイを確認します:
```
kubectl wait --for=condition=Ready pod -l 'app.qlik.com/owned-by' --timeout 10m -A 
```
  このコマンドは、すべてのネームスペースにわたって、app.qlik.com/owned-byというラベルを持つすべてのポッドの準備状況を確認します。
  
  デプロイメントが成功すると、次のようなレスポンスが表示されます:
```
pod/dynamic-engine-operator-799bb96687-rfm2g condition met
pod/dpe-data-service-route-deployer-74b7f566c-lrl99 condition met
pod/dpe-di-job-deployer-5cff46b6-x5t85 condition met
pod/dpe-di-job-restore-orphans-5f57f5f86f-d9vpb condition met
pod/dpe-engine-config-manager-956d5d7b9-7krcn condition met
pod/dpe-job-controller-66fd596588-7x5w5 condition met
pod/dpe-log-collector-7dd9499c8-dnvrn condition met      
```
  この出力は、Dynamic Engineで必要となるすべてのポッドとその環境が準備できていることを確証するものです。
正しく完了すると、Talend Management ConsoleにあるDynamic Engine論理エンティティのステータスが[Active] (アクティブ)になります。

Kubernetesクラスターに何がインストールされているかを知る必要がある場合は、Kubernetesマシンにアクセスし、このKubernetes公式ドキュメンテーションで説明されているコマンドを実行します。
以下のコマンドを実行して環境をセットアップします。この例では、1つの環境だけが作成され割り当てられています。
```
kubectl apply -f resources-<environment_id>.yaml
```
情報メモヒント:
エンジンが複数の環境に関連付けられている場合は、正しいファイルを区別するためにこのIDが必要です。
環境IDを見つける方法として、次の2つがあります:
- Talend Management Consoleで、削除する環境の詳細ページを開きます。このIDはURLに表示されます。たとえば、このURL
  https://app.eu.cloud.talend.com/tmc/environments/dynamic-engine-environments/66f2c0bb3e063d3518122259/overview
  66f2c0bb3e063d3518122259セグメントは環境IDです。
- 次のコマンドを使用:
  kubectl get dynamicengineenvs.qlik.com
  これは、中にIDが含まれているリソース名またはネームスペース名を返します。たとえば、qlik-processing-env-66f2c0bb3e063d3518122259となります。
実行が終了したら、次のコマンドを実行してデプロイを確認します:
```
kubectl wait --for=condition=RUNNING=true --all dynamicengineenvs --timeout 300s
```
300秒間、このコマンドはDynamicEngineEnvという種類のリソースをすべて検索します。次のようなレスポンスが表示されれば、エンジン環境が正常にデプロイされたことになります:
```
dynamicengineenvs.qlik.com/qlik-processing-env-66f2c0bb3e063d3518122259 condition met
```
このレスポンスでは、監視対象のリソース名はqlik-processing-env-664b0bbd6c6f5522732e055dとなります。この名前はネームスペース名としても使われ、Dynamic Engine環境リソースに関連するすべてのサービスをグループ化します。
オプション: この確認画面が表示されなかった場合は、デプロイメントに問題があります。次のコマンドを実行し、環境リソースの"serviceStatus"オブジェクトを検査する必要があります:
```
kubectl get dynamicengineenvs qlik-processing-env-664b0bbd6c6f5522732e055d -o json | jq -r '.status'
```
このコマンドでは、dynamicengineenvsがDynamic Engine環境専用であるカスタムリソースのkind (種類)を、そして前の例で示したように、qlik-processing-env-664b0bbd6c6f5522732e055dがリソースおよび環境のネームスペース名を表しています。
- 以下のメッセージは、"serviceStatus"オブジェクトにある"di-job-deployer"サービスのエラー例です。"jobErrorMessage"フィールドはデプロイ中に観察されたエラーの詳細を示し、期待されたhelmチャートが見つからなかったことを表しています。
  以下の例では、行がいくつかスキップされています。
```
{
  "conditions": [
    {
      "lastTransitionTime": "2024-05-30T13:05:25Z",
      "message": "Service is not deployed",
      "reason": "Deployment_not_found",
      "status": "True",
      "type": "NOT_DEPLOYED"
    }
  ],
  "serviceStatus": {
    ...
    "di-job-deployer": {
      "conditions": [
        ...
        {
          "lastTransitionTime": "2024-05-30T13:06:39Z",
          "message": "Service is in error",
          "reason": "Pod_failed",
          "status": "False",
          "type": "IN_ERROR"
        }
      ],
      "creationDate": "2024-05-30T13:05:25Z",
      "jobErrorMessage": "Error: release: not found\nUpgrading...\nupgrade result: Release \"di-job-deployer-92d6e127-e070-4264-a9e8-00adbbbfbc03\" does not exist. Installing it now.\nError: failed to download ...\nError: failed to download \"https://artifactory.datapwn.com/artifactory/tlnd-helm-ce-dev/dpe-di-job-deployer-2.0.0.tgz\"\nexit_code: 1\n",
      "jobStatus": "FAILED",
      "lastUpdateDate": "2024-05-30T13:01:52Z"
    },
    ...
  }
}
```
  このような場合はサポートチームに連絡し、Dynamic Engine環境のマニフェストファイルを調査してください。情報が提供されたら、環境の割り当てを解除し、再度割り当てて新しいマニフェストファイルを生成します。

タスクの結果

正しく完了すると、Dynamic Engine環境サービスがクラスターにインストールされ、Dynamic Engineに接続します。

Talend Management Consoleではこの環境のステータスが[Ready] (準備完了)になり、タスクまたはプランを実行する準備ができていることが確定されます。

マニフェストの実装に失敗した場合、またはDynamic EngineサービスがDynamic Engineから切り離された場合、ステータスは[Not ready] (まだ準備できていません)になります。

次のタスク

Dynamic EngineがKubernetesに正常にデプロイされ、Talend Management Consoleに接続され、Dynamic Engine環境に関連付けられたので、標準エンジンで通常行うようにジョブタスクまたはプランを実行する準備ができています。実行のためにタスクをDynamic Engine環境に追加する方法は、タスクをDynamic Engine環境に追加をご覧ください。

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

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

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