VMware NSX Container Plugin 3.2.1.3 | 2022 年 9 月 13 日 | ビルド 20385490

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

新機能

これは、以前のリリースで見つかった問題を解決するアップデート リリースです。

廃止のお知らせ

アノテーション 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.7 と TAS 2.7 (LTS)

Ops Manager 2.10 と TAS 2.11

Ops Manager 2.10 と TAS 2.12

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 を超えることが予想されるクラスタでは、この機能を有効にしないでください。この制限を超えると、ポッドのリソースの作成が遅延する可能性があります。

解決した問題

  • 問題 3026811:Windows ノード上のポッドは「実行中」状態になっているが、トラフィックを送受信できない

    CNI ADD 要求の処理中に、ワークロード コンテナで接続時に障害が発生すると、nsx-node-agent は対応する HNS エンドポイントを削除します。kubelet が新しいワークロードに対して別の CNI ADD 要求を送信し、この要求が成功すると、ポッドは「実行中」状態になり、HNS エンドポイントがワークロード コンテナに接続されます。ただし、別の kubelet のスレッドが最初のワークロードのステータスを取得するために CNI ADD を引き続き送信する場合があります。接続が失敗し、対応する HNS エンドポイントが削除されます。これにより、正しく作成された 2 番目のワークロードのネットワーク接続が切断されます。

    回避策:なし

既知の問題

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

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

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

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

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

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

  • タイプが 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 以下にします。

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

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

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

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

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

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

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

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

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

    • BgpneighbourConfig(共有リソースの一部)

    • BgpRoutingConfig(共有リソースの一部)

    • StaticRoute BfdPeer(共有リソースの一部)

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

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

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

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

  • 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 の実行中にポッドを再作成します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    回避策:なし

  • 問題 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 ポッドを削除します。

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

  • 問題 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 グループもサポートされていません。

    回避策:なし

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

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

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

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

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

    回避策:なし

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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