VMware vSphere with Tanzu 8.0 リリースノート

リリースノートの概要

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

新機能
本リリースのインストールとアップグレード
既知の問題

新機能

2023 年 9 月 21 日時点での新機能
新機能 2023 年 7 月 27 日
新機能 2023 年 4 月 18 日
新機能 2023 年 3 月 30 日
新機能 2023 年 2 月 14 日
新機能 2022 年 12 月 15 日
新機能 2022 年 10 月 11 日

2023 年 9 月 21 日時点での新機能

VMware vSphere 8.0.2 \| 2023 年 9 月 21 日 ESXi 8.0.2 \| 2023 年 9 月 21 日 \| ビルド 22380479 vCenter Server 8.0.2 \| 2023 年 9 月 21 日 \| ビルド 22385739 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy Community Edition 2.2.2、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0.2 | 2023 年 9 月 21 日

ESXi 8.0.2 | 2023 年 9 月 21 日 | ビルド 22380479

vCenter Server 8.0.2 | 2023 年 9 月 21 日 | ビルド 22385739

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy Community Edition 2.2.2、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere with Tanzu 8.0 Update 2 には、次の新機能および機能強化が含まれています。

スーパーバイザー

仮想マシンサービスによる Windows OS、GPU、および従来の vSphere 仮想マシンで使用可能なその他すべてのオプションを持つ仮想マシンのサポート - 仮想マシンサービスは、vSphere 仮想マシンで現在サポートされている構成での仮想マシンの展開をサポートするようになりました。これにより、vSphere 上の従来の仮想マシン（ただしスーパーバイザー上の Infrastructure as a Service の一部として展開された仮想マシン）との完全な同等性を実現します。これには、Linux 仮想マシンと並行して Windows 仮想マシンをプロビジョニングするためのサポート、およびハードウェア、セキュリティ、デバイス、カスタムまたはマルチ NIC のサポート、および vSphere でサポートされるパススルーデバイスのサポートが含まれます。GPU を使用してワークロード仮想マシンをプロビジョニングし、AI/ML ワークロードをサポートできるようになりました。
仮想マシンイメージサービス - DevOps チーム、開発者、およびその他の仮想マシンユーザーは、仮想マシンイメージサービスを使用してセルフサービス方式で仮想マシンイメージを公開および管理できます。このサービスを使用すると、ユーザーはスーパーバイザー名前空間スコープのイメージレジストリ内の K8s API を使用してイメージを公開、変更、および削除できます。仮想マシンイメージサービスは、各 CCS リージョンと CCS プロジェクトで自動的に作成され、イメージレジストリへのイメージの追加は、ペルソナおよび使用レベル（グローバルレベルまたはプロジェクトレベル）によって範囲設定されます。イメージは、仮想マシンサービスを介した仮想マシンの展開に使用できます。
スーパーバイザー構成のインポートとエクスポート - 以前のバージョンでは、スーパーバイザーの有効化は、構成を保存する機能を使用せずに手動で段階的に行うプロセスでした。現在のリリースでは、スーパーバイザー構成の共有とエクスポートを、人間が解読可能な形式でピアと行ったり、またはソース制御システム内で行ったりすることや、新しいスーパーバイザーへの構成のインポート、および複数のスーパーバイザー間での標準構成のレプリケートが可能になりました。スーパーバイザー構成をエクスポートおよびインポートする方法の詳細については、こちらのドキュメントを確認してください。
フラグメンテーションの削減による GPU 使用率の向上 - ワークロード配置では GPU が認識されるようになり、DRS は同様のプロファイル要件を持つワークロードを同じホストに配置します。これにより、リソース使用率が向上し、必要なレベルのパフォーマンスを達成するために取得する必要がある GPU ハードウェアリソースの数が少なくなるため、コストが削減されます。
スーパーバイザーによる Kubernetes 1.26 のサポート - このリリースでは、Kubernetes 1.26 のサポートが追加され、Kubernetes 1.23 のサポートが削除されています。このリリースでサポートされている Kubernetes のバージョンは、1.26、1.25、および 1.24 です。Kubernetes バージョン 1.23 で実行されているスーパーバイザーは、バージョン 1.24 に自動的にアップグレードされます。これにより、すべてのスーパーバイザーがサポートされているバージョンの Kubernetes で実行されるようになります。
NSX ネットワークで構成されたスーパーバイザーでの NSX Advanced Load Balancer のサポート - L4 ロードバランシングに NSX Advanced Load Balancer (Avi Networks) を使用してスーパーバイザーを有効にできるほか、NSX ネットワークで構成されたスーパーバイザーと Tanzu Kubernetes Grid クラスタの制御プレーンノードでロードバランシングを有効にできます。NSX を使用した NSX Advanced Load Balancer の構成については、こちらのドキュメントページを確認してください。
Telegraf によるメトリックおよびイベントストリーミングのサポート - 組み込みの Telegraf バージョンと互換性のあるメトリックサービスにスーパーバイザーメトリックをプッシュするように、Kubernetes API を介して Telegraf を構成できるようになりました。Telegraf の構成については、こちらのドキュメントを参照してください。

スーパーバイザーの Tanzu Kubernetes Grid

vSphere 8.0 上の TKR の STIG コンプライアンス - vSphere U2 では、1.23.x 以降のすべての Tanzu Kubernetes Grid クラスタは STIG（セキュリティ技術実装ガイド）に準拠しており、例外に関するドキュメントが含まれています。ドキュメントはここで見つけることができます。これらの強化は、コンプライアンスプロセスの簡素化に向けた重要なステップを反映するもので、コンプライアンス要件を満たすことを簡素化し、米連邦のマーケットをはじめとする規制された業界で Tanzu Kubernetes Grid を迅速かつ信頼して使用できるようにします。
期限の近い証明書に対する制御プレーンのロールアウトの有効化 - ClusterClass に基づいて TKG クラスタをプロビジョニングするための v1beta1 API が更新され、クラスタでは制御プレーンノード仮想マシンの証明書の期限が切れる前に自動的に更新できます。この構成は、クラスタ仕様に変数として追加できます。詳細については、

「クラスタ v1beta1 API」を参照してください。
CSI スナップショットによる TKR のサポート - Tanzu Kubernetes リリース 1.26.5 以降でプロビジョニングされた TKG クラスタは CSI ボリュームスナップショットをサポートするため、データ保護の要件を満たすことができます。ボリュームスナップショットを使用すると、まったく新しいボリュームを作成することなく、特定の時点のボリュームのコンテンツを標準化された方法でコピーできます。
Tanzu パッケージのインストールと管理 - TKG クラスタに Tanzu パッケージをインストールして管理するための新しい統合リポジトリとドキュメントが提供されます。パッケージのすべてのニーズについては、『Installing and Using VMware Tanzu Packages』ドキュメントを参照してください。
カスタム ClusterClass の機能強化 - vSphere 8 U2 では、カスタム ClusterClass クラスタを実装するためのワークフローが簡素化されました。
TKG クラスタのローリングアップデート - vSphere 8 U2 にアップグレードする場合は、次のシナリオでプロビジョニングされた TKG クラスタのローリングアップデートを想定できます。
- 以前にリリースされた vSphere 8 バージョンから vSphere 8 U2 にアップグレードする場合は、次の理由が考えられます。
  - TKR の Kubernetes レベルの STIG の変更が ClusterClass の一部として vSphere 8 U2 に含まれている
  - 1.23 以降の TKG クラスタでは、v8.0 U2 との互換性を確保するためにローリングアップデートが実行される
