リリース ノートの概要

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

新機能

新機能 2024 年 6 月 25 日

VMware vSphere 8.0 Update 3 | 2024 年 6 月 25 日 

vCenter Server 8.0 Update 3 | 2024 年 6 月 25 日 | ISO ビルド 24022515

VMware ESXi 8.0 Update 3 | 2024 年 6 月 25 日 | ISO ビルド 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

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

Tanzu Kubernetes Grid 3.0 | 2024 年 6 月 25 日

vSphere IaaS 制御プレーン 8.0 Update 3 では、次の機能が追加または強化されています。

  • スーパーバイザーおよび TKG 証明書の自動ローテーション - このリリースでは、新しい証明書ローテーション メカニズムが追加されました。これにより、スーパーバイザーおよび TKG クラスタ証明書は、期限切れになる前に自動的にローテーションされます。自動ローテーションに失敗すると、vCenter Server にその旨が通知されます。この場合、証明書を手動で更新する必要があります。

  • ストレッチ vSAN クラスタでの、スーパーバイザーと vSphere ポッドおよび TKG クラスタのサポート - このリリース以降、vSAN ストレッチ クラスタで稼動するようにスーパーバイザーを構成できます。この構成は、新規の環境でのみサポートされます。つまり、vSAN クラスタの拡張が必要で、ワークロード管理とコンテンツ ライブラリがまだ構成されていない環境のみ対象となります。これらの 2 つのコンポーネントは、vSAN ストレッチ クラスタ ストレージ ポリシーを使用して構成する必要があります。詳細については、該当のドキュメントを参照してください。

  • 仮想マシン サービスの仮想マシンに使用する仮想マシン クラスを名前空間スコープに変更 - このリリースでは、kubectl を使用して仮想マシン クラスを一覧表示するときに、特定の vSphere 名前空間を範囲とする仮想マシン クラスのみを表示できます。以前は、仮想マシン クラスはクラスタ スコープのリソースであり、どの仮想マシン クラスが特定の名前空間に割り当てられ利用可能かを簡単には判断できませんでした。

  • スーパーバイザーのバックアップおよびリストア - vSphere でスーパーバイザーのバックアップとリストアがサポートされるようになりました。これで、スーパーバイザーのバックアップが vCenter Server バックアップの一部となるように構成して、ディザスタ リカバリ、アップグレード失敗、障害の発生といったリカバリ シナリオで、スーパーバイザーをバックアップからリストアできます。「スーパーバイザー制御プレーンのバックアップとリストア」を参照してください。

  • 仮想マシン サービスの仮想マシン向けバックアップおよびリストア - vSphere で仮想マシン サービスの仮想マシン向けバックアップおよびリストアがサポートされるようになりました。これにより、VADP ベースのバックアップ ベンダーを使用して、仮想マシン サービスの仮想マシンを保護でき、データ損失を伴う障害などのシナリオが生じた場合に、vSphere 名前空間内の仮想マシンをバックアップからリストアすることも可能です。

  • 仮想マシン オペレータ API v1alpha2 が利用可能に - VM Operator API の次のバージョンとして VM Operator v1alpha2 がリリースされ、ブートストラップ プロバイダのサポートがさらに強化されました。たとえば、インライン Cloud-Init および Windows への対応、ゲスト ネットワーク構成の強化、ステータス機能の拡充、ユーザー定義準備ゲートへの対応、VirtualMachineWebConsoleRequest API の新規導入、API ドキュメントの改善などが行われています。 

  • スーパーバイザーでのログ転送に Fluent Bit を活用 - 外部ログ監視プラットフォームに対する、スーパーバイザー制御プレーンのログとシステム ログのログ転送をサポートできるようになりました。詳細については、該当のドキュメントを参照してください。

  • スーパーバイザー サービスのプライベート レジストリサポート - スーパーバイザー サービスとして展開されたワークロードがプライベート レジストリからイメージとパッケージを取得できるようにするプライベート レジストリの詳細を定義できるようになりました。これは、エアギャップ環境をサポートするための一般的な要件です。詳細については、このドキュメントを参照してください。

  • スーパーバイザー アップグレード ワークフローの向上 - スーパーバイザーの Kubernetes バージョンのアップグレードを開始する際に、スーパーバイザー アップグレードの事前チェックを開始できるようになりました。すべての事前チェックが正常に完了した場合にかぎり、実際の更新が実行されます。このリリースでは、コンポーネントのアップグレード プロセスを以前に失敗した時点から再開する機能が導入されました。詳細については、「スーパーバイザーの更新」を参照してください。

  • スーパーバイザーによる Kubernetes 1.28 のサポート - このリリースでは、Kubernetes 1.28 のサポートが追加され、Kubernetes 1.25 のサポートが削除されています。

