VMware NSX Container Plugin 3.2.1.1 | 2022 年 5 月 17 日 | ビルド 19750154

各リリース ノートで、追加および更新された機能をご確認ください。

新機能

  • 複数の vNIC を使用する OCP ワーカー ノードの展開のサポート

    複数の vNIC を使用する OCP ワーカー ノードの展開は、最初の vNIC がコンテナ ネットワークに使用されることを前提としてサポートされます。

  • natfirewallmatch オプションのサポート

    natfirewallmatch オプションは、Kubernetes ネームスペース用に作成された NAT ルールでの NSX-T ゲートウェイ ファイアウォールの動作を指定します。このオプションは、新しく作成された Kubernetes ネームスペースにのみ適用されます。既存のネームスペースには適用されません。

廃止のお知らせ

アノテーション ncp/whitelist-source-range は、NCP 4.0 で廃止されます。NCP 3.1.1 以降では、代わりにアノテーション ncp/allowed-source-range を使用できます。

ncp/ingress_controller アノテーションを使用して入力方向コントローラ ポッドへの NAT 経由のアクセスを許可する機能は廃止され、2023 年に削除される予定です。入力方向コントローラ ポッドを公開する場合は、LoadBalancer タイプのサービスを使用することをお勧めします。

互換性の要件

製品

バージョン

Tanzu Application Service (TAS) の NCP/NSX-T タイル

3.2.1

NSX-T

3.1.3、3.2、3.2.1（以下の注を参照）

vSphere

6.7、7.0

Kubernetes

1.21、1.22、1.23

OpenShift 4

4.7、4.8、4.9

OpenShift ホスト仮想マシン OS

RHCOS 4.7、4.8

Kubernetes ホスト仮想マシン OS

Ubuntu 18.04、20.04

CentOS 8.2

RHEL 8.4、8.5

以下の注を参照。

Tanzu Application Service

Ops Manager 2.10 と TAS 2.11

Ops Manager 2.10 と TAS 2.12（サポート終了日：2023 年 3 月 31 日）

Tanzu Kubernetes Grid Integrated (TKGI)

1.13.6, 1.14

注：

CentOS/RHEL に nsx-ovs カーネル モジュールをインストールするには、特定のカーネル バージョンが必要です。CentOS/RHEL のバージョンに関係なく、サポートされる CentOS/RHEL カーネル バージョンは 193、305、348 です。デフォルトのカーネル バージョンは 193 (RHEL 8.2)、305 (RHEL 8.4)、348 (RHEL 8.5) です。別のカーネル バージョンを実行している場合は、次のいずれかを行うことができます。(1) カーネルバージョンをサポート対象のバージョンに変更する。カーネル バージョンを変更してから仮想マシンを再起動する場合は、Kubernetes API サーバとの接続が失われないようにするため、IP アドレスとスタティック ルートがアップリンク インターフェイス（ovs_uplink_port で指定）に保持されていることを確認します。(2) nsx-node-agent 構成マップの nsx_node_agent セクションで use_nsx_ovs_kernel_module を False に設定して、nsx-ovs カーネル モジュールのインストールをスキップする。

RHEL/CentOS で nsx-ovs カーネル モジュールを実行するには、vCenter Server の仮想マシン設定で [起動オプション] の [UEFI セキュア ブート] オプションを無効にする必要があります。

NCP 3.1.2 以降では、RHEL イメージは配布されません。サポートされている統合では、Red Hat Universal Base Image (UBI) を使用してください。詳細については、https://www.redhat.com/ja/blog/introducing-red-hat-universal-base-image を参照してください。

TKGI 1.14.0 は NCP 3.2.1.0 に付属しており、NSX-T 3.2.1 をサポートしていません。

TKGI 1.13.x および TKGI 1.14.x は、NSX-T 3.2.0.x と互換性がありません。

このリリースへのアップグレードのサポート：

  • すべての 3.1.x リリース

  • 以前のすべての 3.2.x リリース

制限事項

NCP のベースライン ポリシー機能は、クラスタ内のすべてのメンバーを選択する動的グループを作成します。NSX-T には、動的グループの有効メンバー数が 8,000 までという制限があります（詳細については、構成の上限を参照してください）。そのため、ポット数が 8,000 を超えることが予想されるクラスタでは、この機能を有効にしないでください。この制限を超えると、ポッドのリソースの作成が遅延する可能性があります。

