VMware NSX Container Plugin 3.0.1 | 2020 年 4 月 30 日 | ビルド 16118386

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

リリース ノートの概要

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

新機能

 
NSX Container Plugin 3.0.1 には、以下の新しい機能が導入されています。
  • IP アドレス管理と L3 接続、サービス クラスタの IP、IPv6 Kubernetes クラスタのロード バランシングをサポート
  • 1 つのポッドで複数インターフェイスをサポート(Multus と同様の機能)
  • OpenShift Container Platform (OCP) 4 のサポート
  • NCP configmap で DFW ルールのログ オプションを公開
  • NCP configmap で Tier-1 ルーターの設定を公開
  • NCP configmap でロード バランサの HTTP プロファイル構成(ヘッダー サイズとタイムアウト)を公開
  • ポリシー API にロード バランサの CRD サポートを追加
  • X-Forwarded ポートのサポート
  • SSL パススルー(SNI ベースのホスト スイッチング)と再暗号化
  • ネットワーク ポリシー コントローラのエラー レポート機能を向上
  • ポリシーへの Manager オブジェクトのインポートをサポート
  • コンテナ ワークロードのレイヤー 3 マルチキャスト サポート(単一階層の共有 Tier-0 トポロジのみ)
  • ポリシー モードの NCP 展開専用の YAML ファイル

互換性の要件

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

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

廃止のお知らせ:今後のリリースでは、OpenShift ベアメタルのサポートを廃止する予定です。

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

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

 

解決した問題

  • 問題 2330811:NCP の停止中に LoadBalancer タイプの Kubernetes サービスを作成すると、NCP の再起動後にサービスが作成できなことがある

    LoadBalancer タイプの Kubernetes サービスで使用可能な NSX-T リソースがなくなった場合、既存のサービスの一部を削除すると、新しいサービスを作成できます。ただし、NCP の停止中にサービスを削除して作成すると、NCP は新しいサービスを作成できなくなります。

    回避策:LoadBalancer タイプの Kubernetes サービスで使用可能な NSX-T リソースがなくなった場合、NCP の停止中に削除と作成の両方を行わないでください。

  • 問題 2408100:大規模な Kubernetes クラスタで、複数の NCP インスタンスがアクティブ/スタンバイ モードになっているか、稼動状態の検証が有効になっていると、NCP が頻繁に再起動する

    大規模な Kubernetes クラスタ(約 25,000 台のポッド、2,500 個のネームスペース、2,500 個のネットワーク ポリシー)で、複数の NCP インスタンスがアクティブ/スタンバイ モードで実行されているか、稼動状態の検証が有効になっていると、ロック取得の競合または稼動状態の検証エラーにより、NCP プロセスが強制終了され、頻繁に再起動することがあります。 

    回避策:次の手順を実行してください。

    1. NCP 展開の replicas を 1 に設定するか、ncp.ini の構成オプション ha.master_timeout にデフォルト値ではなく、18 ~ 30 の値を設定します。
    2. 次のように、稼動状態検証の引数を変更します。
        containers: 
          - name: nsx-ncp
            livenessProbe: 
              exec: 
                command: 
                  - /bin/sh
                  - -c
                  - timeout 20 check_pod_liveness nsx-ncp
              initialDelaySeconds: 20
              timeoutSeconds: 20
              periodSeconds: 20
              failureThreshold: 5
      
  • 問題 2517201:ESXi ホストでポッドを作成できない

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

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

既知の問題

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

  • 問題 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 をインストールできるようにします。

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

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

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

  • 問題 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 アドレスを使用します。

  • 問題 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 をアップグレードします。

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

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

    回避策:なし。

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

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

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

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

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

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

    回避策:バックアップとリストア機能を使用して 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 を再起動します。

  • 問題 2593017:NSX-T で古い論理ルーター ポートが削除されない

    マネージャ API を使用した 2 層トポロジでは、古い論理ルーター ポートが削除されない場合があります。古いルーター ポートの数が多い場合、ルーターの動作に影響を及ぼす可能性があります。

    回避策:NSX Manager から、古いルーター ポートを手動で削除します。

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

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

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

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