スーパーバイザーでサポートされる Kubernetes バージョン：

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

Tanzu Kubernetes Grid Service for vSphere

  • スーパーバイザー サービスとしての TKG サービス – このリリースでは、TKG サービス コンポーネントが vCenter Server から分離され、vCenter Server およびスーパーバイザー リリースとは関係なく更新および管理できるスーパーバイザー サービスとしてパッケージ化されています。TKG サービスのリリース ノートはこちらで確認できます。

  • ストレッチ vSAN クラスタへの TKG サービス クラスタのデプロイのサポート – このリリースでは、vSAN ストレッチ クラスタ トポロジへの TKG サービス クラスタのデプロイがサポートされています。vSAN ストレッチ クラスタで TKG サービス クラスタに HA を構成する方法の詳細については、このドキュメントを参照してください。

  • TKG サービス クラスタの自動スケーリング – このリリースでは、TKG サービス クラスタにクラスタ autoscaler パッケージをインストールして、ワーカー ノードの自動スケール アウト/スケール インを有効にできます。 

  • TKG クラスタのバックアップとリストア – このリリースでは、スーパーバイザー データベースのバックアップとリストアがサポートされています。これには、vSphere 名前空間オブジェクトと TKG クラスタ仮想マシンが含まれます。TKG クラスタ ワークロードは個別にバックアップおよびリストアする必要があることに注意してください。

  • Antrea-NSX 統合と NSX 管理プロキシ サービスのサポート – このリリースでは、クラスタ ネットワークの観測と制御を目的とした Antrea CNI を使用する TKG クラスタと NSX Manager の統合がサポートされます。

  • 構成可能な MachineHealthCheck – このリリースでは、v1beta1 クラスタの MachineHealthCheck の構成がサポートされています。

  • クラスタ全体の PSA 構成 – このリリースでは、クラスタの作成または更新中にクラスタ全体ベースで PSA を構成できます。

  • 標準パッケージのインストールのアップデート – このリリースには、TKG サービス クラスタへの標準パッケージのインストールに関するドキュメントの更新が含まれています。 

  • TKG クラスタのプロビジョニング用 v1beta1 API のアップデート – このリリースには、次の v1beta1 API の変更が含まれています。

    • podSecurityStandard がクラスタ全体の PSA 実装用に追加されました

    • controlPlaneCertificateRotation が更新されました 

  • TKG クラスタの制御プレーン ノード ボリュームのスケーリングのサポート

利用可能な言語の更新

次回のメジャー リリース以降、サポートされるローカライズ言語の数を少なくする予定です。サポートされる 3 つの言語は次のとおりです。

  • 日本語

  • スペイン語

  • フランス語

次の言語はサポートされません。

  • イタリア語、ドイツ語、ポルトガル語（ブラジル）、繁体字中国語、韓国語、簡体字中国語

影響:

  • 廃止された言語を使用しているユーザーは、これらの言語での更新またはサポートを受け取らなくなります。

  • すべてのユーザー インターフェイス、ヘルプ ドキュメント、カスタマー サポートは、英語または上記の 3 つのサポート対象言語でのみ使用できます。

新機能 2024 3 月 26 日

VMware vSphere 8.0 Update 2c | 2024 年 3 月 26 日 

ESXi 8.0 Update 2b | 2024 年 2 月 29 日 | ISO ビルド 23305546

vCenter Server 8.0 Update 2c | 2024 年 3 月 26 日 | ISO ビルド 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

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

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 制御プレーン 8.0 Update 2c では、次の機能が追加または強化されています。

新機能

  • TKr 1.27 のサポート - このリリースでは、今後リリースされる vSphere 8.x で TKr 1.27 をサポートするのに必要な変更が行われました。詳細については、「VMware Tanzu Kubernetes releases Release Notes」を参照してください。

  • vCenter 7.x から vCenter 8.x へのアップグレードのサポート - vSphere 7.x で TKr 1.27.6 を実行している場合、このリリースによって、vCenter 8.x にアップグレードできるようになりました。以前は、vSphere 7.x 向けにリリースされた TKr 1.27.6 は、vCenter 8.x と互換性がありませんでした。ナレッジベースの記事 KB96501 を参照してください。

