| VMware NSX Container Plugin 4.1.1 | 2023 年 8 月 17 日 | ビルド 22071564 各リリース ノートで、追加および更新された機能をご確認ください。 |
新機能
-
このリリースから、新しい TAS 展開は NSX ポリシーでのみ許可されます。既存の基盤の場合、アップグレード時に NCP の設定は変更されません。
-
展開ネットワーク用に TKGi によって作成された NSX リソースが、管理プレーンからポリシーへの移行中にポリシーに移行されるようになりました。
-
NCP は、1 台の NSX ロード バランサ仮想サーバで最大 500 個の OCP ルートをサポートします。
-
NSX をバックアップして、後で以前の状態にリストアできます。NCP は、OpenShift クラスタと NSX 内のリソースの整合性を維持します。
-
OpenShift Operator により特定のオプション構成が自動化され、NCP の展開が容易になりました。configmap からの入力であるオプションの検証も強化されています。
廃止のお知らせ
ncp/ingress_controller アノテーションを使用して入力方向コントローラ ポッドへの NAT 経由のアクセスを許可する機能は廃止され、2023 年に削除される予定です。入力方向コントローラ ポッドを公開する場合は、LoadBalancer タイプのサービスを使用することをお勧めします。
nsx-ovs カーネル モジュールは廃止されました。アップストリーム OVS カーネル モジュールのみがサポートされます。これがデフォルトの動作です。nsx-node-agent configmap の nsx_node_agent セクションにある configmap オプション use_nsx_ovs_kernel_module が削除されました。
互換性の要件
| 製品 |
バージョン |
| Tanzu Application Service (TAS) の NCP/NSX タイル |
4.1.1 |
| NSX |
3.2.2、3.2.3、4.0.1.1、4.1.0、4.1.1 |
| Kubernetes |
1.24、1.25、1.26 |
| OpenShift 4 |
4.10、4.11、4.12 |
| Kubernetes ホスト仮想マシン OS |
Ubuntu 20.04 カーネル 5.15 を使用する Ubuntu 22.04（nsx-ovs カーネル モジュールとアップストリーム OVS カーネル モジュールの両方をサポート） 5.15 以降のカーネルを使用する Ubuntu 22.04（アップストリーム OVS カーネル モジュールのみをサポート） RHEL：8.4、8.5、8.6 以下の注を参照。 |
| Tanzu Application Service (TAS) |
Ops Manager 2.10 と TAS 2.13 Ops Manager 3.0 と TAS 2.13 Ops Manager 2.10 と TAS 3.0 Ops Manager 3.0 と TAS 3.0 Ops Manager 2.10 と TAS 4.0 Ops Manager 3.0 と TAS 4.0 |
| Tanzu Kubernetes Grid Integrated (TKGI) |
1.17 |
注：
サポートされている統合では、Red Hat Universal Base Image (UBI) を使用してください。詳細については、https://www.redhat.com/ja/blog/introducing-red-hat-universal-base-image を参照してください。
TAS の新しい展開では、ポリシー モードのみがサポートされます。
このリリースへのアップグレードのサポート：
-
4.1.0、4.1.1、およびすべての 4.0.x リリース。
制限事項
-
NCP のベースライン ポリシー機能は、クラスタ内のすべてのメンバーを選択する動的グループを作成します。NSX-T には、動的グループの有効メンバー数が 8,000 までという制限があります（詳細については、構成の上限を参照してください）。そのため、ポット数が 8,000 を超えることが予想されるクラスタでは、この機能を有効にしないでください。この制限を超えると、ポッドのリソースの作成が遅延する可能性があります。
-
透過モードのロード バランサ
-
Kubernetes クラスタの North-South トラフィックのみがサポートされます。クラスタ内トラフィックはサポートされません。
-
LoadBalancer CRD に接続されているサービスの場合、または自動スケーリングが有効になっている場合はサポートされません。この機能を使用するには、自動スケーリングを無効にする必要があります。
-
この機能は、新しく展開されたクラスタでのみ使用することをお勧めします。
-
-
マネージャからポリシーへの移行
-
以前の移行が失敗し、クラスタがロールバックされた場合、Kubernetes クラスタを移行することはできません。これは、NSX 4.0.0.1 以前のリリースにのみ適用される制限です。
-
-
入力方向/出力方向ルールでマルチセレクタ基準を使用するネットワーク ポリシーを実装する場合、実際のグループ メンバーの計算でパフォーマンスが大幅に低下し、ネットワーク トラフィックに影響するリスクがあります。この制限に対応するため、新しい構成オプション enable_mixed_expression_groups が追加されました。これは、ポリシー モードでマルチセレクタを使用する Kubernetes ネットワーク ポリシーに影響します。マネージャ モードのクラスタは影響を受けません。このオプションのデフォルト値は False です。クラスタで次の値を使用することを推奨します。
-
TKGi
-
新しいクラスタ、ポリシー モード：False
-
既存のクラスタ（ポリシーベース）：True
-
マネージャからポリシーへの移行後：True
-
-
OC：Kubernetes ネットワーク ポリシーの適合性を維持するため、True に設定します
-
DIY Kubernetes
-
新規クラスタ（ポリシーベース）: False
-
既存のクラスタ（ポリシーベース）：True
-
マネージャからポリシーへの移行後：True
-
この制限は、enable_mixed_expression_groups が True に設定されている場合に適用されます。これは、NCP バージョン 3.2.0 以降および NSX-T バージョン 3.2.0 以降を使用するインストールに影響します。ネットワーク ポリシーの影響を受けるネームスペースの数に制限はありません。このオプションを True に設定し、NCP を再起動すると、NCP はすべてのネットワーク ポリシーを再度同期して、この動作を実装します。
enable_mixed_expression_groups が False に設定されている場合、入力方向/出力方向ルールでマルチセレクタ基準を使用するネットワーク ポリシーは、実際のメンバーの計算におけるパフォーマンス低下の影響を受けない動的 NSX グループで実現されます。ただし、ネットワーク ポリシーで定義されている他の基準に応じて、ルールは最大 5 つのネームスペースにのみ適用できます。ネットワーク ポリシーが任意の時点で 5 つ以上のネームスペースに影響する場合は、「ncp/error: NETWORK_POLICY_VALIDATION_FAILED」という注釈が付き、NSX では適用されません。これは、マルチセレクタ条件を満たす新しいネームスペースが作成された場合、または既存のネームスペースが更新された場合に発生する可能性があります。このオプションを False に設定し、NCP を再起動すると、NCP はすべてのネットワーク ポリシーを再度同期して、この動作を実装します。
-
解決した問題
-
問題 3049209：マネージャからポリシーへの移行後、クラスタを削除しても mp_default_LR_xxx_user_rules リソースが削除されない
マネージャからポリシーへの移行を実行してからクラスタを削除した後、mp_default_LR_xxx_user_rules という名前の一部の GatewayPolicy リソースが削除されないことがあります。
回避策：リソースを手動で削除します。
-
問題 3113985：単一の Tier-1 トポロジを移行するときに、すべてのスタティック ルートが移行されない
loadbalancers.vmware.com タイプの複数のカスタム リソースを含む単一の Tier-1 トポロジで、マネージャ モードの NCP でロード バランサ用に作成されたスタティック ルートの一部が移行されません。
回避策：Kubernetes から loadbalancers.vmware.com タイプのカスタム リソースを削除した後、Manager API を使用してスタティック ルートを手動で削除します。スタティック ルートのタグに、範囲 ncp/crd_lb_uid のカスタム リソースの UID が含まれます。
-
問題 3055618：ノードで複数の Windows ポッドを同時に作成すると、一部のポッドにネットワーク アダプタがない
yaml ファイルを適用して同じノードに複数の Windows ポッドを作成すると、一部のポッドにネットワーク アダプタがありません。
回避策：ポッドを再起動します。
-
問題 3088138：nsx-node-agent-config configmap で log_file を設定した後、nsx-node-agent ポッドが起動に失敗する
nsx-node-agent-config configmap で log_file オプションを設定し、nsx-node-agent ポッドの前に nsx-ncp-bootstrap ポッドを再起動すると、nsx-node-agent ポッドの起動に失敗し、CrashLoopBackOff 状態になります。
回避策：nsx-node-agent-config configmap で log_file オプションを設定した後、nsx-ncp-bootstrap ポッドを再起動する前に、nsx-node-agent ポッドを再起動します。
-
問題 3091318：NCP が停止しているときに、ネームスペースの静的サブネットを更新した後、ポッドの作成に失敗する
ncp/subnets が設定されたネームスペース（たとえば 172.70.0.0/29 に設定）を作成する際に、ネームスペースにポッドが作成されていない場合、NCP を停止して再起動した後に ncp/subnets を更新すると（たとえば 172.71.0.0/29 に更新）、ネームスペースでのポッドの作成に失敗し、ポッドが「ContainerCreating」状態で停止することがあります。
回避策：ポッドを再作成します。
-
問題 3110833：TKGI Windows ワーカー ノードでポッドを起動できず、状態が「ContainerCreating」になる
Windows ワーカー ノードのすべてのノードが起動に失敗します。ノードの nsx-node-agent ログに次の項目が継続的に記録されます。「Failed to process cif config request with error [...].Restart node agent service to recover.」
回避策：ノードで nsx-node-agent サービスを再起動します。
既知の問題
-
問題 3306543：ポッドの削除後、同じ名前で作成した新しいポッドのネットワーク構成が正しくない
まれに、ポッドを削除して同じ名前で新しいポッドを作成すると、新しいポッドに古いボットのネットワーク構成が使用されます。新しいポッドのネットワーク構成が正しくありません。
回避策：新しいポッドを削除し、nsx-node-agent を再起動してから、ポッドを再作成します。
-
問題 3239352：TAS 環境でタスクを割り当てることができない場合、再試行が機能しないことがある
NCP TAS 環境で、タスクを割り当てることができない場合、Auctioneer がタスクを拒否し、BBS が task.max_retries 設定で指定された回数までタスクの配置を再試行します。task.max_retries に達すると、BBS はタスクを PENDING 状態から COMPLETED 状態に更新し、Failed とマークします。また、クラスタにタスクに対する容量がないことを説明する FailureReason を示します。
再試行中に、task_changed イベントを NCP に通知する新しいセルにタスクがスケジュール設定されることがあります。NCP は task_changed イベントを処理しないため、新しいセルでタスクに新しいポートを割り当てることはできません。タスクを正しく実行できません。
回避策：再試行を無効にして、task.max_retries 値を 0 に設定します。
-
問題 3252571：NSX Manager が使用不能になると、マネージャからポリシーへの移行が完了しない
マネージャからポリシーへの移行中に NSX Manager が使用不能になると、移行が完了しない可能性があります。たとえば、ログに移行に関する更新がない場合は、この状況を表しています。
回避策：NSX Manager への接続を再確立し、移行を再開します。
-
問題 3248662：ワーカー ノードがサービスにアクセスできない。ノードにサービスの OVS フローが作成されていない
nsx-kube-proxy ログに「greenlet.error: cannot switch to a different thread」というエラー メッセージが記録されます。
回避策：ノードで nsx-kube-proxy を再起動します
-
問題 3241693：作成されたルートの数が一部の制限を超えると、レイヤー 7 ルートの動作が開始するまでに 10 分以上かかる
OpenShift 環境では、ConfigMap で relax_scale_validation フラグを True に設定し、l4_lb_auto_scaling を False に設定することで、1,000 を超えるルートを展開できます。ただし、作成されたルートの数が一部の制限を超えると、動作が開始するまでに 10 分以上かかります。制限は、500 個の HTTPs ルートと 2,000 個の HTTP ルートです。
回避策：ルート数が制限を超えないようにします。500 個の HTTPS ルート 2,000 個の HTTP ルートを作成する場合は、大規模な Edge 仮想マシンを使用してルートを展開する必要があります。
-
問題 3158230：Ubuntu 20.04 で AppArmor プロファイルをロード中に、nsx-ncp-bootstrap コンテナの初期化に失敗する
ホスト OS とコンテナ イメージで AppArmor のパッケージ バージョンが異なるため、nsx-ncp-bootstrap DaemonSet の nsx-ncp-bootstrap コンテナの初期化に失敗します。コンテナのログに、「/etc/apparmor.d/abi/2.13 から policy-features をロードできませんでした：該当するファイルまたはディレクトリがありません」などのメッセージが表示されます。
回避策：AppArmor をバージョン 2.13.3-7ubuntu5.2 またはホスト OS の focal-updates から入手可能な最新バージョンにアップデートします。
-
問題 3179549：既存のネームスペースの NAT モードの変更がサポートされていない
既存のポッドを含むネームスペースの場合、NAT モードを SNAT から NO_SNAT に変更しても、ポッドは引き続き container_ip_blocks で指定された IP アドレス ブロックから割り当てられた IP アドレスを使用します。ネームスペース内のセグメント サブネットに使用可能な IP アドレスが残っている場合、新しく作成されたポッドは既存のセグメント サブネットの IP アドレスを引き続き使用します。新しく作成されたセグメントの場合、サブネットは no_snat_ip_block から割り当てられます。ただし、ネームスペースでは SNAT ルールが削除されます。
回避策：なし。
-
問題 3218243：NCP をバージョン 4.1.1 にアップグレードした後、またはユーザーがネームスペースを作成または更新すると、NSX でマルチセレクタ基準を使用する Kubernetes ネットワーク ポリシー用に作成されたセキュリティ ポリシーが削除される
NCP で enable_mixed_expression_groups オプションが False に設定されていることを確認します（デフォルト値は False）。その場合、ネットワーク ポリシーによって、サポートされていない 6 個以上のグループ基準が NSX に作成されます。
回避策：NCP 構成マップで enable_mixed_expression_groups を True に設定し、NCP を再起動します。この場合、ネットワーク トラフィックに影響を与える実際のグループ メンバーの計算で、パフォーマンスが大幅に低下するリスクがあります。
-
問題 3235394：TKGI セットアップで、ネームスペースの設定を含むベースライン ポリシーが機能しない
TGKI 環境で baseline_policy_type を allow_namespace または allow_namespace_strict に設定すると、NCP は明示的なベースライン ポリシーを作成して、同じネームスペース内のポッド同士の通信を許可し、他のネームスペースからの入力を拒否します。このベースライン ポリシーは、kube-system などのシステム ネームスペースから異なるネームスペース内のポッドへのアクセスをブロックします。
回避策：なし。NCP は、TKGI セットアップでこの機能をサポートしていません。
-
問題 3179960：vMotion の後に、アプリケーション インスタンスが到達不能になり、別のアプリケーション インスタンスと同じ IP アドレスが設定される
たとえば、NSX ホストのアップグレードなどで一括 vMotion が発生すると、ホストは 1 台ずつメンテナンス モードになり、ホスト間で Diego Cell が移行します。vMotion の後、一部のセグメント ポートが欠落し、一部のアプリケーション インスタンスが到達不能になり、2 つのアプリケーション インスタンスが同じ IP アドレスを持つ可能性があります。この問題は、TAS 2.13.18 で発生する可能性が高くなります。
回避策：この問題の影響を受けるアプリケーション インスタンスを再作成します。
-
問題 3108579：LB CRD を削除して同じシークレットですぐに再作成すると失敗する
マネージャ モードで、LB CRD の Ingress を削除して LB CRD を削除し、同じ証明書を使用して Ingress と LB CRD をすぐに再作成すると、「Attempted to import a certificate which has already been imported」というエラーが表示されることがあります。この問題はタイミングが原因で発生します。LB CRD は、Ingress の削除が完了してから削除する必要があります。
回避策：次のいずれかを実行します。
- 次のコマンドを実行して、Ingress の削除が完了してから LB CRD を削除します。
- kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep ‘name: <Ingress name>’
- 2 分以上経過してから Ingress と LB CRD を再作成します。
-
問題 3161931：Ubuntu 18.04 および Ubuntu 20.04 ホスト仮想マシンで nsx-ncp-bootstrap ポッドの実行に失敗する
nsx-ncp-bootstrap ポッドの nsx-ncp-bootstrap コンテナで、「AppArmor」の再ロードに失敗し、次のログ メッセージが表示されます。「/etc/apparmor.d/abi/2.13」から policy-features をロードできませんでした：該当するファイルまたはディレクトリがありません。」この問題は、nsx-ncp-bootstrap ポッドとホスト OS の実行に使用されるイメージにインストールされている「AppArmor」パッケージのバージョンが異なるために発生します。この問題は、Ubuntu 22.04 ホスト仮想マシンには存在しません。
回避策：Ubuntu 18.04 は、NCP 4.1.1 でサポートされていません。Ubuntu 20.04 で、「AppArmor」を最小バージョン 2.13.3-7ubuntu5.2 に更新します。パッケージは、focal-updates を介して使用可能です。
-
問題 3221191：クラスタに 4,000 を超えるポッドがある場合、ドメイン グループの作成に失敗する
NCP オプション k8s.baseline_policy_type が allow_cluster、allow_namespace、または allow_namespace_strict に設定されていて、クラスタに 4,000 を超えるポッドがある場合、ポッドのすべての IP アドレスを含むドメイン グループ（dg-k8sclustername などの名前）は作成できません。これは、NSX の制限が原因で発生します。
回避策：k8s.baseline_policy_type オプションを設定しないでください。また、クラスタ内のポッド数が 4,000 未満になるようにしてください。
-
問題 3043496：マネージャからポリシーへの移行が失敗すると NCP が実行を停止する
NCP には、NCP と TKGI で使用される NSX リソースを移行するための migrate-mp2p ジョブがあります。移行が失敗すると、移行されたすべてのリソースがロールバックされますが、NCP がマネージャ モードで再起動されません。
回避策：
-
すべてのリソースがロールバックされたことを確認します。これは、migrate-mp2p ジョブのログで確認できます。ログの最後に、「ポリシーにインポートされた管理プレーンリソースはすべて完全にロールバックされました」という行があるはずです。
-
すべてのリソースがロールバックされている場合は、各マスター ノードに SSH で接続し、sudo /var/vcap/bosh/bin/monit start ncp コマンドを実行します。
-
-
問題 2131494：Ingress のクラスを nginx から nsx に変更しても NGINX Kubernetes Ingress が動作を続ける
NGINX Kubernetes Ingress の作成時、NGINX はトラフィック転送ルールを作成します。Ingress のクラスを他の値に変更すると、クラスの変更後に Kubernetes Ingress を削除しても、NGINX はルールを削除せずにルールの適用を継続します。これは NGINX の制限の 1 つです。
回避策：NGINX が作成したルールを削除するには、クラスの値が nginx である Kubernetes Ingress を削除します。その後、再度 Kubernetes Ingress を作成します。
-
問題 2999131：ポッドから ClusterIP サービスにアクセスできない
大規模な TKGi 環境で、ポッドから ClusterIP サービスにアクセスできません。関連する他の問題は次のとおりです。(1) nsx-kube-proxy が nsx-kube-proxy のログの出力を停止する。(2) ノードで OVS フローが作成されない。
回避策：nsx-kube-proxy を再起動します。
-
問題 2984240：ネットワーク ポリシーのルールの namespaceSelector で matchExpressions の NotIn 演算子が機能しない
ネットワーク ポリシーのルールを指定するときに、namespaceSelector、matchExpressions、NotIn 演算子を指定すると、ルールが機能しません。NCP ログに「NotIn operator is not supported in NS selectors.」というエラー メッセージが記録されます。
回避策：NotIn 演算子を使用しないように matchExpressions を書き換えます。
-
問題 3033821：マネージャからポリシーへの移行後、分散ファイアウォール ルールが正しく適用されない
マネージャからポリシーへの移行後、新しく作成されたネットワーク ポリシー関連の分散ファイアウォール (DFW) ルールが、移行された DFW ルールよりも優先されます。
回避策：ポリシー API を使用して、必要に応じて DFW ルールの順序を変更します。
-
タイプが ClusterIP の Kubernetes サービスの場合、ヘアピンモード フラグがサポートされない
NSX Container Plugin (NCP) ではタイプが ClusterIP の Kubernetes サービスの場合、ヘアピンモード フラグがサポートされません。
回避策：なし
-
問題 2224218：サービスまたはアプリケーションの削除後、SNAT IP アドレスが IP アドレス プールに戻るのに 2 分かかる
サービスまたはアプリケーションを削除し、2 分以内に再作成すると、新しい SNAT IP アドレスが IP アドレス プールから取得されます。
回避策：同一の IP アドレスをもう一度使用する場合は、サービスまたはアプリケーションの削除後、2 分間待ってから再作成します。
-
問題 2404302：同じリソース タイプ（たとえば、HTTP）の複数のロード バランサ アプリケーション プロファイルが NSX-T に存在する場合、NCP は仮想サーバに接続するいずれかのロード バランサ アプリケーション プロファイルを選択する
NSX-T に複数の HTTP ロード バランサ アプリケーション プロファイルが存在する場合、NCP は適切な x_forwarded_for 構成の HTTP ロード バランサ アプリケーション プロファイルのいずれかを選択して、HTTP および HTTPS 仮想サーバに接続します。NSX-T に複数の FastTCP プロファイルと UDP アプリケーション プロファイルが存在する場合、NCP はプロファイルのいずれかを選択して、TCP 仮想サーバまたは UDP 仮想サーバに接続します。ロード バランサ アプリケーション プロファイルは、異なるアプリケーションによって作成され、異なる値が設定されている可能性があります。NCP によって作成した仮想サーバに、これらのロード バランサ アプリケーション プロファイルのいずれかを接続するよう NCP が選択した場合、他のアプリケーションのワークフローが壊れることがあります。
回避策：なし
-
問題 2518111：NCP が、NSX-T から更新された NSX-T リソースを削除できない
NCP は、指定した構成に基づいて NSX-T リソースを作成します。これらの NSX-T リソースを NSX Manager または NSX-T API で更新すると、NCP がこれらのリソースを削除できず、必要に応じて再作成することがあります。
回避策：NCP によって作成された NSX-T リソースを NSX Manager または NSX-T API で更新しないでください。
-
問題 2416376：NCP で、128 を超える空間に割り当てる TAS ASG（アプリケーション セキュリティ グループ）の処理に失敗する
NSX-T 分散ファイアウォールの制限のため、NCP は 128 を超える空間に割り当てる TAS ASG を処理できません。
回避策：複数の ASG を作成し、各 ASG を割り当てる空間を 128 以下にします。
-
Kubernetes のインストール中にファイルへのログ出力が有効になっていると、NCP の起動に失敗する
この問題は、コンテナ ホストの uid:gid=1000:1000 にログ フォルダに対する権限がないと発生します。
回避策：次のいずれかを実行します。
-
コンテナ ホストでログ フォルダのモードを 777 に変更します。
-
ログ フォルダに対する rwx 権限をコンテナ ホストの uid:gid=1000:1000 に付与します。
-
ファイルへのログ出力機能を無効にします。
-
-
問題 2653214：ノードの IP アドレスが変更された後に、ノードのセグメント ポートを検索するとエラーが発生する
ノードの IP アドレスが変更された後に、NCP をアップグレードしたり、NCP Operator ポッドが再起動された場合、oc describe co nsx-ncp コマンドで NCP Operator の状態を確認すると、「ノードのセグメント ポートの検索中にエラーが発生しました...」というエラー メッセージが表示されます。
回避策：なし。DHCP 構成のあるノード インターフェイスに静的 IP アドレスを追加することはできません。
-
問題 2672677：OpenShift 4 環境の負荷が非常に高くなると、ノードが応答不能になる
ノードあたりのポッドの集約度が高く、ポッドの削除および作成が頻繁に行われている OpenShift 4 環境で、RHCOS ノードが「準備未完了」の状態になることがあります。DaemonSet メンバーを除いて、影響を受けるノードで実行されているポッドは退去され、環境の他のノードで再作成されます。
回避策：影響を受けるノードを再起動します。
-
問題 2707174：ポッドを削除して同じネームスペースに再作成すると、ネットワークに接続できない
NCP が実行されず、nsx-ncp-agents が実行されているときに、ポッドを削除して同じネームスペースに再作成すると、ポッドが誤ったネットワーク構成を取得し、ネットワークにアクセスできない場合があります。
回避策：ポッドを削除し、NCP の実行中にポッドを再作成します。
-
問題 2745907：monit コマンドを実行すると、nsx-node-agent について誤った状態情報が返される
diego_cell 仮想マシンで monit を実行して nsx-node-agent を再起動したときに、nsx-node-agent が完全に起動するまでに 30 秒以上かかると、nsx-node-agent の状態が「Execution failed」と表示されます。nsx-node-agent が完全に機能するようになった場合でも状態が「running」に更新されません。
回避策：なし。
-
問題 2735244：稼動状態検証のエラーが原因で nsx-node-agent と nsx-kube-proxy がクラッシュする
nsx-node-agent と nsx-kube-proxy は、sudo を使用して、いくつかのコマンドを実行します。/etc/resolv.conf に DNS サーバと検索ドメインに関するエントリが多数存在する場合、sudo はホスト名の解決に時間がかかる場合があります。これにより、nsx-node-agent と nsx-kube-proxy が sudo コマンドによって長時間ブロックされ、稼動状態検証が失敗します。
回避策：次のいずれかのアクションを実行します。
-
/etc/hosts にホスト名エントリを追加します。たとえば、ホスト名が host1 の場合は、「127.0.0.1 host1」というエントリを追加します。
-
nsx-node-agent の稼動状態検証のタイムアウト値を大きくします。kubectl edit ds nsx-node-agent -n nsx-system コマンドを実行して、nsx-node-agent と nsx-kube-proxy コンテナの両方のタイムアウト値を更新します。
-
-
問題 2736412：max_allowed_virtual_servers が設定されていると、members_per_small_lbs パラメータが無視される
max_allowed_virtual_servers と members_per_small_lbs の両方が設定されている場合、max_allowed_virtual_servers のみが考慮されるため、仮想サーバが使用可能なロード バランサに接続できないことがあります。
回避策：自動スケーリングを有効にするのではなく、スケールの制約を緩和します。
-
問題 2740552：api-server を使用して静的ポッドを削除するときに、nsx-node-agent はポッドの OVS ブリッジ ポートを削除せず、Kubernetes によって自動的に再作成される静的ポッドのネットワークが使用できなくなる
Kubernetes では、api-server による静的ポッドの削除は許可されません。Kubernetes によって、静的ポッドのミラー ポッドが作成され、api-server で静的ポッドを検索できます。api-server でポッドを削除するときに、ミラー ポッドだけが削除され、NCP はポッドに割り当てられているすべての NSX リソースを削除する削除要求を受信して処理します。ただし、静的ポッドはまだ存在し、nsx-node-agent は、静的ポッドの OVS ブリッジ ポートを削除する削除要求を CNI から取得しません。
回避策：api-server によって静的ポッドを削除するのではなく、マニフェスト ファイルを削除して静的ポッドを削除します。
-
問題 2824129：再起動後 3 分以上、ノードの状態 network-unavailable が true になる
NCP operator を使用して NCP のライフサイクルを管理している場合、nsx-node-agent デーモンセットが非実行状態からリカバリすると、3 分間実行されるまでノードの状態 network-unavailable が true になります。これは、想定どおりの動作です。
回避策：nsx-node-agent の再起動後、少なくとも 3 分間待機します。
-
問題 2832480：ClusterIP タイプの Kubernetes サービスの場合、sessionAffinityConfig.clientIP.timeoutSeconds に 65535 より大きい値を設定できない
ClusterIP タイプの Kubernetes サービスの場合、sessionAffinityConfig.clientIP.timeoutSeconds を 65535 より大きい値に設定しても、実際の値は 65535 になります。
回避策：なし
-
問題：2940772：NSX-T 3.2.0 で NCP リソースをマネージャからポリシーに移行すると失敗する
NSX-T 3.1.3 および NSX-T 3.2.1 では、NCP リソースをマネージャからポリシーに移行できますが、NSX-T 3.2.0 ではサポートされていません。
回避策：なし
-
問題 2934195：分散ファイアウォール ルールで、一部のタイプの NSX グループがサポートされない
分散ファイアウォール (DFW) ルールで、タイプが「IP アドレスのみ」の NSX グループはサポートされていません。メンバーとして手動で追加された IP アドレスを持つ「汎用」タイプの NSX グループもサポートされていません。
回避策：なし
-
問題 2939886：オブジェクトをマネージャ モードからポリシー モードに移行すると失敗する
ネットワーク ポリシーの仕様で出力側と入力側に同じセレクタが設定されている場合、オブジェクトをマネージャ モードからポリシー モードに移行すると、移行に失敗します。
回避策：なし
-
問題 3066449：use_ip_blocks_in_order が True に設定されている場合、ネームスペース サブネットが、最初に使用可能な IP ブロックから割り当てられない場合がある
use_ip_blocks_in_order が True に設定された複数のネームスペースを作成するときに、最初のネームスペースのサブネットが、最初に使用可能な IP ブロックから割り当てられていないことがあります。たとえば、container_ip_blocks = '172.52.0.0/28,172.53.0.0/28'、サブネット プレフィックス長 29、サブネット 172.52.0.0/29 がすでに割り当てられているとします。2 つのネームスペース ns-1 と ns-2 を作成すると、サブネットの割り当ては (1) ns-1 になります。172.52.0.8/29、ns-2：172.53.0.0/29 または (2) ns-1：172.53.0.0/29、ns-2：172.52.0.8/29。
use_ip_blocks_in_order パラメータは、異なる IP ブロックが container_ip_blocks パラメータに指定された順序で使用されるようにします。複数のネームスペースを同時に作成するときに、任意のネームスペースが、別のネームスペースの前に API 呼び出しを介してサブネットを要求することがあります。したがって、特定のネームスペースに特定の IP ブロックからサブネットが割り当てられるという保証はありません。
回避策：ネームスペースを個別に作成します。最初のネームスペースを作成し、サブネットが割り当てられていることを確認してから、次のネームスペースを作成します。
