# デフォルトのネットワークポリシーを使用したDynamic Engineのデプロイ

インストールまたはアップグレード時に、Dynamic EngineチャートおよびDynamic Engine環境チャートのデフォルトのネットワークポリシーを有効にし、Dynamic Engineチャート、環境チャート、外部サービス間のトラフィックを制御します。

デフォルトの設定を行った後、リンクされている高度なカスタマイズのシナリオに従って、カスタムエグレスルールを設定できます。

## 始める前に

* 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変更ログ](https://help.qlik.com/talend/en-US/dynamic-engine-changelog/Cloud)をチェックしてください。
     * [Dynamic Engineバージョンエンドポイント](https://talend.qlik.dev/apis/dynamic-engine/2021-03/#operation_return-all-supported-dynamic-engine-versions)へのAPIコールを使用します。

  2. 次のコマンドを実行し、目的のバージョンのHelmチャートをインストールします。

     ```
     helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
     ```

     &lt;helm\_chart\_version&gt;を、お使いのDynamic Engineバージョンでサポートされているチャートのバージョンに置換します。

     バージョンを指定しないと、利用可能な最新のdynamic-engine-crdチャートバージョンがインストールされます。
* Kubernetesクラスターは、ネットワークポリシーの適用をサポートするネットワークプラグインを使用する必要があります。Kubernetesネットワークポリシーの詳細については、[ネットワークポリシー](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を参照してください。

## このタスクについて

この手順は、クラスターのCNIプラグインがKubernetes NetworkPolicyリソースを適用する場合、標準クラスターおよびマネージドKubernetesモードに適用されます。初回インストール時またはアップグレード時に適用できます。

デフォルトのネットワークポリシーセットは、Dynamic Engineデプロイメントにおけるデフォルトのセキュリティベースラインを提供します。カスタムエグレス制御については、[エグレスを既知のIPアドレスに制限する](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/install-dynamic-engine-with-known-ip-network-policies "デフォルトのインターネットエグレスポリシーを、既知の外部IPアドレスおよびKubernetes APIサーバーへのアクセスのみを許可するカスタムポリシーに置き換えます。")および[内部制限付きの一般的なエグレスの許可](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/install-dynamic-engine-with-general-egress-network-policies "デフォルトのインターネットエグレスポリシーを、内部の制限は維持しつつ、より広範なアウトバウンドトラフィックを許可するカスタムポリシーに置き換えます。")を参照してください。

Kubernetesのネットワークポリシーへのサポートは、[Dynamic Engine v1.6.0](https://help.qlik.com/talend/ja-JP/dynamic-engine-changelog/Cloud/dynamic-engine-v1-6-0-release-changelog)で導入されました。

## 手順

1. デプロイのサンプル変数を設定します。
   ```
   export DYNAMIC_ENGINE_VERSION=1.6.0
   export DYNAMIC_ENGINE_ID=c-m-sjufu4qy
   export DYNAMIC_ENGINE_ENVIRONMENT_ID=684c3baec6a6f88f61e9d59d
   ```

   サンプル値を、ユーザーのエンジンの情報に置き換えます。
2. 組み込みのポリシーセットを使用して、Dynamic Engineおよび環境のチャートをインストールまたはアップグレードします。
   ```
   cat <<EOF > custom-network-policies-values.yaml
   configuration:
     networkPolicies:
       enabled: true
   EOF
   ```
   ```
   helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
     -f $DYNAMIC_ENGINE_ID-values.yaml \
     -f custom-network-policies-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-network-policies-values.yaml \
     oci://ghcr.io/talend/helm/dynamic-engine-environment \
     --version $DYNAMIC_ENGINE_VERSION
   ```

   これにより、Dynamic Engineインスタンスとその環境の両方で、デフォルトのポリシーが有効になります。
3. ポリシーが作成されたことを確認します。
   ```
   kubectl get networkpolicies -A -l "app.qlik.com/owned-by=qlik"
   ```

   出力には、エンジンおよび環境の各ネームスペースにおけるデフォルトの許可および拒否ポリシーが表示される必要があります。
   ```
   NAMESPACE                                      NAME                                     POD-SELECTOR                                           AGE
   qlik-processing-env-684c3baec6a6f88f61e9d59d   default-allow-dns                        <none>                                                 56m
   qlik-processing-env-684c3baec6a6f88f61e9d59d   default-allow-egress-to-internet         <none>                                                 56m
   qlik-processing-env-684c3baec6a6f88f61e9d59d   default-allow-egress-to-same-namespace   <none>                                                 56m
   qlik-processing-env-684c3baec6a6f88f61e9d59d   default-deny-all                         <none>                                                 56m
   qlik-dynamic-engine                            default-allow-dns                        <none>                                                 4s
   qlik-dynamic-engine                            default-allow-egress-to-internet         app.kubernetes.io/name in (engine-operator,reloader)   4s
   qlik-dynamic-engine                            default-allow-ingress-docker-registry    app=docker-registry                                    4s
   qlik-dynamic-engine                            default-deny-all                         <none>                                                 4s
   ```

   この出力に示されているように、ネットワークポリシーは、エンジンおよびその環境のネームスペースを対象としています。各ネームスペースは、独自のネットワークポリシーを持っています。

## タスクの結果

Dynamic Engineインスタンスとその環境は、現在、デフォルトのネットワークポリシーで動作しています。Talend Management Consoleにおいて、必要なトラフィックがポリシーで許可されている場合、環境は準備完了状態を維持する必要があります。

Dynamic Engineのデフォルトのネットワークポリシーは、ポッドのネットワークアクセス制御を強化するほとんどのニーズに対して十分です。カスタムエグレスルールが必要な場合は、[Dynamic Engineのエグレスを既知のIPアドレスに制限する](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/install-dynamic-engine-with-known-ip-network-policies "デフォルトのインターネットエグレスポリシーを、既知の外部IPアドレスおよびKubernetes APIサーバーへのアクセスのみを許可するカスタムポリシーに置き換えます。")または[Dynamic Engineにおける内部制限付きの一般的なエグレスの許可](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/install-dynamic-engine-with-general-egress-network-policies "デフォルトのインターネットエグレスポリシーを、内部の制限は維持しつつ、より広範なアウトバウンドトラフィックを許可するカスタムポリシーに置き換えます。")を参照してください。

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

ポッドが実行中であるにもかかわらず、ヘルスチェックに失敗したり、通信できなかったりする場合は、ポリシーの制限が厳しすぎる可能性があります。

* kubectl get networkpolicies -n &lt;namespace&gt; -o yamlを使用して、各ネームスペースのポリシーを確認してください。
* 接続エラーがないか、ポッドのログを確認します。
* helm upgradeおよび--set configuration.networkPolicies.enabled=falseを使用して接続性を検証するために、宣言的にポリシーを一時的に無効化します。Helmで管理されているNetworkPolicyリソースを直接削除することは避けてください。
* クラスターがネットワークポリシーを適用するCNIプラグインを使用するようにします。

DNS解決の失敗は、通常、kube-dnsサービスへのエグレスがブロックされていることを意味します。

* default-allow-dnsポリシーが有効になっていることを確認します。
* ポリシーがポート53へのエグレスを許可していることを確認します。
* それでもDNSが失敗する場合は、UDPポート53でのkube-systemネームスペースへのエグレスを許可するルールを追加します。

外部サービスへの接続に問題がある場合、通常は必要なエンドポイントまたはポートに対するエグレスルールが不足しています。

* digを使用してIPアドレスを確認します。
* kubectl execおよびcurl -I https://api.us.cloud.talend.comを使用して、ポッド内から接続テストを実行します。
* Kubernetes APIサーバーがポート443または8443で引き続き到達可能であることを確認します。

ポッドがイメージをプルできない場合、レジストリのエグレスルールが欠落しているか、誤ったレジストリを指している可能性があります。

* 組み込みレジストリを使用する場合は、環境ポリシーでdocker-registryサービスへのエグレスが許可されていることを確認します。
* 外部レジストリを使用する場合は、そのIPアドレスとポートに対するエグレスルールを追加します。
* レジストリサービスが実行されており、クラスターからアクセス可能であることを確認します。

ネットワークポリシーを作成したにもかかわらずポッドが依然として自由に通信できる場合、ネットワークプラグインがポリシーを適用していない可能性があります。

* クラスターが Calico、Cilium、Weave、またはネットワークポリシーをサポートするその他のCNIを使用しているかどうかを確認します。
* ポリシーが正しいネームスペースに作成されていることを確認します。
* kube-systemネームスペース内のネットワークコントローラーポッドを調査します。

有用なデバッグコマンドの例

```
# View all network policies
kubectl get networkpolicies -A

# Describe a specific policy
kubectl describe networkpolicy <policy-name> -n <namespace>

# Check pod connectivity
kubectl exec <pod-name> -n <namespace> -- ping <target-pod-ip>

# Test DNS from a pod
kubectl exec <pod-name> -n <namespace> -- nslookup <service-name>

# Check pod labels (used by policies)
kubectl get pods -n <namespace> --show-labels

# Test external connectivity
kubectl exec <pod-name> -n <namespace> -- curl -I https://<external-url>
```