- vSphere 7 バージョンから vSphere 8 U2 にアップグレードする場合は、次の理由が考えられます。
  - 基盤となる CAPI プロバイダを CAPW から CAPV に移動する
  - 既存のクラスタをクラスレス CAPI クラスタからクラスベースの CAPI クラスタに移行する必要がある

解決した問題

スーパーバイザー制御プレーン仮想マシンの /var/log/audit/ にある監査ログファイルが非常に大きなサイズになり、ルートディスクに空きがなくなることがあります。ジャーナルログには、この状態を示す「no space left on device」というエラーが記録されます。これにより、スーパーバイザー制御プレーン機能（kubernetes API など）が随所で動作しない可能性があります。

新機能 2023 年 7 月 27 日

VMware vSphere 8.0.1c \| 2023 年 7 月 27 日 ESXi 8.0.1c \| 2023 年 7 月 27 日 \| ビルド 22088125 vCenter Server 8.0.1c \| 2023 年 4 月 18 日 \| ビルド 22088981 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy Community Edition 2.2.2、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0.1c | 2023 年 7 月 27 日

ESXi 8.0.1c | 2023 年 7 月 27 日 | ビルド 22088125

vCenter Server 8.0.1c | 2023 年 4 月 18 日 | ビルド 22088981

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy Community Edition 2.2.2、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

新機能

スーパーバイザーによる Kubernetes 1.25 のサポート - このリリースでは、Kubernetes 1.25 のサポートが追加され、Kubernetes 1.22 のサポートが削除されています。
スーパーバイザーの Tanzu Kubernetes Grid 2.2.0 - スーパーバイザーの Tanzu Kubernetes Grid 2.2.0 クラスタを管理します。

サポート対象の Kubernetes バージョン

このリリースでサポートされている Kubernetes のバージョンは、1.25、1.24、および 1.23 です。Kubernetes バージョン 1.22 で実行されているスーパーバイザーは、バージョン 1.23 に自動的にアップグレードされます。これにより、すべてのスーパーバイザーがサポートされているバージョンの Kubernetes で実行されるようになります。

サポート

vRegistry 作成の廃止 -

組み込みの Harbor インスタンス vRegistry の作成は廃止されました。既存の vRegistry インスタンスは引き続き機能しますが、新しい vRegistry インスタンスの作成は廃止されました。

vRegistry 作成 API は廃止済みとしてマークされており、今後のリリースで新しい vRegistry インスタンスをデプロイする機能は削除される予定です。代わりに、パフォーマンスと機能強化の強化には、Harbor をスーパーバイザーサービスとして使用してコンテナイメージとリポジトリを管理することを推奨します。

既存の vRegistry をスーパーバイザーサービスとしての Harbor に移行するには、移行の詳細について「組み込みレジストリから Harbor へのイメージの移行」を参照してください。

解決した問題

新しいアラートメッセージが vSphere Client に表示され、スーパーバイザーまたは TKG クラスタ上の証明書が期限切れになることを警告します。アラートには、スーパーバイザーの名前や証明書の有効期限などの詳細情報が表示されます。また、影響を受ける証明書の置き換え方法の詳細について説明するナレッジベースの記事 KB90627 へのリンクも含まれています。

エラーまたは「No resources found」を返すコマンド kubectl get clustervirtualmachineimages。以前のバージョンでは、コマンド kubectl get clustervirtualmachineimages を使用するとエラーが発生していました。8.0 Update 1c にアップグレードした後は、コマンドによって次のメッセージが返ります：No resources found。仮想マシンイメージに関する情報を取得するには、代わりに次のコマンドを使用します： kubectl get virtualmachineimages
antrea-nsx-routed CNI は、vSphere with Tanzu 8.x リリースの v1alpha3 Tanzu Kubernetes クラスタでは動作しません。
v1beta1 クラスタでノードのドレインタイムアウトが正しく伝達されません。

新機能 2023 年 4 月 18 日

VMware vSphere 8.0.1 \| 2023 年 4 月 18 日 ESXi 8.0.1 \| 2023 年 4 月 18 日 \| ビルド 21495797 vCenter Server 8.0.1 \| 2023 年 4 月 18 日 \| ビルド 21560480 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy Community Edition 2.2.2、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

VMware vSphere 8.0.1 | 2023 年 4 月 18 日

ESXi 8.0.1 | 2023 年 4 月 18 日 | ビルド 21495797

vCenter Server 8.0.1 | 2023 年 4 月 18 日 | ビルド 21560480

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy Community Edition 2.2.2、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新機能

スーパーバイザー

スーパーバイザーサービスは、Distributed Switch ベースのスーパーバイザーで使用できるようになりました - 以前は、スーパーバイザーサービスの利用は NSX ベースのスーパーバイザーのみに制限されていました。現在のリリースでは、Harbor、Contour、S3 オブジェクトストレージ、および Velero Supervisor Services を Distributed Switch ベースのスーパーバイザーに展開できます。注：Distributed Switch ベースのスーパーバイザーのスーパーバイザーサービス機能を使用するには、ESXi を 8.0 U1 にアップデートする必要があります。
すべての Linux イメージに対する仮想マシンサービスのサポート - CloudInit を使用して、仮想マシンサービスのイメージ仕様に準拠した Linux イメージを OVF 形式でカスタマイズし、vAppConfig を介した OVF テンプレートを使用して、レガシー Linux イメージのデプロイが可能になりました。
仮想マシンサービス仮想マシンの Web コンソールサポート - 仮想マシンサービス仮想マシンをデプロイした後、DevOps エンジニアは kubectl CLI を使用してその仮想マシンに対する Web コンソールセッションを起動し、vSphere 管理者がゲスト仮想マシンにアクセスすることなく、ゲスト OS 内でトラブルシューティングとデバッグを有効にすることができます。
スーパーバイザーコンプライアンス - vSphere with Tanzu 8 スーパーバイザーリリースのセキュリティ技術実装ガイド (STIG)。詳細については、「Tanzu STIG Hardening」を参照してください。

スーパーバイザーの Tanzu Kubernetes Grid 2.0

カスタムクラスタクラス - スーパーバイザー上の TKG クラスタ用に独自のクラスタクラスを使用します。詳細については、https://kb.vmware.com/s/article/91826を参照してください。
TKG ノードのカスタムイメージ - vSphere TKG Image Builder（Ubuntu および Photon）を使用して独自のカスタムノードイメージを構築します。

注：v1alpha1 API で特定の TKR を使用するには、fullVersion を使用します。
新しい TKR イメージ：詳細については、Tanzu Kubernetes リリースノートを参照してください。

