リリース ノートの概要

更新日：2023 年 7 月 6 日

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

新機能 2023 年 7 月 6 日

2023 年 7 月 6 日ビルド情報

ESXi 7.0 Update 3m | 2023 年 5 月 3 日 | ISO ビルド 21686933

vCenter Server 7.0 Update 3n | 2023 年 7 月 6 日 | ISO ビルド 21958406

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

新機能

  • スーパーバイザー クラスタによる Kubernetes 1.24 のサポート - 本リリースでは、Kubernetes 1.24 のサポートが追加され、Kubernetes 1.21 のサポートが削除されています。

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

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

新機能 2023 年 3 月 30 日

2023 年 3 月 30 日ビルド情報

ESXi 7.0 Update 3l | 2023 年 3 月 30 日 | ISO ビルド 21424296

vCenter Server 7.0 Update 3l | 2023 年 3 月 30 日 | ISO ビルド 21477706

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

新機能：

  • なし。これはバグ修正リリースです。

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

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

解決した問題

このパッチでは、次の問題が解決しています。

  • Large Receive Offload (LRO) を有効にすると、Antrea-ENCAP を使用する Tanzu Kubernetes Grid クラスタ仮想マシンでネットワーク パフォーマンスの問題が発生することがある。

  • スーパーバイザーで組み込みの Harbor レジストリを有効にすると、デフォルト構成が安全でなくなる可能性がある。

新機能 2023 年 2 月 23 日

2023 年 2 月 23 日 ビルド情報

ESXi 7.0 Update 3i | 2022 年 12 月 8 日 | ISO ビルド 20842708

vCenter Server 7.0 Update 3k | 2023 年 2 月 23 日 | ISO ビルド 21290409

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

新機能：

スーパーバイザー

  • スーパーバイザー クラスタによる Kubernetes 1.23 のサポート - 本リリースでは、Kubernetes 1.23 のサポートが追加され、Kubernetes 1.20 のサポートが削除されています。このリリースでサポートされている Kubernetes のバージョンは、1.23、1.22、および 1.21 です。Kubernetes バージョン 1.20 で実行されているスーパーバイザーは、バージョン 1.21 に自動的にアップグレードされます。これにより、すべてのスーパーバイザーがサポート対象バージョンの Kubernetes で実行されるようになります。

新機能 2022 年 12 月 8 日

2022 年 12 月 8 日ビルド情報

ESXi 7.0 Update 3i | 2022 年 12 月 8 日 | ISO ビルド 20842708

vCenter Server 7.0 Update 3i | 2022 年 12 月 8 日 | ISO ビルド 20845200

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

新機能：

新しい SecurityPolicy CRD：vSphere 7.0 Update 3i では、ユーザーがスーパーバイザーの仮想マシンおよびポッドに NSX ベースのセキュリティ ポリシーを適用するための SecurityPolicy CRD が導入されています。これにより、スーパーバイザー名前空間の CRD を介して Kubernetes ネットワーク ポリシーを拡張することで、コードを使用して「Kubernetes ネットワーク ポリシー」を構成できます。

サポート: kube-apiserver-authproxy-svc サービスおよびシステム ポッドで使用される TLS バージョンが TLSv1.2 に更新されました。

2022 年 9 月 13 日時点での新機能

2022 年 9 月 13 日ビルド情報

ESXi 7.0 Update 3g | 2022 年 9 月 13 日 | ISO ビルド 20328353

vCenter Server 7.0 Update 3h | 2022 年 9 月 13 日 | ISO ビルド 20395099

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022 年 3 月 29 日

新機能

  • なし。これはバグ修正リリースです。

解決した問題：

このパッチは、アップグレード後に WCP サービスが開始されなかったことによって失敗したバージョン 70u3f への vCenter Server アップグレードの問題を修正します。このエラーは、70u3d よりも前のバージョンで vSphere with Tanzu を有効にした vCenter Server をアップグレードする際に発生していました。vCenter Server を 70u3d よりも前のバージョンから vCenter Server 70u3d にアップグレードしてから、vCenter Server 70u3f へのアップグレードを試行すると失敗します。

解決済みの問題の詳細については、ナレッジベースの記事 KB89010を参照してください。

2022 年 7 月 12 日時点での新機能

2022 年 7 月 12 日ビルド情報

ESXi 7.0 Update 3f | 2022 年 7 月 12 日 | ISO ビルド 20036589

vCenter Server 7.0 Update 3f | 2022 年 7 月 12 日 | ISO ビルド 20051473

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022 年 3 月 29 日

新機能

  • スーパーバイザー クラスタ

    • 仮想マシン サービスの LoadBalancer IP 文字列値のサポート - NSX-T で作成およびタグ付けされた IP アドレス プールを表す/一致する spec.LoadBalancerIP 値にユーザーが文字列値を指定できるようにします。

    • 仮想マシン サービスの仮想マシンのバックアップとリストア - VMware は、vSphere Storage APIs for Data Protection (vADP) に基づく Veeam およびその他のバックアップ ベンダーをサポートする完全に文書化された包括的なワークフローを通じて、オンプレミスの vSphere と VMware Cloud on AWS で仮想マシン サービスの仮想マシンのバックアップとリストアをサポートするようになりました。これにより、より完全なデータ保護ソリューションと、VMware Cloud on AWS における仮想マシン サービスの一般提供が実現します。

新機能 2022 年 5 月 12 日

2022 年 5 月 12 日ビルド情報

ESXi 7.0 Update 3d | 2022 年 3 月 29 日 | ISO ビルド 19482537

vCenter Server 7.0 Update 3e | 2022 年 5 月 12 日 | ISO ビルド 19717403

VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022 年 3 月 29 日

新機能

  • 仮想マシン オペレータ サービスを介してデプロイされた仮想マシンに対するネットワーク セキュリティ ポリシーのサポートが追加されました – NSX-T のセキュリティ ポリシーは、タグに基づきセキュリティ グループを介して作成できます。NSX-T ベースのセキュリティ ポリシーを作成し、NSX-T タグに基づき仮想マシン オペレータを介してデプロイされた仮想マシンに適用できるようになりました。

  • スーパーバイザー クラスタによる Kubernetes 1.22 のサポート - このリリースでは、Kubernetes 1.22 のサポートが追加され、Kubernetes 1.19 のサポートが削除されています。このリリースでサポートされている Kubernetes のバージョンは、1.22、1.21、および 1.20 です。Kubernetes バージョン 1.19 で実行されているスーパーバイザー クラスタは、バージョン 1.20 に自動的にアップグレードされます。これにより、すべてのスーパーバイザー クラスタがサポートされているバージョンの Kubernetes で実行されるようになります。

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

vCenter Server を 7.0 Update 3c より前のバージョンからアップグレードした際に、スーパーバイザー クラスタが Kubernetes 1.19.x で実行されている場合、tkg-manager-controller ポッドが CrashLoopBackOff 状態になり、ゲスト クラスタが制御できなくなります。次のようなエラーが表示されます。

Observed a panic: Invalid memory address or nil pointer dereference

回避策：この問題の詳細と対処方法については、ナレッジベースの記事 KB88443 を参照してください。

2022 年 3 月 29 日時点での新機能

2022 年 3 月 29 日ビルド情報

ESXi 7.0 Update 3d | 2022 年 3 月 29 日 | ISO ビルド 19482537

vCenter Server 7.0 Update 3d | 2022 年 3 月 29 日 | ISO ビルド 19480866

VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022 年 3 月 29 日

新機能

  • なし。これはバグ修正リリースです。

解決した問題

  • vTPM ホストで Spherelet VIB のインストールに失敗する

    • Spherelet VIB のインストールが、vTPM ホストで「信頼されている署名者が見つかりませんでした: 自己署名証明書」というエラーで失敗します。

  • vSphere をアップグレードすると、スーパーバイザー クラスタが不安定になる

    • vSphere 7.0 Update 1 から 7.0 Update 2 にアップグレードすると、スーパーバイザー クラスタが構成中の状態になります。

  • NSX-T Advanced Load Balancer を使用している際にスーパーバイザー クラスタの有効化が停止する

    • NSX-T Advanced Load Balancer を使用してスーパーバイザー クラスタを有効にすると、デフォルトの認証構成に基づいて構成が停止する可能性があります。

新機能 2021 年 10 月 21 日

2021 年 10 月 21 日ビルド情報

ESXi 7.0 Update 3 | 2022 年 1 月 27 日 | ISO ビルド 19193900

vCenter Server 7.0 Update 3a | 2021 年 10 月 21 日 | ISO ビルド 18778458

VMware NSX Advanced Load Balancer 20.1.7 | 2021 年 10 月 21 日 | ISO ビルド 18778458

重要：VMware は、アップグレードに影響する問題のため、2021 年 11 月 19 日に ESXi 7.0 Update 3、7.0 Update 3a および 7.0 Update 3b をすべてのサイトから削除しました。ESXi 7.0 Update 3c ISO のビルド 19193900 は、ビルド 18644231 に置き換えられます。詳細については、「VMware ESXi 7.0 Update 3c リリース ノート」を参照してください。

新機能

  • Tanzu Kubernetes Grid Service for vSphere

    • Tanzu Kubernetes クラスタで、コンテナ化されたワークロードに GPU アクセラレーションを利用できるようになりました - vSphere 管理者は GPU アクセラレーションが適用される仮想マシンを Tanzu Kubernetes クラスタにプロビジョニングできるようになり、開発者はネイティブの Kubernetes コマンドを使用して、GPU アクセラレーションが適用される仮想マシンを Tanzu Kubernetes Grid クラスタに追加できるようになりました。

    • Ubuntu 20.04 に基づく Tanzu Kubernetes リリース (TKr) - これは、Ubuntu 20.04 に基づく最初の TKr リリースです。このイメージは、GPU (AI/ML) ワークロード専用に最適化およびテストされました。詳細については、TKr リリース ノートを参照してください。

新機能 2021 年 10 月 5 日

2021 年 9 月 28 日ビルド情報

ESXi 7.0 Update 3 | 2022 年 1 月 27 日 | ISO ビルド 19193900

vCenter Server 7.0 Update 3 | 2021 年 10 月 5 日 | ISO ビルド 18700403

VMware NSX Advanced Load Balancer 20.1.6 | 2021 年 10 月 5 日 | ISO ビルド 18700403

重要：VMware は、アップグレードに影響する問題のため、2021 年 11 月 19 日に ESXi 7.0 Update 3、7.0 Update 3a および 7.0 Update 3b をすべてのサイトから削除しました。ESXi 7.0 Update 3c ISO のビルド 19193900 は、ビルド 18644231 に置き換えられます。詳細については、「VMware ESXi 7.0 Update 3c リリース ノート」を参照してください。

新機能

  • スーパーバイザー クラスタ

    • vSphere サービス - vSphere 管理者は vSphere サービス フレームワークを使用することで、MinIO、Cloudian Hyperstore、Dell ObjectScale、Velero などのスーパーバイザー サービスを非同期に管理できるようになりました。スーパーバイザー サービスは本来分離されているため、管理者は vCenter Server リリース外部のサービス カタログに新しいサービスを追加して、DevOps コミュニティをさらに強化することができます。スーパーバイザー サービスは、NSX-T Data Center ネットワークが構成されたスーパーバイザー クラスタでのみ使用できます。vSphere Client でのスーパーバイザー サービスの管理については、ドキュメントを確認してください。

    • 仮想マシン サービスでの vGPU のサポート - vSphere 管理者は Kubernetes を使用することにより、仮想マシンを介して GPU を使用するためのセルフサービス アクセス権を開発者に付与できるようになりました。この場合は、仮想マシン クラスによる制限が適用されます。DevOps ユーザーは、これらの事前定義された仮想マシン クラスとイメージを使用して、GPU を搭載した仮想マシンをすばやく作成できます。

    • DHCP ネットワークを使用したワークロード管理の有効化 - このリリースでは、代替ネットワーク セットアップ パスとして DHCP ネットワークを追加することにより、迅速な POC を簡単に有効にできます。vSphere 管理者はネットワークとポート グループを選択することで、DHCP を使用する管理ネットワークとワークロード ネットワークを構成できます。DNS、NTP、フローティング IP を含む他のすべての入力は、DHCP を使用して自動的に取得されます。

    • 有効化中のネットワークとロード バランサの健全性チェック - 有効化中にネットワーク接続、DNS、NTP、およびロード バランサ接続の健全性チェックを行うと、スーパーバイザー クラスタの有効化が成功したかどうかが検証され、人間が解読可能なエラー メッセージが表示されます。これらのメッセージは、診断を行って、一般的な問題に対処する際に役立ちます。エラー メッセージの解決方法の詳細については、ドキュメントを確認してください。

    • スーパーバイザー クラスタによる Kubernetes 1.21 のサポート - このリリースでは、Kubernetes 1.21 のサポートが追加され、Kubernetes 1.18 のサポートが削除されています。このリリースでサポートされている Kubernetes のバージョンは、1.21、1.20、および 1.19 です。Kubernetes バージョン 1.18 で実行されているスーパーバイザー クラスタは、バージョン 1.19 に自動的にアップグレードされます。これにより、すべてのスーパーバイザー クラスタがサポートされているバージョンの Kubernetes で実行されるようになります。

    • スーパーバイザー名前空間のラベルと注釈 - DevOps ユーザーが名前空間セルフサービス テンプレートを使用して作成した名前空間に、Kubernetes のラベルと注釈を設定できるようになりました。

    • 有効化後のスーパーバイザー クラスタ構成の編集 - vSphere 管理者は、vSphere ネットワーク スタックを使用するスーパーバイザー クラスタを有効にした後に、API と vSphere Client の両方に対して次の設定を編集できるようになりました。ロード バランサのユーザー名とパスワード、管理ネットワークの DNS 検索ドメイン、ワークロード ネットワークの DNS サーバ、NTP サーバ、サービスの IP アドレス範囲の拡張、新しいワークロード ネットワークの追加。vSphere ネットワークまたは NSX-T ネットワークのいずれかを使用しているクラスタでは、有効化の後に制御プレーンのサイズをスケールアップできます。現時点ではクラスタの拡張のみが可能で、クラスタの縮小はサポートされていないことに注意してください。vSphere Client を使用してスーパーバイザー クラスタの設定を変更する方法については、ドキュメントを参照してください。

    • Tanzu ライセンス キーの有効期限 - vSphere 管理者は、期限切れの Tanzu Edition ライセンス キーをさらに柔軟に管理できるようになりました。Tanzu ライセンス キーが期限切れになった場合、ハード適用は自動的に行われないため、管理者は通常の操作に影響を与えずに新しいライセンス キーを柔軟に調達して割り当てることができます。

  • Tanzu Kubernetes Grid Service for vSphere

    • vSAN パーシステント ボリュームに対する RWX のサポート - Tanzu Kubernetes クラスタで実行されているワークロードによって、vSAN ベースの RWX パーシステント ボリュームをマウントできるようになりました。

    • Tanzu Kubernetes Grid Service v1alpha2 API Update - API が Tanzu Kubernetes クラスタ API に更新されて、新しいフィールドが公開されました。これにより、複数のワーカー ノード プールのサポートなど、Tanzu Kubernetes Grid Service の構成を強化できるようになりました。新しい v1alpha2 API の優先のため、v1alpha1 API は非推奨になります。詳細については、ドキュメントを参照してください。

    • メトリック サーバ - バージョン 1.20.9 以降および 1.21 の Tanzu Kubernetes リリースでは、メトリック サーバが Tanzu Kubernetes クラスタにデフォルトで含まれるようになりました。

    • NAT 以外の（ルーティング）トポロジのサポート機能 - クラスタ ノードをクラスタ ネットワークの外部にルーティングできるネットワーク トポロジを使用して、Tanzu Kubernetes クラスタを作成できるようになりました。詳細については、ドキュメントを参照してください。

新機能 2021 年 8 月 24 日

2021 年 8 月 24 日ビルド情報

ESXi 7.0 Update 2c | 2021 年 8 月 24 日 | ISO ビルド 18426014

vCenter Server 7.0 Update 2c | 2021 年 8 月 24 日 | ISO ビルド 18356314

