デフォルトのネットワークポリシーを使用したDynamic Engineのデプロイ
インストールまたはアップグレード時に、Dynamic EngineチャートおよびDynamic Engine環境チャートのデフォルトのネットワークポリシーを有効にし、Dynamic Engineチャート、環境チャート、外部サービス間のトラフィックを制御します。
デフォルトの設定を行った後、リンクされている高度なカスタマイズのシナリオに従って、カスタムエグレスルールを設定できます。
始める前に
-
dynamic-engine-crdカスタムリソース定義は、oci://ghcr.io/talend/helm/dynamic-engine-crd Helmチャートを使用してインストールされている必要があります。インストールされていない場合は、次のコマンドを実行してインストールしてください。
- 使用するチャートのバージョンを見つけます。
- 次の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コールを使用します。
- 次のHelmコマンドを実行します:
- 次のコマンドを実行し、目的のバージョンのHelmチャートをインストールします。<helm_chart_version>を、お使いのDynamic Engineバージョンでサポートされているチャートのバージョンに置換します。
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>バージョンを指定しないと、利用可能な最新のdynamic-engine-crdチャートバージョンがインストールされます。
- 使用するチャートのバージョンを見つけます。
- Kubernetesクラスターは、ネットワークポリシーの適用をサポートするネットワークプラグインを使用する必要があります。Kubernetesネットワークポリシーの詳細については、ネットワークポリシーを参照してください。
このタスクについて
この手順は、クラスターのCNIプラグインがKubernetes NetworkPolicyリソースを適用する場合、標準クラスターおよびマネージドKubernetesモードに適用されます。初回インストール時またはアップグレード時に適用できます。
デフォルトのネットワークポリシーセットは、Dynamic Engineデプロイメントにおけるデフォルトのセキュリティベースラインを提供します。カスタムエグレス制御については、エグレスを既知のIPアドレスに制限するおよび内部制限付きの一般的なエグレスの許可を参照してください。
Kubernetesのネットワークポリシーへのサポートは、Dynamic Engine v1.6.0で導入されました。
手順
タスクの結果
Dynamic Engineインスタンスとその環境は、現在、デフォルトのネットワークポリシーで動作しています。Talend Management Consoleにおいて、必要なトラフィックがポリシーで許可されている場合、環境は準備完了状態を維持する必要があります。
Dynamic Engineのデフォルトのネットワークポリシーは、ポッドのネットワークアクセス制御を強化するほとんどのニーズに対して十分です。カスタムエグレスルールが必要な場合は、Dynamic Engineのエグレスを既知のIPアドレスに制限するまたはDynamic Engineにおける内部制限付きの一般的なエグレスの許可を参照してください。
ポッドが実行中であるにもかかわらず、ヘルスチェックに失敗したり、通信できなかったりする場合は、ポリシーの制限が厳しすぎる可能性があります。
- kubectl get networkpolicies -n <namespace> -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>