vSphere with Tanzu 8.0.0 GA ユーザーの重要な要件

注：この要件は、仮想マシンサービスを介してプロビジョニングされた仮想マシンに使用するコンテンツライブラリには適用されません。TKR コンテンツライブラリにのみ適用されます。

vSphere with Tanzu 8.0.0 GA をデプロイしている場合は、vSphere with Tanzu 8 U1 にアップグレードする前に、一時的な TKR コンテンツライブラリを作成して、TKG 2.0 TKr が既存のコンテンツライブラリにプッシュされたときに TKG コントローラポッドが CrashLoopBackoff に移行する既知の問題を回避する必要があります。この問題を回避するには、次の手順を実行します。

https://wp-content.vmware.com/v2/8.0.0/lib.json を参照する一時的なサブスクリプション URL を使用して、新しいサブスクライブ済みコンテンツライブラリを作成します。
一時コンテンツライブラリ内のすべてのアイテムを同期します。
一時コンテンツライブラリを TKG 2 クラスタをデプロイした各 vSphere 名前空間に関連付けます。
コマンド kubectl get tkr を実行し、すべての TKr が作成されていることを確認します。
この時点で、TKG コントローラは実行状態である必要があります。これは、スーパーバイザー名前空間内のポッドを一覧表示して確認できます。
TKG コントローラが CrashLoopBackOff (CLBO) 状態の場合は、次のコマンドを使用して TKG コントローラのデプロイを再起動します。

kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager
vSphere with Tanzu 8 Update 1 にアップグレードします。
各 vSphere 名前空間を更新して、元のサブスクライブ済みコンテンツライブラリ (https://wp-content.vmware.com/v2/latest/lib.json) を使用します。

解決した問題

v1beta1 API を使用してプロビジョニングされた Tanzu Kubernetes Grid 2.0 クラスタは、デフォルトの ClusterClass に基づいている必要がある

v1beta1 API を使用してスーパーバイザー上に Tanzu Kubernetes Grid 2.0 クラスタを作成する場合、クラスタはデフォルトの「tanzukubernetescluster」ClusterClass に基づいている必要があります。システムは、他の ClusterClass に基づいたクラスタを調整しません。

新機能 2023 年 3 月 30 日

ESXi 8.0.0c \| 2023 年 3 月 30 日 \| ビルド 21493926 vCenter Server 8.0.0c \| 2023 年 3 月 30 日 \| ビルド 21457384 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0.0c | 2023 年 3 月 30 日 | ビルド 21493926

vCenter Server 8.0.0c | 2023 年 3 月 30 日 | ビルド 21457384

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

解決した問題：

Harbor の安全でないデフォルト構成の問題

本リリースでは、Supervisor 7.0 または 8.0 で組み込みの Harbor レジストリを有効にしている場合に発生する Harbor の安全でないデフォルト構成の問題が解決されています。

本バージョン vCenter Server 8.0.0c で解決されています。この問題の詳細と、このリリースのインストールまたは一時的な回避策の適用によって問題に対処する方法については、VMware ナレッジベースの記事 KB91452を参照してください。
vCenter Server 8.0b へのアップグレード後、スーパーバイザークラスタと TKG クラスタへのログインが失敗する

vCenter Server 8.0b で実行されるコンポーネントは、以前のリリースの vCenter Server を使用してデプロイされたスーパーバイザーと後方互換性がありません。

回避策：vCenter Server を新しいバージョンにアップグレードするか、デプロイされているすべてのスーパーバイザーをアップグレードします。

新機能 2023 年 2 月 14 日

ESXi 8.0.0b \| 2023 年 2 月 14 日 \| ビルド 21203435 vCenter Server 8.0.0b \| 2023 年 2 月 14 日 \| ISO ビルド 21216066 VMware NSX Advanced Load Balancer avi-22.1.1-9052 \| 2022 年 7 月 15 日 HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0.0b | 2023 年 2 月 14 日 | ビルド 21203435

vCenter Server 8.0.0b | 2023 年 2 月 14 日 | ISO ビルド 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022 年 7 月 15 日

HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新機能：

Cert-Manager CA クラスタ発行者のサポートの追加 - 管理者はスーパーバイザーにおいてスーパーバイザーサービスとしてクラスタスコープの CA 発行者を定義してデプロイできるようになります。クラスタスコープの CA 発行者をデプロイすると、スーパーバイザー名前空間の利用者は CA 発行者が署名した証明書を要求および管理できます。

本リリースでは、この新機能のほかにバグ修正が提供されます。

解決した問題：

スーパーバイザー制御プレーン仮想マシンのルートディスクに空きがなくなる

スーパーバイザー制御プレーン仮想マシンの /var/log/audit/ にある監査ログファイルが非常に大きなサイズになり、ルートディスクに空きがなくなることがあります。ジャーナルログには、この状態を示す「no space left on device」というエラーが記録されます。これにより、スーパーバイザー制御プレーン機能（kubernetes API など）が随所で動作しない可能性があります。

本バージョン vSphere 8.0.0b で解決されました。

新機能 2022 年 12 月 15 日

ESXi 8.0 \| 2022 年 10 月 11 日 \| ビルド 20513097 vCenter Server 8.0.0a \| 2022 年 12 月 15 日 \| ビルド 20920323 VMware NSX Advanced Load Balancer avi-22.1.1-9052 \| 2022 年 7 月 15 日 HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0 | 2022 年 10 月 11 日 | ビルド 20513097

vCenter Server 8.0.0a | 2022 年 12 月 15 日 | ビルド 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022 年 7 月 15 日

HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新機能

スーパーバイザーサービスとしての Harbor の追加 - スーパーバイザーで実行される、機能をすべて備えた Harbor（OCI イメージレジストリ）インスタンスを提供します。Harbor インスタンスを使用すると、Harbor 管理者はプロジェクトとユーザーを作成/管理したり、イメージスキャンを設定したりできます。
vRegistry の廃止 - vRegistry と呼ばれる組み込みの Harbor インスタンスは、今後のリリースで削除される予定です。代わりに、Harbor をスーパーバイザーサービスとして使用できます。移行の詳細については、Migrate Images from the Embedded Registry to Harborを参照してください。
スーパーバイザークラスタによる Kubernetes 1.24 のサポート - このリリースでは、Kubernetes 1.24 のサポートが追加され、Kubernetes 1.21 のサポートが削除されます。このリリースでサポートされている Kubernetes のバージョンは、1.24、1.23、および 1.22 です。Kubernetes バージョン 1.21 で実行されているスーパーバイザークラスタは、バージョン 1.22 に自動的にアップグレードされます。これにより、すべてのスーパーバイザークラスタがサポートされているバージョンで実行されるようになります。
vSphere Zone API - vSphere Zone は、可用性の高いスーパーバイザークラスタと Tanzu Kubernetes クラスタを作成するために、アベイラビリティゾーンを vSphere クラスタに割り当てることができるようにする構造です。vSphere 8.0 では、vSphere Client から vSphere Zone 機能を作成および管理できていました。vSphere 8.0.0a リリースでは、ユーザーが DCLI または vSphere Client API Explorer を使用して、vSphere Zone を作成および管理できます。SDK バインドの完全なサポート（Java、Python など）については、今後のリリースで対応する予定です。

アップグレードに関する考慮事項：

Tanzu Kubernetes クラスタのローリングアップデートは、次に示すスーパーバイザーのアップグレードシナリオで発生します。
- 8.0 から 8.0.0a にアップグレードした後で、スーパーバイザーを任意の Kubernetes リリースからスーパーバイザー Kubernetes 1.24 にアップグレードし、次に示すいずれかの条件を満たした場合。
  - Tanzu Kubernetes クラスタで、空ではない noProxy リストを含むプロキシ設定を使用している場合
  - スーパーバイザーで vRegistry が有効になっている場合。この設定は、NSX ベースのスーパーバイザーでのみ使用できます。
- vSphere 7.0 リリースから vSphere 8.0.0a にアップグレードする場合。

解決した問題：

vSphere 8 では、Tanzu 8 ライセンスキーではなく Tanzu 7 ライセンスキーがサポートされる

vCenter 8.0 では、Tanzu 8 ライセンスキーではなく Tanzu 7 ライセンスキーがサポートされます。この問題の有無に関係なく、vCenter Server 8.0 では Tanzu の機能を完全に使用できます。vCenter Server 8.0 のデプロイで Tanzu ライセンスを変更するには、事前に VMware ナレッジベースの記事KB89839で詳細を確認してください。
NSX-ALB に 2 つの SE グループが存在する場合に LoadBalancer とゲストクラスタが作成されない

SE または仮想サービスが割り当てられているかどうかにかかわらず、2 つ目の SE グループが NSX-ALB に追加されると、新しいスーパーバイザークラスタまたはゲストクラスタの作成に失敗し、既存のスーパーバイザークラスタをアップグレードできません。NSX-ALB コントローラでの仮想サービスの作成に失敗して、次のエラーが表示されます。
```
get() returned more than one ServiceEngineGroup – it returned 2
```
その結果、新しいロードバランサを使用できず、新しいワークロードクラスタを正常に作成できません。詳細については、VMware ナレッジベースの記事KB90386を参照してください。

新機能 2022 年 10 月 11 日

VMware vSphere 8.0 \| 2022 年 10 月 11 日 ESXi 8.0 \| 2022 年 10 月 11 日 \| ビルド 20513097 vCenter Server 8.0 \| 2022 年 10 月 11 日 \| ビルド 20519528 VMware NSX Advanced Load Balancer 21.1.4 \| 2022 年 4 月 7 日 HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

VMware vSphere 8.0 | 2022 年 10 月 11 日

ESXi 8.0 | 2022 年 10 月 11 日 | ビルド 20513097

vCenter Server 8.0 | 2022 年 10 月 11 日 | ビルド 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 2022 年 4 月 7 日

HAProxy 2.2.2 Community Edition、データプレーン API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

vSphere with Tanzu 8.0 には、次の新機能および機能強化が含まれています。

ワークロード管理構成の監視 - スーパーバイザーの有効化、無効化、およびアップグレードのステータスをより詳細に追跡できるようになりました。スーパーバイザーの有効化、無効化、またはアップグレードを開始すると、スーパーバイザーは、制御プレーン仮想マシンなどの各コンポーネントに関連付けられたさまざまな条件に到達することで、目的の状態への到達を試行します。各条件のステータスの追跡、関連する警告の表示、ステータスの再試行、到達した条件およびそのタイムスタンプの表示を行うことができます。
vSphere Zones - vSphere Zone は、アベイラビリティゾーンを vSphere クラスタに割り当てることができるようにする新しい構造です。複数の vSphere Zone にスーパーバイザーをデプロイすると、特定のアベイラビリティゾーンおよび障害ドメインに Tanzu Kubernetes Grid クラスタをプロビジョニングできます。これにより、複数のクラスタにわたってワークロードを実行することができ、ハードウェアとソフトウェアの障害に対する回復性が向上します。
マルチクラスタスーパーバイザー - vSphere Zone を使用すると、スーパーバイザーを複数の vSphere クラスタにわたってデプロイし、Tanzu Kubernetes Grid クラスタに高可用性と障害ドメインを提供できます。vSphere クラスタを別の vSphere Zone に追加し、複数の vSphere Zone にまたがるスーパーバイザーを有効にすることができます。これにより、ローカライズされたハードウェアおよびソフトウェアの障害に対するフェイルオーバーと回復性が提供されます。ゾーンまたは vSphere クラスタがオフラインになると、スーパーバイザーが障害を検出し、別の vSphere Zone でワークロードを再開します。遅延の最大値を超えない距離を範囲とする環境であれば、vSphere Zone を使用することができます。遅延要件の詳細については、「ゾーンスーパーバイザーのデプロイの要件」を参照してください。
スーパーバイザーによる Kubernetes 1.23 のサポート - このリリースでは、Kubernetes 1.23 のサポートが追加され、Kubernetes 1.20 のサポートが削除されています。このリリースでサポートされている Kubernetes のバージョンは、1.23、1.22、および 1.21 です。Kubernetes バージョン 1.20 で実行されているスーパーバイザーは、バージョン 1.21 に自動的にアップグレードされます。これにより、すべてのスーパーバイザーがサポートされているバージョンの Kubernetes で実行されるようになります。
SecurityPolicy CRD による一貫したネットワークポリシーの提供 - SecurityPolicy カスタムリソース定義では、スーパーバイザー名前空間内の仮想マシンと vSphere Pod のネットワークセキュリティ制御を構成できます。
スーパーバイザーの Tanzu Kubernetes Grid 2.0 - Tanzu Kubernetes Grid がバージョン 2.0 に移行されました。Tanzu Kubernetes Grid 2.0 は、Tanzu および Kubernetes コミュニティにおける大きな技術革新の極致で、Tanzu Kubernetes Grid を使用してプライベートクラウドとパブリッククラウドを操作する場合の共通のインターフェイスセットの基盤となります。このリリースの新機能に、次の 2 つの主要機能があります。
- ClusterClass - Tanzu Kubernetes Grid 2.0 で ClusterClass がサポートされるようになりました。ClusterClass はアップストリームに合わせたインターフェイスを提供し、Tanzu Kubernetes Grid プラットフォームにカスタマイズ機能を提供する Tanzu Kubernetes クラスタの代わりに使用されます。ClusterClass を使用すると、管理者はエンタープライズ環境の要件を満たすテンプレートを定義する一方で、ボイラープレートを減らし、委任されたカスタマイズを実行できます。
- Carvel - Carvel では、アプリケーションの構築、構成、Kubernetes へのデプロイを支援する、信頼性の高い、単一用途の構成可能なツールセットが提供されます。特に、kapp および kapp-controller は、アップストリームに合わせた宣言型ツールのセットを介して、パッケージの管理、互換性、およびライフサイクルの機能を提供します。テンプレート化を行う ytt と組み合わせることで、柔軟で管理しやすいパッケージ管理機能が実現します。
vSphere 8 の新しいドキュメント構造と Web ページ - vSphere with Tanzu ドキュメントの構造が改善されました。これにより、製品を使用したワークフローがより適切に反映され、有用なコンテンツを確認できるようになりました。また、新しいドキュメントの Web ページから、利用可能な vSphere with Tanzu のすべての技術ドキュメントにアクセスすることもできます。

本リリースのインストールとアップグレード

vSphere with Tanzu のインストールと構成のガイダンスについては、vSphere with Tanzu のインストールと構成ドキュメントを参照してください。vSphere with Tanzu の更新の詳細については、vSphere with Tanzu のメンテナンスドキュメントを参照してください。

アップグレードを実行する場合は、次の点に注意してください。

vCenter Server 8.0 に更新する前に、すべてのスーパーバイザーの Kubernetes バージョンが 1.21 以上（できればサポートされている最新バージョン）であることを確認します。Tanzu Kubernetes Grid クラスタの Tanzu Kubernetes リリースバージョンは 1.21（できればサポートされている最新バージョン）である必要があります。
vSphere with Tanzu 8.0 MP1 リリース以降では、レガシー TKGS TKr から TKG 2 TKr にアップグレードできます。サポートされているバージョンのマトリックスについては、Tanzu Kuberentes releases Release Notesを参照してください。アップグレード情報については、vSphere with Tanzu での Tanzu Kubernetes Grid 2 の使用ドキュメントを参照してください。

スーパーバイザーに関する既知の問題

スーパーバイザーの自動アップグレード中に、vSphere の WCP サービスプロセスがパニック状態になり、予期せず停止する場合がある

WCP サービスプロセス用に生成されたコアダンプファイルを確認できます。

回避策：なし。VMON プロセスによって WCP サービスが自動的に再起動され、WCP サービスはその他の問題なくアップグレードを再開します。
vSphere ポッドで、スーパーバイザーのアップグレードが ErrImagePull およびプロバイダ失敗ステータスでサスペンドされる。ErrImagePull の失敗時に、vSphere ポッド（スーパーバイザーサービスを含む）に接続されたパーシステントボリュームが分離されない場合があります。

ErrImagePull で失敗する vSphere ポッドの場合、パーシステントボリュームが分離されない可能性があります。これにより、失敗した vSphere ポッドのカスケードが発生する可能性があります。この問題が発生するのは、必要なパーシステントボリュームが失敗したインスタンスに接続されているためです。スーパーバイザーのアップグレードで、スーパーバイザー内の vSphere ポッドが「provider failed」状態に移行し、応答しなくなることがあります。

回避策：パーシステントボリュームが接続されている失敗した vSphere ポッドのインスタンスを削除します。vSphere ポッドに関連付けられているパーシステントボリュームの要求 (PVC) とパーシステントボリュームを保持できることに注意してください。アップグレードが完了したら、同じ PodSpecPVC を使用して vSphere ポッドを再作成し、データの整合性と機能を維持します。この問題を軽減するには、ReplicaSet（DaemonSet、デプロイ）を使用して vSphere ポッドを作成し、常に実行されているレプリカ vSphere ポッドの安定したセットを維持します。
スーパーバイザーのアップグレードが 50% で停止し、リーダーの選出が原因で Pinniped のアップグレードに失敗する

Pinniped ポッドがロールアウト中に保留状態のままになり、Pinniped コンポーネントのアップグレードでスーパーバイザーのアップグレードが失敗します。
回避策の手順は次のとおりです。
1. kubectl get pods -n vmware-system-pinniped を実行して、Pinniped ポッドのステータスを確認します。
2. kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml を実行して、holderIdentity が保留状態の Pinniped ポッドのいずれでもないことを確認します。
3. kubectl delete leases -n vmware-system-pinniped pinniped-supervisor を実行して、holderIdentity としてデッドポッドを持つ pinniped-supervisor のリースオブジェクトを削除します。
4. kubectl get pods -n vmware-system-pinniped を再度実行して、vmware-system-pinniped のすべてのポッドが実行中であることを確認します。
スーパーバイザー制御プレーン仮想マシンがパワーオン状態の場合、ESXi ホストノードをメンテナンスモードに切り替えることができない

NSX Advanced Load Balancer を使用したスーパーバイザーのセットアップで、パワーオン状態の Avi サービスエンジン仮想マシンがあると、ESXi ホストをメンテナンスモードに切り替えることができません。これは、メンテナンスモードでの ESXi ホストのアップグレードと NSX のアップグレードに影響します。

回避策：Avi サービスエンジン仮想マシンをパワーオフして、ESXi をメンテナンスモードに切り替えることができます。
VDIS 上の vSphere ポッドで ClusterIP を使用してループバックトラフィックを受信できない

vSphere ポッド内のアプリケーションが、別のコンテナにある同じ vSphere ポッド内で提供される ClusterIP に到達すると、VSIP 内の DLB はトラフィックを元の vSphere ポッドに再度ルーティングすることができません。

回避策：なし。
ネットワークポリシーが Distributed Switch ベースのスーパーバイザーに適用されない

NetworkPolicy を使用する既存のサービス YAML では、変更は必要ありません。ファイルに NetworkPolicy が存在する場合、適用されません。

回避策：Distributed Switch のネットワークにはポリシーベースのルールを設定する必要があります。ネットワークポリシーのサポートには、NSX ネットワークのサポートが必要です。
スーパーバイザーから Carvel サービスをアンインストールした後も、サービスの名前空間が vSphere Client に表示され続ける場合がある

Carvel サービスがスーパーバイザーからのアンインストールに 20 分以上を要した場合、サービスのアンインストール後も名前空間が vSphere Client に表示されることがあります。

名前空間が削除されるまで、同じスーパーバイザーにサービスを再インストールすると失敗します。また、再インストール時に ns_already_exist_error メッセージが表示されます。

ログファイルには次のエントリが記録されます。

/var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"
回避策：名前空間を vSphere Client から手動で削除します。
1. vSphere Client のホームメニューから、[ワークロード管理] を選択します。
2. 名前空間 タブをクリックします。
3. 名前空間のリストから、不明な名前空間を選択し、削除ボタンをクリックして名前空間を削除します。
スーパーバイザーをアップグレードせずに ESXi ホストを 7.0 Update 3 から 8.0 にアップグレードすると、ESXi ホストに「準備ができていません」と表示され、ワークロードがオフラインになる

スーパーバイザーに属している ESXi ホストを vSphere 7.0 Update 3 から vSphere 8.0 にアップグレードする一方で、スーパーバイザーの Kubernetes バージョンをアップグレードしなかった場合、ESXi ホストに「準備ができていません」と表示され、ホストで実行されているワークロードがオフラインになります。

回避策：スーパーバイザーの Kubernetes バージョンを 1.21、1.22、または 1.23 以降にアップグレードします。
vCenter Server のワンクリックアップグレードを実行しても、スーパーバイザーが自動的にアップグレードされない

スーパーバイザーの Kubernetes バージョンが 1.22 より前である場合は、vCenter Server を 8.0 にワンクリックでアップグレードするときに、スーパーバイザーを 8.0 でサポートされている最小の Kubernetes バージョン (1.23) に自動的にアップグレードすることはできません。

回避策：vCenter Server を 8.0 にアップグレードする前に、スーパーバイザーの Kubernetes バージョンを 1.22 にアップグレードします。vCenter Server を 8.0 にすでにアップグレードしている場合は、スーパーバイザーの Kubernetes バージョンを 1.23 に手動でアップグレードします。
セキュリティポリシーのカスタムリソースでルールを変更したときに、古いルールが削除されないことがある

この問題は、セキュリティポリシーを更新するときに発生する可能性があります。たとえば、ルール A と B を含むセキュリティポリシーのカスタムリソースを作成した後に、ポリシーを更新してルールを B および C に変更しても、ルール A が削除されることはありません。NSX 管理プレーンには、B と C に加えて、ルール A が引き続き表示されます。

回避策：セキュリティポリシーを削除してから、同じポリシーを作成します。
vCenter Server と vSphere with Tanzu のアップグレード後、クラスタのノードに接続されていると表示されるボリュームが原因で、Tanzu Kubernetes Grid クラスタがアップグレードを完了できない

Tanzu Kubernetes Grid クラスタのアップグレードに失敗すると、ボリュームがクラスタのノードに接続されていると表示され、クリアされないことがあります。この問題は、アップストリーム Kubernetes の問題が原因で発生する可能性があります。
回避策：
1. 次のコマンドを使用して、スケジュール設定が無効になっている TKG クラスタノードに関する情報を取得します。
  
  kubectl get node tkc_node_name -o yaml
  
  例：
```
# kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
```
  status.volumeAttached プロパティで、このノードに vSphere CSI ボリュームがあるかどうかを確認します。ボリュームがある場合は、次の手順に進みます。
2. 手順 1 で特定したノードでポッドが実行されていないことを確認します。次のコマンドを使用します。
  
  kubectl get pod -o wide | grep tkc_node_name
  
  例：
```
kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
```
  このコマンドの出力が空の場合は、ポッドがないことを示します。手順 1 の出力には、ポッドがないノードに接続されているボリュームが表示されているため、次の手順に進みます。
3. すべてのノードオブジェクトに関する情報を取得して、同じボリュームが別のノードに接続されていることを確認します。
  
  kubectl get node -o yaml
  
  例：
  
  同じボリューム名が 2 つの TKG クラスタノードオブジェクトに表示されます。
```
On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...
```
4. ボリューム名のボリュームハンドルに基づいて PV を検索します。
  
  上記の例では、ボリューム名は kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd です。ボリュームハンドルは 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd です。
  
  次のコマンドを使用して、すべての PV を取得し、上記のボリュームハンドルを検索します。
  
  kubectl get pv -o yaml
  
  上記の例では、そのボリュームハンドルを使用する PV は pvc-59c73cea-4b75-407d-8207-21a9a25f72fd です。
5. volumeattachment コマンドを使用して、前の手順で見つかった PV を検索します。
  
  kubectl get volumeattachment | grep pv_name
  
  例：
```
# kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h
```
  ノード gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 ではなく、ノード gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 に接続されているボリューム接続を確認できます。これは、gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 の status.volumeAttached が正しくないことを示します。
6. 古い volumeAttached エントリをノードオブジェクトから削除します。
  
  kubectl edit node tkc_node_name
  
  例：
  
  kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
  
  古いボリュームエントリを status.volumeAttached から削除します。
7. status.volumeAttached プロパティで、すべての古いボリュームに対して上記の手順を繰り返します。
8. WCPMachines がまだ存在する場合は手動で削除し、数分間待ってからクラスタを調整します。
```
# kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted
```
クラスタのキャパシティを超えるリソース制限を持つセルフサービス名前空間テンプレートを vSphere 管理者が構成すると、アラートがトリガされない.

vSphere 管理者がクラスタのキャパシティを超えるリソースの制限を構成すると、DevOps エンジニアはそのテンプレートを使用して、リソースの多い vSphere Pod をデプロイする場合があります。その結果、ワークロードが失敗することがあります。

回避策：なし
Tanzu Kubernetes Grid クラスタを含むスーパーバイザー名前空間を削除すると、スーパーバイザー内のパーシステントボリュームの要求が終了中の状態のままになる場合がある

この問題が生じるのは、システムが名前空間を削除して、Tanzu Kubernetes Grid クラスタ内のポッドからボリュームを分離するときにリソースの競合が発生した場合です。

スーパーバイザー名前空間の削除は不完全なままになり、vSphere Client では名前空間が終了中の状態と表示されます。Tanzu Kubernetes Grid クラスタ内のポッドに関連付けられたパーシステントボリュームの要求も終了中の状態のままになります。

次のコマンドを実行すると、「Operation cannot be fulfilled on persistentvolumeclaims」というエラーが表示されます。

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

failed to update PersistentVolumeClaim: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\".Error: Operation cannot be fulfilled on persistentvolumeclaims \\\"<pvc-name>\\\": the object has been modified; please apply your changes to the latest version and try again\

回避策：

次のコマンドを使用して、問題を修正します。

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge
vSAN などの共有データストアから複数の FCD とボリュームを削除すると、パフォーマンスが変化する場合がある

このパフォーマンスの変化は、修正された問題が原因で発生する可能性があります。この問題が未修正の状態では、FCD の削除操作が失敗した後に、古い FCD とボリュームがデータストアに残っていました。

回避策：なし。パフォーマンスの変化に関係なく、通常どおりに削除操作を実行できます。
vCenter Server の再起動中に DevOps ユーザーがボリューム操作またはステートフルアプリケーションのデプロイを開始すると、操作が失敗することがある

この問題は、ワークロードストレージ管理ユーザーアカウントがロックされ、スーパーバイザーで実行される vSphere CSI プラグインが認証に失敗するために発生します。その結果、ボリューム操作が失敗し、InvalidLogin エラーが表示されます。

ログファイル /var/log/vmware/vpxd/vpxd.log には、次のメッセージが記録されます。

Authentication failed: The account of the user trying to authenticate is locked.:: The account of the user trying to authenticate is locked.:: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})
回避策：
1. アカウントのロック解除時間を取得します。
  1. vSphere Client で、[管理] に移動し、[Single Sign-On] の下の [構成] をクリックします。
  2. [ローカルアカウント] タブをクリックします。
  3. [ロックアウトポリシー] で、ロック解除時間（秒単位）を取得します。