VMware NSX Advanced Load Balancer 20.1.5 | 2021 年 8 月 24 日 | ISO ビルド 18379150

新機能

  • スーパーバイザー クラスタ

    • スーパーバイザー クラスタによる Kubernetes 1.20 のサポート︰このリリースでは、Kubernetes 1.20 のサポートが追加され、Kubernetes 1.17 のサポートが削除されています。このリリースでサポートされている Kubernetes のバージョンは、1.20、1.19、および 1.18 です。Kubernetes バージョン 1.17 で実行されているスーパーバイザー クラスタは、バージョン 1.18 に自動的にアップグレードされます。これにより、すべてのスーパーバイザー クラスタがサポートされているバージョンの Kubernetes で実行されるようになります。

    • vSphere Pod の Velero Plugin for vSphere でのサポート：このリリースでは、vSphere Pod のバックアップとリストアのために、Velero 1.5.1 と Velero Plugin for vSphere 1.1.0 以降がサポートされています。

  • Tanzu Kubernetes Grid Service for vSphere

    • 新しいクラスタ内拡張機能の Harbor および external-dns：プラットフォーム オペレータは、追加でサポートされる 2 つのクラスタ内拡張機能 Harbor および external-dns にアクセスできるようになりました。Harbor は CNCF の Graduated のコンテナ レジストリであり、external-dns は、DNS レコードを Kubernetes のロード バランシングされたサービスに基づいて動的に構成するためによく使用されるツールです。

    • 制御プレーン ノードの修正の強化：Tanzu Kubernetes クラスタで、一般的な制御プレーン ノードの障害が自動的に修正されるようになったため、より堅牢な Kubernetes ランタイムが実現します。

    • Tanzu Kubernetes クラスタ ワークロードの Velero Plugin for vSphere でのサポート：このリリースでは、Tanzu Kubernetes クラスタで実行されているワークロードのバックアップとリストアのために、Velero 1.5.1 以降と Velero Plugin for vSphere 1.1.0 以降がサポートされています。

    • Tanzu Kubernetes クラスタ ワークロードの Velero スタンドアローン サポート：このリリースでは、Restic を備えたスタンドアローン Velero を使用して Tanzu Kubernetes クラスタ ワークロードをバックアップおよびリストアするための Velero 1.6 がサポートされています。

2021 年 4 月 27 日の新機能

2021 年 4 月 27 日ビルド情報

ESXi 7.0 | 2021 年 3 月 9 日 | ISO ビルド 17630552

vCenter Server 7.0 | 2021 年 4 月 27 日 | ISO ビルド 17920168

新機能

  • スーパーバイザー クラスタ

    • 仮想マシン サービスで Kubernetes を使用した仮想マシンの管理。このリリースでは、vSphere with Tanzu 下のインフラストラクチャ サービスに仮想マシン サービスを追加し、開発者向けの Kubernetes ネイティブ仮想マシン管理を提供します。仮想マシン サービスでは、開発者は Kubernetes コマンドを使用して名前空間で仮想マシンのデプロイと管理ができます。さらに、開発者にクラウド ネイティブ環境を提供しながら、vSphere 管理者はサービスのリソース消費と可用性を管理できます。

    • 開発者向けの名前空間のセルフサービス作成。vSphere 管理者は、セルフサービス名前空間テンプレートとしてスーパーバイザー名前空間の作成と構成ができます。使用するリソースの制限と権限は、このテンプレートで定義します。開発者は、このテンプレートで名前空間をプロビジョニングし、その中でワークロードを実行できます。名前空間を要求して承認を待つ必要はありません。

  • Tanzu Kubernetes Grid Service for vSphere

    • 重要：TKR の CVE 修正︰CVE-2021-30465 に対処する新しい Tanzu Kubernetes リリースが利用可能です。

    • 重要：Contour Ingress 拡張機能の CVE 修正︰CVE-2021-28682、CVE-2021-28683、および CVE-2021-29258 に対処する新しい Envoy イメージ バージョンがあります。詳細については、関連するナレッジベースの記事を参照してください。

    • デフォルトの仮想マシン クラスを使用するための新しいワークフロー。デフォルトの仮想マシン クラスを使用して Tanzu Kubernetes クラスタをプロビジョニングするための新しいワークフローがあります。新しいクラスタを作成する前に、クラスタをプロビジョニングする vSphere 名前空間にデフォルトの仮想マシン クラスを追加します。ガイダンスについては、ドキュメントを参照してください。

    • システムの革新をもたらす Webhook は、ドライラン モードをサポートするようになりました。また、Terraform Kubernetes プロバイダのようによく知られたツールを Tanzu Kubernetes Grid サービスと統合できるようになりました。これまで、Terraform の「plan」コマンドの要件であった、ドライラン モードがシステム Webhook ではサポートされていませんでした。

    • カスタムの仮想マシン クラス。Tanzu Kubernetes クラスタは、仮想マシン サービスを介してカスタムの仮想マシン クラスを使用できます。これにより、Tanzu Kubernetes クラスタを形成する仮想マシンに割り当てられるさまざまな容量の CPU とメモリを構成することができます。

新機能 2021 年 3 月 9 日

2021 年 3 月 9 日ビルド情報

ESXi 7.0 | 2020 年 3 月 9 日 | ISO ビルド 17630552

vCenter Server 7.0 | 2021 年 3 月 9 日 | ISO ビルド 17694817

VMware NSX Advanced Load Balancer | 2020 年 10 月 12 日 | 20.1.X

新機能

  • スーパーバイザー クラスタ

    • VDS ネットワークで構成されたスーパーバイザー クラスタ用の NSX Advanced Load Balancer のサポート。NSX Advanced Load Balancer (Avi Networks) でスーパーバイザー クラスタの L4 ロード バランシングを有効にできるだけでなく、スーパーバイザー クラスタと Tanzu Kubernetes クラスタの制御プレーン ノードのロード バランシングも有効にできるようになりました。NSX Advanced Load Balancer の構成については、ドキュメント ページを確認してください。

    • Kubernetes 1.16 を実行しているスーパーバイザー クラスタの自動アップグレードを使用した、スーパーバイザー クラスタの Kubernetes 1.19 へのアップグレード。スーパーバイザー クラスタを Kubernetes 1.19 にアップグレードできます。この更新では、次のスーパーバイザー クラスタのバージョンがサポートされます：1.19、1.18、1.17。Kubernetes 1.16 を実行しているスーパーバイザー クラスタは、vCenter Server が更新されると自動的に 1.17 にアップグレードされます。これにより、すべてのスーパーバイザー クラスタがサポート対象バージョンの Kubernetes で実行されるようになります。

    • PersistentVolumeClaim (PVC) の拡張。現在使用中のボリュームでも、PersistentVolumeClaim オブジェクトを変更すれば、拡張できるようになりました。これは、スーパーバイザー クラスタと Tanzu Kubernetes クラスタ内のボリュームに適用されます。

    • vSphere Lifecycle Manager によるスーパーバイザー クラスタ ライフサイクルの管理。NSX-T ネットワークで構成したスーパーバイザー クラスタでは、vSphere Lifecycle Manager でインフラストラクチャの構成とライフサイクルの管理ができます。

  • Tanzu Kubernetes Grid Service for vSphere

    • プライベート コンテナ レジストリのサポート。vSphere 管理者と Kubernetes プラットフォーム オペレータは、Tanzu Kubernetes クラスタで使用する追加の認証局証明書 (CA) を定義して、プライベート コンテナ レジストリの信頼性を保証できるようになりました。この機能により、Tanzu Kubernetes クラスタは、エンタープライズ証明書または自己署名証明書を持つコンテナ レジストリからコンテナ イメージをプルできます。スーパーバイザー クラスタ全体で、または Tanzu Kubernetes クラスタごとに、プライベート CA を Tanzu Kubernetes クラスタのデフォルトとして構成できます。Tanzu Kubernetes クラスタに対してプライベート コンテナ レジストリのサポートを構成する方法については、ドキュメント ページを参照してください。

    • ユーザー定義の IP アドレスの使用（LoadBalancer with NSX-T と NSX Advanced Load Balancer 向けのユーザー定義の IP アドレス。Kubernetes アプリケーション オペレータは、サービス タイプ LoadBalancer の構成時にユーザー定義の LoadBalancerIP を指定することで、サービスに固定 IP アドレスのエンドポイントを許可できるようになりました。この高度な機能には、スーパーバイザー クラスタによる NSX-T ロード バランシングまたは NSX Advanced Load Balancer が必要です。この機能の構成方法については、ドキュメントを参照してください。

    • NSX-T でのサービス タイプ：LoadBalancer with NSX-T 向けの ExternalTrafficPolicy と LoadBalancerSourceRanges。Kubernetes アプリケーション オペレータは、サービスのために「local」の ExternalTrafficPolicy を構成して、クライアント IP アドレスをエンド ポッドに伝えることができるようになりました。また、サービスの loadBalancerSourceRanges を定義することにより、ロード バランシングされるサービスにアクセスできるクライアントの数を制限することもできます。この 2 つの高度な機能には、スーパーバイザー クラスタによる NSX-T ロード バランシングが必要です。

    • Kubernetes のバージョン管理と表示。TanzuKubernetesReleases と基盤となるスーパーバイザー クラスタ環境との互換性を kubectl で確認できるようになりました。Tanzu Kubernetes クラスタでは、Kubernetes の利用可能なアップグレードがあるかどうか、および今後使用することが推奨される TanzuKubernetesRelease が示されます。この新機能の使用の詳細については、ドキュメント ページを参照してください。

    • クラスタのステータスを一目で確認。前回リリースでは、VMware は条件付きステータス レポート機能を実装して WCPCluster CRD と WCPMachine CRD を拡張して一般的な問題やエラーを検出していました。vSphere 7.0 Update 2 リリースでは TanzuKubernetesCluster CRD を強化して、サブシステム コンポーネントの条件付きステータス レポートのサマリを提供し、問題の調査に役立つ直接的な答えと詳細なガイダンスを提供しています。この機能を構成する方法については、ドキュメント ページを参照してください。

    • Tanzu Kubernetes クラスタ単位の HTTP プロキシ構成。HTTP/HTTPS プロキシ構成は、Tanzu Kubernetes クラスタ単位か、デフォルト構成によるスーパーバイザー クラスタ全体のいずれかで定義できるようになりました。この機能の構成の詳細については、ドキュメント ページを参照してください。

    • Tanzu Kubernetes Grid 拡張機能のサポート。Fluent Bit、Contour、Prometheus、AlertManager、Grafana などのクラスタ内拡張機能は、Tanzu Kubernetes Grid サービスで全面的なサポート対象になりました。

Tanzu Kubernetes クラスタの更新に関する考慮事項

vSphere 7.0 Update 2 リリースには、vCenter Server が更新されると自動的にスーパーバイザー クラスタがアップグレードされる機能が含まれています。環境内に Tanzu Kubernetes クラスタがプロビジョニングされている場合は、vCenter Server 7.0 Update 2 にアップグレードする前にナレッジベースの記事 KB82592 を参照してください。この記事では、スーパーバイザー クラスタが自動アップグレードされた後に互換性を失う Tanzu Kubernetes クラスタがないかどうか、事前チェックを実行して判断するためのガイダンスを提供します。

解決した問題

  • 組み込みのコンテナ レジストリの SSL 証明書が Tanzu Kubernetes クラスタ ノードにコピーされない

    • スーパーバイザー クラスタに対して組み込みのコンテナ レジストリが有効になっている場合、そのスーパーバイザー クラスタに作成された Tanzu Kubernetes クラスタ ノードには Harbor SSL 証明書が含まれていないため、これらのノードからレジストリに接続することはできません。

  • Tanzu Kubernetes Grid 1.16.8 から 1.17.4 にアップグレードすると、いずれかの制御プレーン ノードの「guest-cluster-auth-svc」ポッドが「コンテナ作成中」状態で停止する

    • Tanzu Kubernetes クラスタを Tanzu Kubernetes Grid サービス 1.16.8 から 1.17.4 にアップデートした後、いずれかのクラスタ制御プレーン ノードの「guest-cluster-auth-svc」ポッドが「コンテナ作成中」の状態で停止します。

  • ユーザーは、クラスタの更新の実行中または実行後に、Tanzu Kubernetes クラスタの既存のポッドを管理できない

    • ユーザーは、クラスタの更新の実行中または実行後に、Tanzu Kubernetes クラスタの既存のポッドを管理できない

  • Tanzu Kubernetes クラスタのアップグレード ジョブが「etcd 健全性チェック完了の待機中にタイムアウトになりました」というエラーで失敗する

    • Tanzu Kubernetes クラスタのアップグレードに関連付けられている vmware-system-tkg 名前空間内のアップグレード ジョブが、「etcd 健全性チェック完了の待機中にタイムアウトになりました」というエラー メッセージと共に失敗します。この問題は、etcd ポッドの PodIP アドレスが見つからないことが原因で発生します。

  • Antrea CNI は現在の TKC バージョンでサポートされない

    • Tanzu Kubernetes クラスタをプロビジョニングしているときに、「Antrea CNI not supported in current TKC version」というエラーが表示されます。

      オプション 1（推奨）：Antrea（v 1.17.8 以降）をサポートする OVA バージョンを使用するように、Tanzu Kubernetes クラスタを更新します。

      オプション 2：Tanzu Kubernetes クラスタ仕様の YAML で、spec.settings.network.cni セクションに「calico」と入力します。

      オプション 3：デフォルトの CNI を Calico に変更します。これを行う方法については、ドキュメントのトピックを参照してください。

新機能 2021 年 2 月 2 日

2021 年 2 月 2 日ビルド情報

ESXi 7.0 | 2020 年 12 月 17 日 | ISO ビルド 17325551

vCenter Server 7.0 | 2021 年 2 月 2 日 | ISO ビルド 17491101

新機能

  • スーパーバイザー クラスタ

    • vSphere ネットワークを使用するスーパーバイザー クラスタのアップデート：vSphere ネットワークを使用するスーパーバイザー クラスタを、Kubernetes の以前のバージョンから最新のバージョンにアップデートできるようになりました。スーパーバイザー クラスタの新しいバージョンでは、最新の Tanzu Kubernetes Grid Service 機能も利用できるようになりました。

解決した問題

  • 新しい Tanzu Kubernetes Grid Service 機能が、vSphere ネットワークを使用する既存のスーパーバイザーで利用できない

    • 以前のリリースでは、新しい Tanzu Kubernetes Grid Service 機能とバグ修正は、vSphere ネットワークが使用されていたときに新しく作成されたスーパーバイザー クラスタでの使用に限定されていました。本リリースでは、ユーザーは vSphere ネットワークを使用するスーパーバイザー クラスタをアップデートすることで、最新の Tanzu Kubernetes Grid Service 機能とバグ修正を利用できます。

新機能 2020 年 12 月 17 日

2020 年 12 月 17 日ビルド情報

ESXi 7.0 | 2020 年 12 月 17 日 | ISO ビルド 17325551

vCenter Server 7.0 | 2020 年 12 月 17 日 | ISO ビルド 17327517

注：本リリースの新しい Tanzu Kubernetes Grid サービス機能とバグ修正を利用するには、vSphere ネットワークを使用している場合は、新しいスーパーバイザー クラスタを作成する必要があります。

