VMware NSX Container Plugin 3.0.2 | 2020 年 9 月 10 日 | ビルド 16863080

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

リリース ノートの概要

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

新機能

 
NSX Container Plugin 3.0.2 では、以下の新しい機能が導入されています。
  • OpenShift 4.4 のサポート(NSX-T Data Center 3.0.1.1 以降)
  • Ingress での JWT クライアント認証のサポート(NSX-T Data Center 3.0.0 以降)
  • セレクタのない LoadBalancer タイプの Kubernetes サービスのサポート
  • 注釈を使用してネームスペースとサービス単位で特定の SNAT IP アドレスを指定する機能
  • 分散ファイアウォール ルールでログ トラフィックを有効にする新しい注釈
  • Photon OS のサポート
  • ポッド セキュリティ ポリシーのサポート
  • Ingress での pathType 属性のサポート

NSX Container Plugin 3.0.2.2 はパッチ リリースです。これは、Pivotal Stemcells 621.85 以降、および 456.121 以降での OVS カーネル モジュールのコンパイルの問題を解決します。

 

互換性の要件

製品 バージョン
Tanzu Application Service (PCF) の NCP/NSX-T タイル 3.0.2
NSX-T 2.5.2、2.5.2.1、2.5.2.2、2.5.3、3.0.0、3.0.1、3.0.2、3.0.3
vSphere 6.7、7.0
Kubernetes 1.17、1.18
OpenShift 3 3.11
OpenShift 4 RHCOS 4.3、4.4
Kubernetes ホスト仮想マシン OS Ubuntu 16.04、Ubuntu 18.04、CentOS 7.7、CentOS 7.8、CentOS 8.1、RHEL 7.8、RHEL 8.1

注:RHEL/CentOS 7.8、8.1 の場合、nsx-ovs はサポートされません。アップストリーム OVS とのみ互換性があります。
OpenShift ホスト仮想マシン OS RHEL 7.7、RHEL 7.8
OpenShift BMC
(このリリースで廃止)
 
Tanzu Application Service (Pivotal Cloud Foundry) Ops Manager 2.8 と PAS 2.8
Ops Manager 2.9 と PAS 2.9
Ops Manager 2.10 と PAS 2.10

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

  • 以前のすべての 3.0.x リリースとすべての NCP 2.5.x リリース

 

解決した問題

  • 問題 2518312:NCP ブートストラップ コンテナが Ubuntu 18.04.4、カーネル 4.15.0-88 に nsx ovs カーネル モジュールをインストールできない

    NCP ブートストラップ コンテナ (nsx-ncp-bootstrap) が Ubuntu 18.04.4、カーネル 4.15.0-88 に nsx ovs カーネル モジュールをインストールできません。

    このカーネルに NSX OVS がインストールされないように nsx-node-agent-config で use_nsx_ovs_kernel_module = False を設定してください。ホスト上のアップストリーム OVS カーネル モジュールを使用してください(Ubuntu にはデフォルトで OVS カーネル モジュールが含まれています)。ホストに OVS カーネル モジュールがない場合は、OVS カーネル モジュールを手動でインストールし、nsx-node-agent-config で use_nsx_ovs_kernel_module = False を設定します。あるいは、カーネル バージョンを 4.15.0-76 にダウングレードして NSX-OVS をインストールできるようにします。

  • 問題 2548815:NCP で、Manager からポリシーにインポートされた NCP クラスタから自動的に拡張された Tier-1 ルーターを削除できない

    Manager からポリシーにインポートした後、ポリシー モードで実行されている NCP では自動的に拡張された Tier-1 ルーターを削除できません。これは、ルーターが LocaleService によって参照されているためです。

    回避策:NSX Manager UI を使用して Tier-1 ルーターを手動で削除します。

  • 問題 2549433:DHCP のリースが期限切れになると、ovs_uplink_port として設定された単一インターフェイスの OpenShift ノードでネーム サーバの情報が失われる

    単一インターフェイスの OpenShift ノードで、そのインターフェイスが nsx-node-agent config で ovs_uplink_port として設定されていると、ovs_uplink_port の DHCP リースが期限切れになったときにネーム サーバの情報が失われます。

    回避策:静的 IP アドレスを使用します。

  • 問題 2550625:クラスタを Manager からポリシーに移行した後、共有 IP プール内の IP アドレスが解放されない

    クラスタを Manager からポリシーに移行した後、ネームスペースを削除しても、そのネームスペースに割り当てられた IP アドレスが解放されません。

    回避策:なし。

  • 問題 2549765:複数の宛先ポートを含む NAT ルールがあると、Manager オブジェクトのポリシーへのインポートが失敗する

    複数の宛先ポートを含む NAT ルールが上位層のルーターに存在していると、Manager からポリシーへのインポートが失敗します。たとえば、NCP 構成で Kubernetes パラメータ ingress_mode が nat に設定され、Kubernetes に ncp/ingress-controller というアノテーションを含むポッドが存在する場合、このエラーが発生します。

    回避策:NCP が実行されていない場合は、インポートを開始する前に NAT ルールを編集し、宛先ポート「80」と「443」を削除します。

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

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

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

  • コンテナ IP アドレス ブロックが構成されていない場合、起動時に NCP でエラーが発生する

    完全にルーティングされている展開で、「SNAT IP ブロックなし」が構成されていてもコンテナ IP ブロックが構成されていないと、NCP 3.0.1 の起動時に「IndexError: list index from range」というエラーが発生します。

既知の問題

  • 問題 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 をインストールすると、ノードの状態が「準備完了」に変わります。

  • 問題 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 を使用して、以前の状態を手動でクリアします。

  • 問題 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 の過負荷状態を回避できます。

  • 問題 2552918:分散ファイアウォールで、クラスタのロールバックが失敗するため、Manager からポリシーへのインポートをロールバックできない

    まれですが、Manager からポリシーのインポート プロセスのロールバックが分散ファイアウォールのセクションとルールで失敗することがあります。これにより、クラスタのロールバックが失敗し、NSX Manager に古いリソースが残ります。

    回避策:バックアップとリストア機能を使用して NSX Manager を良好な状態に戻します。

  • 問題 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 に付与します。
    • ファイルへのログ出力機能を無効にします。
  • 問題 3033821:マネージャからポリシーへの移行後、分散ファイアウォール ルールが正しく適用されない

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

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

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