2. kubectl 向けの vSphere プラグインを使用してスーパーバイザーで認証します。
  
  kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME
3. vmware-system-csi- 名前空間内の vsphere-csi-controller のデプロイの元のレプリカ数をメモします。
  
  kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'
  
  original-replica-count
4. vsphere-csi-controller のデプロイのレプリカ数をゼロにスケールダウンします。
  
  kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi
5. [ロック解除時間] に示されている秒数だけ待機します。
6. vsphere-csi-controller のデプロイのレプリカ数を元の値にスケールアップします。
  
  kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

スーパーバイザー上の TKG に関する既知の問題

TKG クラスタのクリーンアップ時または ESXi ホストのダウンタイムからのリカバリ時に TKG クラスタ内のポッド、PV、および PVC がTerminatingの状態のままになる場合がある

通常の TKG クラスタの削除およびクリーンアッププロセスの一環として、Deployments、StatefulSets、PVC、PV、および同様のすべてのオブジェクトが削除されます。ただし、TKR v1.24 以前に基づく TKG クラスタの場合は、DetachVolume エラーが原因で一部の PV がTerminatingの状態で停止することがあります。この問題は、VolumeAttachment オブジェクトでの DetachVolume エラーが原因で VolumeAttachment のファイナライザーが削除されず、関連オブジェクトの削除に失敗した場合に発生します。このシナリオは、ESXi ホストにダウンタイムがある場合にも発生する可能性があります。
回避策：TKG クラスタで次のコマンドを実行し、detachError を使用して volumeattachments からファイナライザーを削除します。
```
kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments
```
バックアップおよびリストア後に TGK クラスタにアクセスできない

