|
VMware NSX Container Plugin 3.1 | 2020 年 11 月 19 日 | ビルド 17170700 本ドキュメントの追加情報およびアップデート情報を定期的に確認してください。 |
リリース ノートの概要
このリリース ノートには、次のトピックが含まれています。
新機能
- Tanzu Application Service (TAS) 組織の SNAT IP アドレスを指定できるようになりました。
- Tanzu Kubernetes Grid Integrated (TKGI) のノード ローカル DNS キャッシュのサポート。
- 分散ファイアウォール ログに Kubernetes クラスタ ラベルを追加し、マルチテナント環境の Kubernetes クラスタのファイアウォール ログを区別できるようになりました。
- Tanzu を使用する vSphere で、スーパーバイザーのネームスペース トポロジごとに Tier-1 ルーターを有効にできます。
- コンテナ関連の機能に対する NSX ライセンスの適用をサポート。
互換性の要件
| 製品 | バージョン |
|---|---|
| Tanzu Application Service (PCF) の NCP/NSX-T タイル | 3.1 |
| NSX-T | 3.0.0、3.0.1、3.0.2、3.1.0、3.1.1 |
| vSphere | 6.7、7.0 |
| Kubernetes | 1.18、1.19 |
| OpenShift 3 | 3.11 注：今後のリリースで廃止される予定です。 |
| OpenShift 4 | RHCOS 4.4、4.5 |
| Kubernetes ホスト仮想マシン OS | Ubuntu 18.04、Ubuntu 20.04、CentOS 7.7、CentOS 7.8、CentOS 8.1、CentOS 8.2、RHEL 7.8、RHEL 8.1、RHEL 8.2 注：Ubuntu 20.04、RHEL/CentOS 7.8、8.1 の場合、nsx-ovs カーネル モジュールのインストールはサポートされません。アップストリーム OVS とのみ互換性があります。 |
| OpenShift ホスト仮想マシン OS | RHEL 7.7、RHEL 7.8 |
| Tanzu Application Service (Pivotal Cloud Foundry) | Ops Manager 2.7 と PAS 2.7 (LTS) Ops Manager 2.9 と PAS 2.9 Ops Manager 2.10 と PAS 2.10 |
| Tanzu Kubernetes Grid Integrated (TKGI) | 1.10 |
このリリースへのアップグレードのサポート：
- すべての NCP 3.0.x リリース
解決した問題
- 問題 2552918：分散ファイアウォールで、クラスタのロールバックが失敗するため、Manager からポリシーへのインポートをロールバックできない
まれですが、Manager からポリシーのインポート プロセスのロールバックが分散ファイアウォールのセクションとルールで失敗することがあります。これにより、クラスタのロールバックが失敗し、NSX Manager に古いリソースが残ります。
回避策：バックアップとリストア機能を使用して NSX Manager を良好な状態に戻します。
既知の問題
- 問題 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 をインストールすると、ノードの状態が「準備完了」に変わります。
- 問題 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 を超える空間に割り当てる 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 をアップグレードします。
- 問題 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 の過負荷状態を回避できます。
- 問題 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 を再起動します。
- 問題 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 クラスタが表示されません。この問題は通常、PKS 環境で発生します。
回避策：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 で DHCP 接続プロファイルを有効にしますが、これにより、NetworkManager で失敗した状態が継続する可能性があります。結果として、ovs_uplink_port または ovs_bridge の仮想マシンに IP（接続）が存在しません。
回避策：仮想マシンを再起動します。または、DHCP IP アドレスが正常に割り当てられるまで、しばらく待ちます。
- 問題 2671647：OVS デーモンの ovsdb-server と ovs-vswitchd で monit ジョブを再起動すると、OVS フローが失われる
monit restart <process-name> コマンドを使用して openvswitch デーモンの monit ジョブを再起動すると、nsx-node-agent が作成した OVS フローが失われます。
回避策：openvswitch デーモンが稼動状態に戻った後、monit restart nsx-node agent コマンドを使用して nsx-node-agent を再起動します。
- 問題 2672677：OpenShift 4 環境の負荷が非常に高くなると、ノードが応答不能になる
ノードあたりのポッドの集約度が高く、ポッドの削除および作成が頻繁に行われている OpenShift 4 環境で、RHCOS ノードが「準備未完了」の状態になることがあります。DaemonSet メンバーを除いて、影響を受けるノードで実行されているポッドは退去され、環境の他のノードで再作成されます。
回避策：影響を受けるノードを再起動します。
- 問題 2653241：Kubernetes のシークレットの証明書を更新できない
シークレットの証明書を更新しても、新しい証明書が NSX-T で更新されません。この問題は、マネージャとポリシーの両方のモードで発生します。
回避策：シークレットを削除し、更新された証明書を使用して新しいシークレットを作成します。
- 問題 2674503：nsx-ncp-bootstrap は、CentOS 7.8、8.1、8.2、または RHEL 7.8、8.1、8.2 での NSX OVS カーネル モジュールのインストールをサポートしていません。
nsx-ncp-bootstrap コンテナは、CentOS 7.8、8.1、8.2、または RHEL 7.8、8.1、8.2 での NSX OVS カーネル モジュールのインストールをサポートしていません。
回避策：NSX ノード エージェントの ConfigMap で、
use_nsx_ovs_kernel_moduleをFalseに設定し、Linux アップストリーム OVS カーネル モジュールを使用します。 - 問題 3033821：マネージャからポリシーへの移行後、分散ファイアウォール ルールが正しく適用されない
マネージャからポリシーへの移行後、新しく作成されたネットワーク ポリシー関連の分散ファイアウォール (DFW) ルールが、移行された DFW ルールよりも優先されます。
回避策：ポリシー API を使用して、必要に応じて DFW ルールの順序を変更します。
