This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware NSX Container Plugin 3.1.2 | 2021 年 4 月 15 日 | ビルド 17855682

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

リリース ノートの概要

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

新機能

NSX Container Plugin (NCP) 3.1.2 には、以下の新しい機能が導入されています。
  • レイヤー 7 ロード バランサのパーシステンスで Cookie 名の指定をサポート

廃止のお知らせ

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

互換性の要件

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

注：

CentOS/RHEL に nsx-ovs カーネル モジュールをインストールするには、特定のカーネル バージョンが必要です。RHEL のバージョンに関係なく、サポートされる RHEL カーネル バージョンは 1127 および 1160 です。デフォルトのカーネル バージョンは 1127 (RHEL 7.8) と 1160 (RHEL 7.9) です。別のカーネル バージョンを実行している場合は、nsx-node-agent 構成マップの nsx_node_agent セクションで use_nsx_ovs_kernel_module を False に設定すると、nsx-ovs カーネル モジュールのインストールをスキップできます。

NCP 3.1.2 以降では、RHEL イメージは配布されません。サポートされている統合では、Red Hat Universal Base Image (UBI) を使用してください。詳細については、https://www.redhat.com/ja/blog/introducing-red-hat-universal-base-image を参照してください。

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

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

 

解決した問題

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

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