新機能

  • スーパーバイザー クラスタ

    • 専用 T1 ルーターによるスーパーバイザー名前空間の隔離。NSX-T ネットワークを使用するスーパーバイザー クラスタは、名前空間ごとに専用の T1 ルーターが割り当てられる新しいトポロジを使用します。

      • 新規に作成されたスーパーバイザー クラスタは、この新しいトポロジを自動的に使用します。

      • 既存のスーパーバイザー クラスタは、アップグレード中にこの新しいトポロジに移行されます。

    • スーパーバイザー クラスタは NSX-T 3.1.0 をサポート。スーパーバイザー クラスタは、NSX-T 3.1.0 と互換性があります。

    • スーパーバイザー クラスタ バージョン 1.16.x のサポートを廃止。スーパーバイザー クラスタ バージョン 1.16.x は削除されました。バージョン 1.16.x を実行しているスーパーバイザー クラスタは、新しいバージョンにアップグレードする必要があります。

  • Tanzu Kubernetes Grid Service for vSphere

    • HTTP/HTTPS プロキシのサポート。新規に作成した Tanzu Kubernetes クラスタでは、出力方向トラフィックだけでなく、インターネット レジストリからのコンテナ イメージのプルにもグローバル HTTP/HTTPS プロキシを使用できます。

    • レジストリ サービスとの統合。新規に作成した Tanzu Kubernetes クラスタは、特別な設定を必要とせずに vSphere レジストリ サービスで使用できます。既存のクラスタは、新しいバージョンに更新すると、レジストリ サービスと統合されます。

    • 構成可能なノード ストレージ。Tanzu Kubernetes クラスタは、仮想マシンにストレージ ボリュームを追加マウントできるようになり、使用可能なノードのストレージ容量を拡張できます。これにより、デフォルトの 16 GB のルート ボリューム サイズを超える可能性のある、より大きなコンテナ イメージをデプロイできるようになります。

    • ステータス情報の強化。WCPCluster と WCPMachine のカスタム リソース定義には、条件付きステータス レポートが実装されました。正常な Tanzu Kubernetes クラスタのライフサイクル管理は、複数のサブシステム（スーパーバイザー、ストレージ、ネットワークなど）に依存しているため、障害の把握が難しいことがあります。WCPCluster と WCPMachine CRD から共通のステータスと障害状態が表示されるようになったことで、トラブルシューティングが簡素化されました。

解決した問題

  • vCenter Server 7.0 Update 1 に導入された新しいデフォルトの仮想マシン クラスが見つからない

    • vSphere 7.0.1 をアップグレードし、スーパーバイザークラスタの vSphere 名前空間の更新を実行すると、コマンド「kubectl get virtualmachineclasses」を実行しても、新しい仮想マシン クラスのサイズの 2x-large、4x-large、8x-large がリストされません。この問題は解決され、すべてのスーパーバイザー クラスタが、デフォルトの仮想マシン クラスの正しいセットで構成されます。

新機能 2020 年 10 月 6 日

2020 年 10 月 6 日ビルド情報

ESXi 7.0 | 2020 年 10 月 6 日 | ISO ビルド 16850804

vCenter Server 7.0 | 2020 年 10 月 6 日 | ISO ビルド 16860138

新機能

  • スーパーバイザー クラスタ

    • vSphere ネットワークを使用したスーパーバイザー クラスタの構成。スーパーバイザー クラスタ向けの vSphere ネットワークが導入され、既存のネットワーク インフラストラクチャで開発者対応のプラットフォームを提供できます。

    • vSphere ネットワークを使用したスーパーバイザー クラスタを設定するための HAproxy ロード バランサのサポート。vSphere ネットワークでスーパーバイザー クラスタを構成する場合、最新のワークロードを処理できるよう、ロード バランサを追加する必要があります。ロード バランサを HAProxy OVA でデプロイし、設定することができます。

    • vSphere Lifecycle Manager によるスーパーバイザー クラスタ ライフサイクルの管理。vSphere ネットワークで構成したスーパーバイザー クラスタの場合、vSphere Lifecycle Manager でインフラストラクチャの構成とライフサイクルの管理ができます。

    • ご使用のハードウェアで vSphere with Tanzu を試すチャンス。ご使用のハードウェアでスーパーバイザー クラスタを有効にし、この最新アプリケーション プラットフォームを追加コストなしでテストすることをご検討の皆様には製品内評価版を用意しています。

  • Tanzu Kubernetes Grid Service for vSphere

    • DevOps ユーザー対応の Kubernetes バージョンの導入。スーパーバイザー クラスタに新しい「TanzuKubernetesRelease」カスタム リソース定義を導入しました。このカスタム リソース定義では、DevOps ユーザーに対し、Tanzu Kubernetes クラスタで使用可能な Kubernetes バージョンに関する詳細情報が提供されます。

    • VMware Container Networking と Antrea for Kubernetes の統合。新しい Tanzu Kubernetes クラスタ用のデフォルトのコンテナ ネットワーク インターフェイス (CNI) として、商用でサポートされているバージョンの Antrea を統合しました。Antrea は、包括的なエンタープライズ ネットワーク ポリシー機能を Tanzu Kubernetes Grid サービスに提供します。詳細については、リリースに関するお知らせを参照してください。Antrea はデフォルトの CNI ですが、vSphere 管理者および DevOps ユーザーは引き続き Calico を Tanzu Kubernetes クラスタの CNI として選択できます。

    • vSphere ネットワークを使用するスーパーバイザー クラスタ環境のサポート。vSphere ネットワークを使用するスーパーバイザー クラスタ環境をサポートするようになりました。これで、既存のネットワーク インフラストラクチャを活用できます。

解決した問題

  • リストはありません。これは機能リリースです。

新機能 2020 年 8 月 25 日

2020 年 8 月 25 日ビルド情報

ESXi 7.0 | 2020 年 6 月 23 日 | ISO ビルド 16324942

vCenter Server 7.0 | 2020 年 8 月 25 日 | ISO ビルド 16749653

新機能

  • なし。これはバグ修正リリースです。

解決した問題

  • 7 月 30 日のパッチにアップグレードすると、CPU 使用率が上昇する

    • 7 月 30 日のパッチにアップグレードすると、vCenter Server の CPU 使用率が上昇します。この問題は現在修正されています。

  • Windows の行末を含む証明書が原因でスーパーバイザー クラスタの有効化に失敗する

    • 証明書に Windows の行末が含まれていると、スーパーバイザー クラスタを有効にできないことがあります。この問題は現在修正されています。

新機能 2020 年 7 月 30 日

2020 年 7 月 30 日ビルド情報

ESXi 7.0 | 2020 年 6 月 23 日 | ISO ビルド 16324942

vCenter Server 7.0 | 2020 年 7 月 30 日 | ISO ビルド 16620007

新機能

  • スーパーバイザー クラスタ：新バージョンの Kubernetes、カスタム証明書および PNID 変更のサポート

    • スーパーバイザー クラスタは、Kubernetes 1.18.2 を（1.16.7 および 1.17.4 とともに）サポートするようになりました

    • マシン SSL 証明書をカスタム証明書に置き換える処理がサポートされるようになりました

    • vCenter Server にスーパーバイザー クラスタがある場合、vCenter Server PNID のアップデートがサポートされるようになりました

  • Tanzu Kubernetes Grid Service for vSphere：クラスタのスケールイン、ネットワーク、およびストレージについて新機能が追加されました

    • Tanzu Kubernetes Grid サービス クラスタで、クラスタのスケールイン処理がサポートされるようになりました

    • すべての Tanzu Kubernetes Grid サービス クラスタで、入力方向のファイアウォール ルールがデフォルトで適用されるようになりました

    • 定期的に非同期で vSphere に配布される Kubernetes 新バージョンのパッチ、現行バージョンは 1.16.8、1.16.12、1.17.7、1.17.8

  • ネットワーク サービス：NSX Container Plug-in (NCP) の新バージョン

    • ClusterIP サービスで SessionAffinity がサポートされるようになりました

    • Kubernetes 1.18 の入力側で、IngressClass、PathType、および Wildcard ドメインがサポートされます

    • クライアント認証が入力側コントローラでサポートされるようになりました

  • レジストリ サービス：Harbor の新バージョン

    • レジストリ サービスが 1.10.3 にアップグレードされました

アップグレード方法の詳細と手順については、「vSphere with Tanzu クラスタの更新」ドキュメントを参照してください。

解決した問題

  • Tanzu Kubernetes Grid サービス クラスタの NTP 同期の問題

新機能 2020 年 6 月 23 日

2020 年 6 月 23 日ビルド情報

ESXi 7.0 | 2020 年 6 月 23 日 | ISO ビルド 16324942

vCenter Server 7.0 | 2020 年 6 月 23 日 | ISO ビルド 16386292

Tanzu Kubernetes クラスタ OVA：v1.16.8+vmware.1-tkg.3.60d2ffd

新機能

  • なし。これはバグ修正リリースです。

解決した問題

  • Tanzu Kubernetes Grid サービス クラスタのアップグレードの失敗

    • Tanzu Kubernetes Grid サービス クラスタのアップグレードが「Error: unknown previous node」が原因で失敗するという問題が解決されました。

  • スーパーバイザー クラスタのアップグレードの失敗

    • 組み込みの Harbor が障害状態のときにスーパーバイザー クラスタの更新が停止することがある問題が解決されました。

新機能 2020 年 5 月 19 日

2020 年 5 月 19 日ビルド情報

ESXi 7.0 | 2020 年 4 月 2 日 | ISO ビルド 15843807

vCenter Server 7.0 | 2020 年 5 月 19 日 | ISO ビルド 16189094

Tanzu Kubernetes クラスタ OVA：v1.16.8+vmware.1-tkg.3.60d2ffd

新機能

  • Tanzu Kubernetes Grid Service for vSphere：ローリング アップグレードとサービスのアップグレード

    • Tanzu Kubernetes Grid Service for vSphere のワーカー ノードおよび制御プレーン ノードでローリング アップグレードを実行し、pvCSI、Calico、および authsvc サービスをアップグレードできるようになりました。これには、このサービスのマトリックスの事前チェックとアップグレード互換性が含まれます。

    • ローリング アップグレードは、ワーカー ノードの垂直方向のスケーリングに使用できます。つまり、ワーカー ノードの仮想マシン クラスをより小さいサイズまたはより大きなサイズに変更できます。

  • スーパーバイザー クラスタ：Kubernetes の新しいバージョン、アップグレードのサポート

    • スーパーバイザー クラスタが Kubernetes 1.17.4 をサポートするようになりました。

    • スーパーバイザー クラスタが Kubernetes 1.16.x から 1.17.x へのアップグレードをサポートするようになりました

解決した問題

  • 削除された名前空間の名前の競合

    • ユーザーが vSphere 名前空間を削除して同じ名前の新しい vSphere 名前空間を作成したときに、名前の競合が発生し、Tanzu Kubernetes クラスタを作成できないという問題が修正されました。

  • ディストリビューション名の向上

    • OVF のバージョン情報を別の列に移動することで、実行している Kubernetes のバージョンを明確にしました。

vSphere with Kubernetes の初回リリースのビルド情報

2020 年 4 月 2 日ビルド情報

ESXi 7.0 | 2020 年 4 月 2 日 | ISO ビルド 15843807

vCenter Server 7.0 | 2020 年 4 月 2 日 | ISO ビルド 15952498

Tanzu Kubernetes クラスタ OVA：v1.16.8+vmware.1-tkg.3.60d2ffd

vSphere with Tanzu について

VMware は、vSphere with Tanzu について学習するために使用できるさまざまなリソースを提供しています。

  • vSphere with Tanzu の構成、管理、および使用方法については、『vSphere with Tanzu の構成と管理』を参照してください。このガイドは、vSphere のシステム管理者と DevOps チーム向けに設計されています。vSphere with Tanzu のアーキテクチャ、サービス、ライセンス、システム要件、セットアップ、使用方法についての詳細を説明しています。

  • vSphere with Tanzu のハードウェア互換性と製品の相互運用性 については、『VMware 互換性ガイド』を使用してください。vSphere with Tanzu には、vSphere 7.0 と同じハードウェア要件があります。特定の構成では、NSX-T Edge 仮想マシンも使用する必要があります。また、これらの仮想マシンでは、CPU 互換性の範囲がより狭くなります。詳細については、『NSX-T Data Center インストールガイド』を参照してください。

  • vSphere with Tanzu で使用可能な言語については、vSphere 7.0 リリース ノートの「利用可能な言語」のセクションを参照してください。vSphere と同じ言語が使用可能です。

  • vSphere with Tanzu オープン ソース コンポーネントの著作権およびライセンスについては、vSphere 7.0 リリース ノートの「vSphere 7.0 用オープン ソース コンポーネント」のセクションを参照してください。vSphere 7.0 リリース ノートには、vSphere のオープン ソース コンポーネントのダウンロードの場所についても記載されています。

解決した問題

  • vCenter Server を vCenter Server 7.0 Update 2c にアップグレードすると、[名前空間の概要] ページの仮想マシン サービス カードが表示されなくなる

    vCenter Server を vCenter Server 7.0 Update 2a から vCenter Server 7.0 Update 2c にアップグレードした後、アップグレード前に作成された既存の名前空間の [名前空間の概要] ビューに、仮想マシン クラスとコンテンツ ライブラリのカードが表示されません。これは、アップグレード元が vCenter Server 7.0 Update 2a の場合の固有の問題です。vCenter Server 7.0 Update 2 などの以前のバージョンからアップグレードした場合は、影響を受けません。

    影響を受ける名前空間の場合、スーパーバイザー クラスタをアップグレードすると、[名前空間の概要] ビューのカードがリストアされます。

  • 仮想マシンのハードウェア バージョンに互換性がない場合、仮想マシン サービスで作成した仮想マシンで特定の操作が失敗する場合がある

    OVF イメージの仮想マシンのハードウェア バージョンが操作をサポートしていない場合、仮想マシン上の操作は失敗します。たとえば、仮想ハードウェア バージョン vmx-11 のイメージの場合、パーシステント ボリュームを接続しようとすると次のエラーで失敗します。

    Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed

    回避策：なし

  • スーパーバイザー クラスタのアップグレード中に、デーモンのセットが使用される場合、余分な vSphere ポッドが作成され、保留中の状態で停止することがある

    スーパーバイザー クラスタのアップグレード中に、デーモン セット コントローラによって、スーパーバイザー制御プレーン ノードごとに余分な vSphere ポッドが作成されます。これは、アップストリーム Kubernetes の問題が原因で発生します。

    回避策：vSphere ポッド仕様に NodeSelector/NodeAffinity を追加し、デーモン セット コントローラがポッド作成の制御プレーン ノードをスキップできるようにします。

  • ポッドの作成が断続的に失敗する

    一部の環境で、ポッドの作成が次のエラーを表示して断続的に失敗します：「イメージの取得に失敗しました。「ホストへのルートがありません」エラーで接続がタイムアウトになりました。」これは、イメージ取得の要求時に、デフォルトで 3 秒のタイムアウトが設定されていることが原因で発生します。

    デフォルトのタイムアウト値を増やすには、VMware サポートにお問い合わせください。

  • vCenter Server に切断されたホストが多数ある場合、スーパーバイザー サービスがクラッシュすることがある

    ユーザー名とパスワードが正しくないために多くのホストが切断されている環境では、スーパーバイザー サービスがクラッシュし、再度起動できない場合があります。

    この問題は最新リリースで修正されました。

  • vCenter Server 7.0 Update 3 で NSX-T Data Center を使用したスーパーバイザー クラスタを構成すると失敗することがある

    NSX-T Data Center を使用してスーパーバイザー クラスタを構成すると、ESXi ホストへの Spherelet VIB のインストールが失敗して、次のエラーが表示されることがあります。

    Could not find a trusted signer: self signed certificate

    自己署名された Spherelet VIB は、vCenter Server 7.0 Update 3 にバンドルされています。ただし、vSphere クラスタに含まれている ESXi ホストでセキュア ブートが有効になっていない場合、またはクラスタ内のこのホストで vSphere Life Cycle Manager (vLCM) が有効になっていない場合は、スーパーバイザー クラスタを有効にする操作が成功します。この問題は最新リリースで修正されました。

  • WCP サービスが開始しなかったことが原因で vCenter Server 70u3f へのアップグレードに失敗する

    ナレッジベースの記事 KB89010を参照してください。

    この回避策は、失敗状態の vCenter Server 7.0u3f 自体、または 7.0u3f へのアップグレードを開始する前の vCenter Server 7.0u3d のいずれかに適用できます。

    1.root 認証情報を使用して、vCenter Server SSH セッションに接続します。

    2.次のコマンドを使用して WCP データベースに接続します。

    PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost

    3.次のコマンドを実行して、instance_id が null のエントリを確認します。

    SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;

    4.cluster_db_configs の instance_id が null の場合、ランダムな UUID に更新します。

    UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;

    5.DB エントリが修正されたら、WCP サービス（およびアップグレード後に開始されていない他のすべてのサービス）を再開する必要があります。

    service-control --status --all

    service-control --restart --all (--stop または --start)

    または

    service-control --restart wcp (--stop または --start)

    6.手順 2 と 3 を再実行して、instance_id が NULL でないことを確認します。vCenter Server が実行されます。

    7.この段階で、ユーザーが vCenter Server 70u3d でこの回避策を適用している場合は、vCenter Server 70u3f へのアップグレードに進みます。または、ユーザーが vCenter Server 70u3f で回避策を適用している場合は、VMware Appliance Management Interface (VAMI) または CLI インストーラにアクセスして、アップグレードを再開します。

  • アップグレード後にセキュリティ ポリシー機能を使用できない場合がある

    NSX-T 3.1.x/3.0.x が存在する場合に、vCenter Server をアップグレードしてからスーパーバイザーをアップグレードし、最後に NSX-T 3.2 以降にアップグレードすると、セキュリティ ポリシー機能を使用できない可能性があります。これは、NCP が NSX-T のアップグレードを認識しないためです。

  • LRO を有効にした状態で Antrea-ENCAP を使用する Tanzu Kubernetes Grid クラスタ仮想マシンのネットワーク スループット パフォーマンスを向上

    データ パスの最適化が追加され、LRO を有効にした状態で Antrea-ENCAP を使用する Tanzu Kubernetes Grid クラスタ仮想マシンのネットワーク スループット パフォーマンスが向上します。

    なし

  • スーパーバイザーで組み込みの Harbor レジストリを有効にすると、デフォルト構成が安全でなくなる可能性がある

    「スーパーバイザー クラスタの組み込み Harbor レジストリの有効化」に記載されている手順を完了すると、組み込みの Harbor レジストリのデフォルト構成が安全でなくなる可能性があります。この問題の詳細については、VMware ナレッジベースの記事 KB91452 を参照してください。

    回避策：この問題を解決するには、本リリースをインストールするか、KB91452 の説明に従って一時的な回避策を実行します。

