VMware NSX Container Plugin 3.0.0 | 2020 年 4 月 7 日 | ビルド 15841604

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

リリース ノートの概要

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

新機能

NSX Container Plugin (NCP) 3.0.0 は、vSphere with Kubernetes のユーザーのみを対象としたものです。他のすべての Kubernetes、Redhat、Pivotal ディストリビューションを使用している場合は、NSX Container Plugin 3.0.1 までお待ちください。
 
NSX Container Plugin 3.0.0 には、以下の新しい機能が導入されています。
  • ロード バランサ サービスのスケール制限を緩和するためのサポート。ポリシー API で、Kubernetes LoadBalancer サービスのロード バランサ サービスごとのプール メンバーの制限をサポート。
  • ポリシー API で、Kubernetes LoadBalancer サービスおよび Ingress の送信元 IP のホワイトリストへの登録をサポート。

互換性の要件

製品 バージョン
NSX-T 3.0.0
vSphere with Kubernetes 7.0

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

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

 

解決した問題

  • 問題 2370137:OVS データベース ファイルが /etc/openvswitch にないため、nsx-ovs および nsx-node-agent コンテナを実行できない

    nsx-ovs および nsx-node-agent コンテナは、起動時に /etc/openvswitch で OVS データベース ファイルを検索します。ディレクトリ内に実際の OVS ファイル(たとえば、conf.db)にリンクするシンボリック リンクが存在する場合、nsx-ovs および nsx-node-agent コンテナが実行されません。

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

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

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

既知の問題

  • 問題 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 分間待ってから再作成します。

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

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

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

  • 問題 2397438:再起動後、NCP が MultipleObjects エラーを報告する

    再起動の前に、ServerOverload エラーが原因で、NCP では、分散ファイアウォール セクションの作成に失敗しました。NCP は、最大試行回数に到達するまで再試行を行いました。ファイアウォール セクションは作成されています。再起動後、NCP は重複するファイアウォール セクションを受信し、MultipleObjects エラーを報告します。

    回避策:重複する古い分散ファイアウォール セクションを手動で削除し、NCP を再起動します。

  • 問題 2397684:NCP が正しいトランスポート ゾーンを検出しているにもかかわらず、「デフォルトのトランスポート ゾーンが構成されていません」というエラーが発生して、処理が失敗する

    ポリシー API ベースの NCP を使用して Kubernetes ネームスペースを作成すると、NSX-T に複数のオーバーレイ トランスポート ゾーンが存在するため、インフラストラクチャ セグメントの作成に失敗することがあります。この問題は、オーバーレイ トランスポート ゾーンがデフォルトとしてマークされていない場合に発生します。

    回避策:NCP ConfigMap で設定されているオーバーレイ トランスポート ゾーンを更新し、「is_default」フィールドを True に設定します。

  • 問題 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 のインストール エラー

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

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

  • 問題 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
      
  • 問題 2412421:Docker がコンテナの再起動に失敗する

    (1) ConfigMap が更新され、(2) コンテナが subPath を使用して ConfigMap をマウントし、(3) コンテナを再起動した場合、Docker がコンテナの起動に失敗します。

    回避策:DaemonSet がポッドを再作成できるようにポッドを削除します。

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

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

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

  • 問題 2410909:大規模環境で、特に多くのネットワーク ポリシーがある場合、再起動後に NCP がキャッシュを初期化し、新しいポッドとリソースの準備が完了するまでに 30 分ほどかかることがある

    再起動後、NCP が起動するまでに時間がかかることがあります。関連するリソースの量によっては、ポッド、ネームスペース、ネットワーク ポリシーなどのリソースの準備にさらに多くの時間がかかる場合があります。

    回避策:なし

  • 問題 2447127:NCP を 2.4.1 から 2.5.0 または 2.5.1 にアップグレードすると、NCP の起動に時間がかかる場合がある

    NCP 2.4.1 から 2.5.x へのアップグレードで、NCP がリーダーを選択するためにスイッチング プロファイル API を呼び出すと、NSX-T 2.4.1 の応答が遅くなることがあります。これにより、NCP の起動に数分かかる場合があります。

    回避策:なし。

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

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

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

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

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

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

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

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