リリース ノートの概要

更新日:2021 年 4 月 27 日

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

 

新機能

VMware vSphere with Tanzu では、Kubernetes やその他のサービスを更新し、アップストリームに対応し、報告された問題を解決するための新しい機能を導入するためのパッチを毎月公開しています。ここでは、毎月のパッチで提供されたものについて説明します。

 

2021 年 4 月 27 日の新機能 

2021 年 4 月 27 日のビルド情報

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

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

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

新機能

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

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

  • Tanzu Kubernetes Grid Service for vSphere
     
    • Kubernetes メトリクス サーバはデフォルトで有効です。Kubernetes メトリクス サーバは、すべての Tanzu Kubernetes クラスタで有効になるクラスタ使用データのアグリゲータと言えます。現在のノードとポッドの使用量は、「kubectl top」で表示できるようになりました。
       
    • システムの革新をもたらす Webhook は、ドライラン モードをサポートするようになりました。また、Terraform Kubernetes プロバイダのようによく知られたツールを Tanzu Kubernetes Grid サービスと統合できるようになりました。  これまで、Terraform の「plan」コマンドの要件であった、ドライラン モードがシステム Webhook ではサポートされていませんでした。
       
    • カスタムの仮想マシン クラス。Tantan 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 から共通のステータスと障害状態が表示されるようになったことで、トラブルシューティングが簡素化されました。

解決した問題

  • vSphere 7.0 U1 で導入された新しいデフォルトの仮想マシン クラスがない

    • 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 のオープン ソース コンポーネントのダウンロードの場所についても記載されています。

既知の問題

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

スーパーバイザー クラスタ
  • 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 を使用してスーパーバイザー クラスタ名前空間を手動で共有します。

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

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

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

  • 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 のクラスタ構成で、構成中にタイムアウト エラーが表示される

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

    param0 への API 要求に失敗しました

    または

    param0 ノード仮想マシンの構成操作がタイムアウトになりました

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

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

    ユーザーがユーザー インターフェイスからコンテナ レジストリを有効にすると、有効化アクションは 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 レジストリへのログイン操作が「非認証: 認証が必要です。」または「ユーザー名またはパスワードが無効です」というエラーで失敗することがあります。

    回避策:レジストリ エージェント ポッドを 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) ルート証明書を変更すると、スーパーバイザー クラスタのプライベート コンテナ レジストリに問題が発生して、レジストリ操作が想定どおりに動作しなくなる場合があります。クラスタ構成ユーザー インターフェイスに、コンテナ レジストリに関する次の健全性ステータス メッセージが表示されます。

    クラスタ domain-c8 の Harbor レジストリ harbor-1560339792 が健全ではありません理由: Harbor 健全性の取得に失敗しました: Get https://30.0.248.2/api/health: x509: 証明書が不明な認証局によって署名されています

    回避策:

    次の手順に従って、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 または 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:user@vsphere.local" cannot list resource "namespaces" in API group "" at the cluster scope

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

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

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

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

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

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

    Error from server (Forbidden): User "sso:nuser@vsphere.local" cannot patch resource "namespaces" in API group "" in the namespace ""

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

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

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

    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 の仮想マシン イメージのみを使用します。

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

    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

    回避策:なし

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

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

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

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

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

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

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

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

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

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

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

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

ネットワーク
  • 低速ネットワークで 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.1 ~ 4094 の間の VLAN ID を使用してください

    回避策:次のプロセスのいずれかを使用して、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 範囲を使用しないでください。

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

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

    警告 ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller 制御プレーンが制御プレーン健全性チェックをパスし、調整を続行するまで待機しています: マシンの (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) ノード (tkg-cluster-3-control-plane-4bz9r) がチェックされませんでした

    回避策なし。

  • 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 に vSphere 7 U1 と互換性がない

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

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

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

    説明: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 initresolvConf/etc/resolv.conf に設定する構成ファイルを生成します。この構成ファイルは、/run/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.18kubelet-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 以降] を選択します。

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

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

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

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

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

    回避策: 

    1. Tantain Kubernetes クラスタ PV で、persistentVolumeReclaimPolicyRetain に変更します。
    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 exceeded F0817 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 が再初期化されます。

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