RSS
 

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