解決した問題

  • vCenter 8.0 Update 2b へのアップグレード後に、vmon の管理対象サービスの wcp が STOPPED の状態になり、vCenter Server のパッチ適用が失敗することがある。

  • ライブラリのリンクを解除、または、共有ライブラリがある名前空間を削除すると、関連アイテムがコンテンツ ライブラリから削除される。

新機能 2024 2 月 29 日

VMware vSphere 8.0 Update 2b | 2024 年 2 月 29 日 

ESXi 8.0 Update 2b | 2024 年 2 月 29 日 | ISO ビルド 23305546

vCenter Server 8.0 Update 2b | 2024 年 2 月 29 日 | ISO ビルド 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

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

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 制御プレーン 8.0 Update 2b では、次の機能が追加または強化されています。

新機能

  • vSphere Client を介した、仮想マシン サービスの仮想マシン クラス構成への対応 - スーパーバイザーで稼動する仮想マシン サービスでは、vSphere 仮想マシンで現在サポートされている構成を使用して仮想マシンをデプロイできるようになりました。仮想マシン クラスの CPU、メモリ、ハードウェア、セキュリティ デバイス、パススルー デバイスの構成に、vSphere Client の仮想マシン クラス ウィザードを使用できます。AI/ML ワークロードの実行に使用する、仮想マシン サービスの仮想マシンを定義および管理するプロセスを、vSphere Client を介して簡素化できます。

  • スーパーバイザーでの Avi クラウド設定のサポート - NSX Advanced Load Balancer（Avi ロード バランサとも言う）を使用している場合に、Avi クラウドをスーパーバイザーごとに構成できるようになりました。これにより、複数の vCenter Server インスタンスとデータセンターで、1 つの Avi インスタンスを使用できるため、スーパーバイザーをデプロイする vCenter Server またはデータセンターごとに Avi インスタンスを設定する必要がなくなります。

  • FQDN でのログインのサポート - スーパーバイザーおよび TKG クラスタ向けに、生成した kubeconfigs の IP アドレスを有効な FQDN に置き換えられるようになりました。ホスト名を適切に解決するには、これらの FQDN と IP アドレスを DNS に追加する必要があります。

  • スーパーバイザーでの Kubernetes 1.27 のサポート - スーパーバイザーで、Kubernetes 1.27 がサポートされるようになりました。これに伴い、Kubernetes 1.24 のサポートが終了します。

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

  • このリリースでサポートされている Kubernetes バージョンは、1.27、1.26、1.25 です。Kubernetes 1.24 で稼動しているスーパーバイザーは、互換性を確保するために、バージョン 1.25 に自動アップグレードされます。

8.0 Update 2b へのアップグレード

8.0 Update 2 より前の vSphere 8.x バージョンから 8.0 Update 2b リリースにアップグレードすると、プロビジョニングしたすべての TKGS クラスタのローリング アップデートが開始され、次の変更点が伝達されます。

  • 8.0 Update 2 では、ClusterClass の一部として、TKGS コントローラに実装する、vSphere 7 および vSphere 8 の TKR がともに変更されています。

  • 1.23 以降の TKGS クラスタは 8.0 Update 2b と互換性があるため、すべての TKGS クラスタでローリング アップグレードが実行されます。

解決した問題

  • スーパーバイザーのアップグレード プロセスが 20% で停止する。

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 日

vSphere IaaS 制御プレーン 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 プロジェクトで自動的に作成され、イメージ レジストリへのイメージの追加は、ペルソナおよび使用レベル（グローバル レベルまたはプロジェクト レベル）によって範囲設定されます。イメージは、仮想マシン サービスを介した仮想マシンの展開に使用できます。

    この機能には、仮想マシン イメージ名の新しい形式が導入されています。名前の変更によって発生する可能性がある問題の解決方法については、「vSphere 8.0 U2 で仮想マシン イメージ名の形式を変更する」を参照してください。

  • スーパーバイザー構成のインポートとエクスポート - 以前のバージョンでは、スーパーバイザーの有効化は、構成を保存する機能を使用せずに手動で段階的に行うプロセスでした。現在のリリースでは、スーパーバイザー構成の共有とエクスポートを、人間が解読可能な形式でピアと行ったり、またはソース制御システム内で行ったりすることや、新しいスーパーバイザーへの構成のインポート、および複数のスーパーバイザー間での標準構成のレプリケートが可能になりました。スーパーバイザー構成をエクスポートおよびインポートする方法の詳細については、こちらのドキュメントを確認してください。

  • フラグメンテーションの削減による 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 年 7 月 27 日 | ビルド 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 IaaS 制御プレーン 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 日