既知の問題

既知の問題には、次のトピックが含まれます。

スーパーバイザー クラスタ

  • <span style="color:#FF0000">NEW：</span>vSAN などの共有データストアから複数の FCD とボリュームを削除すると、パフォーマンスが変化する場合がある

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

    回避策：なし。パフォーマンスの変化に関係なく、通常どおりに削除操作を実行できます。

  • 切断された ESXi ノードをクラスタから移動した後も、このノードが同じデータセンターに残っている場合は、ノードで実行されているポッドと PVC が終了状態のままになる

    PSOD が原因で ESXi ホストが応答しない状態になったため、このホストを同じデータセンター内のクラスタの外部に移動した場合、このホストで実行されているポッドと PVC が終了状態で停止します。この問題は、クラスタでスペア ノードが使用可能な場合でも発生します。

    通常、この問題は次の状況になった場合に発生します。

    1. スーパーバイザー クラスタでパートナー サービスを有効にして、サービスのインスタンスを作成します。

    2. サービス インスタンスが実行されている ESXi ノードで PSOD が発生します。

    3. 応答しないホストを切断して、同じデータセンター内のクラスタの外部に移動します。

      ホストがクラスタの外部にある場合、ノードに存在するポッドと PVC が終了状態のままであると表示されることがあります。

    回避策：ホストを同じデータセンターのクラスタの外部に移動せず、インベントリから削除します。

  • DRS が手動モードに設定されていると、スーパーバイザー クラスタでポッドの作成に失敗することがある

    ワークロード管理を有効にするクラスタでも、HA と自動 DRS を有効にする必要があります。HA および DRS が有効でないクラスタや、DRS が手動モードで実行されているクラスタでワークロード管理を有効にすると、動作が不安定になり、ポッドの作成に失敗する可能性があります。

    回避策：クラスタで DRS を有効にし、[完全自動化] または [一部自動化] に設定します。さらに、HA がクラスタで有効になっていることも確認します。

  • 対応するストレージ ポリシーを削除した後でも、kubectl get sc を実行するとストレージ クラスが表示される

    ストレージ ポリシーを作成してそのポリシーを名前空間に追加し、ポリシーを削除した後で kubectl get sc を実行した場合、対応するストレージ クラスがコマンド応答に一覧表示されます。

    回避策：kubectl describe namespace を実行すると、名前空間に実際に関連付けられているストレージ クラスを確認できます。

  • スーパーバイザー クラスタで kubectl describe storage-class または kubectl get storage-class を実行すると、スーパーバイザー名前空間のストレージ クラスではなく、すべてのストレージ クラスが返される

    スーパーバイザー クラスタで kubectl describe storage-class または kubectl get storage-class コマンドを実行すると、スーパーバイザー ネームスペースのストレージ クラスだけではなく、すべてのストレージ クラスが返されます。

    回避策：名前空間に関連付けられているストレージ クラス名を、割り当ての詳細名から推測します。

  • 構成した FQDN が Kubernetes API エンドポイントの共有ボタンで無視される

    スーパーバイザー クラスタ名前空間の Kubernetes 制御プレーン IP アドレスに FQDN が構成されている場合でも、名前空間の共有ボタンで FQDN ではなく IP アドレスが取得されます。

    回避策：FQDN を使用してスーパーバイザー クラスタ名前空間を手動で共有します。

  • kubectl vSphere によるログインでロード バランサにアクセスできない

    ロード バランシングされたエンドポイントを使用している場合、kubectl vSphere によるログインで API サーバにアクセスすることはできません。

    回避策：これは 2 つの方法で確認できます。

    1. 制御プレーンで <curl -k https://vip:6443（または 443）> を実行し、API サーバにアクセスできるかどうかを確認します。

      1. API サーバからロード バランサにアクセスできない場合、API サーバはまだ稼動していません。

      2. 回避策：API サーバがアクセス可能になるまで数分待ちます。

    2. エッジ仮想マシン ノードの状態が接続中であることを確認します。

      1. NSX Manager にログインします。

      2. [システム] > [ファブリック] > [ノード] > [エッジ トランスポート ノード] の順に移動します。ノードの状態が接続中になっている必要があります。

      3. [ネットワーク] > [ロード バランサ] > [仮想サーバ] の順に移動します。末尾が kube-apiserver-lb-svc-6443 と kube-apiserver-lb-svc-443 の仮想マシン IP アドレスを見つけます。状態が接続中でない場合は、次の回避策を使用します。

      4. 回避策：エッジ仮想マシンを再起動します。再起動後にエッジ仮想マシンを再構成する必要があります。

  • vSphere with Tanzu のクラスタ構成で、構成中にタイムアウト エラーが表示される

    クラスタの構成中に次のエラー メッセージが表示されることがあります。

    Api request to param0 failed

    または

    Config operation for param0 node VM timed out

    回避策：なし。vSphere with Tanzu が有効になるまでに 30 分から 60 分かかります。このような param0 のタイムアウト メッセージはエラーではないため、無視してかまいません。

  • vSphere with Tanzu で vSphere サービスを無効にしてすぐに再度有効にすると、vCenter Server の対応する名前空間が応答しなくなる

    vSphere サービスを無効にしてすぐに再度有効にすると、スーパーバイザー クラスタの名前空間が削除され、再作成されます。ただし、vCenter Server の対応する名前空間は「終了」状態のままになります。その結果、リソースを vCenter Server の名前空間に割り当てることができず、DevOps エンジニアは、名前空間にポッドや PVC などのリソースを作成できません。また、サービス オペレータ ポッドを実行できないため、ユーザー インターフェイス プラグインのデプロイに失敗します。

    スーパーバイザー クラスタで次のコマンドを実行すると、App Platform のログを取得できます。kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0

    回避策：

    サービスを再度有効にする前に、名前空間が vCenter Server から完全に削除されるのを待ちます。

    名前空間が終了状態で停止している場合は、次の手順を実行します。

    1.サービスを再度無効にします。

    2.vCenter Server で wcp サービスを再起動します。

    3.名前空間が削除されるのを待ちます。この手順には時間がかかることがあります。

    4.サービスを再度有効にします。

  • コンテナ レジストリの有効化がエラーで失敗する

    ユーザーがユーザー インターフェイスからコンテナ レジストリを有効にすると、有効化アクションは 10 分後にタイムアウト エラーで失敗します。

    回避策：コンテナ レジストリを無効にし、有効化を再試行します。タイムアウト エラーが再度発生する可能性があることに注意してください。

  • クラスタを無効にした後で有効にするとエラーで失敗する

    クラスタを無効にした直後にクラスタを有効にすると、サービス アカウントのパスワードのリセット プロセスで競合が発生する可能性があります。有効化アクションがエラーで失敗します。

    回避策：vmon-cli --restart wcp コマンドを使用して再起動します。

  • 組み込みのコンテナ レジストリ内のコンテナ イメージ タグを削除すると、同じ物理コンテナ イメージを共有しているすべてのイメージ タグが削除されることがある

    同じコンテナ イメージから、異なるタグを持つ複数のイメージを組み込みのコンテナ レジストリ内のプロジェクトにプッシュすることができます。プロジェクトのいずれかのイメージを削除すると、同じイメージからプッシュされた異なるタグを持つ他のすべてのイメージが削除されます。

    回避策：この操作は元に戻せません。イメージをプロジェクトに再度プッシュします。

  • レジストリ プロジェクトでパージ操作に失敗すると、プロジェクトが「エラー」状態になる

    レジストリ プロジェクトに対してパージ操作を実行すると、そのプロジェクトは一時的にエラー状態として表示されます。このようなプロジェクトではイメージをプッシュまたはプルすることはできません。プロジェクトは定期的にチェックされ、エラー状態のプロジェクトはすべて削除されて再作成されます。この状況が発生すると、以前のすべてのプロジェクト メンバーが再作成されたプロジェクトに再度追加されます。これにより、プロジェクトに以前に含まれていたすべてのリポジトリとイメージが削除され、実質的にパージ操作が完了します。

    回避策：なし。

  • ストレージ容量が 2,000 MiB 未満のときにコンテナ レジストリの有効化に失敗する

    コンテナ レジストリには、VMODL の「制限」フィールドとして扱われる合計ストレージ容量の最小要件があります。これは、一部の Kubernetes ポッドが正常に動作するためには十分なストレージ容量が必要になるためです。コンテナ レジストリ機能を実現するには、最小 5 GB の容量が必要です。この制限によってパフォーマンスの向上やサポート可能なイメージの数またはサイズの増加が確実に実現されるわけではないことに注意してください。

    回避策：この問題を回避するには、合計容量が大きいコンテナ レジストリをデプロイします。推奨されるストレージ ボリュームは、5 GB 以上です。

  • Kubernetes クラスタ用の NSX ロードバランサの TLS 証明書を置き換えると、Docker クライアントまたは Harbor ユーザー インターフェイスから組み込みの Harbor レジストリへのログインが失敗することがある

    Kubernetes クラスタ用の NSX ロードバランサの TLS 証明書を置き換えるには、vSphere ユーザー インターフェイスから [構成] > [名前空間] > [証明書] > [NSX ロードバランサ] > [アクション] に移動し、[証明書の置き換え] をクリックします。NSX の証明書を置き換えると、Docker クライアントまたは Harbor ユーザー インターフェイスから組み込みの Harbor レジストリへのログイン操作が「unauthorized: authentication required」または「Invalid user name or password」というエラーで失敗することがあります。

    回避策：レジストリ エージェント ポッドを vmware-system-registry 名前空間で再起動します。

    1. kubectl get pod -n vmware-system-registry コマンドを実行します。

    2. kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry コマンドを実行してポッドの出力を削除します。

    3. ポッドが再起動するまで待機します。

  • DNSDefault でデプロイされたポッドは、clusterDNS 設定を使用する

    DNSDefault を使用するスーパーバイザー クラスタにデプロイされた vSphere ポッドは、クラスタ用に構成された clusterDNS を使用するようにフォールバックされます。

    回避策：なし。

  • スーパーバイザー クラスタをアップグレードするときに、クラスタ内のすべてのホストが同時に更新されることがある

    場合によっては、クラスタ内のすべてのホストがスーパーバイザー クラスタのアップグレード プロセスで並行して更新されます。これにより、このクラスタで実行されているすべてのポッドでダウンタイムが発生します。

    回避策：スーパーバイザー クラスタのアップグレード中は、wcpsvc を再起動したり、ホストを削除または追加したりしないでください。

  • VMCA を中間 CA として使用すると、スーパーバイザー クラスタのアップグレードが無期限に停止することがある

    VMCA が中間 CA として使用されている場合、スーパーバイザー クラスタのアップグレードは「構成中」で無期限に停止する可能性があります。

    回避策：VMCA 用の非中間 CA に切り替え、「構成中」で停止しているすべての制御プレーン仮想マシンを削除します。

  • 暗号化が有効になっているストレージ ポリシーがポッドの短期ディスクに割り当てられている場合、vSphere ポッドのデプロイが失敗する

    暗号化が有効なストレージ ポリシーをポッドの短期ディスクに使用すると、vSphere ポッドを作成できず、「AttachVolume.Attach failed for volume」というエラーが発生します。

    回避策：ポッドの短期ディスクには、暗号化なしのストレージ ポリシーを使用します。

  • 「名前空間クラスタのアップグレードでホストのアップグレード手順が実行されている」ときに、スーパーバイザー クラスタのアップグレードが 50% でハングする

    この問題は、Kubernetes 制御プレーン ノードのアップグレード中に vSphere Pod が終了状態でハングする場合に発生します。制御プレーン ノードのコントローラが Spherelet プロセスをアップグレードしようとし、そのフェーズで vSphere ポッドがその制御プレーン ノードで退去または強制終了され、ノードが Kubernetes 制御プレーンから登録解除されます。このため、終了状態の vSphere ポッドがインベントリから削除されるまで、スーパーバイザー クラスタのアップグレードは以前のバージョンでハングします。

    回避策：

    1.vSphere Pod が終了状態でハングしている ESXi ホストにログインします。

    2.次のコマンドを使用して、終了状態の vSphere ポッドを削除します。

    # vim-cmd vmsvc/getallvms

    # vim-cmd vmsvc/destroy

    この手順の後、vSphere ポッドは vSphere Client で親 (実体) なし状態で表示されます。

    3.最初にユーザーを ServiceProviderUsers グループに追加して、親 (実体) なし vSphere ポッドを削除します。

    a.) vSphere Client にログインし、[管理] -> [ユーザーおよびグループ] -> [ユーザーの作成] の順に選択し、[グループ] をクリックします。

    b.) ServiceProviderUsers または管理者グループを検索し、ユーザーをグループに追加します。

    4.作成したユーザーを使用して vSphere Client にログインし、親 (実体) なし vSphere ポッドを削除します。

    5.kubectl で次のコマンドを使用します。

    kubectl patch pod -p -n '{"metadata":{"finalizers":null}}'

  • ワークロード管理のユーザー インターフェイスで、次のライセンス エラーが発生する：この vCenter Server に接続されているホストにはいずれも、ワークロード管理のためのライセンスがありません

    vSphere クラスタでワークロード管理を正常に有効にした後、vCenter Server を再起動するか、ワークロード管理が有効な ESXi ホストをアップグレードした後に、次のライセンス エラーが表示される場合があります：この vCenter Server に接続されているホストにはいずれも、ワークロード管理のためのライセンスがありません。これはユーザー インターフェイスの表示上のエラーです。実際にはライセンスは有効なままで、ワークロードは引き続き実行されています。

    回避策：ユーザーは、vSphere Client のブラウザ キャッシュをクリアする必要があります。

  • 大規模な vSphere 環境では、クラウドへの VMware NSX Advanced Load Balancer Controller の同期に時間がかかる場合がある

    2,000 台を超える ESXi ホストと 45,000 台を超える仮想マシンを含むインベントリがある vSphere 環境では、NSX Advanced Load Balancer Controller をクラウドに同期するのに 2 時間程度かかる場合があります。

    回避策：なし

  • VMware Certificate Authority (VMCA) ルート証明書が vCenter Server 7.0 Update 2 で変更された後、スーパーバイザー クラスタのプライベート コンテナ レジストリに問題が発生することがある

    vCenter Server システム 7.0 Update 2 上で VMware Certificate Authority (VMCA) ルート証明書を変更すると、スーパーバイザー クラスタのプライベート コンテナ レジストリに問題が発生して、レジストリ操作が想定どおりに動作しなくなる場合があります。クラスタ構成ユーザー インターフェイスに、コンテナ レジストリに関する次の健全性ステータス メッセージが表示されます。

    Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority

    回避策：

    次の手順に従って、vSphere kubernetes クラスタの vmware-system-registry 名前空間でレジストリ エージェント ポッドを手動で再起動します。

    1. kubectl get pod -n vmware-system-registry コマンドを実行してレジストリ エージェント ポッドを取得します。

    2. kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry コマンドを実行してポッドの出力を削除します。

    3. ポッドが再起動するまで待機します。

    4. クラスタ構成ユーザー インターフェイスでイメージ レジストリを更新して少し経過すると、健全性ステータスが実行中と表示されます。

  • スーパーバイザー クラスタで新しく作成された名前空間のプロジェクトが、プライベート コンテナ レジストリに自動的に作成されない

    スーパーバイザー クラスタに新しく作成された名前空間のプライベート コンテナ レジストリには、プロジェクトが自動的に作成されない場合があります。コンテナ レジストリのステータスは健全と表示されますが、新しい名前空間が作成されたときにクラスタのコンテナ レジストリにプロジェクトが表示されません。コンテナ レジストリ上の新しい名前空間のプロジェクトに、イメージをプッシュまたはプルすることができません。

    回避策：

    1. kubectl get pod -n vmware-system-registry コマンドを実行してレジストリ エージェント ポッドを取得します。

    2. kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry コマンドを実行してポッドの出力を削除します。

    3. ポッドが再起動するまで待機します。

    4. プライベート コンテナ レジストリにログインして、クラスタ上の名前空間にプロジェクトが作成されることを確認します。

  • 10 個のレプリカでポッドを作成中に ErrImgPull が発生する場合がある

    YAML で 10 個のレプリカ ポッドを持つデプロイを使用すると、この問題が発生する場合があります。プライベート コンテナ レジストリを使用してこの YAML で作成すると、10 個のレプリカのうち少なくとも 7 個が成功し、3 個が「ErrImgPull」の問題で失敗することがあります。

    回避策：使用するレプリカ セットの数を減らし、最大 5 個にします。

  • vCenter Server がカスタム ポートを使用してデプロイされている場合、NSX Advanced Load Balancer コントローラはサポートされない

    登録中に NSX Advanced Load Balancer コントローラ ユーザー インターフェイスでカスタム vCenter Server ポートを提供するオプションがないため、vCenter Server を NSX Advanced Load Balancer コントローラに登録することはできません。

    NSX Advanced Load Balancer コントローラは、vCenter Server がデフォルト ポート 80 および 443 でデプロイされている場合にのみ機能します。

  • 実行中のスーパーバイザー クラスタがすでに含まれている vCenter Server でドメインの再ポイントを実行すると、スーパーバイザー クラスタが [設定中] 状態になる

    スーパーバイザー クラスタが含まれている vCenter Server では、ドメインの再ポイントはサポートされていません。ドメインの再ポイントを実行すると、既存のスーパーバイザー クラスタが [設定中] 状態になり、制御プレーン仮想マシンと Tanzu Kubernetes クラスタ仮想マシンが [ホストおよびクラスタ] ビューのインベントリに表示されなくなります。

    回避策：なし

  • Kubernetes を使用してスーパーバイザー クラスタに作成した仮想マシンには、タグとカスタム属性の割り当てが機能しない

    vSphere ユーザー インターフェイス クライアントまたは vAPI でスーパーバイザー クラスタに作成した仮想マシンにタグまたはカスタム属性を割り当てると、「タグの添付中にエラーが発生しました」というメッセージが表示され、操作が失敗します。

    回避策：なし

  • 名前空間をセルフサービスする権限を持つ開発者は、ストレージ クラスなどのクラスタ スコープのリソースにアクセスできない

    開発者が次の kubectl コマンドでクラスタ スコープのストレージ クラスをリストしようとすると

    kubectl get storageclass -n test-ns or kubectl get storageclass

    次のエラーが発生します。

    Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope

    回避策：開発者が、開発者にアクセス権のある名前空間テンプレートに割り当てられたストレージ クラスのみにアクセスできるので、これは想定内の動作です。これは vSphere 管理者によって事前に指定済みです。

    次のコマンドを使用すると、名前空間に関連付けられているストレージ クラスがリストされます。

    kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE>

  • 「kubectl apply -f」で名前空間をセルフサービスすると失敗する

    kubectl apply -f でマニフェストを使用して名前空間を作成しようとすると失敗します。

    Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope

    回避策：開発者は、代わりに kubectl create -f コマンドで名前空間を作成できます。

  • セルフサービス名前空間で vSphere ポッドを作成しようとすると断続的に失敗する

    セルフサービス名前空間テンプレートで作成した名前空間内に vSphere ポッドを作成しようとすると、「リソース ポッドを作成できません」というエラーが発生することがあります。

    回避策：名前空間の作成後、数秒待ってから、名前空間に vSphere ポッドを作成します。

  • セルフサービス名前空間テンプレートで作成した名前空間に、開発者がラベルや注釈を追加できない

    kubectl apply -f コマンドを使用して名前空間の作成または変更に使用したマニフェストにラベルや注釈を指定しようとすると、エラーが発生して失敗します。

    Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""

    回避策：名前空間マニフェストに必要なラベルと注釈を追加し、代わりに kubectl create -f でラベルや注釈を追加します。

  • スーパーバイザー クラスタのアップグレードが実行されるまで名前空間テンプレートを使用できない

    スーパーバイザー クラスタのアップグレードを開始すると、アクティベーション、アクティベーション解除、更新などの名前空間テンプレートに関連するタスクは、アップグレードが完了するまでキューに留まります。

    回避策：アップグレード処理が完了するまで待機してから、名前空間テンプレートを操作するコマンドを実行します。

  • Tanzu Kubernetes クラスタ上のポッドにパーシステント ボリュームを接続しようとすると、「CNS: SCSI コントローラがないため、ディスクの接続に失敗しました」というエラー メッセージが表示される

    Tanzu Kubernetes クラスタ上のポッドにパーシステント ボリュームを接続しようとすると失敗して、ポッドが保留状態のままになります。エワーカー ノード仮想マシンに PVSCSI コントローラが構成されていても、SCSI コントローラが見つからないことを示すエラー メッセージが表示されます。

    この問題は、ワーカー ノード仮想マシンのブロック ボリューム数が上限の 60 に達した場合に発生する可能性があります。ただし、Kubernetes は vSphere のボリューム制限を無視し、そのノードでのブロック ボリュームの作成をスケジューリングします。

    回避策：クラスタにワーカー ノードを追加します。ポッドを削除して、新しく追加したワーカー ノードへのデプロイをスケジューリングします。

  • 非アクティブな vCenter Server セッション後にステートフル ポッドを削除し、後で Tanzu Kubernetes クラスタ内のボリュームを再利用または削除すると、エラーが発生し、予期しない動作が発生することがある

    1 日ほど非アクティブになった後にステートフル ポッドを削除すると、そのボリュームは Tanzu Kubernetes クラスタのノード仮想マシンから正常に接続解除されたように見えます。ただし、そのボリュームを使用して新しいステートフル ポッドを作成するか、ボリュームを削除すると、ボリュームは vCenter Server 内のノード仮想マシンに接続されたままであるため、その試行は失敗します。

    回避策：CNS API を使用してノード仮想マシンからボリュームを接続解除し、Tanzu Kubernetes クラスタと vCenter Server 内のボリュームの状態を同期します。また、スーパーバイザー クラスタの CSI コントローラを再起動して、非アクティブなセッションを更新します。

  • スーパーバイザー クラスタのプライマリ ワークロード ネットワーク（vSphere ネットワークを使用している場合）または NCP クラスタ ネットワーク ポッド CIDR（NSX-T Container Plug-in を使用している場合）で IP アドレス範囲が枯渇しているため、スーパーバイザー クラスタのアップグレードが停止する、または完了しない

    スーパーバイザー クラスタのアップグレードが保留中の状態で停止し、「名前空間クラスタのアップグレードで新しいマスターのプロビジョニング手順が実行されています」というメッセージが表示されます。

    クラスタのアップグレード中にデプロイされた新しい制御プレーン仮想マシンは、1 つのネットワーク インターフェイスのみを受信します。制御プレーン仮想マシンには 2 つのネットワーク インターフェイスがあり、1 つは管理ネットワークに接続され、もう 1 つはワークロード ネットワークに接続されている必要があります。

    新しい制御プレーン仮想マシンにデプロイされるはずの coredns などの特定のシステム ポッドが保留状態で停止することがあります。

    回避策：少数のワークロード（仮想マシン、ポッド仮想マシン、TKG クラスタ）を削除して、アップグレード プロセスを完了するのに十分な IP アドレスを解放します。少なくとも 3 つの IP アドレスを解放する必要があります。

  • スーパーバイザー サービス構成のキーと値のペアまたはレジストリ認証情報を更新する

    誤ったログイン認証情報を入力したことや、レジストリ パスワードが期限切れになっていたことが原因で、スーパーバイザー サービスの構成レジストリのキーと値のペアの変更が必要になる場合があります。

    回避策：

    1.スーパーバイザー クラスタに新しいシークレット リソースを作成します。

    kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=

    2.スーパーバイザー サービス リソースのサービス参照を更新します。

    # kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services

    3.spec.config セッションを更新します。

    spec:

    config:

    secretNamespace: vmware-system-supervisor-services

    secretRef: new-secret

  • Tanzu Kubernetes Grid Service およびスーパーバイザー サービスのユーザー インターフェイス プラグインが動作しない

    vCenter Server がカスタム CA 証明書によって署名され、スーパーバイザー クラスタが有効になっている場合、Tanzu Kubernetes Grid サービス ユーザー インターフェイス プラグイン、および vSphere Client にデプロイされたすべてのスーパーバイザー サービス ユーザー インターフェイス プラグインは機能しません。このユーザー インターフェイス プラグインがスーパーバイザー クラスタ内のそれぞれのバックエンド サーバとの通信を試行すると、SSL 認証の問題が発生します。Tanzu Kubernetes Grid Service プラグインに次のエラーが表示されます。

    The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details

    回避策：/etc/ssl/certs の別のファイル（vmca.pem ではない）に信頼ルートを追加し、c_rehash を使用してハッシュを再生成します。この操作は、3 つのすべての制御プレーン仮想マシンで実行する必要があります。

    /etc/ssl/certs/vmca.pem の内容はクラスタを同期するたびにアップデート コントローラによって上書きされるため、このファイルを編集することは適切ではありません。

    スーパーバイザー クラスタ内の制御プレーン仮想マシンのいずれかが再デプロイされた場合（たとえば、制御プレーン仮想マシンのサイズを変更した場合や、修復操作を行った場合）、/etc/ssl/certs に手動で追加した証明書は失われるため、この回避策を仮想マシンに再適用する必要があります。

  • スーパーバイザー クラスタが構成中の状態でハングする

    vSphere クラスタをスーパーバイザー クラスタとして構成した後、クラスタが構成中の状態でハングします。vSphere ポッドおよび Tanzu Kubernetes クラスタが作成できません。

    回避策：次のコマンドを使用して、wcp サービスを再起動します。

    vmon-cli restart wcp

    詳細な手順については、ドキュメントを確認してください。

  • 関連付けられたコンテンツ ライブラリが仮想マシン イメージにポピュレートされている場合でも、コマンド「kubectl get virtualmachineimages」が結果を返さない

    仮想マシン サービスで使用されているコンテンツ ライブラリがセキュリティ ポリシーで有効になっている場合、仮想マシン サービスがイメージの読み取りに失敗し、このコンテンツ ライブラリのイメージを使用して仮想マシンを展開することはできなくなります。

    回避策：スーパーバイザー名前空間からコンテンツ ライブラリとセキュリティ ポリシーの関連付けを解除します。関連するコンテンツ ライブラリから「デフォルトの OVF セキュリティ ポリシー」の設定を削除してから、コンテンツ ライブラリを名前空間に再関連付けします。

  • ホストがメンテナンス モードに切り替わると、仮想マシン サービスによって管理される vGPU およびパススルー デバイスを使用する仮想マシンで、開発者に誤った POWERSTATE が表示される

    ホストがメンテナンス モードになると、仮想マシン サービスによって管理される vGPU およびパススルー デバイスを使用する仮想マシンは、DRS によって自動的にパワーオフされます。ただし、kubectl get vm の出力には、以前の電源状態と仮想マシンが表示されます。これにより、vCenter Server で仮想マシンがパワーオフされている場合でも、POWERSTATE=poweredOn と表示されます。

    なし。

  • NSX-T が設定されたスーパーバイザー クラスタで、ESXi ホストが自己署名された Spherelet VIB を引き続き使用することがある

    vCenter Server 7.0 Update 3 で利用可能な Kubernetes バージョンを使用してスーパーバイザー クラスタを構成またはアップグレードし、スーパーバイザー クラスタの Kubernetes バージョンを vCenter Server 7.0 Update 3a で利用可能なバージョンにアップグレードした場合、ESXi ホストで自己署名された Spherelet VIB が引き続き使用される場合があります。この問題は、vCenter Server 7.0 Update 3 および vCenter Server 7.0 Update 3a にインストールされている自己署名された Spherelet VIB のバージョンが同一であるために発生します。この問題は、vSphere ネットワーク スタックが構成されたスーパーバイザー クラスタには適用されません。

    回避策 1：

    vSphere クラスタが vSphere Lifecycle Manager に基づいていない場合は、次の手順を実行して、VMware 認定の Spherelet VIB をインストールします。

    1. ESXi ホストをメンテナンス モードにして、スーパーバイザー クラスタによって「準備ができていません」とマークされるまで待機します。

    2. このホストをスタンドアローン ホストとしてクラスタの外部に移動し、Spherelet と NSX-T VIB がアンインストールされるまで待機します。

    3. 同じホストをクラスタに戻し、メンテナンス モードを終了して、新しい Spherelet と NSX-T VIB が再び構成されるまで待機します。

    4. クラスタ内の ESXi ホストごとに上記の手順を繰り返します。

    vSphere Lifecycle Manager でスーパーバイザー クラスタが有効になっている場合は、スーパーバイザー クラスタを無効にして、再度再構成します。

    回避策 2：

    vCenter Server を vCenter Server 7.0 Update 3a にアップグレードした後に、スーパーバイザー クラスタを無効にして、再構成します。これは、vSphere Lifecycle Manager が有効になっているクラスタと非 vLCM/VUM ベースのクラスタの両方に適用されます。

  • ホストの再起動またはスーパーバイザー クラスタのアップグレード後に、一部の vSphere ポッドに NodeAffinity ステータスが表示される

    ホストを再起動するか、スーパーバイザー クラスタをアップグレードした後、一部の vSphere ポッドに NodeAffinity ステータスが表示されることがあります。この動作は、kubelet の再起動後に Kubernetes スケジューラがクラスタ内に NodeAffinity ステータスの冗長ポッドを作成するアップストリーム Kubernetes に問題がある場合に発生します。この問題は、クラスタの機能には影響しません。アップストリーム Kubernetes の問題の詳細については、https://github.com/kubernetes/kubernetes/issues/92067 を参照してください。

    回避策：NodeAffinity ステータスの冗長ポッドを削除します。

  • 環境を vCenter Server 7.0 Update 3e 以降にアップグレードすると、vSphere with Tanzu で有効な vDPP サービス オペレータ ポッドとインスタンス ポッドが保留状態になる

    この問題は、スーパーバイザー クラスタにインストールされているパートナー サービスのバージョンが Kubernetes バージョン 1.22 をサポートしていない場合に発生します。vSphere with Tanzu 環境を Kubernetes 1.22 準拠のバージョン 7.0 Update 3e 以降にアップグレードすると、サービスに互換性がなくなります。その結果、オペレータ ポッドとインスタンス ポッドが保留状態になります。

    サービスの新しいバージョンへのアップグレードは失敗します。

    回避策：vSphere with Tanzu を vCenter Server 7.0 Update 3e にアップグレードする前に、vDPP サービスを Kubernetes 1.22 と互換性のあるバージョンにアップグレードします。

  • Kubernetes 1.19.1 から 1.20.8 へのクラスタの自動アップグレードが進行しない

    まれに、Kubernetes 1.19.1 から 1.20.8 へのクラスタの自動アップグレードが次のエラーで失敗することがあります。

    アップグレードのタスクが見つかりません。アップグレードを再度トリガしてください。

    回避策：クラスタのアップグレードを手動で開始します。

  • スーパーバイザー名前空間の処理は、短時間で再利用された場合失敗することがある

    スーパーバイザー名前空間が削除され、短時間に同じ名前で再作成された場合、キャッシュ内の無効なエントリが原因で処理が失敗することがあります。

    最新リリースで、この問題は修正されました。

  • スーパーバイザー サポート バンドルに vCenter Server サポート バンドルが含まれる

    スーパーバイザー サポート バンドルを生成した場合、vCenter Server サポート バンドルは自動的には含まれません。

    最新バージョンで修正されました。

  • ネットワーク サポート チェックリストのコンテンツがローカライズされていない

    ワークロード管理の有効化中に、ネットワーク チェックリスト シートをダウンロードすることが可能です。ローカライズはシートには適用されていません。

    最新リリースで修正されました。

  • スケーリングされた Tanzu Kubernetes クラスタのセットアップ時に、WCP システム ポッド capi-kubeadm-control-plane-controller-manager で OOM の確認の問題が発生する

    ナレッジベースの記事に記載

    https://kb.vmware.com/s/article/88914

    ナレッジベースの記事を参照してください

  • TKG または capw のアップグレードの失敗が原因で、スーパーバイザー クラスタのアップグレードがコンポーネントのアップグレード段階で停止する

    ナレッジベースの記事に記載

    https://kb.vmware.com/s/article/88854

  • 更新されたルールがセキュリティ ポリシーで削除されない

    ルール A と B を含むセキュリティ ポリシー CR を作成した後に、ポリシーを更新してルールを B および C に変更しても、ルール A が引き続き有効になります。

    回避策：セキュリティ ポリシーを削除し、更新されたルールを使用して再作成します。

  • NSX Advanced Load Balancer に SE グループが 2 つ存在する場合、LoadBalancers および Tanzu Kubernetes クラスタが作成されない

    SE または仮想サービスが割り当てられているかどうかにかかわらず、2 つ目の SE グループが NSX Advanced Load Balancer に追加されると、新しいスーパーバイザー クラスタまたは Tanzu Kubernetes クラスタの作成に失敗し、既存のスーパーバイザー クラスタをアップグレードできません。NSX Advanced Load Balancer コントローラでの仮想サービスの作成に失敗して、次のエラーが表示されます。

    「get() が複数の ServiceEngineGroup を返しました – 2 を返しました」

    その結果、新しいロード バランサを使用できず、新しいワークロード クラスタを正常に作成できません。

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

    回避策：仮想サービスの作成には SE グループ「Default-Group」のみを使用し、default-group 以外の SE グループはすべて NSX Advanced Load Balancer から削除して、操作を再試行します。

  • 更新されたセキュリティ ポリシーが有効にならない

    ルール A と B を含むセキュリティ ポリシー CR を作成した後に、ポリシーを更新してルールを B および C に変更しても、ルール A が引き続き有効になり、削除されません。

    回避策：ルール B と C を含む新しいポリシーを作成して適用し、A と B を含む古いポリシーを削除します。

  • 名前空間管理 API が HTTP 500 エラーを返し、要求の承認に失敗することがある

    ワークロード管理への要求は断続的に失敗することがあります。API が 500 ステータス コードを返し、要求は処理されません。ログには次のメッセージが記録されます：An unexpected error occurred during the authorization。この問題は断続的に発生しますが、1 つ以上のスーパーバイザーをアクティブに構成している場合など、ワークロード管理の負荷が高い場合に発生する可能性が高くなります。

    回避策：エラーが発生した際に試行していた操作を再試行します。

  • スーパーバイザー クラスタが断続的に「設定中」または「エラー」状態のままになることがある

    スーパーバイザー クラスタの有効化、アップグレード、またはその他のノードの再デプロイ中に、スーパーバイザー クラスタが「設定中」または「エラー」状態のままになり、次のエラー メッセージが表示されることがあります。

    「VMware vCenter Server (vpxd) への API 要求に失敗しました。詳細「ServerFaultCode: 一般的なシステム エラーが発生しました: vix エラー コード = (1, 0) が停止状態になる可能性があります。」

    関連するログは次の場所にあります。/var/log/vmware/wcp/wcpsvc.log

    この問題が発生している制御プレーン仮想マシンに対応する vSphere Agent Manager (EAM) を削除して、ノードの再デプロイを強制的に実行します。

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