解決した問題

  • 問題 3042916：起動後に nsx-kube-proxy が「invalid or unknown port for in_port」というエラーで失敗する

    まれに、OVS アップリンク ofport が空のため、nsx-kube-proxy が起動直後に失敗することがあります。ログに次のエラー メッセージが記録されます。「RuntimeError: Fatal error executing xxx: (): invalid or unknown port for in_port.」

    回避策：nsx-kube-proxy を再起動します。

  • 問題 2863155：大規模環境のポッドから一部のクラスタ IP サービスにアクセスできない

    大規模な環境でログ サイズが大きくなると、nsx-kube-proxy で問題が発生することがあります。一部のクラスタ IP サービスがポッドからアクセスできず、nsx-kube-proxy が nsxcli でその状態を報告できません。

    回避策：nsx-kube-proxy を再起動します。

  • 問題 2944368：ホストが指定された Ingress ルールが、ホストだけでなく、サフィックス付きのホストにも一致する

    たとえば、ホストに「test.co」が指定されているルールが、「test.co」と「test.co.uk」の両方に一致します。

    回避策：なし

  • 問題 2882699：IPv6 環境で baseline_policy_type を allow_namespace_strict に設定すると、通信障害が発生する

    IPv6 環境で baseline_policy_type が allow_namespace_strict に設定されていると、ポッドから Kubernetes ノードにアクセスできません。

    回避策：ベースライン ルールよりも優先度の高い分散ファイアウォール ルールを追加して、ポッドから Kubernetes ノードへのトラフィックを許可します。

  • 問題 2867871：ポッドの Kubernetes ノード名がホスト名と異なる場合、サービスが参照しているポッドから clusterIP サービスへのアクセスに失敗する

    NCP では現在、Kubernetes ノード名がホスト名と同じ場合にのみ、clusterIP サービスへのポッドの自己アクセスをサポートしています。これは、ホスト名がノード名と同じ場合にのみ、nsx-kube-proxy が自己アクセス フローを追加するためです。

    回避策：なし

  • 問題 2555336：Manager モードで作成された論理ポートが重複しているため、ポッド トラフィックが機能しない

    この問題は、複数のクラスタに多くのポッドが存在すると発生する可能性が高くなります。ポッドの作成時に、ポッドへのトラフィックが機能しません。NSX-T には、同じコンテナに複数の論理ポートが作成されていることが表示されますが、NCP ログには 1 つの論理ポートの ID のみが記録されています。

    回避策：ポッドを削除して再作成します。NCP が再起動すると、NSX-T の古いポートが削除されます。

  • 問題 2664457：OpenShift で DHCP を使用しているときに、nsx-node-agent を開始または再起動すると、接続が一時的に失われることがある

    nsx-ovs は、ovs_bridge を構成するために 5 つの一時的な接続プロファイルを作成して有効にしますが、一時的に NetworkManager で有効化が失敗し続けることがあります。結果として、ovs_uplink_port または ovs_bridge の仮想マシンに IP（接続）が存在しません。

    回避策：仮想マシンを再起動するか、NetworkManager がすべてのプロファイルを正常に有効にするまで待機します。

