RSS
 

VMware NSX Container Plugin 4.1.0 | 2023 年 2 月 28 日 | ビルド 21302845

各リリース ノートで、追加および更新された機能をご確認ください。

新機能

  • OpenShift 4.11 のサポートとさまざまなバグ修正。

廃止のお知らせ

ncp/ingress_controller アノテーションを使用して入力方向コントローラ ポッドへの NAT 経由のアクセスを許可する機能は廃止され、2023 年に削除される予定です。入力方向コントローラ ポッドを公開する場合は、LoadBalancer タイプのサービスを使用することをお勧めします。

互換性の要件

製品

バージョン

Tanzu Application Service (TAS) の NCP/NSX-T タイル

4.1

NSX

NSX 3.2.2、4.0.0.1、4.0.1.1、4.1

vSphere

6.7、7.0、8.0.0.1

Kubernetes

1.24、1.25、1.26

OpenShift 4

4.8、4.9、4.10

Kubernetes ホスト仮想マシン OS

Ubuntu 20.04

Ubuntu 22.04（アップストリーム OVS カーネル モジュールのみサポート）

RHEL：8.4、8.5、8.6

以下の注を参照。

Tanzu Application Service

Ops Manager 2.10 と TAS 2.11 (LTS)

Ops Manager 2.10 と TAS 2.13

Ops Manager 2.10 と TAS 3.0

Ops Manager 3.0 と TAS 3.0

Tanzu Kubernetes Grid Integrated (TKGI)

1.16

注：

RHEL に nsx-ovs カーネル モジュールをインストールするには、特定のカーネル バージョンが必要です。RHEL のバージョンに関係なく、サポートされる RHEL カーネル バージョンは 193、305、348、および 372 です。デフォルトのカーネル バージョンは 193 (RHEL 8.2)、305 (RHEL 8.4)、348 (RHEL 8.5)、372 (RHEL 8.6) です。別のカーネル バージョンを実行している場合は、次のいずれかを行うことができます。(1) カーネルバージョンをサポート対象のバージョンに変更する。カーネル バージョンを変更してから仮想マシンを再起動する場合は、Kubernetes API サーバとの接続が失われないようにするため、IP アドレスとスタティック ルートがアップリンク インターフェイス（ovs_uplink_port で指定）に保持されていることを確認します。(2) nsx-node-agent 構成マップの nsx_node_agent セクションで use_nsx_ovs_kernel_module を False に設定して、nsx-ovs カーネル モジュールのインストールをスキップする。NSX-OVS カーネル モジュールとアップストリーム OVS カーネル モジュールの切り替えの詳細については、https://docs.vmware.com/jp/VMware-NSX-Container-Plugin/4.1/ncp-kubernetes/GUID-7225DDCB-88CB-4A2D-83A3-74BB9ED7DCFF.html を参照してください。

RHEL で nsx-ovs カーネル モジュールを実行するには、vCenter Server の仮想マシン設定で [起動オプション] の [UEFI セキュア ブート] オプションを無効にする必要があります。

サポートされている統合では、Red Hat Universal Base Image (UBI) を使用してください。詳細については、https://www.redhat.com/ja/blog/introducing-red-hat-universal-base-image を参照してください。

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

  • 以前のすべての 4.0.x リリース

制限事項

  • NCP のベースライン ポリシー機能は、クラスタ内のすべてのメンバーを選択する動的グループを作成します。NSX-T には、動的グループの有効メンバー数が 8,000 までという制限があります（詳細については、構成の上限を参照してください）。そのため、ポット数が 8,000 を超えることが予想されるクラスタでは、この機能を有効にしないでください。この制限を超えると、ポッドのリソースの作成が遅延する可能性があります。

  • 透過モードのロード バランサ

    • Kubernetes クラスタの North-South トラフィックのみがサポートされます。クラスタ内トラフィックはサポートされません。

    • LoadBalancer CRD に接続されているサービスの場合、または自動スケーリングが有効になっている場合はサポートされません。この機能を使用するには、自動スケーリングを無効にする必要があります。

    • この機能は、新しく展開されたクラスタでのみ使用することをお勧めします。

  • マネージャからポリシーへの移行

    • 以前の移行が失敗し、クラスタがロールバックされた場合、Kubernetes クラスタを移行することはできません。これは、NSX 4.0.0.1 以前のリリースにのみ適用される制限です。

解決した問題