ネットワーク

  • 低速ネットワークで NSX Edge 仮想マシンのデプロイが失敗する

    NSX Edge OVF のデプロイと NSX Edge 仮想マシンの登録には、合計で 60 分のタイムアウトがあります。低速なネットワークまたはストレージが低速の環境では、Edge のデプロイと登録の経過時間がこの 60 分のタイムアウトを超えた場合、操作が失敗します。

    回避策：Edge をクリーンアップし、デプロイを再起動します。

  • クラスタ構成後に vCenter Server DNS、NTP、または Syslog 設定が変更された場合、NSX Edge が更新されない

    DNS、NTP、Syslog の設定は、クラスタの構成時に vCenter Server から NSX Edge 仮想マシンにコピーされます。これらの vCenter Server 設定のいずれかが構成後に変更された場合、NSX Edge は更新されません。

    回避策：NSX Manager API を使用して、NSX Edge の DNS、NTP、および Syslog 設定を更新します。

  • NSX Edge 管理ネットワーク構成で、選択したポートグループに対してのみサブネットおよびゲートウェイ構成が提供される

    NSX Edge 管理ネットワークの互換性ドロップダウン リストには、選択した Distributed Switch の DVPG によってバッキングされているホストで ESXi VMKnic が構成されている場合にのみ、サブネットとゲートウェイの情報が表示されます。VMKnic が接続されていない分散ポートグループを選択する場合は、ネットワーク構成のためにサブネットとゲートウェイを指定する必要があります。

    回避策：次のいずれかの構成を使用します。

    • 単独のポートグループ：現在、VMK はありません。このポートグループに対して適切なサブネットとゲートウェイの情報を入力する必要があります。

    • 共有管理ポートグループ：ESXi ホストの管理 VMK が配置されています。サブネットとゲートウェイの情報は自動的にプルされます。

  • クラスタの構成中に VLAN 0 を使用できない

    オーバーレイ トンネル エンドポイントまたはアップリンク構成で VLAN 0 を使用すると、次のメッセージが表示されて操作が失敗します。

    Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network. Please use a VLAN ID between 1-4094

    回避策：次のプロセスのいずれかを使用して、VLAN 0 のサポートを手動で有効にします。

    1.デプロイされた vCenter Server に SSH で接続します (root/vmware)。

    2./etc/vmware/wcp/nsxdsvc.yaml を開きます。次のような内容が表示されます。 

    logging: 
  level: debug
  maxsizemb: 10

    a. NSX クラスタ オーバーレイ ネットワークの VLAN0 のサポートを有効にするには、/etc/vmware/wcp/nsxdsvc.yaml に次の行を追加し、ファイルを保存します。

    experimental:
 supportedvlan: 
  hostoverlay: 
    min: 0 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    b. NSX Edge オーバーレイ ネットワークの VLAN0 のサポートを有効にするには、/etc/vmware/wcp/nsxdsvc.yaml に次の行を追加し、ファイルを保存します。

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 0 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    c. NSX Edge アップリンク ネットワークの VLAN0 のサポートを有効にするには、/etc/vmware/wcp/nsxdsvc.yaml に次の行を追加し、ファイルを保存します。

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 0 
    max: 4094

    3.vmon-cli --restart wcp を使用して、ワークロード管理サービスを再起動します。

  • vSphere Lifecycle Manager イメージが有効なクラスタでは、vSphere with Tanzu および NSX-T を有効にできない

    vSphere with Tanzu と NSX-T は vSphere Lifecycle Manager イメージと互換性がありません。これらは、vSphere Lifecycle Manager ベースラインにのみ対応しています。クラスタで vSphere Lifecycle Manager イメージが有効な場合、そのクラスタで vSphere with Tanzu または NSX-T を有効にすることはできません。

    回避策：vSphere Lifecycle Manager イメージが無効なクラスタにホストを移動します。vSphere Lifecycle Manager ベースラインでクラスタを使用する必要があります。ホストを移動したら、新しいクラスタで NSX-T、vSphere with Tanzu を順に有効にすることができます。

  • vSphere with Tanzu ネットワーク が NSX-T で構成されている場合、「ExternalTrafficPolicy: local」はサポートされない

    LoadBalancer タイプの Kubernetes サービスでは、「ExternalTrafficPolicy: local」構成はサポートされません。

    回避策：なし。

  • vSphere with Tanzu ネットワークが NSX-T で構成されている場合、Tanzu Kuberetes クラスタでサポート可能な LoadBalancer タイプのサービスの数がスーパーバイザー クラスタの NodePort 範囲によって制限される

    LoadBalancer タイプの各 VirtualMachineService は、LoadBalancer タイプの 1 つの Kubernetes サービスと 1 台の Kubernetes エンドポイントに変換されます。スーパーバイザー クラスタで作成可能な LoadBalancer タイプの Kubernetes サービスの最大数は 2,767 ですが、これにはスーパーバイザー クラスタ自体に作成されたものと Tanzu Kubernetes クラスタで作成されたサービスが含まれます。

    回避策：なし。

  • NSX Advanced Load Balancer Controller では vCenter Server の PNID の変更がサポートされない

    NSX Advanced Load Balancer でスーパーバイザー クラスタを構成した後では、vCenter Server の PNID を変更できません。

    回避策：vCenter Server の PNID を変更する必要がある場合は、NSX Advanced Load Balancer Controller を削除し、vCenter Server の PNID を変更してから、vCenter Server の新しい PNID を使用して NSX Advanced Load Balancer Controller を再デプロイし、構成します。

  • vSphere Distributed Switch (vDS) 環境では、Tanzu Kubernetes クラスタにスーパーバイザー クラスタと重複または競合するネットワーク CIDR 範囲を構成したり、その逆を行ったりできるため、コンポーネントが通信不能になることがある

    vDS 環境では、スーパーバイザー クラスタの CIDR 範囲を構成する際、または Tanzu Kubernetes クラスタの CIDR 範囲を構成する際に、設計時のネットワークの検証は行われません。その結果、次に示す 2 つの問題が発生することがあります。

    1) Tanzu Kubernetes クラスタ用に予約されているデフォルトの CIDR 範囲と競合する CIDR 範囲を持つスーパーバイザー クラスタが作成されます。

    2) スーパーバイザー クラスタで使用される CIDR 範囲と重複するカスタム CIDR 範囲を持つ Tanzu Kubernetes クラスタが作成されます。

    回避策：vDS 環境でスーパーバイザー クラスタを構成する場合は、サービス用に予約されている 192.168.0.0/16、ポッド用に予約されている 10.96.0.0/12 など、Tanzu Kubernetes クラスタで使用されるデフォルトの CIDR 範囲を使用しないでください。vSphere with Tanzu ドキュメントの「Tanzu Kubernetes クラスタの構成パラメータ」も参照してください。

    vDS 環境で Tanzu Kubernetes クラスタを作成する場合は、スーパーバイザー クラスタで使用される CIDR 範囲を使用しないでください。

  • 18 個を超えるカスタム ラベルが添付されていると、ゲスト クラスタの仮想ネットワークの作成に失敗する

    名前空間にゲスト クラスタと仮想マシンを正常に作成するには、名前空間に最大 18 個のカスタム ラベルを追加できます。それ以外の場合は、名前空間にゲスト クラスタの仮想ネットワークを正常に作成することはできません。

    名前空間からラベルを削除して、合計数を 18 個以下にします。NCP の再試行メカニズムは再試行して名前空間を作成しますが、間隔によっては最大 6 時間かかる場合があります。

  • WCP のポリシー API を介して作成されたトランスポート ゾーンのサポート

    NSX トランスポート ゾーンがポリシー API を介して作成されている場合、スーパーバイザーの有効化に失敗する可能性がありました。ポリシー API を介した NSX トランスポート ゾーンの作成がサポートされるようになりました。同時に、MP API を使用して作成された NSX トランスポート ゾーンとの後方互換性も維持されるようになりました。

    最新リリースで修正されました。

  • 組み込みリンク モード トポロジを使用する vCenter Server には NSX Advanced Load Balancer を使用することはできない

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

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

