RSS
 

VMware NSX Container Plugin 3.2.0.2 | 2021 年 12 月 16 日 | ビルド 19024342

本ドキュメントの追加情報およびアップデート情報を定期的に確認してください。

リリース ノートの概要

このリリース ノートには、次のトピックが含まれています。

新機能

NSX Container Plugin (NCP) 3.2.0.2 には、以下の新しい機能が導入されています。
  • NSX-T 3.2.0 のサポート

廃止のお知らせ

アノテーション 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
NSX-T 3.1.3、3.2（以下の注を参照）
vSphere 6.7、7.0
Kubernetes 1.20、1.21、1.22
OpenShift 4 4.7、4.8
OpenShift ホスト仮想マシン OS RHCOS 4.7、4.8
Kubernetes ホスト仮想マシン OS Ubuntu 18.04、20.04
CentOS 7.8、7.9、8.2
RHEL 8.2、8.4
以下の注を参照。
Tanzu Application Service Ops Manager 2.7 と TAS 2.7 (LTS)
Ops Manager 2.10 と TAS 2.10
Ops Manager 2.10 と TAS 2.11
Ops Manager 2.10 と TAS 2.12
Tanzu Kubernetes Grid Integrated (TKGI) 1.13

注：

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

RHEL 8.2（カーネル バージョン 193）で 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.13.x および TKGI 1.14.x は、NSX-T 3.2.0.x と互換性がありません。

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

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

 

解決した問題

  • タイプが ClusterIP の Kubernetes サービスの場合、クライアント IP アドレス ベースのセッション アフィニティがサポートされない

    NSX Container Plugin (NCP) ではタイプが ClusterIP の Kubernetes サービスの場合、クライアント IP アドレス ベースのセッション アフィニティがサポートされません。

    回避策：なし

既知の問題

  • 問題 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 サービスを設定し、インストールに失敗したクラスタを削除して、クラスタを再作成します。

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

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

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

  • 問題 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 アドレスを追加することはできません。

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

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

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

  • 問題 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 コンテナの両方のタイムアウト値を更新します。
  • 問題 2744557：入力方向パスの照合で、キャプチャ グループ () と {0} の両方を含む複雑な正規表現パターンがサポートされない

    たとえば、正規表現 (regex) パターン/foo/bar/(abc){0,1} が /foo/bar/ と一致しません。

    回避策：入力方向の正規表現ルールを作成する場合に、キャプチャ グループ () と {0} を使用しません。/foo/bar/ と照合する場合は、通常のパターン EQUALS を使用します。

  • 問題 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 を停止し、クリーンアップ スクリプトを実行しても、クリーンアップ後にアラームが削除されずに残ります。

    回避策：なし

  • 問題 2869247：Ubuntu 18.04 ホスト OS で、nsx-ovs コンテナが再起動を繰り返す

    liveness probe が失敗し続けるため、nsx-ovs コンテナが再起動を繰り返します。/var/log/nsx-ujo/openvswitch/ovs-vswitchd.log に、再起動が繰り返し発生していることを示すログが記録されます。次はその例です。

    2021-10-28T17:38:49.364Z|00004|backtrace(monitor)|WARN|Backtrace using libunwind not supported. 
2021-10-28T17:38:49.364Z|00005|daemon_unix(monitor)|WARN|2 crashes: pid 282 died, killed (Aborted), core dumped, waiting until 10 seconds since last restart 
2021-10-28T17:38:57.364Z|00006|daemon_unix(monitor)|ERR|2 crashes: pid 282 died, killed (Aborted), core dumped, restarting

    この問題は、nsx-ovs コンテナにインストールされたアップストリーム OVS ユーザー空間パッケージとホスト上の OVS カーネル モジュール間に互換性がないことが原因で発生します。

    回避策：ホスト OS を Ubuntu 20.0 にアップグレードするか、次の手順を実行して、NSX で提供される OVS カーネル モジュールを使用します。

    1. nsx-node-agent の構成マップで、use_nsx_ovs_kernel_module を True に設定します。
    2. ncp-ubuntu*.yaml ファイルの nsx-ncp-bootstrap DaemonSet で、ボリューム マウントのコメントを解除します（「Uncomment these mounts if installing NSX-OVS kernel module」と「Uncomment these volumes if installing NSX-OVS kernel module」を検索します）。
    3. ncp-ubuntu*.yaml ファイルを再適用し、nsx-node-agent ポッドを再起動します。
  • 問題 2867871：ポッドの Kubernetes ノード名がホスト名と異なる場合、サービスが参照しているポッドから clusterIP サービスへのアクセスに失敗する

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

    回避策：なし

  • 問題 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 になります。

    回避策：なし

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

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

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

  • 問題：2887484：NCP リソースをマネージャからポリシーに移行すると失敗する

    このリリースでは、マネージャからポリシーへの NCP リソースの移行はサポートされていません。

    回避策：なし

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

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

    回避策：なし

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

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

    回避策：なし

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

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

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

  • 問題 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 を再起動します。

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