既知の問題

  • 問題 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 に設定します。

  • 問題 3033821：マネージャからポリシーへの移行後、分散ファイアウォール ルールが正しく適用されない

    マネージャからポリシーへの移行後、新しく作成されたネットワーク ポリシー関連の分散ファイアウォール (DFW) ルールが、移行された DFW ルールよりも優先されます。

    回避策：ポリシー API を使用して、必要に応じて DFW ルールの順序を変更します。

  • 問題 2960121：正しく構成していないと、LoadBalancer タイプのサービスで Windows ワーカー ノードのポッドに接続できない

    デフォルトの LB セグメント サブネットを使用するように NCP が構成されている場合、LoadBalancer タイプのサービスで、Windows ワーカー ノードのポッドに接続できません。デフォルトのサブネット 169.254.128.0/22 は IPv4 リンクローカル スペースに属し、Windows ノードでは転送されません。

    回避策：デフォルト以外の LB セグメント サブネットを使用するように NCP を構成します。これを行うには、nsx_v3 セクションでパラメータ lb_segment_subnet を設定します。これは、新しく作成された NSX ロード バランサでのみ有効です。

  • 問題 2972811：大規模な環境で一部のワーカー ノードへの HyperBus 接続が停止する

    大規模な環境では、RPC チャネルのタイムアウトにより、ポッドの作成が 10 ～ 15 分間停止することがあります。次の問題が発生する可能性があります。

    • Kubernetes クラスタで、一部のポッドの状態が 10 ～ 15 分間 ContainerCreating になります。

    • cfgAgent で、トンネルの状態が 10 ～ 15 分間 COMMUNICATION_ERROR になります。

    • NSX ユーザー インターフェイスで、HyperBus 接続の停止を示すアラームが生成されることがあります。

    回避策：なし。この問題は、10 ～ 15 分後に自動的に回復します。

  • 問題：2966586：マネージャ オブジェクトをポリシーに移行した後、ネームスペースの作成に失敗する

    マネージャ モードで IP ブロックを作成すると、マネージャ オブジェクトがポリシーに移行された後、NCP がこの IP ブロックからサブネットを割り当てることができないため、ネームスペースの作成に失敗します。

    回避策：ポリシー モードで新しい IP ブロックを作成し、これらの新しい IP ブロックを使用するように NCP を構成します。

  • 問題：2961789：マネージャ オブジェクトをポリシーに移行した後、健全性チェック ポッドの関連リソースの一部を削除できない

    マネージャ オブジェクトをポリシーに移行した後、健全性チェック ポッドを削除しても、ポッド関連のセグメント ポートと分散ファイアウォール ルールのターゲット グループが削除されません。

    回避策：これらのリソースを手動で削除します。

  • 問題 2923436：Kubernetes リソース名が長いと失敗する

    Kubernetes リソース名が長すぎる場合、NSX リソース名が NSX の表示名の制限を超えるため、対応する NSX リソースを作成できません。ログに、「フィールド レベルの検証エラー：{display_name ipp-k8scl-two-aaaaaa... が有効な最大長 255 を超えています}」のようなエラー メッセージが記録されます。NSX には次の制限があります。

    • セグメントの表示名：80 文字

    • グループ名 + ドメイン名：245 文字

    • その他の NSX リソースの表示名：255 文字

    回避策：Kubernetes リソース名を短くします。

  • 問題 2939886：オブジェクトをマネージャ モードからポリシー モードに移行すると失敗する

    ネットワーク ポリシーの仕様で出力側と入力側に同じセレクタが設定されている場合、オブジェクトをマネージャ モードからポリシー モードに移行すると、移行に失敗します。

    回避策：なし

  • 問題 2936436：NSX Manager のユーザー インターフェイスの [コンテナ クラスタ] ページに NCP のバージョンが表示されない

    NSX Manager のユーザー インターフェイスの [インベントリ] タブにコンテナ クラスタが表示されているときに、NCP バージョンが表示されません。

    回避策：NCP のバージョンを確認するには、API /policy/api/v1/fabric/container-clusters を呼び出します。

  • 問題 2934195：分散ファイアウォール ルールで、一部のタイプの NSX グループがサポートされない

    分散ファイアウォール (DFW) ルールで、タイプが「IP アドレスのみ」の NSX グループはサポートされていません。メンバーとして手動で追加された IP アドレスを持つ「汎用」タイプの NSX グループもサポートされていません。

    回避策：なし

  • 問題：2940772：NSX-T 3.2.0 で NCP リソースをマネージャからポリシーに移行すると失敗する

    NSX-T 3.1.3 および NSX-T 3.2.1 では、NCP リソースをマネージャからポリシーに移行できますが、NSX-T 3.2.0 ではサポートされていません。

    回避策：なし

  • 問題 2832480：ClusterIP タイプの Kubernetes サービスの場合、sessionAffinityConfig.clientIP.timeoutSeconds に 65535 より大きい値を設定できない

    ClusterIP タイプの Kubernetes サービスの場合、sessionAffinityConfig.clientIP.timeoutSeconds を 65535 より大きい値に設定しても、実際の値は 65535 になります。

    回避策：なし

  • 問題 2868572：NCP を実行する前に、ホスト仮想マシンで Open vSwitch (OVS) を無効にする必要がある

    ホスト仮想マシンに NCP を展開するには、最初に次のコマンドを使用して OVS 関連のプロセスを停止し、ホスト上の一部のファイルを削除する必要があります。

    1. sudo systemctl disable openvswitch-switch.service

    2. sudo systemctl stop openvswitch-switch.service

    3. rm -rf /var/run/openvswitch

    ホスト仮想マシンに NCP が展開済みで、OVS が正しく実行されていない場合は、次の手順でリカバリします。

    1. 上記の 3 つの手順を実行します。

    2. kubectl delete pod $agent-pod -n nsx-system コマンドを使用して、ノード エージェント ポッドの再起動に問題が発生しているノードの nsx-node-agent ポッドを削除します。

    回避策：上記を参照してください。

  • 問題 2867361：NCP のクリーンアップ後に nsx-node-agent アラームと Hyperbus アラームが削除されない

    何らかの理由（すべての NSX ノード エージェントの停止など）で nsx-node-agent アラームと Hyperbus アラームが表示された後、NCP を停止し、クリーンアップ スクリプトを実行しても、クリーンアップ後にアラームが削除されずに残ります。

    回避策：なし

  • 問題 2824129：再起動後 3 分以上、ノードの状態 network-unavailable が true になる

    NCP operator を使用して NCP のライフサイクルを管理している場合、nsx-node-agent デーモンセットが非実行状態からリカバリすると、3 分間実行されるまでノードの状態 network-unavailable が true になります。これは、想定どおりの動作です。

    回避策：nsx-node-agent の再起動後、少なくとも 3 分間待機します。

  • 問題 2841030：Kubernetes 1.22 で、nsx-node-agent の状態が常に「AppArmor」になる

    Kubernetes 1.22 で、nsx-node-agent ポッドが「準備完了」になっても、状態が「AppArmor」から「実行中」に更新されません。これは、NCP または nsx-node-agent の機能に影響しません。

    回避策：nsx-node-agent ポッドを再起動します。

  • 問題 2860091：baseline_policy_type が allow_namespace に設定されていると、DNS トラフィックが失敗する

    OpenShift または Kubernetes 環境で、baseline_policy_type が allow_namespace に設定されていると、他のネームスペースのポッド (hostNetwork: False) が DNS サービスにアクセスできなくなります。

    回避策：ルール ネットワーク ポリシーを追加して、他のポッドから DNS ポッドへのトラフィックを許可します。

  • 問題 2795482：ノード/ハイパーバイザーの再起動後、または他の操作の実行後に、実行中のポッドが ContainerCreating 状態で停止する

    wait_for_security_policy_sync フラグが true の場合、ワーカー ノードのハード リブート、ハイパーバイザーの再起動、またはその他の理由により、ポッドが実行状態を 1 時間以上継続した後、ContainerCreating 状態になることがあります。ポッドが作成状態を継続します。

    回避策：ポッドを削除して再作成します。

  • 問題 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 によって静的ポッドを削除するのではなく、マニフェスト ファイルを削除して静的ポッドを削除します。

  • 問題 2736412：max_allowed_virtual_servers が設定されていると、members_per_small_lbs パラメータが無視される

    max_allowed_virtual_servers と members_per_small_lbs の両方が設定されている場合、max_allowed_virtual_servers のみが考慮されるため、仮想サーバが使用可能なロード バランサに接続できないことがあります。

    回避策：自動スケーリングを有効にするのではなく、スケールの制約を緩和します。

  • 問題 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 コンテナの両方のタイムアウト値を更新します。

  • 問題 2745907：monit コマンドを実行すると、nsx-node-agent について誤った状態情報が返される

    diego_cell 仮想マシンで monit を実行して nsx-node-agent を再起動したときに、nsx-node-agent が完全に起動するまでに 30 秒以上かかると、nsx-node-agent の状態が「Execution failed」と表示されます。nsx-node-agent が完全に機能するようになった場合でも状態が「running」に更新されません。

    回避策：なし。

  • 問題 2745904：「デフォルトで実行中の ASG に IPset を使用する」機能で、既存のコンテナ IP ブロックの削除または置き換えがサポートされない

    NCP タイルで [デフォルトで実行中の ASG に IPset を使用する] を有効にすると、NCP は、同じ NCP タイルの [コンテナ ネットワークの IP ブロック] で構成されたコンテナ IP ブロックに専用の NSGroup を作成します。この NSGroup は、グローバルで実行中の ASG に作成されたファイアウォール ルールで使用され、すべてのコンテナのトラフィックが許可されます。既存のコンテナ IP ブロックを後で削除または置き換えると、NSGroup 内で削除または置き換えが行われます。元の IP ブロック内の既存のコンテナと実行中のグローバル ASG の関連付けが解除されます。このため、トラフィックが機能しなくなる可能性があります。

    回避策：[コンテナ ネットワークの IP ブロック] に新しい IP ブロックのみを追加します。

  • 問題 2707174：ポッドを削除して同じネームスペースに再作成すると、ネットワークに接続できない

    NCP が実行されず、nsx-ncp-agents が実行されているときに、ポッドを削除して同じネームスペースに再作成すると、ポッドが誤ったネットワーク構成を取得し、ネットワークにアクセスできない場合があります。

    回避策：ポッドを削除し、NCP の実行中にポッドを再作成します。

  • 問題 2672677：OpenShift 4 環境の負荷が非常に高くなると、ノードが応答不能になる

    ノードあたりのポッドの集約度が高く、ポッドの削除および作成が頻繁に行われている OpenShift 4 環境で、RHCOS ノードが「準備未完了」の状態になることがあります。DaemonSet メンバーを除いて、影響を受けるノードで実行されているポッドは退去され、環境の他のノードで再作成されます。

    回避策：影響を受けるノードを再起動します。

  • 問題 2653214：ノードの IP アドレスが変更された後に、ノードのセグメント ポートを検索するとエラーが発生する

    ノードの IP アドレスが変更された後に、NCP をアップグレードしたり、NCP Operator ポッドが再起動された場合、oc describe co nsx-ncp コマンドで NCP Operator の状態を確認すると、「ノードのセグメント ポートの検索中にエラーが発生しました...」というエラー メッセージが表示されます。

    回避策：なし。DHCP 構成のあるノード インターフェイスに静的 IP アドレスを追加することはできません。

  • Kubernetes のインストール中にファイルへのログ出力が有効になっていると、NCP の起動に失敗する

    この問題は、コンテナ ホストの uid:gid=1000:1000 にログ フォルダに対する権限がないと発生します。

    回避策：次のいずれかを実行します。

    • コンテナ ホストでログ フォルダのモードを 777 に変更します。

    • ログ フォルダに対する rwx 権限をコンテナ ホストの uid:gid=1000:1000 に付与します。

    • ファイルへのログ出力機能を無効にします。

  • 問題 2579968：LoadBalancer タイプの Kubernetes サービスに対する変更が頻繁に発生すると、一部の仮想サーバとサーバ プールが正常に削除されない

    LoadBalancer タイプの Kubernetes サービスで頻繁に変更が行われているときに、仮想サーバとサーバ プールの削除を行うと、一部の仮想サーバとサーバ プールが NSX-T 環境に残ることがあります。

    回避策：NCP を再起動します。あるいは、古い仮想サーバとそれに関連付けられたリソースを手動で削除します。external_id タグに LoadBalancer タイプの Kubernetes サービスの ID が含まれていない場合、そのサーバは古い仮想サーバです。

  • 問題 2597423：マネージャ オブジェクトをポリシーにインポートするときにロールバックすると、一部のリソースのタグがなくなる

    マネージャ オブジェクトをポリシーにインポートするときにロールバックを行うと、次のオブジェクトのタグはリストアされません。

    • Spoofguard プロファイル（共有リソースとクラスタ リソースの一部）

    • BgpneighbourConfig（共有リソースの一部）

    • BgpRoutingConfig（共有リソースの一部）

    • StaticRoute BfdPeer（共有リソースの一部）

    回避策：共有リソースに含まれるリソースの場合は、手動でタグをリストアします。クラスタ リソースに含まれるリソースをリストアする場合は、バックアップとリストア機能を使用します。

  • 問題 2552564：OpenShift 4.3 環境で、重複するアドレスが見つかると DNS フォワーダが停止することがある

    OpenShift 4.3 環境でクラスタをインストールするには、DNS サーバが構成されている必要があります。NSX-T を使用して DNS フォワーダを構成するときに、DNS サービスと重複する IP アドレスが存在すると、DNS フォワーダが停止し、クラスタのインストールに失敗します。

    回避策：外部 DNS サービスを構成し、インストールに失敗したクラスタを削除して、クラスタを再作成します。

  • 問題 2537221：NSX-T を 3.0 にアップグレードした後、NSX Manager ユーザー インターフェイスでコンテナ関連オブジェクトのネットワーク状態が「不明」と表示される

    NSX Manager ユーザー インターフェイスで、[インベントリ] > [コンテナ] タブの順に移動すると、コンテナ関連のオブジェクトとその状態が表示されます。TKGI 環境で NSX-T を 3.0 にアップグレードすると、コンテナ関連のオブジェクトのネットワーク状態が「不明」と表示されます。この問題は、TKGI が NSX-T のバージョンの変更を検出しないことが原因で発生します。NCP がポッドとして実行され、稼動状態の検証が有効になっている場合、この問題は発生しません。

    回避策：NSX-T のアップグレード後、NCP インスタンスを段階的に再起動します（同時に再起動するインスタンス数は 10 個以下にします）。これにより、NSX Manager の過負荷状態を回避できます。

  • 問題 2416376：NCP で、128 を超える空間に割り当てる TAS ASG（アプリケーション セキュリティ グループ）の処理に失敗する

    NSX-T 分散ファイアウォールの制限のため、NCP は 128 を超える空間に割り当てる TAS ASG を処理できません。

    回避策：複数の ASG を作成し、各 ASG を割り当てる空間を 128 以下にします。

  • 問題 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 で更新しないでください。

  • 問題 2404302：同じリソース タイプ（たとえば、HTTP）の複数のロード バランサ アプリケーション プロファイルが NSX-T に存在する場合、NCP は仮想サーバに接続するいずれかのロード バランサ アプリケーション プロファイルを選択する

    NSX-T に複数の HTTP ロード バランサ アプリケーション プロファイルが存在する場合、NCP は適切な x_forwarded_for 構成の HTTP ロード バランサ アプリケーション プロファイルのいずれかを選択して、HTTP および HTTPS 仮想サーバに接続します。NSX-T に複数の FastTCP プロファイルと UDP アプリケーション プロファイルが存在する場合、NCP はプロファイルのいずれかを選択して、TCP 仮想サーバまたは UDP 仮想サーバに接続します。ロード バランサ アプリケーション プロファイルは、異なるアプリケーションによって作成され、異なる値が設定されている可能性があります。NCP によって作成した仮想サーバに、これらのロード バランサ アプリケーション プロファイルのいずれかを接続するよう NCP が選択した場合、他のアプリケーションのワークフローが壊れることがあります。

    回避策：なし

  • 問題 2224218：サービスまたはアプリケーションの削除後、SNAT IP アドレスが IP アドレス プールに戻るのに 2 分かかる

    サービスまたはアプリケーションを削除し、2 分以内に再作成すると、新しい SNAT IP アドレスが IP アドレス プールから取得されます。

    回避策：同一の IP アドレスをもう一度使用する場合は、サービスまたはアプリケーションの削除後、2 分間待ってから再作成します。

  • タイプが ClusterIP の Kubernetes サービスの場合、ヘアピンモード フラグがサポートされない

    NSX Container Plugin (NCP) ではタイプが ClusterIP の Kubernetes サービスの場合、ヘアピンモード フラグがサポートされません。

    回避策：なし

  • 問題 2131494：Ingress のクラスを nginx から nsx に変更しても NGINX Kubernetes Ingress が動作を続ける

    NGINX Kubernetes Ingress の作成時、NGINX はトラフィック転送ルールを作成します。Ingress のクラスを他の値に変更すると、クラスの変更後に Kubernetes Ingress を削除しても、NGINX はルールを削除せずにルールの適用を継続します。これは NGINX の制限の 1 つです。

    回避策：NGINX が作成したルールを削除するには、クラスの値が nginx である Kubernetes Ingress を削除します。その後、再度 Kubernetes Ingress を作成します。

check-circle-line exclamation-circle-line close-line
Scroll to top icon