vSphere 名前空間が NSX のバックアップ後に作成され、カスタマイズされた入力方向/出力方向 CIDR で構成されている場合、NSX がバックアップからリストアされると、NCP はリストアプロセスを完了できず、vSphere 名前空間の TKG クラスタを使用できません。リストアプロセス時に NCP で障害が発生し、次のようなエラーが表示されます。

NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

回避策：スーパーバイザーのバックアップが NSX のバックアップと同じタイミングで（ただし、影響を受ける vSphere 名前空間が作成される前に）作成された場合は、バックアップからスーパーバイザーもリストアします。または、vSphere 名前空間と関連する TKG クラスタを削除し、NCP が再同期するまで待ってから、削除されたリソースを再作成します。
NSX のバックアップおよびリストア後に TKG クラスタにアクセスできない

スーパーバイザーにカスタマイズされた入力方向 CIDR が構成されている場合は、NSX のバックアップおよびリストア後に NCP コンポーネントが TKG クラスタの入力方向 VIP を適切に検証できないため、TKG クラスタが使用できなくなる可能性があります。

回避策：NSX API を使用して、NSX の TKG クラスタの VIP を手動で構成し、アクセスをリストアします。
プロキシサーバを使用して構成された既存の Tanzu Kubernetes Grid クラスタを vSphere 8 スーパーバイザーにアップグレードできない