既知の問題

  • 問題 3113985：単一の Tier-1 トポロジを移行するときに、すべてのスタティック ルートが移行されない

    loadbalancers.vmware.com タイプの複数のカスタム リソースを含む単一の Tier-1 トポロジで、マネージャ モードの NCP でロード バランサ用に作成されたスタティック ルートの一部が移行されません。

    回避策：Kubernetes から loadbalancers.vmware.com タイプのカスタム リソースを削除した後、Manager API を使用してスタティック ルートを手動で削除します。スタティック ルートのタグに、範囲 ncp/crd_lb_uid のカスタム リソースの UID が含まれます。

  • 問題 3049209：マネージャからポリシーへの移行後、クラスタを削除しても mp_default_LR_xxx_user_rules リソースが削除されない

    マネージャからポリシーへの移行を実行してからクラスタを削除した後、mp_default_LR_xxx_user_rules という名前の一部の GatewayPolicy リソースが削除されないことがあります。

    回避策：リソースを手動で削除します。

  • 問題 3043496：マネージャからポリシーへの移行が失敗すると NCP が実行を停止する

    NCP には、NCP と TKGI で使用される NSX リソースを移行するための migrate-mp2p ジョブがあります。移行が失敗すると、移行されたすべてのリソースがロールバックされますが、NCP がマネージャ モードで再起動されません。

    回避策：

    1. すべてのリソースがロールバックされたことを確認します。これは、migrate-mp2p ジョブのログで確認できます。ログの最後に、「ポリシーにインポートされた管理プレーンリソースはすべて完全にロールバックされました」という行があるはずです。

    2. すべてのリソースがロールバックされている場合は、各マスター ノードに SSH で接続し、sudo /var/vcap/bosh/bin/monit start ncp コマンドを実行します。

  • 問題 3055618：ノードで複数の Windows ポッドを同時に作成すると、一部のポッドにネットワーク アダプタがない

    yaml ファイルを適用して同じノードに複数の Windows ポッドを作成すると、一部のポッドにネットワーク アダプタがありません。

    回避策：ポッドを再起動します。

  • 問題 2131494：Ingress のクラスを nginx から nsx に変更しても NGINX Kubernetes Ingress が動作を続ける

    NGINX Kubernetes Ingress の作成時、NGINX はトラフィック転送ルールを作成します。Ingress のクラスを他の値に変更すると、クラスの変更後に Kubernetes Ingress を削除しても、NGINX はルールを削除せずにルールの適用を継続します。これは NGINX の制限の 1 つです。

    回避策：NGINX が作成したルールを削除するには、クラスの値が nginx である Kubernetes Ingress を削除します。その後、再度 Kubernetes Ingress を作成します。

  • 問題 2999131：ポッドから ClusterIP サービスにアクセスできない

    大規模な TKGi 環境で、ポッドから ClusterIP サービスにアクセスできません。関連する他の問題は次のとおりです。(1) nsx-kube-proxy が nsx-kube-proxy のログの出力を停止する。(2) ノードで OVS フローが作成されない。

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

  • 問題 2984240：ネットワーク ポリシーのルールの namespaceSelector で matchExpressions の NotIn 演算子が機能しない

    ネットワーク ポリシーのルールを指定するときに、namespaceSelector、matchExpressions、NotIn 演算子を指定すると、ルールが機能しません。NCP ログに「NotIn operator is not supported in NS selectors.」というエラー メッセージが記録されます。

    回避策：NotIn 演算子を使用しないように matchExpressions を書き換えます。

  • 問題 2997828：Ingress に 255 個を超えるルールがあると、マネージャ モードからポリシー モードへのクラスタの移行に失敗する

    ポリシー モードでは、NSX ロード バランサは最大 255 個のルールをサポートできます。クラスタに 255 を超えるルールを持つ Ingress リソースがある場合、クラスタをマネージャ モードからポリシー モードに移行できません。

    回避策：LoadBalancer CRD を作成して、複数の NSX ロード バランサにルールを分散します。

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

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

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

  • タイプが ClusterIP の Kubernetes サービスの場合、ヘアピンモード フラグがサポートされない

    NSX Container Plugin (NCP) ではタイプが ClusterIP の Kubernetes サービスの場合、ヘアピンモード フラグがサポートされません。

    回避策：なし

  • 問題 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 が選択した場合、他のアプリケーションのワークフローが壊れることがあります。

    回避策：なし

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

  • 問題 2416376：NCP で、128 を超える空間に割り当てる TAS ASG（アプリケーション セキュリティ グループ）の処理に失敗する

    NSX-T 分散ファイアウォールの制限のため、NCP は 128 を超える空間に割り当てる TAS ASG を処理できません。

    回避策：複数の ASG を作成し、各 ASG を割り当てる空間を 128 以下にします。

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

  • 問題 2552564：OpenShift 4.3 環境で、重複するアドレスが見つかると DNS フォワーダが停止することがある

    OpenShift 4.3 環境でクラスタをインストールするには、DNS サーバが構成されている必要があります。NSX-T を使用して DNS フォワーダを設定するときに、DNS サービスと重複する IP アドレスが存在すると、DNS フォワーダが停止し、クラスタのインストールに失敗します。

    回避策：外部 DNS サービスを設定し、インストールに失敗したクラスタを削除して、クラスタを再作成します。

  • 問題 2597423：マネージャ オブジェクトをポリシーにインポートするときにロールバックすると、一部のリソースのタグがなくなる

    マネージャ オブジェクトをポリシーにインポートするときにロールバックを行うと、次のオブジェクトのタグはリストアされません。

    • Spoofguard プロファイル（共有リソースとクラスタ リソースの一部）

    • BgpneighbourConfig（共有リソースの一部）

    • BgpRoutingConfig（共有リソースの一部）

    • StaticRoute BfdPeer（共有リソースの一部）

    回避策：共有リソースに含まれるリソースの場合は、手動でタグをリストアします。クラスタ リソースに含まれるリソースをリストアする場合は、バックアップとリストア機能を使用します。

  • 問題 2579968：LoadBalancer タイプの Kubernetes サービスに対する変更が頻繁に発生すると、一部の仮想サーバとサーバ プールが正常に削除されない

    LoadBalancer タイプの Kubernetes サービスで頻繁に変更が行われているときに、仮想サーバとサーバ プールの削除を行うと、一部の仮想サーバとサーバ プールが NSX-T 環境に残ることがあります。

    回避策：NCP を再起動します。あるいは、古い仮想サーバとそれに関連付けられたリソースを手動で削除します。external_id タグに LoadBalancer タイプの Kubernetes サービスの 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 アドレスを追加することはできません。

  • 問題 2672677：OpenShift 4 環境の負荷が非常に高くなると、ノードが応答不能になる

    ノードあたりのポッドの集約度が高く、ポッドの削除および作成が頻繁に行われている OpenShift 4 環境で、RHCOS ノードが「準備未完了」の状態になることがあります。DaemonSet メンバーを除いて、影響を受けるノードで実行されているポッドは退去され、環境の他のノードで再作成されます。

    回避策：影響を受けるノードを再起動します。

  • 問題 2707174：ポッドを削除して同じネームスペースに再作成すると、ネットワークに接続できない

    NCP が実行されず、nsx-ncp-agents が実行されているときに、ポッドを削除して同じネームスペースに再作成すると、ポッドが誤ったネットワーク構成を取得し、ネットワークにアクセスできない場合があります。

    回避策：ポッドを削除し、NCP の実行中にポッドを再作成します。

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

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

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

  • 問題 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 コンテナの両方のタイムアウト値を更新します。

  • 問題 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 によって静的ポッドを削除するのではなく、マニフェスト ファイルを削除して静的ポッドを削除します。

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

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

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

  • 問題 2841030：Kubernetes 1.22 で、nsx-node-agent の状態が常に「AppArmor」になる

    Kubernetes 1.22 で、nsx-node-agent ポッドが「準備完了」になっても、状態が「AppArmor」から「実行中」に更新されません。これは、NCP または nsx-node-agent の機能に影響しません。

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

  • 問題 2824129：再起動後 3 分以上、ノードの状態 network-unavailable が true になる

    NCP operator を使用して NCP のライフサイクルを管理している場合、nsx-node-agent デーモンセットが非実行状態からリカバリすると、3 分間実行されるまでノードの状態 network-unavailable が true になります。これは、想定どおりの動作です。

    回避策：nsx-node-agent の再起動後、少なくとも 3 分間待機します。

  • 問題 2868572：NCP を実行する前に、ホスト仮想マシンで Open vSwitch (OVS) を無効にする必要がある

    ホスト仮想マシンに NCP を展開するには、最初に次のコマンドを使用して OVS 関連のプロセスを停止し、ホスト上の一部のファイルを削除する必要があります。

    1. sudo systemctl disable openvswitch-switch.service

    2. sudo systemctl stop openvswitch-switch.service

    3. rm -rf /var/run/openvswitch

    ホスト仮想マシンに NCP が展開済みで、OVS が正しく実行されていない場合は、次の手順でリカバリします。

    1. 上記の 3 つの手順を実行します。

    2. kubectl delete pod $agent-pod -n nsx-system コマンドを使用して、ノード エージェント ポッドの再起動に問題が発生しているノードの nsx-node-agent ポッドを削除します。

    回避策：上記を参照してください。

  • 問題 2832480：ClusterIP タイプの Kubernetes サービスの場合、sessionAffinityConfig.clientIP.timeoutSeconds に 65535 より大きい値を設定できない

    ClusterIP タイプの Kubernetes サービスの場合、sessionAffinityConfig.clientIP.timeoutSeconds を 65535 より大きい値に設定しても、実際の値は 65535 になります。

    回避策：なし

  • 問題：2940772：NSX-T 3.2.0 で NCP リソースをマネージャからポリシーに移行すると失敗する

    NSX-T 3.1.3 および NSX-T 3.2.1 では、NCP リソースをマネージャからポリシーに移行できますが、NSX-T 3.2.0 ではサポートされていません。

    回避策：なし

  • 問題 2934195：分散ファイアウォール ルールで、一部のタイプの NSX グループがサポートされない

    分散ファイアウォール (DFW) ルールで、タイプが「IP アドレスのみ」の NSX グループはサポートされていません。メンバーとして手動で追加された IP アドレスを持つ「汎用」タイプの NSX グループもサポートされていません。

    回避策：なし

  • 問題 2936436：NSX Manager のユーザー インターフェイスの [コンテナ クラスタ] ページに NCP のバージョンが表示されない

    NSX Manager のユーザー インターフェイスの [インベントリ] タブにコンテナ クラスタが表示されているときに、NCP バージョンが表示されません。

    回避策：NCP のバージョンを確認するには、API /policy/api/v1/fabric/container-clusters を呼び出します。

  • 問題 2939886：オブジェクトをマネージャ モードからポリシー モードに移行すると失敗する

    ネットワーク ポリシーの仕様で出力側と入力側に同じセレクタが設定されている場合、オブジェクトをマネージャ モードからポリシー モードに移行すると、移行に失敗します。

    回避策：なし

  • 問題：2961789：マネージャ オブジェクトをポリシーに移行した後、健全性チェック ポッドの関連リソースの一部を削除できない

    マネージャ オブジェクトをポリシーに移行した後、健全性チェック ポッドを削除しても、ポッド関連のセグメント ポートと分散ファイアウォール ルールのターゲット グループが削除されません。

    回避策：これらのリソースを手動で削除します。

  • 問題：2966586：マネージャ オブジェクトをポリシーに移行した後、ネームスペースの作成に失敗する

    マネージャ モードで IP ブロックを作成すると、マネージャ オブジェクトがポリシーに移行された後、NCP がこの IP ブロックからサブネットを割り当てることができないため、ネームスペースの作成に失敗します。

    回避策：ポリシー モードで新しい IP ブロックを作成し、これらの新しい IP ブロックを使用するように NCP を構成します。

  • 問題 2972811：大規模な環境で一部のワーカー ノードへの HyperBus 接続が停止する

    大規模な環境では、RPC チャネルのタイムアウトにより、ポッドの作成が 10 ～ 15 分間停止することがあります。次の問題が発生する可能性があります。

    • Kubernetes クラスタで、一部のポッドの状態が 10 ～ 15 分間 ContainerCreating になります。

    • cfgAgent で、トンネルの状態が 10 ～ 15 分間 COMMUNICATION_ERROR になります。

    • NSX ユーザー インターフェイスで、HyperBus 接続の停止を示すアラームが生成されることがあります。

    回避策：なし。この問題は、10 ～ 15 分後に自動的に回復します。

  • 問題 2960121：正しく構成していないと、LoadBalancer タイプのサービスで Windows ワーカー ノードのポッドに接続できない

    デフォルトの LB セグメント サブネットを使用するように NCP が構成されている場合、LoadBalancer タイプのサービスで、Windows ワーカー ノードのポッドに接続できません。デフォルトのサブネット 169.254.128.0/22 は IPv4 リンクローカル スペースに属し、Windows ノードでは転送されません。

    回避策：デフォルト以外の LB セグメント サブネットを使用するように NCP を構成します。これを行うには、nsx_v3 セクションでパラメータ lb_segment_subnet を設定します。これは、新しく作成された NSX ロード バランサでのみ有効です。

  • 問題 3088138：nsx-node-agent-config configmap で log_file を設定した後、nsx-node-agent ポッドが起動に失敗する

    nsx-node-agent-config configmap で log_file オプションを設定し、nsx-node-agent ポッドの前に nsx-ncp-bootstrap ポッドを再起動すると、nsx-node-agent ポッドの起動に失敗し、CrashLoopBackOff 状態になります。

    回避策：nsx-node-agent-config configmap で log_file オプションを設定した後、nsx-ncp-bootstrap ポッドを再起動する前に、nsx-node-agent ポッドを再起動します。

  • 問題 3091318：NCP が停止しているときに、ネームスペースの静的サブネットを更新した後、ポッドの作成に失敗する

    ncp/subnets が設定されたネームスペース（たとえば 172.70.0.0/29 に設定）を作成する際に、ネームスペースにポッドが作成されていない場合、NCP を停止して再起動した後に ncp/subnets を更新すると（たとえば 172.71.0.0/29 に更新）、ネームスペースでのポッドの作成に失敗し、ポッドが「ContainerCreating」状態で停止することがあります。

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

  • 問題 3082030：NSX cfgAgent サービスの再起動後に、Diego Cell でのアプリケーション インスタンスの展開に失敗する

    ハイパーバイザーで NSX cfgAgent サービスを再起動した後、Diego Cell で実行されている nsx-node-agent インスタンスが HyperBus 接続を拒否することがあります。その結果、Diego Cell でのアプリケーション インスタンスの展開に失敗します。Diego Cell の状態は良好のままです。Diego Cell の NSX-node-agent ログに、「nsx_ujo.agent.agent Agent is exiting as connection is unavailable.」などのログ メッセージが記録されます。ESXi ホストの NSX Syslog には、次のようなメッセージが記録されます。「[nsx@6876 comp="nsx-controller" subcomp="cfgAgent" s2comp="nsx-net" tid="XXXXXX" level="warn"] StreamConnection[YYY Connecting to tcp://169.254.1.XX:2345 sid:YYY] Couldn't connect to 'tcp://169.254.1.XX:2345' (error: 111-Connection refused).」

    回避策：

    1. 影響を受ける Diego Cell への SSH セッションを開き、monit restart nsx-node-agent コマンドを使用して nsx-node-agent サービスを再起動します。

    2. 影響を受ける Diego Cell を再構築します。

  • 問題 3066449：use_ip_blocks_in_order が True に設定されている場合、ネームスペース サブネットが、最初に使用可能な IP ブロックから割り当てられない場合がある

    use_ip_blocks_in_order が True に設定された複数のネームスペースを作成するときに、最初のネームスペースのサブネットが、最初に使用可能な IP ブロックから割り当てられていないことがあります。たとえば、container_ip_blocks = '172.52.0.0/28,172.53.0.0/28'、サブネット プレフィックス長 29、サブネット 172.52.0.0/29 がすでに割り当てられているとします。2 つのネームスペース ns-1 と ns-2 を作成すると、サブネットの割り当ては (1) ns-1 になります。172.52.0.8/29、ns-2：172.53.0.0/29 または (2) ns-1：172.53.0.0/29、ns-2：172.52.0.8/29。

    use_ip_blocks_in_order パラメータは、異なる IP ブロックが container_ip_blocks パラメータに指定された順序で使用されるようにします。複数のネームスペースを同時に作成するときに、任意のネームスペースが、別のネームスペースの前に API 呼び出しを介してサブネットを要求することがあります。したがって、特定のネームスペースに特定の IP ブロックからサブネットが割り当てられるという保証はありません。

    回避策：ネームスペースを個別に作成します。最初のネームスペースを作成し、サブネットが割り当てられていることを確認してから、次のネームスペースを作成します。

  • 問題 3110833：TKGI Windows ワーカー ノードでポッドを起動できず、状態が「ContainerCreating」になる

    Windows ワーカー ノードのすべてのノードが起動に失敗します。ノードの nsx-node-agent ログに次の項目が継続的に記録されます。「Failed to process cif config request with error [...].Restart node agent service to recover.」

    回避策：ノードで nsx-node-agent サービスを再起動します。

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