新機能

スーパーバイザー

  • スーパーバイザー サービスが、VDS ベースのスーパーバイザーで利用可能に - 以前は、スーパーバイザー サービスの利用は 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 IaaS 制御プレーン 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 IaaS 制御プレーン 8.0.0 GA のお客様にご注意いただきたい重要な要件

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

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

  1. https://wp-content.vmware.com/v2/8.0.0/lib.json を参照する一時的なサブスクリプション URL を使用して、新しいサブスクライブ済みコンテンツ ライブラリを作成します。

  2. 一時コンテンツ ライブラリ内のすべてのアイテムを同期します。

  3. 一時コンテンツ ライブラリを TKG 2 クラスタをデプロイした各 vSphere 名前空間に関連付けます。

  4. コマンド kubectl get tkr を実行し、すべての TKr が作成されていることを確認します。

  5. この時点で、TKG コントローラは実行状態である必要があります。これは、スーパーバイザー名前空間内のポッドを一覧表示して確認できます。

  6. TKG コントローラが CrashLoopBackOff (CLBO) 状態の場合は、次のコマンドを使用して TKG コントローラのデプロイを再起動します。

    kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

  7. vSphere IaaS 制御プレーン 8 Update 1 にアップグレードします。

  8. 各 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 日

解決した問題：

  • 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 日

新機能：

  • 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 日

新機能

  • スーパーバイザー サービスとしての 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 日

vSphere IaaS 制御プレーン 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 IaaS 制御プレーン ドキュメントの構造が改善されました。これにより、製品を使用したワークフローがより適切に反映され、有用なコンテンツを確認できるようになりました。また、新しいドキュメントの Web ページから、利用可能な vSphere IaaS 制御プレーンのすべての技術ドキュメントにアクセスすることもできます。


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

vSphere IaaS 制御プレーンのインストールと構成のガイダンスについては、『Installing and Configuring vSphere IaaS Control Plane』ドキュメントを参照してください。vSphere IaaS 制御プレーンの更新方法については、『Updating vSphere IaaS Control Plane』ドキュメントを参照してください。

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

  • vCenter Server 8.0 に更新する前に、すべてのスーパーバイザーの Kubernetes バージョンが 1.21 以上（できればサポートされている最新バージョン）であることを確認します。Tanzu Kubernetes Grid クラスタの Tanzu Kubernetes リリース バージョンは 1.21（できればサポートされている最新バージョン）である必要があります。

  • vSphere IaaS 制御プレーン 8.0 MP1 リリース以降では、レガシー TKGS TKr から TKG 2 TKr にアップグレードできます。サポートされているバージョンのマトリックスについては、Tanzu Kuberentes releases Release Notesを参照してください。アップグレード情報については、『Using TKG on Supervisor with vSphere IaaS Control Plane』ドキュメントを参照してください。