ストレージ

  • <span style="color:#FF0000">NEW：</span>vSAN Direct データストアでディスクの削除操作を実行すると、「VimFault - 操作を完了できません」というエラーで失敗する

    通常、次のいずれかのシナリオが発生すると、このエラーが発生する可能性があります。

    • ディスクの削除操作では、vSAN Direct データストアに配置されているすべてのパーシステント ボリュームは、同じ ESXi ホスト上の別の vSAN Direct データストアに再配置されます。この再配置は、ターゲット vSAN Direct データストアに使用可能な容量がない場合に失敗することがあります。この障害を回避するには、ターゲット vSAN Direct データストアに、アプリケーションの実行に必要なストレージ容量があることを確認します。

    • ESXi ホスト上のターゲット vSAN Direct データストアに十分なストレージがある場合でも、ディスクの削除操作が失敗することがあります。この問題は、親操作のディスクの削除によって生成される、基盤となるパーシステント ボリュームの再配置操作が、ボリュームのサイズが原因で 30 分以上かかる場合に発生することがあります。この場合、[タスク] ビューで、基盤となる vSphere ポッドの再構成が進行中のままであることを確認できます。

      進行中のステータスは、ディスクの削除操作がタイムアウトになって失敗しても、vSphere ポッドの再構成によって行われた基盤となるパーシステント ボリュームの再配置が中断されないことを示します。

    回避策：

    vSphere ポッドの再構成タスクが完了したら、ディスクの削除操作を再度実行します。ディスクの削除操作は正常に続行されます。

  • オフライン モードまたはオンライン モードでスーパーバイザー クラスタ PVC を拡張しても、対応する Tanzu Kubernetes クラスタ PVC が拡張されない

    Tanzu Kubernetes クラスタ PVC を使用するポッドは、ファイルシステムのサイズが変更されていないので、スーパーバイザー クラスタ PVC の拡張容量を使用できません。

    回避策：Tanzu Kubernetes クラスタ PVC のサイズをスーパーバイザー クラスタ PVC のサイズ以上に変更します。

  • 基盤となるボリュームと比較して、静的にプロビジョニングされた TKG PVC のサイズが一致しない

    Kubernetes の静的プロビジョニングでは、PV とバッキング ボリュームのサイズが等しいかどうかは検証しません。Tanzu Kubernetes クラスタ内で PVC を静的に作成し、その PVC のサイズが、対応する基盤スーパーバイザー クラスタ PVC のサイズよりも小さい場合、PV で要求した容量よりも多くの容量を使用できる可能性があります。Tanzu Kubernetes クラスタで静的に作成する PVC のサイズが、基盤となるスーパーバイザー クラスタ PVC のサイズよりも大きい場合、Tanzu Kubernetes クラスタ PV で要求したサイズを使い尽くす前に、「No space left on device」というエラーが表示されることがあります。

    回避策：

    1. Tanzu Kubernetes クラスタ PV で、persistentVolumeReclaimPolicy を Retain に変更します。

    2. Tanzu Kubernetes クラスタ PV の volumeHandle をメモして、Tanzu Kubernetes クラスタ内の PVC と PV を削除します。

    3. volumeHandle で Tanzu Kubernetes クラスタの PVC と PV を静的に再作成し、ストレージを対応するスーパーバイザー クラスタ PVC のサイズと同じサイズに設定します。

  • 外部 csi.vsphere.vmware.com プロビジョナがリーダーの選出用のリースを失うと、スーパーバイザー名前空間または TKG クラスタからの PVC 作成が失敗する

    kubectl コマンドを使用して、スーパーバイザー名前空間または TKG クラスタから PVC を作成しようとすると、失敗することがあります。PVC は保留状態のままです。PVC について説明する場合、[イベント] フィールドのテーブル レイアウトには、次の情報が表示されます。

    • タイプ – Normal

    • 理由 – ExternalProvisioning

    • 期間 – 56s (x121 over 30m)

    • 起点 – persistentvolume-controller

    • メッセージ – waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator

    回避策：

    1. vmware-system-csi 名前空間内の vsphere-csi-controller ポッドのすべてのコンテナが実行中であることを確認します。

      kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi

    2. 次のコマンドを使用して、外部プロビジョナ ログを確認します。

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

      次のエントリは、external-provisioner sidecar コンテナがそのリーダー選出を失ったことを示します。

      I0817 14:02:59.582663 1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading

    3. この vsphere-csi-controller のインスタンスを削除します。

      kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi

    Kubernetes によって CSI コントローラの新しいインスタンスが作成され、すべての sidecar が再初期化されます。

  • CSI が vCenter Server に接続できない場合、ボリュームの作成、接続、接続解除、削除などのすべての PVC 操作が失敗する

    操作が失敗するほか、スーパーバイザー クラスタでボリュームの健全性情報とストレージ プールの CR を更新できなくなります。CSI および Syncer ログには、vCenter Server に接続できないことに関するエラーが記録されます。

    CSI は、特定のソリューション ユーザーとして vCenter Server に接続します。この SSO ユーザーのパスワードは 24 時間ごとに wcpsvc によってローテーションされ、新しいパスワードは、CSI ドライバが vCenter Server に接続する際に読み取るシークレットに転送されます。新しいパスワードがシークレットに提供されない場合、古いパスワードがスーパーバイザー クラスタに残り、CSI ドライバの操作は失敗します。

    この問題は、vSAN データ パーシステンス プラットフォームおよびすべての CSI ボリューム操作に影響します。

    回避策：

    通常、WCP サービスは、更新されたパスワードを Kubernetes クラスタで実行される CSI に提供します。接続問題や同期プロセスの以前の部分でのエラーなどが原因で、パスワードが提供されないことがあります。CSI は古いパスワードを使用し続け、最終的に、認証失敗回数が多くなりすぎてアカウントがロックされます。

    WCP クラスタが健全で実行中の状態であることを確認します。[ワークロード管理] 画面で、そのクラスタについてエラーが報告されていない必要があります。同期が失敗する原因となった問題の解決後、パスワードを強制的に更新して、ロックされたアカウントのロックを解除します。

    パスワードを強制的にリセットするには、次の手順を実行します。

    1. wcpsvc を停止します。

      vmon-cli -k wcp

    2. 最後のパスワード ローテーションの時刻を小さい値（たとえば 1）に編集します。これには、/etc/vmware/wcp/.storageUser の 3 番目の行を 1 に変更します。

    3. wcpsvc を開始します。

      vmon-cli -i wcp

    パスワードが wcpsvc によってリセットされるため、アカウントのロックは解除され、新しいパスワードがクラスタに提供されます。

