VMware NSX Container Plugin 3.1.1 | 2021 年 2 月 4 日 | ビルド 17559186

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

リリース ノートの概要

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

新機能

NSX Container Plugin (NCP) 3.1.1 には、以下の新しい機能が導入されています。
  • Operator による NCP の展開と Kubernetes クラスタの管理を簡素化
  • ノードで nsx-node-agent が使用できない場合にノードの NetworkUnavaialble 条件を設定（Operator による操作）
  • SNAT ルールのログ作成を有効化
  • OCP4 のルーター シャーディング
  • Kubernetes クラスタの Tier-1 へのマルチキャスト
  • Ingress 仮想サーバでアクセス ログを有効化
  • ロード バランサで TCP 多重化を有効化
  • hostPort 経由のポッド アクセスをサポート

廃止のお知らせ

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

互換性の要件

製品 バージョン
Tanzu Application Service (PCF) の NCP/NSX-T タイル 3.1.1
NSX-T 3.0.2、3.1.0、3.1.1
vSphere 6.7、7.0
Kubernetes 1.18 (P1)、1.19、1.20
OpenShift 3 3.11
注：OpenShift 3.x のサポートは今後のリリースで廃止される予定です。
OpenShift 4 RHCOS 4.5、4.6
Kubernetes ホスト仮想マシン OS Ubuntu 18.04、Ubuntu 20.04
CentOS 7.8、CentOS 7.9、CentOS 8.2
RHEL 7.8、RHEL 7.9、RHEL 8.3（注：vanilla Kubernetes の RHEL サポートは今後のリリースで廃止される予定です）
以下の注を参照。
OpenShift ホスト仮想マシン OS RHEL 7.7、RHEL 7.8（注：vanilla Kubernetes の RHEL サポートは今後のリリースで廃止される予定です）
Tanzu Application Service (Pivotal Cloud Foundry) Ops Manager 2.7 と PAS 2.7 (LTS)
Ops Manager 2.9 と PAS 2.9
Ops Manager 2.10 と PAS 2.10
Tanzu Kubernetes Grid Integrated (TKGI) 1.10

注：