修正済み：この既知の問題は、vSphere 8 with Tanzu MP1 リリースでは修正されています。

プロキシサーバを使用して既存の Tanzu Kubernetes Grid クラスタが構成されている場合、このクラスタを vSphere 7 スーパーバイザーから vSphere 8 スーパーバイザー上の Tanzu Kubernetes Grid 2.0 にアップグレードすることはできません。

回避策：noProxy フィールドの内容にアップグレードチェックとの競合があります。このフィールドはプロキシスタンザがクラスタ仕様に追加されている場合に必要となるため、クラスタ内のプロキシ構成全体を削除してから vSphere 8 にアップグレードする必要があります。
antrea-resource-init ポッドが保留状態でハングする

Tanzu Kubernetes Grid クラスタの Tanzu Kubernetes リリースバージョンをアップグレードした後、antrea-resource-init ポッドが保留状態になることがあります。

回避策：スーパーバイザーでポッドを再起動します。
Tanzu Kubernetes Grid クラスタ v1.21.6 が FALSE 状態になり、一部のマシンが移行されないことがある

vCenter Server 8 にアップグレードしてスーパーバイザーを更新すると、v1.21.6 の Tanzu Kubernetes Grid クラスタが FALSE 状態になり、一部の wcpmachines が vspheremachines に移行されないことがあります。

回避策：なし
デフォルトでは、TKR バージョン v1.23.8---vmware.2-tkg.2-zshippable を実行する TKG クラスタで vmware-system-user アカウントのパスワードが 60 日で期限切れになる

STIG セキュリティ強化の一環として、TKR バージョン v1.23.8---vmware.2-tkg.2-zshippable を実行している TKG クラスタの場合、vmware-system-user アカウントは 60 日後に期限切れになるように構成されます。これは、vmware-system-user アカウントを使用してクラスタノードに SSH 接続するユーザーに影響を与える可能性があります。

vmware-system-user パスワードの有効期限を更新し、必要に応じて TKG クラスタノードへの SSH セッションを許可するには、次のナレッジベースの記事を参照してください：https://kb.vmware.com/s/article/90469

vSphere with Tanzu 8.0.0a の TKC で tanzu-capabilities-controller-manager ポッドが再起動を繰り返して CLBO が発生する

サービスアカウントの権限に関する問題の結果、TKR バージョン v1.23.8+vmware.2-tkg.2-zshippable の使用時に Tanzu Kubernetes クラスタの tanzu-capabilities-controller-manager ポッドが CLBO (Crash Loop Back Off) で停止します。

回避策：TKC で機能サービスアカウント tanzu-capabilities-manager-sa に必要な権限を追加します。

TKC で機能パッケージの調整を一時停止します。

kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

新しいファイル capabilities-rbac-patch.yaml を作成します。

apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

TKC で機能クラスタロールにパッチを適用します。

//Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

TKC で tanzu-capabilities-controller-manager を削除します。

3 つの vSphere Zone にデプロイされたスーパーバイザー上の Tanzu Kubernetes Grid 2.0 クラスタで、vGPU とインスタンスストレージを持つ仮想マシンがサポートされない.

3 つの vSphere Zone にデプロイされているスーパーバイザーインスタンスでプロビジョニングされた Tanzu Kubernetes Grid 2.0 クラスタで、vGPU とインスタンスストレージを持つ仮想マシンがサポートされません。

回避策：なし
TKR バージョン v1.22.9 がコンテンツライブラリイメージにはリストされるが、kubectl コマンドではリストされない

TKR イメージのコンテンツライブラリには TKR v1.22.9 がリストされます。「kubectl get tkr」コマンドでは、このイメージが使用可能なイメージとしてリストされません。TKR v1.22.9 を使用できないことと、使用が推奨されないことが理由です。このイメージは、エラーによってコンテンツライブラリに表示されています。

回避策：TKR v1.22.9 以外の TKR を使用してください。使用可能な TKR のリストについては、TKR リリースノートを参照してください。
vSphere with Tanzu 8.0.0a で v1alpha1 API と v1.23.8 TKR を使用して TKC をプロビジョニングできない

TKC v1alpha1 API を使用して、バージョン v1.23.8 の TKC をプロビジョニングする場合、要求が「unable to find a compatible full version matching version hint "1.23.8" and default OS labels: "os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0"」というエラーで失敗します。

回避策：TKC のプロビジョニング時に TKC v1alpha2 または v1alpha3 API に切り替えてください。
v1beta1 API を使用してプロビジョニングされた Tanzu Kubernetes Grid 2.0 クラスタは、デフォルトの ClusterClass に基づいている必要がある