VMware Tanzu Kubernetes Grid Service for vSphere

  • スーパーバイザー クラスタのアップグレード後、Tanzu Kubernetes クラスタが「更新中」状態でハングする

    スーパーバイザー クラスタがアップグレードされると、すべての Tanzu Kubernetes クラスタのローリング アップデートがトリガされ、新しい構成が伝達されます。このプロセス中に、以前「実行中」であった TKC クラスタが「更新中」フェーズでハングすることがあります。「実行中」の Tanzu Kubernetes クラスタは制御プレーンの利用可能性のみを示し、必要な制御プレーンとワーカー ノードが正常に作成されていない可能性があります。このような Tanzu Kubernetes クラスタはスーパーバイザー クラスタのアップグレード完了時に開始するローリング アップデート中に実行される健全性チェックに失敗することがあります。これにより Tanzu Kubernetes クラスタが「更新中」フェーズでハングします。これは Tanzu Kubernetes クラスタに関連付けられている KubeadmControlPlane リソースのイベントで確認できます。リソースによって発生するイベントは、次のようなものになります。

    Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked

    回避策：なし。

  • Tanzu Kubernetes クラスタが削除済みのストレージ ポリシーにアクセスし続ける

    仮想インフラストラクチャ管理者が vCenter Server の名前空間からストレージ クラスを削除しても、そのストレージ クラスをすでに使用している Tanzu Kubernetes クラスタでは、ストレージ クラスへのアクセスが削除されません。

    回避策：

    1. 仮想インフラストラクチャ管理者として vCenter Server 名前空間からストレージ クラスを削除した後、同じ名前の新しいストレージ ポリシーを作成します。

    2. 既存のストレージ ポリシーまたは再作成したストレージ ポリシーを、スーパーバイザー ネームスペースに再度追加します。このストレージ クラスを使用している TanzuKubernetesCluster インスタンスが完全に動作するようになります。

    3. 削除するストレージ クラスを使用しているそれぞれの TanzuKubernetesCluster リソースに対し、異なるストレージ クラスを使用して新しい TanzuKubernetesCluster インスタンスを作成します。Velero を使用して、ワークロードを新しいクラスタに移行します。

    4. このストレージ クラスを使用している TanzuKubernetesCluster または PersistentVolume がない状態になると、これを安全に削除できます。

  • 組み込みのコンテナ レジストリの SSL 証明書が Tanzu Kubernetes クラスタ ノードにコピーされない

    スーパーバイザー クラスタに対して組み込みのコンテナ レジストリが有効になっている場合、そのスーパーバイザー クラスタに作成された Tanzu Kubernetes クラスタ ノードには Harbor SSL 証明書が含まれていないため、これらのノードからレジストリに接続することはできません。

    回避策：スーパーバイザー クラスタの制御プレーンから Tanzu Kubernetes クラスタのワーカー ノードに SSL 証明書をコピーして貼り付けます。

  • 仮想マシン イメージはコンテンツ ライブラリからは使用できません

    複数の vCenter Server インスタンスが組み込みリンク モードの設定で構成されている場合、ユーザー インターフェイスで別の vCenter Server インスタンスで作成されたコンテンツ ライブラリを選択できます。このようなライブラリを選択すると、DevOps ユーザーが Tanzu Kubernetes クラスタをプロビジョニングするために仮想マシン イメージを使用できなくなります。この場合、「kubectl get virtualmachineimages」は結果を返しません。

    回避策：コンテンツ ライブラリを Tanzu Kubernetes クラスタ仮想マシン イメージのスーパーバイザー クラスタに関連付ける場合は、スーパーバイザー クラスタが配置されているのと同じ vCenter Server インスタンスで作成されたライブラリを選択します。または、Tanzu Kubernetes クラスタのエアギャップ環境でのプロビジョニングもサポートするローカル コンテンツ ライブラリを作成します。

  • コンテンツ ライブラリのサブスクライバは公開者と同期できないため、新しい Tanzu Kubernetes クラスタのプロビジョニングや既存のクラスタのスケールアウトを実行できない

    Tanzu Kubernetes クラスタの OVA 用のサブスクライブ済みコンテンツ ライブラリを設定すると、SSL 証明書が生成され、証明書のサムプリントを確認して証明書を手動で信頼するように求められます。ライブラリの初回セットアップ後に SSL 証明書が変更された場合は、サムプリントを更新して新しい証明書を再度信頼する必要があります。

    サブスクライブ済みコンテンツ ライブラリの設定を編集します。これにより、ライブラリに関する変更要求がない場合でも、サブスクリプション URL のプローブが開始されます。プローブを行うと SSL 証明書が信頼されていないことが検出され、信頼するように求められます。

  • Tanzu Kubernetes リリース バージョン 1.16.8 に vCenter Server 7.0 Update 1 との互換性がない

    Tanzu Kubernetes リリース バージョン 1.16.8 には vCenter Server 7.0 Update 1 との互換性がありません。vSphere 名前空間を U1 にアップデートする前に、Tanzu Kubernetes クラスタを新しいバージョンにアップデートする必要があります。

    vSphere 名前空間を vCenter Server 7.0 Update 1 リリースにアップデートする前に、バージョン 1.16.8 が実行されている各 Tanzu Kubernetes クラスタを新しいバージョンにアップデートします。詳細については、ドキュメントの「Tanzu Kubernetes リリースのリスト」を参照してください。

  • ワークロード制御プレーンを vCenter Server 7.0 Update 1 にアップグレードすると、新しい仮想マシン クラスのサイズを使用できなくなります。

    説明：vSphere 7.0.1 をアップグレードし、スーパーバイザークラスタの vSphere 名前空間の更新を実行すると、Tanzu Kubernetes クラスタでは、コマンド「kubectl get virtualmachineclasses」を実行しても、新しい仮想マシンのクラスのサイズの 2x-large、4x-large、8x-large がリストされません。

    回避策：なし。新しい仮想マシン クラスのサイズは、ワークロード制御プレーンの新規インストールでのみ使用できます。

  • Calico CNI の使用時に、Tanzu Kubernetes リリース バージョン 1.17.11 vmware.1-tkg.1 のクラスタ DNS サーバへの接続がタイムアウトになる

    Tanzu Kubernetes リリース バージョン v1.17.11+vmware.1-tkg.1 には、Photon OS カーネルの問題があるため、Calico CNI との併用時にイメージが正常に動作しません。

    回避策：Tanzu Kubernetes リリース バージョン 1.17.11 では、「v1.17.11+vmware.1-tkg.2.ad3d374.516」で識別されるイメージで、Calico との問題が修正されています。Kubernetes 1.17.11 を実行するには、「v1.17.11+vmware.1-tkg.1.15f1e18.489」の代わりにこのバージョンを使用します。または、バージョン 1.18.5、1.17.8、1.16.14 など、Tanzu Kubernetes の別のリリースを使用します。

  • vSphere with Tanzu に NSX-T Data Center が構成されている場合に「ExternalTrafficPolicy: Local」サービスを「ExternalTrafficPolicy: Cluster」に更新すると、SV マスター上でこのサービスの LB IP がアクセス不能になる

    LoadBalancer タイプの Kubernetes サービスが、最初はワークロード クラスタに ExternalTrafficPolicy: Local で作成され、その後 ExternalTrafficPolicy: Cluster に更新されると、スーパーバイザー クラスタ仮想マシン上のこのサービスの LoadBalancer IP へのアクセスはドロップされます。

    回避策：サービスを削除し、ExternalTrafficPolicy: Cluster で再作成します。

  • Tanzu Kubernetes クラスタ制御プレーン ノードで CPU 使用率が高い

    Kubernetes アップストリーム プロジェクトでは、kube-controller-manager がループに入って CPU 使用率が高くなり、Tanzu Kubernetes クラスタの機能に影響を与える可能性があるという既知の問題があります。プロセス kube-controller-manager が予想よりも多くの CPU を使用しており、failed for updating Node.Spec.PodCIDRs と表示するログを繰り返し出力している場合があります。

    回避策：この問題が発生した制御プレーン ノード内の kube-controller-manager ポッドを削除します。ポッドが再作成され、問題が再発することはありません。

  • K8s 1.16 で作成された Tanzu Kubernetes クラスタを 1.19 に更新できない

    Kubelet の構成ファイルは、kubeadm init の実行時に生成され、クラスタのアップグレード中にレプリケートされます。1.16 の時点で、kubeadm init は resolvConf を /etc/resolv.conf に設定する構成ファイルを生成します。この構成ファイルは、/run/systemd/resolve/resolv.conf を指すコマンドライン フラグ --resolv-conf によって上書きされています。1.17 および 1.18 では、kubeadm は正しい --resolv-conf を使用して Kubelet を引き続き構成します。1.19 以降、kubeadm はコマンドライン フラグを構成しなくなり、代わりに Kubelet 構成ファイルに依存します。クラスタのアップグレード中のレプリケーション プロセスにより、1.16 からアップグレードされた 1.19 クラスタには、resolvConf が /run/systemd/resolve/resolv.conf ではなく /etc/resolv.conf を参照する構成ファイルが含まれます。

    回避策：Tanzu Kubernetes クラスタを 1.19 にアップグレードする前に、正しい resolv.conf を参照するように Kubelet 構成ファイルを再構成します。kube-system 名前空間で、ConfigMap kubelet-config-1.18 を kubelet-config-1.19 に手動で複製してから、その新しい ConfigMap's データを、resolvConf が /run/systemd/resolve/resolv.conf を参照するように変更します。

  • スーパーバイザー クラスタ ネットワークが NSX-T で構成されている場合、サービスを「ExternalTrafficPolicy: Local」から「ExternalTrafficPolicy: Cluster」に更新した後、スーパーバイザー クラスタ制御プレーン ノードでこのサービスのロード バランサ IP アドレスに対して行われた要求が失敗する

    Tanzu Kubernetes クラスタで ExternalTrafficPolicy: Local を使用してサービスを作成し、後でそのサービスを ExternalTrafficPolicy: Cluster に更新すると、kube-proxy がスーパーバイザー クラスタ制御プレーン ノードで誤って IP アドレス テーブル ルールを作成し、サービスの LoadBalancer IP アドレス宛てのトラフィックをブロックします。たとえば、このサービスに LoadBalancer IP アドレス 192.182.40.4 がある場合、次の IP アドレス テーブル ルールが制御プレーン ノードのいずれかに作成されます。

    -A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

    結果的に、その IP アドレスへのアクセスはドロップされます。

    回避策：サービスを削除し、ExternalTrafficPolicy: Cluster で再作成します。

  • TkgServiceConfiguration の仕様で HTTP プロキシまたは信頼の設定を有効にした後、プロキシ/信頼設定を使用しないすべての既存のクラスタが更新時にグローバルのプロキシ/信頼設定を継承する

    TkgServiceConfiguration の仕様を編集することで、デフォルトの CNI、HTTP プロキシ、信頼証明書の指定を含む TKG サービスを構成できます。TkgServiceConfiguration の仕様に対して行ったすべての構成変更は、このサービスによってプロビジョニングまたは更新されたすべての Tanzu Kuberentes クラスタにグローバルに適用されます。クラスタごとの設定を使用してグローバル構成をオプトアウトすることはできません。

    たとえば、TkgServiceConfiguration の仕様を編集して HTTP プロキシを有効にした場合、そのクラスタによってプロビジョニングされたすべての新しいクラスタは、プロキシ設定を継承します。また、プロキシ サーバを使用しないすべての既存のクラスタは、クラスタの変更時または更新時にグローバル プロキシ構成を継承します。クラスタごとの構成をサポートする HTTP/S プロキシの場合、別のプロキシ サーバを使用してクラスタ仕様を更新することはできますが、グローバル プロキシ設定を削除することはできません。HTTP プロキシがグローバルに設定されている場合は、その HTTP プロキシを使用するか、別のプロキシ サーバで上書きする必要があります。

    回避策：TkgServiceConfiguration 仕様はグローバルに適用されることを理解します。一部のクラスタで HTTP プロキシを使用しない場合は、グローバル レベルで有効にしないようにします。クラスタ レベルで有効にします。

  • 多数の Tanzu Kubernetes クラスタと仮想マシンを含む非常に大規模なスーパーバイザー クラスタ環境で、OutOfMemory の発生により vmop-controller-manager ポッドが機能を停止し、Tanzu Kubernetes クラスタのライフサイクルが管理できなくなることがある

    スーパーバイザー クラスタ内では、vmop-controller-manager ポッドが Tanzu Kubernetes クラスタを構成する仮想マシンのライフサイクルを管理しています。このように、仮想マシン数が非常に多い場合（スーパーバイザー クラスタあたり 850 台を超える仮想マシン）、vmop-controller-manager ポッドが OutOfMemory CrashLoopBackoff 状態になる可能性があります。この状態が発生すると、Tanzu Kubernetes クラスタのライフサイクル管理は、vmop-controller-manager ポッドが処理を再開するまで中断されます。

    クラスタの削除、またはクラスタのスケール ダウンのいずれかの方法で、スーパーバイザー クラスタで管理される Tanzu Kubernetes クラスタ ワーカー ノードの総数を減らします。

  • 6.5 より前のバージョンの vSphere から vSphere 7 with Tanzu にアップグレードすると、PhotonOS タイプがサポートされていないというエラーが発生することがある

    vSphere 6 環境を vSphere 7 with Tanzu にアップグレードした後、Tanzu Kubernetes クラスタをデプロイしようとすると、PhotonOS が「サポートされていません」というエラー メッセージが表示されます。具体的なエラーは次のとおりです。

    failed to create or update VirtualMachine: admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType vmwarePhoton64Guest on image v1.19.7---vmware.1-tkg.1.fc82c41'

    vSphere 6.5 より前の vSphere バージョン（vSphere 6 など）から vSphere 7 with Tanzu にアップグレードした場合、PhotonOS をサポート対象のゲスト OS として表示するには、デフォルトの仮想マシンの互換性レベルを少なくとも「ESXi 6.5 以降」に設定しておく必要があります。そのため、[ワークロード管理] が有効な vSphere クラスタを選択し、右クリックして [仮想マシンのデフォルト互換性の編集] を選択します。[ESXi 6.5 以降] を選択します。

  • 小規模な仮想マシンを使用して Tanzu Kubernetes クラスタをプロビジョニングし、そのクラスタにワークロードをデプロイすると、ワーカー ノードが NotReady 状態になり、ノードの再作成を試みるループが繰り返される

    説明：クラスタの小規模または極小規模のワーカー ノードでは、/bin/opm プロセスが仮想マシン メモリを過度に消費し、ワーカー ノードでメモリ不足エラーが発生することがあります。

    回避策：短期開発またはテスト クラスタの場合でも、ワーカー ノードには小規模または極小規模の仮想マシン クラスを使用しないでください。ベスト プラクティスとして、どの環境でも、ワーカー ノードの最小仮想マシン クラスは中規模です。詳細については、ドキュメントの「デフォルトの仮想マシン クラス」を参照してください。

  • サブスクライブ済みコンテンツ ライブラリから Tanzu Kubernetes リリースを同期すると、「ホスト wp-content.vmware.com の SSL 証明書を認証できません」という HTTP 要求エラー メッセージが表示されて失敗する

    説明：Tanzu Kubernetes クラスタの OVA 用のサブスクライブ済みコンテンツ ライブラリを構成すると、wp-content.vmware.com の SSL 証明書が生成されます。証明書のサムプリントを確認して証明書を手動で信頼するように求められます。ライブラリの初回セットアップ後に SSL 証明書が変更された場合は、サムプリントを更新して新しい証明書を再度信頼する必要があります。コンテンツ ライブラリの現在の SSL 証明書は、2021 年 6 月末に有効期限が切れます。wp-content.vmware.com をサブスクライブしているお客様はコンテンツ ライブラリの同期に失敗するため、「回避策」の手順を実行してサムプリントを更新する必要があります。詳細については、https://kb.vmware.com/s/article/85268 の関連する VMware ナレッジベースの記事を参照してください。

    回避策：vSphere Client を使用して vCenter Server にログインします。サブスクライブ済みコンテンツ ライブラリを選択し、[設定の編集] をクリックします。このアクションにより、ライブラリに関する変更要求がない場合でも、サブスクリプション URL のプローブが開始されます。プローブを行うと SSL 証明書が信頼されていないことが検出され、信頼するように求められます。表示される [アクション] ドロップダウン メニューで [続行] を選択すると、フィンガープリントが更新されます。これで、ライブラリのコンテンツの同期を続行できます。

  • TKGS で、仮想マシン クラスとノードのスケール アップの同時変更がサポートされていない

    仮想マシン クラスの変更とノードのスケール アップの両方に関連する更新をクラスタに適用した後に、エラーが発生することがあります。

    TKC 構成を変更して、2 つのフィールドのいずれかのみを変更し、その変更を再適用してください。

  • 症状：クラスタ仕様のラベルまたはテイントを更新した後に、クラスタで予期しないローリング アップデートが発生する

    説明：TKGS v1alpha2 API の使用時、いずれかのノード プールの spec.topology.nodePools[*].labels または spec.topology.nodePools[*].taints を変更すると、そのノード プールのローリング アップデートがトリガされます。

    回避策：なし

  • 症状：クラスタの更新後、ノード プールに手動で追加したテイントとラベルが表示されなくなる

    説明：TKGS v1alpha2 API を使用すると、クラスタの更新中に、手動で追加され、更新前から存在していた spec.topology.nodePools[*].taints および spec.topology.nodePools[*].labels が保持されません。

    回避策：更新の完了後、ラベルとテイント フィールドを再度手動で追加します。

  • 症状：制御プレーン仮想マシンのいずれかが IP アドレスを取得できなかったため、Tanzu Kubernetes クラスタが作成フェーズで停止する

    説明：制御プレーン仮想マシンのいずれかが IP アドレスを取得できなかったため、Tanzu Kubernetes クラスタが作成フェーズで停止します。

    回避策：この問題を回避するには、Tanzu Kubernetes リリース 1.20.7 以降を使用します。

  • 症状：Tanzu Kubernetes クラスタの作成中、プロセスが「WaitingForNetworkAddress」という理由で更新中の状態で停止する

    説明：制御プレーン仮想マシンとワーカー ノードはパワーオンの状態ですが、IP アドレスが割り当てられていません。これは、VMware Tools のメモリが不足し、再起動しないことが原因で発生することがあります。

    回避策：この問題は、Tanzu Kubernetes リリース v1.20.7 以降では修正されています。また、仮想マシンのメモリを増やすことで問題を修正することもできます。best-effort-xsmall 仮想マシン クラスで提供されるメモリは、2G のみです。メモリの量が多い仮想マシン クラスを使用して、Tanzu Kubernetes クラスタをデプロイします。

  • 症状：セルフサービスの vSphere 名前空間が「削除中」の状態で停止する

    説明：vSphere 名前空間を削除すると、プロセスが進行せずに「削除中」の状態で数時間停止します。

    回避策：kubectl を使用し、名前空間から削除されずに残っている Kubernetes オブジェクトを確認します。kubeadm-control-plane に関連するオブジェクトが残っている場合は、capi-kubeadm-control-plane-controller-manager ポッドを再起動します。このアクションでは、削除するオブジェクトを再度キューに追加する必要があります。

    注：これは高度な操作です。この回避策を実行する前に、VMware サポートに確認してください。

  • TKC v1alpha2 API で、互換性のない TKr を使用した TKC の作成がブロックされない

    vCenter Server 7.0.3 MP2 リリース以降では、1.18.x より前のバージョンの TKr との互換性がありませんが、TKC API では引き続き v1.18.x より前のバージョンの TKC を作成することができます。そのため、互換性のない TKr を使用して TKC を作成した場合でも、TKC オブジェクトの作成はブロックされません。これらの TKC は作成されません。

    互換性のない TKr を使用して作成された、実行中の状態ではない TKC を削除します。その後、互換性のあるバージョンで再作成します。