既知の問題

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

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

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

  • 問題 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 を超える空間に割り当てる TAS ASG（アプリケーション セキュリティ グループ）の処理に失敗する

    NSX-T 分散ファイアウォールの制限のため、NCP は 128 を超える空間に割り当てる TAS 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 で、[インベントリ] > [コンテナ] タブの順に移動すると、コンテナ関連のオブジェクトとその状態が表示されます。TKGI 環境で NSX-T を 3.0 にアップグレードすると、コンテナ関連のオブジェクトのネットワーク状態が「不明」と表示されます。この問題は、TKGI が 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（TKGI 展開の場合）または 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 クラスタが表示されません。この問題は通常、TKGI 環境で発生します。

    回避策：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 サーバへの要求がすべて失敗し、インストールを完了できません。

    回避策：なし

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

    nsx-node-agent ConfigMap で enable_hostport_snat を True に設定すると、Ubuntu ノードのネイティブ Kubernetes および TKGI で 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 の起動時に、ロード バランシング サーバの重複や、ロード バランサの Tier-1 論理ルーターが原因で、NCP が再起動したり、ロード バランサ サービスの初期化に失敗したりすることがあります。また、短い時間（1 秒未満）ですが、NCP の実行中に NSX エンドポイントが「停止」と報告される場合があります。ロード バランサの初期化に失敗すると、NCP ログに「Failed to initialize loadbalancer services」というメッセージが記録されます。 

    この動作は、NCP が複数の NSX Manager インスタンス間でクライアント側のロード バランシングを行っている場合にのみ発生します。ncp.ini で単一の API エンドポイントが構成されている場合は発生しません。

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

  • 問題 2745904：「デフォルトで実行中の ASG に IPset を使用する」機能で、既存のコンテナ IP ブロックの削除または置き換えがサポートされない

    NCP タイルで [デフォルトで実行中の ASG に IPset を使用する] を有効にすると、NCP は、同じ NCP タイルの [コンテナ ネットワークの IP ブロック] で構成されたコンテナ IP ブロックに専用の NSGroup を作成します。この NSGroup は、グローバルで実行中の ASG に作成されたファイアウォール ルールで使用され、すべてのコンテナのトラフィックが許可されます。既存のコンテナ IP ブロックを後で削除または置き換えると、NSGroup 内で削除または置き換えが行われます。元の IP ブロック内の既存のコンテナと実行中のグローバル ASG の関連付けが解除されます。このため、トラフィックが機能しなくなる可能性があります。

    回避策：[コンテナ ネットワークの IP ブロック] に新しい IP ブロックのみを追加します。

  • 問題 2744480：KVM で Kubernetes サービスのセルフ アクセスがサポートされない

    Kubernetes ポッドが、自身がエンドポイントとなっている Kubernetes サービスを介して自身にアクセスしようとすると、KVM ホストで応答パケットがドロップします。

    回避策：なし

  • 問題 2744361：nsx-node-agent ポッドが終了すると、静的 IP アドレスで構成された OpenShift のワークロード仮想マシンの接続が失われることがある

    nsx-node-agent ポッドが終了すると、静的 IP アドレスで構成された OpenShift のワークロード仮想マシンの接続が失われることがあります。

    回避策：仮想マシンを再起動します。

  • 問題 2746362：nsx-kube-proxy が Kubernetes apiserver から Kubernetes サービス イベントを受信できない

    OpenShift クラスタで、nsx-kube-proxy が Kubernetes apiserver から Kubernetes サービス イベントを受信できないことがあります。nsxcli -c get kube-proxy-watchers コマンドの出力に、「Watcher thread status: Up」が含まれていますが、「Number of events processed」は 0 になっています。これは、nsx-kube-proxy が apiserver からイベントを受信していないことを意味します。

    回避策：nsx-kube-proxy ポッドを再起動します。

  • 問題 2745907：monit コマンドを実行すると、nsx-node-agent について誤った状態情報が返される

    diego_cell 仮想マシンで monit を実行して nsx-node-agent を再起動したときに、nsx-node-agent が完全に起動するまでに 30 秒以上かかると、nsx-node-agent の状態が「Execution failed」と表示されます。nsx-node-agent が完全に機能するようになった場合でも状態が「running」に更新されません。

    回避策：なし。

  • 問題 2735244：稼動状態検証のエラーが原因で nsx-node-agent と nsx-kube-proxy がクラッシュする

    nsx-node-agent と nsx-kube-proxy は、sudo を使用して、いくつかのコマンドを実行します。/etc/resolv.conf に DNS サーバと検索ドメインに関するエントリが多数存在する場合、sudo はホスト名の解決に時間がかかる場合があります。これにより、nsx-node-agent と nsx-kube-proxy が sudo コマンドによって長時間ブロックされ、稼動状態検証が失敗します。

    回避策：次のいずれかのアクションを実行します。

    • /etc/hosts にホスト名エントリを追加します。たとえば、ホスト名が host1 の場合は、「127.0.0.1 host1」というエントリを追加します。
    • nsx-node-agent の稼動状態検証のタイムアウト値を大きくします。kubectl edit ds nsx-node-agent -n nsx-system コマンドを実行して、nsx-node-agent と nsx-kube-proxy コンテナの両方のタイムアウト値を更新します。
  • 問題 2744557：入力方向パスの照合で、キャプチャ グループ () と {0} の両方を含む複雑な正規表現パターンがサポートされない

    たとえば、正規表現 (regex) パターン/foo/bar/(abc){0,1} が /foo/bar/ と一致しません。

    回避策：入力方向の正規表現ルールを作成する場合に、キャプチャ グループ () と {0} を使用しません。/foo/bar/ と照合する場合は、通常のパターン EQUALS を使用します。

  • 問題 2751080：KVM ホストのアップグレード後に、コンテナ ホストで Kubernetes ポッドを実行できない

    KVM ホストのアップグレード後、アップグレードされたホストに展開されたコンテナ ホストで Kubernetes ポッドが実行されません。ポッドはコンテナの作成状態のままになります。NCP Operator が展開されている場合、ノードの状態が NotReady になることがあり、networkUnavailable ノード条件が True になります。この問題は RHEL でのみ発生し、Ubuntu では発生しません。

    回避策：KVM ハイパーバイザーで nsx-opsagent を再起動します。

  • 問題 2736412：max_allowed_virtual_servers が設定されていると、members_per_small_lbs パラメータが無視される

    max_allowed_virtual_servers と members_per_small_lbs の両方が設定されている場合、max_allowed_virtual_servers のみが考慮されるため、仮想サーバが使用可能なロード バランサに接続できないことがあります。

    回避策：自動スケーリングを有効にするのではなく、スケールの制約を緩和します。

  • 問題 2740552：api-server を使用して静的ポッドを削除するときに、nsx-node-agent はポッドの OVS ブリッジ ポートを削除せず、Kubernetes によって自動的に再作成される静的ポッドのネットワークが使用できなくなる

    Kubernetes では、api-server による静的ポッドの削除は許可されません。Kubernetes によって、静的ポッドのミラー ポッドが作成され、api-server で静的ポッドを検索できます。api-server でポッドを削除するときに、ミラー ポッドだけが削除され、NCP はポッドに割り当てられているすべての NSX リソースを削除する削除要求を受信して処理します。ただし、静的ポッドはまだ存在し、nsx-node-agent は、静的ポッドの OVS ブリッジ ポートを削除する削除要求を CNI から取得しません。 

    回避策：api-server によって静的ポッドを削除するのではなく、マニフェスト ファイルを削除して静的ポッドを削除します。

  • 問題 2795268：nsx-node-agent と hyperbus 間の接続が変更され、Kubernetes ポッドが作成状態で停止する

    大規模な環境で、nsx-node-agent が Kubernetes apiserver に接続できず、ポッド情報を取得できない場合があります。大量の情報が転送されたため、キープアリスト メッセージが hyperbus に送信されず、hyperbus が接続を終了します。

    回避策：nsx-node-agent を再起動します。Kubernetes apiserver が使用可能で、apiserver に接続するための証明書が正しいことを確認します。

  • 問題 2795482：ノード/ハイパーバイザーの再起動後、または他の操作の実行後に、実行中のポッドが ContainerCreating 状態で停止する

    wait_for_security_policy_sync フラグが true の場合、ワーカー ノードのハード リブート、ハイパーバイザーの再起動、またはその他の理由により、ポッドが実行状態を 1 時間以上継続した後、ContainerCreating 状態になることがあります。ポッドが作成状態を継続します。

    回避策：ポッドを削除して再作成します。

  • 問題 2871314：TKGI を 1.10.x から 1.11.x（1.11.6 より前）にアップグレードすると、NSX ロード バランサの Ingress 証明書が削除される

    NCP 3.1.1 以降では、証明書はリビジョン番号で追跡されます。このため、TKGI 1.10.x を TKG I 1.11.x（1.11.6 より前）にアップグレードすると、NSX ロード バランサの Ingress 証明書が削除され、再インポートされません。

    回避策：次のいずれかを実行します。

    1. NCP を再起動します。または
    2. Kubernetes 環境でシークレットを削除して、同じシークレットを再作成します。または
    3. TKGI を 1.11.6 以降にアップグレードします。
  • 問題 2871321：TKGI を 1.10.x から 1.11.x（1.11.6 より前）にアップグレードした後、CRD LoadBalancer が L7 Cookie パーシステンスを使用すると、IP アドレスが失われる

    この問題は、NSX ロード バランサで Cookie 名の更新をサポートする NCP 3.1.1 の新機能が原因で発生します。

    回避策：次のいずれかを実行します。

    1. Cookie パーシステンスではなく、送信元 IP のパーシステンスを使用します。
    2. TKGI を 1.11.6 以降にアップグレードします。
  • 問題 3033821：マネージャからポリシーへの移行後、分散ファイアウォール ルールが正しく適用されない

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

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

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