v1beta1 API を使用してスーパーバイザー上に Tanzu Kubernetes Grid 2.0 クラスタを作成する場合、クラスタはデフォルトの「tanzukubernetescluster」ClusterClass に基づいている必要があります。システムは、他の ClusterClass に基づいたクラスタを調整しません。

回避策：vSphere 8 U1 リリース以降では、カスタム ClusterClass に基づいて v1beta1 クラスタをプロビジョニングできます。ナレッジベースの記事 https://kb.vmware.com/s/article/91826 を参照してください。

ネットワーク

NSX Advanced Load Balancer のセットアップで、clusternetworkinfo または namespacenetworkinfo の出力に usage.ingressCIDRUsage セクションがない

NSX Advanced Load Balancer のセットアップでは、入力方向 IP アドレスが Avi Controller によって割り当てられ、ingressCIDR の使用状況が clusternetworkinfo または namespacenetworkinfo の出力に表示されません。

回避策：Avi Controller のユーザーインターフェイスの [アプリケーション] > [VS VIP] から ingressCIDR の使用状況を取得します。
ルーティングされたスーパーバイザーの名前空間を削除した後、Tier-0 プリフィックスリストのポッド CIDR が削除されない

ルーティングされたスーパーバイザーでは、名前空間の削除後に Tier-0 プリフィックスリスト内のポッド CIDR が削除されません。

回避策：prefix-lists オブジェクトを削除します。

curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json
NSX Advanced Load Blanacer の使用時に、Kubernetes リソース clusternetworkinfo と namespacenetworkinfo に usage.ingressCIDRUsage が含まれていない

NSX ベースのスーパーバイザーでの NSX Advanced Load Balancer の使用時に、Kuberentes リソース clusternetworkinfo および namespacenetworkinfo に usage.ingressCIDRUsage フィールドが含まれなくなりました。つまり、kubectl get clusternetworkinfo <supervisor-cluster-name> -o json または kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json を実行すると、ingressCIDR の使用状況オブジェクトが出力に含まれません。

回避策：Avi Controller のユーザーインターフェイス画面を使用して、ingressCIDR の使用状況にアクセスします。
NSX のバックアップとリストア後、一部の名前空間に古い Tier-1 セグメントが存在する

NSX のバックアップとリストア手順の後、サービスエンジン NIC を持つ古い Tier-1 セグメントがクリーンアップされません。

NSX のバックアップ後に名前空間が削除されると、リストア操作により、NSX Advanced Load Balancer Controller サービスエンジン NIC に関連付けられている古い Tier-1 セグメントがリストアされます。
回避策：Tier-1 セグメントを手動で削除します。
1. NSX Manager にログインします。
2. ネットワーク > セグメント の順に選択します。
3. 削除した名前空間に関連付けられている古いセグメントを検索します。
4. ポート/インターフェイス セクションから古いサービスエンジン NIC を削除します。
ロードバランサの監視が停止し、vSphere Client でスーパーバイザーが「構成中」の状態で停止する場合がある

NSX Advanced Load Balancer が有効な場合は、NSX に複数の適用ポイントがあるため、NCP がロードバランサのステータスをプルできないことがあります。これは、NSX で NSX Advanced Load Balancer が有効になると、NSX Advanced Load Balancer が構成された既存のスーパーバイザーに影響します。この問題は、NSX Advanced Load Balancer を利用する新しいスーパーバイザーに影響します。この問題の影響を受けるスーパーバイザーは、LB 監視機能を除いて引き続き機能します。

回避策：NSX で NSX Advanced Load Balancer を無効にします。これにより、NSX Advanced Load Balancer を実行している既存のスーパーバイザーを備えた WCP 環境で、NSX Advanced Load Balancer を使用するスーパーバイザーをデプロイする機能が制限される可能性があります。
組み込みリンクモードトポロジを使用する vCenter Server には NSX Advanced Load Balancer を使用することはできない

NSX Advanced Load Balancer コントローラを構成する場合は、複数のクラウドに構成できます。ただし、vSphere with Tanzu を有効にしているときに複数のクラウドを選択するオプションはありません。これは、Default-Cloud オプションのみをサポートするためです。結果的に、組み込みリンクモードトポロジを使用する vCenter Server には NSX Advanced Load Balancer を使用することはできません。

vCenter Server ごとに NSX ロードバランサを構成します。

ストレージ

vSAN Direct データストア内のディスクのボリューム割り当てタイプを変更できない

vSAN Direct データストア内のディスクのボリューム割り当てタイプを決定後に変更することはできません。これは、基盤となるレイヤーがタイプ変換をサポートしていないためです。ただし、クローン作成や再配置などの操作では、新しいディスクのボリューム割り当てタイプの変更が許可されます。

回避策：なし
仮想マシンを削除すると、CNS タスクがキューに入った状態で停止する

CNS に送信された操作はタスク ID を返しますが、タスクの状態はキューに登録された状態から変わることはありません。これは、削除された仮想マシンに接続されているボリューム用のタスクです。
回避策：アプリケーションレイヤーが呼び出し順序を修正できる場合は、CNS 側で何も行う必要はありません。そうでない場合は、次の手順に従って CNS の新しいシリアル化を無効にします。
1. vCenter Server で /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml を開きます。
2. 次の構成を false に変更します。 <newSerializationEnabled>true</newSerializationEnabled>
3. 次のコマンドを使用して vsan-health を再起動します。 vmon-cli -r vsan-health
詳細については、KB93903 を参照してください。
PVC を正常に削除した後、PV が終了状態のままになる

PersistentVolumeClaim (PVC) を削除した後、対応する PersistentVolume (PV) がスーパーバイザーで終了状態のままになることがあります。また、失敗した複数の deleteVolume タスクが vSphere Client に表示されることがあります。
回避策：
1. スーパーバイザーで認証します。
  
  kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME
2. 終了状態のパーシステントボリュームの名前を取得します。
  
  kubectl get pv
3. パーシステントボリュームのボリュームハンドルを書き留めておきます。
  
  kubectl describe pv <pv-name>
4. 前の手順のボリュームハンドルを使用して、スーパーバイザーの CnsVolumeOperationRequest カスタムリソースを削除します。
  
  kubectl delete cnsvolumeoperationrequest delete-<volume-handle>
注：
PV を削除する前に、クラスタ内の他のリソースでその PV が使用されていないことを確認してください。

リリース ノートの概要

新機能

2023 年 9 月 21 日時点での新機能

新機能 2023 年 7 月 27 日

新機能 2023 年 4 月 18 日

新機能 2023 年 3 月 30 日

新機能 2023 年 2 月 14 日

新機能 2022 年 12 月 15 日

新機能 2022 年 10 月 11 日

本リリースのインストールとアップグレード

既知の問題

スーパーバイザーに関する既知の問題

スーパーバイザー上の TKG に関する既知の問題

ネットワーク

ストレージ

リリースノートの概要