vSAN データ パーシステンス プラットフォーム

  • vDPP ユーザー インターフェイス プラグインが vSphere Client にデプロイされず、すでに存在しないスーパーバイザー クラスタからプラグインのダウンロードが試行されたことを示すエラー メッセージが表示される

    この問題は、クラスタに vDPP ユーザー インターフェイス プラグインをデプロイしてから、このクラスタを削除すると、発生することがあります。ただし、この vDPP ユーザー インターフェイス プラグインに関連する古いエントリは vCenter Extension Manager に残ります。後で新しいクラスタを作成する場合、vSphere Client は古いエントリを使用して、存在しない古いクラスタからプラグインをダウンロードするため、このクラスタに同じバージョンの vDPP ユーザー インターフェイス プラグインをインストールすると失敗します。

    回避策：

    1. https://vc-ip/mob and を使用して vCenter Extension Manager に移動し、プラグイン拡張機能を特定します。

    2. 古いクラスタの名前を含むすべての ClientInfo エントリと ServerInfo エントリを削除します。

    3. ClientInfo 配列から、バージョン番号が最も大きい ClientInfo を選択して、そのタイプを vsphere-client-remote-backup から vsphere-client-remote に変更します。

  • スーパーバイザー クラスタの vSphere Pod に vm-uuid 注釈が付かずに保留状態のままになる

    ポッドが長時間保留状態のままになることがあります。この問題は通常、vSAN データ パーシステンス プラットフォーム (vDPP) を使用している場合に発生します。内部エラーまたはユーザー アクションが原因である可能性があります。

    kubectl コマンドを使用してポッド インスタンスをクエリしても、メタデータ注釈内に vmware-system-vm-uuid/vmware-system-vm-moid 注釈は見つかりません。

    回避策：kubectl delete pod pending_pod_name コマンドを使用してポッドを削除します。ポッドがステートフル セットに含まれている場合、ポッドは自動的に再作成されます。

  • 2 つのレプリカ ポッドのホスト ローカル PVC が同じクラスタ ノードにバインドされている場合、vDPP サービスのインスタンスのデプロイに失敗する

    2 つのレプリカ ポッドのホスト ローカル PVC が同じクラスタ ノードに割り当てられている場合、MinIO や Cloudian などの vSAN データ パーシステンス プラットフォーム サービスのインスタンスがある状態になることがあります。通常、同じインスタンスの 2 つのレプリカが、同じクラスタ ノード上にホスト ローカル ストレージを持つことはできません。この場合、レプリカ ポッドの 1 つが無期限に保留状態のままになり、インスタンスのデプロイに失敗することがあります。

    この失敗時に見られる症状には、次のすべてが含まれます。

    • インスタンスの健全性が黄色で表示される。

    • インスタンスの少なくとも 1 つのポッドが 10 分以上保留状態のままである。

    • 保留状態のポッドおよび同じインスタンスの実行されているレプリカ ポッドの 1 つのホスト ローカル PVC が、クラスタの同じノードに割り当てられている。

    この問題の原因となる可能性のある障害のシナリオは次のとおりです。

    • クラスタ内の一部のノードに、インスタンス用の十分なストレージ リソースがない。

    • レプリカの数がクラスタ内のノード数を超えている。原因としては、1 つ以上のノードが一時的に使用できないことが考えられます。

    回避策：

    1. クラスタに十分なストレージ リソースがあり、クラスタ ノードの数がインスタンス レプリカ数よりも多いことを確認します。

    2. 保留状態のポッドとそのすべてのホスト ローカル PVC を削除します。

    サービス オペレータは、ポッドがスケジューリングされる新しいノードでボリューム データを再構築する必要があります。ボリュームのサイズおよびボリューム上の有効なデータ量によっては、完了までに時間がかかることがあります。

  • [アクセシビリティの確保] モードで ESXi ノードのメンテナンスが終了した後も、メンテナンス中にノードに適用されたテイントがノード上で維持されることがある

    この問題は、vSAN データ パーシステンス プラットフォーム (vDPP) を使用してパートナー サービスのインスタンスを作成する場合に発生する可能性があります。ESXi ノードが [アクセシビリティの確保] モードでメンテナンスを終了した後も、ノードに残っているテイント node.vmware.com/drain=planned-downtime:NoSchedule は引き続き見つけることができます。

    通常、この問題は次のアクションが実行された場合に発生します。

    1.パートナー サービスがスーパーバイザー クラスタで有効になり、サービスのインスタンスが作成されます。

    2.ESXi ノードが [アクセシビリティの確保] モードでメンテナンス モードになります。

    3.ノードが [アクセシビリティの確保] でメンテナンス モードに正常に切り替わります。

    4.ノードにテイント「node.vmware.com/drain=planned-downtime:NoSchedule」が適用されます。

    5.ノードのメンテナンス モードが終了します。

    ノードのメンテナンス モードが終了したら、次のコマンドを使用してノードにテイントが残っていないことを確認します。

    kubectl describe node | grep Taints

    回避策：

    テイント「node.vmware.com/drain=planned-downtime:NoSchedule」がホストに存在する場合は、テイントを手動で削除します。

    kubectl taint nodes nodeNamekey=value:Effect-

    注：コマンドの末尾には、必ずハイフンを使用してください。

    この例に従ってください。

    kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule-

  • APD リカバリ後、AttachVolume エラーが発生して、vSAN データ パーシステンス プラットフォームで実行されているパーシステント サービス ポッドが保留状態のままになることがある

    ESXi ホストの ADP およびリカバリ後、vDPP サービス インスタンス ポッドが保留状態のままになることがあります。kubectl -n instance_namespace describe pod name_of_pod_in_pending コマンドを実行すると、AttachVolume エラーが表示されます。

    ポッドが 15 分以上保留状態のままになっている場合、この状態が終了することは通常ありません。

    回避策：次のコマンドを使用して、保留中のポッドを削除します。kubectl -n instance_namespace delete pod name_of_pod_in_pending.ポッドが再作成され、実行状態に移行します。

VM サービス

  • <span style="color:#FF0000">NEW：</span>名前が同一の vSphere ポッドと仮想マシン サービスの仮想マシンをデプロイするとエラーが発生し、予期しない動作が発生する

    障害やエラー、または他の問題のある動作が発生することがあります。これらの問題は、vSphere ポッドが名前空間で実行されている場合に、同じ名前空間に同じ名前を持つ仮想マシン サービス仮想マシンをデプロイする際、またはその逆の場合に発生する可能性があります。

    回避策：同じ名前空間内の vSphere ポッドと仮想マシンに同じ名前を使用しないようにします。

  • 仮想マシン サービスで使用できる仮想マシン イメージのセットが制限される

    仮想マシン サービスと互換性がない仮想マシン イメージを使用しようとすると、仮想マシンの作成時に次のメッセージが表示されます。

    Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image

    回避策：仮想マシン サービスで動作することが確認済みの VMware Marketplace の仮想マシン イメージのみを使用します。

  • DNS 非準拠の名前を持つ仮想マシン イメージを使用できない

    コンテンツ ライブラリ内の OVF イメージの名前が DNS サブドメイン名に準拠していない場合、仮想マシン サービスは OVF イメージから VirtualMachineImage を作成しません。その結果、kubectl get vmimage では名前空間にイメージがリストされず、開発者はこのイメージを使用できません。

    回避策：OVF イメージには DNS サブドメイン名に準拠した名前を使用します。

  • 重複する OVF イメージが重複する VirtualMachineImage として表示されない

    異なるコンテンツ ライブラリで同じ名前の OVF イメージは、異なる VirtualMachineImage として表示されません。

    回避策：仮想マシン サービスで構成されたすべてのコンテンツ ライブラリを通じて、OVF イメージに一意の名前を使用します。

  • 仮想マシン サービスで作成した仮想マシンで、Web またはリモート コンソールにアクセスできない

    仮想マシン サービスで作成した仮想マシンでは、リモート コンソールにアクセスできません。そのため、管理者は vSphere Web Client で [Web コンソールの起動] および [Remote Console を起動] オプションで仮想マシンにログインできません。

    回避策：管理者は、仮想マシンがある ESXi ホストにログインすれば、仮想マシン コンソールにアクセスできます。

  • ESXi ホストがメンテナンス モードに切り替わると、仮想マシンサービスによって管理されている vGPU デバイスおよびパススルー デバイス搭載の仮想マシンがパワーオフ状態になる

    仮想マシン サービスを使用すると、DevOps エンジニアは vGPU またはパススルー デバイスに接続された仮想マシンを作成できます。通常、ESXi ホストがメンテナンス モードに切り替わると、DRS はそのホストで実行されている仮想マシンを推奨します。その後、vSphere 管理者は、vMotion をトリガするための推奨を承諾することができます。

    ただし、仮想マシン サービスによって管理されている vGPU デバイスおよびパススルー デバイス搭載の仮想マシンは、自動的にパワーオフされます。これが、これらの仮想マシンで実行されているワークロードに一時的に影響する可能性があります。ホストがメンテナンス モードを終了すると、仮想マシンは自動的にパワーオンされます。

    回避策：なし。

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