既知の問題

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

  • vSphere 8.0 Update 3 では vSphere 名前空間の作成画面にネットワークのオーバーライド オプションが表示されない

    8.0 Update 3 リリースより前のバージョンでは、vSphere 管理者は、vSphere 名前空間の作成時に使用されるデフォルトのネットワーク構成の代わりに、カスタム ネットワーク構成を提供することができました。8.0 Update 3 リリースでは、ネットワーク構成をオーバーライドするユーザー インターフェイス オプションは使用できません。

    回避策：DCLI を使用することで、カスタム ネットワーク構成による vSphere 名前空間を作成できます。

  • vds-vsip モジュールをロードできないことが原因で、ESXi ホストがスーパーバイザー クラスタへの参加に失敗することがある

    ESXi ホストがスーパーバイザー クラスタへの参加に失敗すると、次の ESXi ホストのログ ファイルに以下のエラーが記録されることがあります： /var/run/log/spherelet.log:

    cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

    この問題は、スーパーバイザー クラスタのアップグレード、証明書のアップグレード、または Spherelet を再起動するその他のスーパーバイザー構成の変更中に発生する可能性があります。

    回避策：vds-vsip モジュールをロードできない ESXi ホストを再起動します。

  • 極小の制御プレーン仮想マシンを使用するスーパーバイザーで、vSphere IaaS 制御プレーン環境を 7.0 Update 3o から 8.0 Update 3 にアップグレードすると、エラーが発生して失敗する

    vCenter Server を 7.0 Update 3o から 8.0 Update 3 にアップグレードした後、極小 の制御プレーン仮想マシンで構成されたスーパーバイザーを Kubernetes バージョン 1.26.8 から 1.27.5 にアップグレードできません。

    次のようなエラーが表示されます： Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

    回避策：アップグレードの前に、制御プレーン仮想マシンのサイズを 極小 から 小 以上にスケール アップします。「スーパーバイザーの制御プレーン サイズの変更」を参照してください。

  • vCenter Server および vSphere IaaS 制御プレーン環境を vSphere 8.0 U3 にアップグレードした後、スーパーバイザーが Kubernetes バージョン 1.26 を使用している場合、vSphere ポッドの作成に失敗する

    環境を vSphere 8.0 U3 にアップグレードし、スーパーバイザーを Kubernetes バージョン 1.26 にアップグレードすると、システムがイメージの取得を試行した際に vSphere ポッドの作成操作が失敗します。クラスタが固定ネットワークで有効になっている場合でも、「failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface」というエラーが表示されます。

    回避策：vSphere IaaS 制御プレーンとスーパーバイザーを Kubernetes バージョン 1.27 以降にアップグレードします。

  • ボリューム スナップショットの削除と PVC リストア操作を同時に実行すると、内部依存関係が原因で操作が完了しないことがある

    この問題は、次の状況で発生する可能性があります。ユーザーがボリューム スナップショットのリストア操作を開始した際に、リストア操作の完了に時間がかかるか、複数の内部要因により再試行されます。その間に、ユーザーがソース スナップショットの削除をトリガします。結果として、両方の操作が衝突し、不完全なままになります。スナップショットの削除がトリガされたことが原因でリストア操作が失敗し始める一方で、このスナップショットに対するリストア操作が進行中であるため、スナップショットの削除は失敗し続けます。

    回避策：この問題を解決するには、リストアされた PVC を削除してリストア操作を停止し、スナップショットの削除を続行する必要があります。この場合、リストアされた PVC を削除した後にスナップショットが削除されるため、スナップショット データは失われ、リストアできません。

  • 仮想マシン サービス仮想マシンが、ストレージ クラスの volumeBindingMode パラメータが WaitForFirstConsumer に設定されている PVC を使用できない

    このタイプの PVC を仮想マシン サービス仮想マシンで使用すると、予期しない動作とエラーが発生します。たとえば、「Waiting for first consumer to be created before binding」というエラーが表示されます。

    回避策：仮想マシン サービス仮想マシンは、ストレージ クラスに即時の volumeBidingMode を含む PVC はサポートしますが、WaitForFirstConsumer はサポートしません。

  • 新しいライセンス モデルにより、VMware vSphere IaaS 制御プレーン環境での NSX Container Plugin (NCP) の動作が変更される

    8.0 Update 3 リリースでは、NSX Distributed Firewall (DFW) ライセンスは個別のアドオン ライセンスとして提供されます。このライセンスがない場合、VMware vSphere IaaS 制御プレーン環境の NCP が NSX に関する DFW ルールを調整し、予期しない動作が発生します。

    たとえば、DFW ライセンスがない場合、NCP が NSX Manager にルールを追加できないため、VMware vSphere IaaS 制御プレーン用に作成された新しいセキュリティ ポリシーとネットワーク ポリシーは機能しません。また、新しく作成された名前空間内のポッドなどのリソースに、別の名前空間からアクセス可能になります。一方、DFW ライセンスがある場合、新しく作成された名前空間には、デフォルトで別の名前空間からアクセスすることはできません。

    回避策：NSX Distributed Firewall (DFW) ライセンスは、NSX Manager 上の個別のアドオン ライセンスとして提供されます。問題を回避するには、ライセンスを NSX Manager に追加します。

  • Velero vSphere Operator が正常にインストールされても、Velero のインスタンスのインスタンス化に失敗することがある

    Velero vSphere Operator は制御プレーン仮想マシンにオペレータ ポッドをデプロイし、一方で Velero のインスタンスは vSphere ポッドとしてデプロイされます。

    vCenter Server が 8.x にアップグレードされる際にデプロイの問題が発生し、スーパーバイザーが Distributed Switch ネットワークを使用することがあります。しかし、そのスーパーバイザーの ESXi ホストはアップグレードされず、8.x より前の非同期のバージョンを使用しています。このシナリオでは ESXi ホストは vSphere ポッドをデプロイできません。その結果、Velero vSphere Operator は正常にインストールされますが、管理者が Velero のインスタンスを使用する際にインスタンス化は失敗します。

    回避策：Velero スーパーバイザー サービスが正しく動作するようにするには、ESXi を先にバージョン 8.x にアップグレードしてから、vCenter Server とスーパーバイザーを同じ 8.x バージョンにアップグレードする必要があります。

  • 仮想マシン オペレータ ポッドが大規模な環境でリソース不足のためにクラッシュする

    たとえば数千台の仮想マシンが存在する大規模な環境で VirtualMachine リソースの認識に時間がかかっている場合は、メモリ不足が原因で仮想マシン オペレータ ポッドがクラッシュしている可能性があります。

    回避策：回避策と詳細については、ナレッジベースの記事 KB88442 を参照してください。

  • vCenter 8.0 Update 2b にアップグレードした後、vmon 管理サービス wcp が STOPPED 状態になり、vCenter のパッチ適用が失敗することがある

    この問題は、vCenter 8.0 Update 1 以降を vCenter 8.0 Update 2b にアップグレードするときに、VDS ネットワーク トポロジを使用する、Kubernetes 1.24 上に存在するスーパーバイザーが 1 つ以上ある場合にのみ発生します。

    回避策：この問題を回避するには、vCenter Server を 8.0 Update 2b にアップグレードする前に、スーパーバイザーを Kubernetes 1.25 以降にアップグレードします。詳細については、カスタマー サポートにお問い合わせください。

  • カスタム vCenter Server 証明書のサイズが 8K を超えると、スーパーバイザーの操作が失敗する

    vSphere 8.0 Update 2b では、vCenter Server システムの CSR の最大キー サイズが 16,384 ビットから 8,192 ビットまで減少しています。証明書のキー サイズが 8,192 ビットを超えると、スーパーバイザーの操作で予期しない動作が発生することがあります。たとえば、スーパーバイザーを有効にしたりアップグレードする操作が失敗することがあります。

    回避策：

    キー サイズが 8,192 ビットを超えるすべての vCenter Server 証明書を再生成します。

    1. キー サイズが 8,192 ビットを超えるすべての証明書を特定します。

      for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done

    2. キー サイズが 8,192 ビットを超えるすべての証明書を置き換えます。

    3. NSX を使用している場合は、NSX に vCenter Server を再登録します。

    4. WCP サービスを再起動します。

    詳細については、ナレッジベースの記事 KB96562 を参照してください。

  • vCenter Server のコンテンツ ライブラリが複数の vSphere 名前空間にリンクされているときに、このコンテンツ ライブラリからテンプレートが削除されることがある

    この問題は、ライブラリが vSphere IaaS 制御プレーン内の複数の名前空間にリンクされているときに、このライブラリが名前空間からリンク解除されるか、名前空間が削除されたときに発生することがあります。

    回避策：

    ライブラリを複数の名前空間にリンクする場合は、ローカル ライブラリを使用しないでください。代わりに、vCenter Server に公開ライブラリを作成し、すべてのテンプレートを公開ライブラリにアップロードします。次に、同じ vCenter Server の公開ライブラリからテンプレートと同期するサブスクライブ済みライブラリを作成し、このサブスクライブ済みライブラリを複数の名前空間にリンクします。このケースでは、ライブラリがいずれかの名前空間からリンク解除された場合や名前空間の 1 つが削除された場合でも、ライブラリ アイテムは vCenter Server から削除されません。

  • VMware vSphere Automation REST API を使用して仮想マシン クラスを作成または更新するときに、configSpec に整数フィールドを含めるとエラーが発生する

    configSpec に numCPU や memoryMB などの整数フィールドが含まれていると、次のエラーが発生することがあります。

    Unknown error - vcenter.wcp.vmclass.configspec.invalid: json: unsupported discriminator kind: struct.

    Unknown error - vcenter.wcp.vmclass.configspec.invalid: json: cannot unmarshal string into Go struct field VirtualMachineConfigSpec.<fieldName> of type int32.

    この問題は、整数を含む Raw REST configSpec JSON を解析し、整数を文字列として渡して障害を引き起こすという VAPI エンドポイントの既知の問題が原因で発生します。この問題は、VMware Developer Center を介して REST API を使用する場合にのみ発生します。

    回避策：REST API の代わりに、DCLI または vSphere Client を使用して仮想マシン クラスを作成または更新します。

    または、python/java 用の vSphere Automation SDK を使用することもできます。次の例は、パブリック プロトコル トランスコーダ サービスを使用し、pyvmomi を使用して vCenter Server から取得した VirtualMachineConfigSpec (vim.vm.ConfigSpec) オブジェクトを変換する方法を示しています。この例の最後のエントリは、手動で作成された JSON を解析する方法を示しています。その後、オブジェクトを VirtualMachineClasses API に送信できます。

  • スーパーバイザーに有効な vSphere VMware Foundation ライセンスを適用した後も、[ワークロード管理] 画面に引き続き古い評価ライセンスと有効期限の警告が表示される

    この問題は、スーパーバイザーで評価ライセンスが有効なときに、スーパーバイザーに vSphere VMware Foundation ライセンスを適用すると発生することがあります。ただし、新しいライセンスは、[vCenter] > [ワークロード管理] > [スーパーバイザー] > [スーパーバイザー] に含まれる vSphere Client の [ワークロード管理] 画面には表示されません。新しいライセンス キーが正常に適用された場合でも、vSphere Client には古い評価ライセンスの有効期限に関する警告が引き続き表示されます。

    回避策：なし。新しいライセンスは、vSphere Client の [管理] > [ライセンス] > [資産] > [スーパーバイザー] に正しく表示されます。

  • 追加または削除するルールがルール リストの最後のルールでない場合、セキュリティ ポリシー CRD で更新したセキュリティ ポリシー ルールが有効にならない

    DevOps は、セキュリティ ポリシー CRD を構成し、NSX ベースのセキュリティ ポリシーがスーパーバイザー クラスタ 名前空間に適用されるようにすることができます。CRD を更新してセキュリティ ポリシー ルールを追加または削除する場合、ルール リストの最後のルールでない限り、更新したルールは有効になりません。

    回避策：ルール リストの最後にルールを追加するか、別のセキュリティ ポリシーを使用してルールを追加または削除します。

  • 古い仮想マシン イメージ名が使用されているときに、vSphere 8.0 U2 で仮想マシン イメージ名の形式を変更すると、問題が発生することがある

    vSphere 8.0 Update 2 より前のバージョンでは、仮想マシン イメージ リソースの名前はコンテンツ ライブラリ アイテムの名前から取得されていました。たとえば、コンテンツ ライブラリ アイテムの名前が photonos-5-x64 の場合、対応する VirtualMachineImage リソースにも photonos-5-x64 という名前が付けられていました。そのため、異なるライブラリにあるライブラリ アイテムの名前が同じであった場合に問題が発生していました。

    vSphere 8.0 Update 2 リリースでは、仮想マシン イメージ サービスが導入され、セルフサービス方式で仮想マシン イメージを管理できるようになりました。「vSphere with Tanzu におけるスタンドアローン仮想マシン向けのコンテンツ ライブラリの作成と管理」を参照してください。

    この新機能により、コンテンツ ライブラリを名前空間またはスーパーバイザー クラスタ全体に関連付けることが可能になり、Kubernetes クラスタ内の仮想マシン イメージ リソースの名前を一意かつ確定的にする必要性が生じました。結果として、ライブラリ アイテム名と競合することがないように、仮想マシン イメージは新しい命名形式 vmi-xxx に従うようになっています。ただし、photonos-5-x64 や centos-stream-8 などの古いイメージ名を参照する以前の仮想マシン YAML を使用している場合は、この変更が原因で vSphere 8.0 Update 2 リリースで問題が発生することがあります。

    回避策：

    1. 次のコマンドを使用して、仮想マシン イメージに関する情報を取得します。

      • 名前空間に関連付けられているイメージを表示するには、kubectl get vmi -n <namespace> を実行します。

      • クラスタで使用可能なイメージを取得するには、kubectl get cvmi を実行します。

    2. NAME 列に一覧表示されているイメージ リソース名を取得したら、仮想マシンのデプロイ仕様で名前を更新します。

  • スーパーバイザーの自動アップグレード中に、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 IaaS 制御プレーンのアップグレード後、クラスタのノードに接続されていると表示されるボリュームが原因で、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 に関する既知の問題

  • vSphere IaaS 制御プレーン 7.0.x 環境を vSphere 8.0.x にアップグレードすると、v1.27.6 のすべての TKG クラスタに互換性がなくなる

    vSphere 8.0.x は TKR 1.27.6 をサポートしていません。

    結果として、IaaS 制御プレーン 7.0.x を vSphere 8.0.x にアップグレードした後、v1.27.6 の TKG クラスタに互換性がなくなります。スーパーバイザーのアップグレード中に、事前チェックの警告は表示されません。

    回避策：

    • vSphere 7.0.x で v1.27.6 の TKGS クラスタが実行されている場合は、8.0.x、特に vCenter 8.0 Update 2b にはアップグレードしないでください。詳細については、「VMware Tanzu Kubernetes release Release Note」およびナレッジベースの記事 KB96501 を参照してください。

    • vSphere 7.x 環境を vCenter 8.x にアップグレードする計画がある場合は、TKR 1.27.6 にアップグレードしないでください。

  • TKG クラスタ ワーカー ノードがパワーオンに失敗し、nsx-ncp ポッドがエラー VIF restore activity already completed for attachment ID をログに記録する

    TKG クラスタ ワーカー ノードが次のエラーによってパワーオンに失敗します。

    nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

    NCP が次のエラーをログに記録します。

    VIF restore activity already completed for attachment ID

    NSX バックアップ後に作成された TKG クラスタ ノードの仮想マシンが、NSX リストア直後に vMotion を使用して移行されると、接続 ID が vMotion で再利用され、NCP のリストア要求がブロックされるため、NCP は仮想マシンのポートをリストアできません。

    回避策：

    1. NSX Manager に移動し、削除する必要があるセグメント ポートを取得します。表示名の形式は次のとおりです。 <vm name>.vmx@<attachment id>

    2. 新たに作成されたポートを削除する前に、仮想マシンが実行されているホストを検索し、そのホストで /etc/init.d/nsx-opsagent stop を実行して ops-agent をオフにします。

    3. 次の NSX API を使用してポートを削除します。 https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true

    4. ホストで /etc/init.d/nsx-opsagent start を実行して ops-agent をオンにします。

    5. NCP がポートをリストアするまで待ちます。

  • 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 IaaS 制御プレーン 8.0.0a の TKC で tanzu-capabilities-controller-manager ポッドが再起動を繰り返して CLBO が発生する

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

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

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

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

    2. 新しいファイル 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

    3. 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

    4. 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 IaaS 制御プレーン 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 IaaS 制御プレーンを有効にしているときに複数のクラウドを選択するオプションはありません。これは、Default-Cloud オプションのみをサポートするためです。結果的に、組み込みリンク モード トポロジを使用する vCenter Server には NSX Advanced Load Balancer を使用することはできません。

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

ストレージに関する既知の問題

  • データストアが vCenter Server システム間で共有されている環境で、複数の CNS ボリューム同期エラーが発生する

    vCenter Server をまたがる移行は CNS ではサポートされていません。ただし、CNS の定期的な同期は自動的に実行され、共有データストア上のボリュームのロック競合が発生します。

    回避策：この問題を回避するには、CNS の定期的な同期の時間間隔をより大きい値に設定します。

    1. vCenter Server で CNS 構成ファイルを見つけます。

      /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml

    2. 次の行に移動します。

      <newSyncInterval>60</newSyncInterval>

      デフォルトでは、定期的な同期は 60 秒に設定されます。

    3. この時間間隔をもっと長い値（たとえば 1 年の場合は 31,536,000 秒）に変更します。

  • 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 が使用されていないことを確認してください。

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