CentOS/RHEL に nsx-ovs カーネル モジュールをインストールするには、特定のカーネル バージョンが必要です。RHEL のバージョンに関係なく、サポートされる RHEL カーネル バージョンは 1127、1160、および 193 です。デフォルトのカーネル バージョンは 1127 (RHEL 7.8)、1160 (RHEL 7.9)、193 (RHEL 8.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 とすべての NCP 3.0.x リリース

 

解決した問題

  • 問題 2671647：OVS デーモンの ovsdb-server と ovs-vswitchd で monit ジョブを再起動すると、OVS フローが失われる

    monit restart <process-name> コマンドを使用して openvswitch デーモンの monit ジョブを再起動すると、nsx-node-agent が作成した OVS フローが失われます。

    回避策：openvswitch デーモンが稼動状態に戻った後、monit restart nsx-node agent コマンドを使用して nsx-node-agent を再起動します。

  • 問題 2674503：nsx-ncp-bootstrap は、CentOS 7.8、8.1、8.2、または RHEL 7.8、8.1、8.2 での NSX OVS カーネル モジュールのインストールをサポートしていません。

    nsx-ncp-bootstrap コンテナは、CentOS 7.8、8.1、8.2、または RHEL 7.8、8.1、8.2 での NSX OVS カーネル モジュールのインストールをサポートしていません。

    回避策：NSX ノード エージェントの ConfigMap で、use_nsx_ovs_kernel_module を False に設定し、Linux アップストリーム OVS カーネル モジュールを使用します。

既知の問題

  • 問題 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 サービスの場合、クライアント IP アドレス ベースのセッション アフィニティがサポートされない

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

    回避策：なし

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

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

    回避策：なし

  • 問題 2192489：PAS ディレクタ設定で「BOSH DNS server」を無効にした後でも、Bosh DNS サーバ (169.254.0.2) がコンテナの resolve.conf ファイルに表示される

    PAS 2.2 を実行している PAS 環境の PAS ディレクタ設定で「BOSH DNS server」を無効にした後でも、Bosh DNS サーバ (169.254.0.2) がコンテナの resove.conf ファイルに表示されます。これにより、完全修飾ドメイン名を指定した ping コマンドの実行にかかる時間が長くなります。この問題は、PAS 2.1 では発生しません。

    回避策：なし。これは PAS の問題です。

  • 問題 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 が選択した場合、他のアプリケーションのワークフローが壊れることがあります。

    回避策：なし

  • 問題 2397621：OpenShift 3 のインストールに失敗する

    OpenShift 3 のインストールでは、ノードの状態が「準備完了」であることを前提にしています。CNI プラグインのインストールが完了すると、この状態になります。このリリースでは、別の CNI プラグイン ファイルが存在しないため、OpenShift のインストールに失敗します。

    回避策：インストールを開始する前に、各ノードに /etc/cni/net.d ディレクトリを作成します。

  • 問題 2413383：準備が完了していないノードがあるため、OpenShift 3 のアップグレードが失敗する

    デフォルトでは、マスター ノードで NCP ブートストラップ ポッドのスケジュールが設定されていません。その結果、マスター ノードの状態は常に「準備ができていません」になります。

    回避策：マスター ノードに compute ロールを割り当て、nsx-ncp-bootstrap と nsx-node-agent DaemonSet にポッドの作成を許可します。nsx-ncp-bootstrap が NSX-CNI をインストールすると、ノードの状態が「準備完了」に変わります。

  • 問題 2451442：NCP を繰り返し再起動してネームスペースを再作成すると、NCP がポッドに IP アドレスを割り当てることができないことがある

    NCP の再起動中に同じネームスペースを繰り返し削除して再作成すると、NCP がそのネームスペース内のポッドに IP アドレスを割り当てることができないことがあります。

    回避策：ネームスペースに関連付けられている古い NSX リソース（論理ルーター、論理スイッチ、論理ポート）をすべて削除してから再作成します。

  • 問題 2460219：デフォルトのサーバ プールがないと、HTTP リダイレクトが機能しない

    HTTP 仮想サーバがサーバ プールに割り当てられていないと、HTTP リダイレクトが失敗します。この問題は、NSX-T 2.5.0 およびそれ以前のリリースで発生します。

    回避策：デフォルトのサーバ プールを作成するか、NSX-T 2.5.1 にアップグレードします。

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

  • 問題 2524778：NCP マスター ノードが削除された後、NSX Manager で NCP の状態が「停止」または「不良」と表示される

    NCP マスター ノードが削除された後（たとえば、バックアップ ノードへの切り替えが正常に完了した後）、NCP が正常に起動していても、健全性の状態が「停止」と表示されます。

    回避策：Manager API DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status を使用して、以前の状態を手動でクリアします。

  • 問題 2517201：ESXi ホストでポッドを作成できない

    ESXi ホストを vSphere クラスタから削除して同じクラスタに再度追加すると、ホストでポッドを作成できなくなります。

    回避策：NCP を再起動します。

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

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

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

  • 問題 2534726：NSX-T タイル経由での NCP 3.0.1 へのアップグレードに失敗したときに、BOSH コマンド ラインでアップグレードをやり直すと、パフォーマンスの問題が発生する

    OpsMgr の NSX-T タイル経由で NCP 3.0.1 にアップグレードすると、NCP で使用されている NSX Manager の HA スイッチング プロファイルが無効とマークされます。NCP が再起動すると、このスイッチング プロファイルは削除されます。アップグレードに失敗し、bosh deploy -d <deployment-id> -n <deployment>.yml などの BOSH コマンドでアップグレードをやり直すと、HA スイッチング プロファイルは削除されません。NCP は引き続き実行されますが、パフォーマンスは低下します。

    回避策：BOSH コマンド ラインではなく、OpsMgr 経由で NCP をアップグレードします。

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

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

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

  • 問題 2550474：OpenShift 環境で、HTTPS ルートを HTTP に変更すると、HTTP ルートが期待どおりに動作しないことがある

    HTTPS ルートを編集し、TLS 関連のデータを削除して HTTP ルートに変換すると、HTTP ルートが期待どおりに動作しないことがあります。

    回避策：HTTPS ルートを削除して、新しい HTTP ルートを作成します。

  • 問題 2552573：OpenShift 4.3 環境で、ポリシー UI を使用して DHCP を設定すると、クラスタのインストールに失敗することがある

    OpenShift 4.3 環境でクラスタをインストールするには、IP アドレスと DNS 情報を提供する DHCP サーバが必要です。ポリシー UI を使用して NSX-T で構成された DHCP サーバを使用していると、クラスタのインストールに失敗することがあります。

    回避策：Manager UI を使用して DHCP サーバを構成し、インストールに失敗したクラスタを削除して、クラスタを再作成します。

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

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

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

  • 問題 2483242：NSX-T SpoofGuard により、コンテナからの IPv6 トラフィックがブロックされる

    SpooGuard が有効になっていると、IPv6 リンク ローカル アドレスがホワイトリストに自動的に登録されません。

    回避策：NCP 構成で nsx_v3.enable_spoofguard = False を設定し、SpoofGuard を無効にします。

  • 問題 2552609：X-Forwarded-For (XFF) と X-Forwarded-Port のデータが正しくない

    HTTPS Ingress ルール (Kubernetes) または HTTPS ルート (OpenShift) で、XFF に INSERT または REPLACE が設定されていると、XFF ヘッダーの X-Forwarded-For と X-Forwarded-Port に間違った値が表示される場合があります。

    回避策：なし。

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

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

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

  • 問題 2554357：IPv6 でロード バランサの自動スケーリングが機能しない

    IPv6 環境では、既存のロード バランサの規模に到達すると、LoadBalancer タイプの Kubernetes サービスがアクティブになりません。

    回避策：/var/vcap/jobs/ncp/config/ncp.ini（PKS 展開の場合）または nsx-ncp-configmap（その他の場合）に nsx_v3.lb_segment_subnet = FE80::/10 を設定します。その後、NCP を再起動します。

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

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

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

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

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

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

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

  • 問題 2536383：NSX-T を 3.0 以降にアップグレードした後、NSX-T UI で NCP 関連情報が正しく表示されない

    NSX-T を 3.0 以降にアップグレードした後、NSX-T UI で [インベントリ] > [コンテナ] タブに移動すると、コンテナ関連のオブジェクトのネットワーク状態が「不明」と表示されます。また、[システム] > [ファブリック] > [ノード] > [NCP クラスタ] タブに NCP クラスタが表示されません。この問題は通常、PKS 環境で発生します。

    回避策：NSX-T のアップグレード後、NCP インスタンスを段階的に再起動します（同時に再起動するインスタンス数は 10 個以下にします）。

  • 問題 2622099：LoadBalancer タイプの Kubernetes サービスの初期化に失敗し、エラー コード NCP00113 とエラー メッセージ「オブジェクトが他のユーザーによって変更されました」が返される

    ポリシー API を使用した単一階層環境で、最上位のゲートウェイとして既存の Tier-1 ゲートウェイを使用し、ゲートウェイのプール割り当てサイズが「ルーティング」の場合、LoadBalancer タイプの Kubernetes サービスの初期化に失敗し、エラーコード NCP00113 と次のエラー メッセージが返されます。「オブジェクトが他のユーザーによって変更されました。再試行してください。」

    回避策：この問題が発生した場合は、5 分間待機します。その後、NCP を再起動します。これで問題が解決します。

  • 問題 2633679：NCP Operator が、API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> を使用して作成された Tier-1 セグメントに接続している OpenShift ノードをサポートしない

    NCP Operator が、API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> を使用して作成された Tier-1 セグメントに接続している OpenShift ノードをサポートしません。

    回避策：API /policy/api/v1/infra/segments/<segment-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 メンバーを除いて、影響を受けるノードで実行されているポッドは退去され、環境の他のノードで再作成されます。

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

  • 問題 2706551：インストール中にノードの準備ができていないと、OpenShift のフルスタック自動インストール (IPI) が失敗する

    keepalived ポッドは、ポッド上で Kubernetes API サーバが開始する前に、マスター ノードの ovs_bridge に Kubernetes VIP を追加します。このため、Kubernetes API サーバへの要求がすべて失敗し、インストールを完了できません。

    回避策：なし

  • 問題 2707883：nsx-ncp-operator が実行されていないときにリソースが削除されると、nsx-ncp-operator が NCP 関連の Kubernetes リソースを作成しない

    nsx-ncp-operator が実行されていないときに nsx-node-agent または nsx-ncp-bootstrap DaemonSet を削除すると、nsx-ncp-operator の再実行時に、これらのリソースが再作成されません。

    回避策：nsx-ncp-operator が再度実行されたら、nsx-ncp-operator ConfigMap のフィールド（[Default] セクションの log_level など）を更新します。

  • 問題 2697547：RHEL/CentOS/RHCOS ノードで HostPort がサポートされない

    nsx-node-agent ConfigMap で enable_hostport_snat を True に設定すると、Ubuntu ノードのネイティブ Kubernetes および PKS で hostPorts を指定できます。ただし、RHEL/CentOS/RHCOS ノードでは hostPort はサポートされません。enable_hostport_snat パラメータは無視されます。

    回避策：なし

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

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

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

  • 問題 2713782：NSX API 呼び出しが「SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC」というエラーで失敗する

    NCP の起動時に、NCP が再起動したり、ロード バランサ サービスの初期化に失敗することがあります。また、短い時間（1 秒未満）ですが、NCP の実行中に NSX エンドポイントが「停止」と報告される場合があります。ロード バランサの初期化に失敗すると、NCP ログに「Failed to initialize loadbalancer services」というメッセージが記録されます。

    回避策：nsx_v3.conn_idle_timeout パラメータの値を大きくします。これにより、クライアント側のロード バランシングを使用している場合、一時的な切断の後にエンドポイントが使用可能として検出されるまでに時間がかかる可能性があります。

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

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

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

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