check-circle-line exclamation-circle-line close-line

リリース ノートの概要

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

新機能

更新日:2020 年 5 月 19 日

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

 

新機能 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 Grid ワークロード クラスタを作成できないという問題が修正されました。
  • ディストリビューション名の向上
    • OVF のバージョン情報を別の列に移動することで、実行している 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

注:ここに記載されている Tanzu Kubernetes クラスタの OVA のビルド番号は、vSphere with Kubernetes の構成と管理ガイドのビルド番号に優先します。

各リリース ノートで、追加および更新された機能をご確認ください。

サービスの概要

VMware vSphere with Kubernetes for VMware vSphere 7.0 の本リリースには、VMware ESXi 7.0 と VMware vCenter Server 7.0 が必要です。

VMware vSphere with Kubernetes for VMware vSphere 7.0 には次のものが含まれます。

  • VMware vSphere 名前空間

    vCenter Server ユーザー インターフェイスで名前空間を作成し、コンピューティング、ネットワーク、ストレージ、アクセス ポリシーを添付します。DevOps エンジニアにこれらの名前空間へのアクセスを許可して、vSphere の kubectl プラグインを使用して、vSphere ポッドと Tanzu Kubernetes クラスタを名前空間に自分でプロビジョニングできるようにします。

  • VMware Tanzu Kubernetes Grid サービス

    Tanzu Kubernetes Grid サービスを使用すると、DevOps エンジニアは、すべての Kubernetes ネイティブ ワークロードに対して、vSphere 名前空間内で kubectl を介してオンデマンドで完全に適合したアップストリーム Kubernetes クラスタを作成できます。

  • VMware vSphere ポッドサービス

    vSphere ポッドは、ハイパーバイザー上で直接、効率的かつ安全に実行するために自動化されています。DevOps のエンジニアはこのサービスを使用して、vSphere 名前空間にコンテナ化されたワークロードをデプロイできます。

  • ストレージ サービス

    ストレージ サービスを使用することで、DevOps エンジニアは vSphere with Kubernetes の準仮想化アーキテクチャに従って vSphere 名前空間内へのパーシステント ボリュームの作成および管理が可能になります。これらのボリュームは、vSphere ポッドと Tanzu Kubernetes クラスタ ポッドの両方に接続および接続解除できます。

  • ネットワーク サービス

    ネットワーク サービスは、Tanzu Kubernetes クラスタの vSphere ポッド ネットワークとノードおよびサービス タイプのロード バランサ ネットワークを自動的に構成します。

  • レジストリ サービス

    vSphere with Kubernetes が有効になっているすべてのクラスタで、Harbor クラウド ネイティブ リポジトリ ( https://goharbor.io/) を含むレジストリ サービスも有効になります。vSphere with Kubernetes クラスタ上に作成されたすべての vSphere 名前空間は、その名前空間のユーザーが利用するために、Harbor で作成された一意のプロジェクトを取得します。

利用可能な言語

vSphere with Kubernetes for vSphere 7.0 は、次の言語で使用可能です。

  • 英語
  • フランス語
  • ドイツ語
  • スペイン語
  • 日本語
  • 韓国語
  • 簡体字中国語
  • 繁体字中国語

vCenter Server、ESXi、vSphere Client、vSphere Host Client を含む vSphere with Kubernetes for vSphere 7.0 のコンポーネントは非 ASCII 入力を受け入れません。

互換性

vSphere with Kubernetes for vSphere 7.0 は、次の製品のグリーンフィールドまたはブラウンフィールド インストールで機能します。

  • vSphere 7.0 以降
  • NSX-T Advanced 3.0 以降

はじめに

vSphere with Kubernetes for vSphere 7.0 には、通常の vSphere ライセンスに加えて特別なライセンスが必要です。このライセンスは、VMware Cloud Foundation 4.0 以降の一部として提供されます。

本リリースのインストールおよびアップグレード

vSphere with Kubernetes for vSphere 7.0 を使用するには、次のインストールが必要です。

  • ESXi 7.0 以降
  • vCenter Server 7.0 以降
  • NSX-T Advanced 3.0 以降

vSphere with Kubernetes for vSphere 7.0 のハードウェア要件は vSphere 7.0 と同じです。ただし、vSphere with Kubernetes for vSphere 7.0 では、NSX-T Edge 仮想マシンを使用する必要があります。また、これらの仮想マシンには、独自の小さな CPU 互換性のサブセットがあります。詳細については、NSX-T Data Center インストールガイドを参照してください。

vSphere with Kubernetes for vSphere 7.0 の開始の詳細については、vSphere with Kubernetes の構成と管理ドキュメントを参照してください。

vSphere 7.0 用オープン ソース コンポーネント

vSphere 7.0 で配布されているオープン ソース ソフトウェア コンポーネントに適用される著作権情報およびライセンスは、http://www.vmware.com をご確認ください。My VMware アカウントにログインする必要があります。[ダウンロード] メニューから [vSphere] を選択します。[オープン ソース] タブでは、vSphere の最新リリースで利用されており、ソース コードやソース コードへの改変の公開が必要な GPL、LGPL、またはその他の類似のライセンスのソース ファイルをダウンロードできます。

製品サポートに関する注意事項

  • VMware vSAN は含まれていますが、必須ではありません。vSphere with Kubernetes for vSphere 7.0 は、すべての vSphere ストレージ パートナーと互換性があります。
  • 本リリースでは vSAN に VMware vSphere Virtual Volumes サポートは含まれていません。
  • Tanzu Kubernetes Grid サービスによってプロビジョニングされた Tanzu Kubernetes クラスタを操作するときは、ユーザーに制限が発生することがあります。詳細については、vSphere with Kubernetes の構成と管理ドキュメントの「Tanzu Kubernetes Clusters の制限事項」を参照してください。
  • vSphere with Kubernetes for vSphere 7.0 は、現時点で、カスタムの HTTP および HTTPS ポートを使用して展開された vCenter Server 7.0 インスタンスをサポートしていません。

 

既知の問題

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

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

  • NodePort タイプのサービスがスーパーバイザー クラスタでサポートされない

    NodePort タイプの Kubernetes サービスはスーパーバイザー クラスタでサポートされていませんが、サービスの作成はブロックされません。

    回避策:NodePort タイプのサービスは作成しないでください。代わりに他のサービスを使用してください。

  • プライマリ ネットワーク識別子 (PNID) の変更がサポートされない

    クラスタでワークロード管理を有効にした後で vCenter Server の PNID を変更すると、問題が発生する可能性があります。

    回避策:vCenter Server の PNID は変更しないでください。

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

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

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

    1. mastervm <curl -k https://vip:6443(または 443)> 経由で apiserver にアクセスできるかどうかを確認します。

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

      2. 回避策:api-server がアクセス可能になるまで数分待ちます。

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

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

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

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

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

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

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

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

    または

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

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

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

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

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

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

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

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

  • vSphere 名前空間が有効な Kubernetes クラスタの障害が発生した組み込みのコンテナ レジストリにあるコンテナ イメージをリストアできない

    組み込みのコンテナ レジストリにあるコンテナ イメージのバックアップとリストアはサポートされていません。vSphere 名前空間が有効な Kubernetes クラスタの組み込みのコンテナ レジストリに障害が発生し、再起動しても復旧されない場合、レジストリにあるコンテナ イメージはリストアできません。

    回避策:組み込みのコンテナ レジストリからイメージをプルして外部コンテナ レジストリにプッシュすることによって、組み込みのコンテナ レジストリのコンテナ イメージを外部のコンテナ レジストリに定期的にバックアップします。
     

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

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

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

  • vSphere の組み込みのコンテナ レジストリにあるプロジェクト内のコンテナ イメージのイメージ プル数が正しくないことがある

    ポッドが vSphere の Kubernetes クラスタにデプロイされ、クラスタの組み込みのコンテナ レジストリにあるプロジェクトのコンテナ イメージを使用する場合、ポッドがデプロイされた後、コンテナ レジストリ ユーザー インターフェイスにイメージのイメージ プル数が 1 ではなく 2 と表示されることがあります。イメージがクラスタ外の Docker クライアントからプルされる場合、イメージのプル数は正常に更新されます。

    回避策:なし。

  • vSphere 上の Kubernetes クラスタの組み込みのコンテナ レジストリ用システム名前空間内の一部のポッドで障害が発生し、再起動することがある

    vSphere 上の Kubernetes クラスタの組み込みのコンテナ レジストリ用に、7 つのポッドがシステム名前空間で実行されています。ポッドのストレージ容量がログでいっぱいになると、ポッドは停止して再起動します。ポッドが再起動すると、コンテナ レジストリは正常に動作するようになります。

    回避策:なし。

  • エラーにより、vSphere 上の Kubernetes クラスタの組み込みのコンテナ レジストリを有効にできないことがある

    組み込みのコンテナ レジストリ名前空間内の一部のポッドは、ポッドの起動中に PVC(パーシステント ボリュームの要求)ボリュームに接続することがあります。このようなポッドで障害が発生した場合、ポッドが PVC ボリュームに接続できないため、新しいポッドが起動できないことがあります。この場合、ポッドのイベントにエラー メッセージ「cns ボリュームの接続に失敗しました」または「リソース「ボリューム」は使用されています」が記録されます。これは、組み込みのコンテナ レジストリの有効化中または有効化後に、ポッドの障害が発生した場合に発生する可能性があります。

    回避策:コンテナ レジストリ名前空間内の障害が発生したすべてのポッドを削除します。

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

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

    回避策:なし。

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

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

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

  • New: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 を再起動したり、ホストを削除または追加したりしないでください。

  • 組み込みの Harbor が障害状態の場合、スーパーバイザー クラスタのアップグレードが停止する場合がある

    組み込みの Harbor が有効でも、障害がある状態の場合は、このスーパーバイザー クラスタのアップグレードは無期限に停止する可能性があります。

    回避策:このスーパーバイザー クラスタの Harbor を再度有効にします(注:レジストリに保存されているすべてのイメージは失われます)。

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

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

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

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

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

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

  • クラスタ構成を実行するには、2 台以上の ESXi ホストが必要になる

    現時点では、単一 ESXi ホストのクラスタはサポートされていません。指定した ESXi ホストが 1 台のみの場合、プリフライト チェックにより、クラスタでの NSX コンポーネントの構成に進むことができなくなります。

    回避策:なし。

  • クラスタ構成後に 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 を使用して、ワークロード管理サービスを再起動します。

  • 複数の NIC があるシナリオでインストールの推奨 API から非管理 NIC が返される

    複数の NIC があるシナリオで NSX をインストールすると、インストールの推奨 API から、管理 IP アドレスが構成されていない NIC の推奨が返されることがあります。

    回避策:vCenter Server に、1 つの NIC を持つ NSX をインストールします。

  • ステップ 2:[NSX ネットワークのインストール]([ワークロード管理のはじめに行う作業] ワークフロー)の [インストール] ボタンが無効状態で表示される

    ステップ 1:[ソフトウェアの取得]([ワークロード管理のはじめに行う作業] クイック スタート)を完了した後、ステップ 2:[NSX ネットワークのインストール] の [インストール] ボタンが無効のままになります。

    回避策:ブラウザの開発者ツールを使用して、[インストール] ボタンを有効にします。

    1. ブラウザの要素検査ツール(Google Chrome の [Inspect Elements] または Mozilla Firefox の [インスペクター])を開きます。

    2. [インストール] ボタン オブジェクトを選択し、"WcpUi: wcp.installNSX.button.title" disabled> Install" 行を "WcpUi: wcp.installNSX.button.title"> Install" に変更して、無効なフラグを削除します。

  • データストアに 35 GB 以上の空き容量がないと NSX のインストールに失敗することがある

    インストールに必要な最小のシン ディスク サイズは 35 GB です。

    回避策:NSX をインストールする前に、データストアに 35 GB 以上の空き容量があることを確認します。

  • vCenter Server からインターネットへの接続がプロキシ サーバによってブロックされる

    プロキシ サーバが構成されている場合、vCenter Server がインターネットに接続できず、MyVMware ポータルへの接続がブロックされることがあります。

    回避策:vCenter Server 用にプロキシが構成されていないことを確認します。

  • NSX Manager 構成の完了後、[ワークロード管理のはじめに行う作業] ワークフローのステップ 3 の [有効] ボタンが無効状態で表示される

    ステップ 2:[NSX ネットワークのインストール]([ワークロード管理のはじめに行う作業] クイック スタート)を完了した後、[有効] ボタン(ステップ 3:[ワークロード管理の有効化])が無効のままになります。

    回避策:移動してクイック スタート画面に戻り、vCenter Server インスタンスを選択してステップ 3 を続行します。

  • [ワークロード管理のはじめに行う作業] ワークフローのステップ 3 の [次へ] ボタンをクリックしてもワークフローの次のステップに進まない

    NSX 構成で ステップ 3:[ワークロード管理の有効化] の部分を完了後、[次へ] ボタンをクリックしても、ステップ 4:[ステッパ] が強調表示されますが、それ以外の効果がありません。

    回避策:ブラウザを更新し、ステップ 3 の NSX の構成部分をスキップし、[次へ] をクリックしてワークフローを続行します。

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

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

    回避策:

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

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

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

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

     

  • リーダーの選出タイムアウトによりスーパーバイザー コンテナが再起動される

    etcd のストレージ I/O 遅延が原因で、リーダーの選出タイムアウトにより、スーパーバイザー コンテナが再起動されることがあります。

    回避策:なし。

  • Tanzu Kubernetes クラスタ名に IP アドレスが追加される

    クラスタがデプロイされているスーパーバイザー名前空間の名前と同一の Tanzu Kubernetes クラスタ名を定義すると、システムは、名前の競合を回避するために、制御プレーンの IP アドレスを Tanzu Kubernetes 名に自動的に追加します。たとえば、Tanzu Kubernetes クラスタに tkg-cluster_01 という名前を付け、スーパーバイザー名前空間に tkg-cluster_01 という名前を付けた場合、kubectl get-contexts を実行すると、Tanzu Kubernetes 名は tkg-cluster_01-10.174.4.33 として表示されます(10.174.4.33 は制御プレーンの IP アドレスです)。

    回避策:IP アドレスを Tanzu Kubernetes クラスタ名の一部として使用しない場合は、Tanzu Kubernetes クラスタがデプロイされているスーパーバイザー名前空間とは異なる名前を定義します。

  • 証明書を更新すると証明書のローテーション エラーが発生する

    ユーザーが証明書を更新するときに証明書のローテーションに関するエラーが表示されることがあります。証明書は、Tanzu Kubernetes クラスタが古い証明書を受信した後に更新されます。

    回避策:証明書の更新を再試行します。

  • Tanzu Kubernetes クラスタにノードを追加すると、vCenter Server で仮想マシンの作成エラーが発生することがある

    ユーザーが Tanzu Kubernetes クラスタにノードを追加してスケールアウトすると、仮想マシン オペレータは、既存のノードの再作成を試みます。この操作は失敗し、vCenter Server タスク リストにタスクの失敗メッセージが表示されます。

    回避策:なし。

  • コンテンツ ライブラリがスーパーバイザー クラスタに関連付けられていない場合、Tanzu Kubernetes クラスタの作成がエラーで失敗する

    Tanzu Kubernetes Grid サービスをスーパーバイザー クラスタで動作させるには、vCenter Server コンテンツ ライブラリをスーパーバイザー クラスタに関連付ける必要があります。これが構成されていない場合、クラスタの作成に失敗し、次のようなエラーが表示されます。

    Error from server (storage class is not valid for control plane VM:  
    Mandatory StorageClass is not specified for TanzuKubernetesCluster '' , 
    storage class is not valid worker VMs: Mandatory StorageClass is not specified for TanzuKubernetesCluster '' , 
    could not find spec.distribution.version "v1.15.5+vmware.1.66-tkg.1.1034"): error when creating "test-cluster.yaml":  
    admission webhook "default.tanzukubernetescluster.kb.io" denied the request:  
    storage class is not valid for control plane VM:  
    Mandatory StorageClass is not specified for TanzuKubernetesCluster '' , 
    storage class is not valid worker VMs: Mandatory StorageClass is not specified for TanzuKubernetesCluster '' , 
    could not find spec.distribution.version "v1.15.5+vmware.1.66-tkg.1.1034"

    回避策:仮想インフラストラクチャ管理者に、スーパーバイザー クラスタを vCenter Server のコンテンツ ライブラリに接続することを依頼します。

  • 削除されたストレージ クラスが原因で、Tanzu Kubernetes クラスタをスケールアウトできない

    削除されたストレージ クラスに依存する Tanzu Kubernetes クラスタをスケールアウトすると、システムは削除されたストレージ クラスを使用して新しいディスクを接続できないため、このアクションは失敗します。

    回避策:vCenter Server で、削除されたストレージ ポリシーと同じ名前の新しいストレージ ポリシーを作成します。再作成したストレージ ポリシーをスーパーバイザー名前空間に追加します。このストレージ クラスを使用している TanzuKubernetesCluster インスタンスが完全に動作するようになります。削除するストレージ クラスを使用しているそれぞれの TanzuKubernetesCluster リソースに対し、異なるストレージ クラスを使用して新しい TanzuKubernetesCluster インスタンスを作成します。Velero を使用して、ワークロードを新しいクラスタに移行します。削除するストレージ クラスを使用している TanzuKubernetesCluster または PersistentVolume がない状態になると、これを安全に削除できます。

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

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

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

  • DNS サーバの更新が Tanzu Kubernetes クラスタに伝達されない

    vSphere 管理者が vSphere with Kubernetes インストールをサポートする DNS サーバを更新すると、更新されたレコードはスーパーバイザー クラスタに伝達されますが、Tanzu Kubernetes Grid サービスを使用してプロビジョニングされた既存の Tanzu Kubernetes クラスタには伝達されません。既存のすべての Tanzu Kubernetes クラスタ ノードは、以前の DNS 設定を引き続き使用します。新しい Tanzu Kubernetes クラスタでは、新しい DNS レコードが継承されます。

    回避策:DNS の変更によりアクセスできない既存の Tanzu Kubernetes クラスタは、アップグレードまたは削除して再作成する必要があります。

  • Tanzu Kubernetes クラスタの仮想マシン ディスクがシック プロビジョニングされている

    Tanzu Kubernetes クラスタの仮想マシン ディスクは、データストア ポリシーに関係なく、シック プロビジョニングされます。

    回避策:なし。

  • Tanzu Kubernetes クラスタに LoadBalancer タイプの Kubernetes サービスが作成される場合、Tanzu Kubernetes クラスタの名前を 31 バイトより大きくすることができない

    LoadBalancer タイプの 1 つ以上の Kubernetes サービスをホストする Tanzu Kubernetes クラスタを作成する場合、クラスタ名は 31 バイト以下にする必要があります。シングルバイトの文字セットの場合は、これは約 30 文字に変換されます。ダブルバイトの文字セットの場合は、15 文字に変換されます。

    回避策:なし。

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

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

    回避策

    1.「システム ユーザーとしての Tanzu Kubernetes クラスタ ノードへの SSH 接続」トピックに記載されている手順を参照して、Tanzu Kuberenets クラスタの制御プレーン ノードのいずれかに SSH 接続します。

    2.「vmware-system-user」ユーザーとしてログインしたら、コマンド「sudo su -」を実行して root ユーザーに切り替えます。

    3.次のコマンドを実行します。"KUBECONFIG=/etc/kubernetes/admin.conf /usr/lib/vmware-wcpgc-manifests/generate_key_and_csr.sh"

    4.数分後に、すべての authsvc ポッドが実行されます。

  • 更新中に Tanzu Kubernetes Grid クラスタが処理中の場合、スーパーバイザー名前空間の更新が 50% で停止することがある

    vSphere 名前空間の更新中に Tanzu Kubernetes クラスタの作成または削除が進行中の場合、Tanzu Kuberentes クラスタが実行されているスーパーバイザー クラスタの更新が保留または 50% の状態で停止することがあります。

    回避策:vSphere 名前空間の更新を開始する前に、すべての Tanzu Kuberentes クラスタが「作成」や「削除」の進行中ではないことを確認します。vSphere with Kubernetes ドキュメントで Tanzu Kubernetes クラスタのライフサイクル ステータス コードを参照してください。

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

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

    回避策

    1.「システム ユーザーとしての Tanzu Kubernetes クラスタ ノードへの SSH 接続」トピックに記載されている手順を参照して、Tanzu Kuberenets クラスタの制御プレーン ノードのいずれかに SSH 接続します。

    2.「vmware-system-user」ユーザーとしてログインしたら、コマンド「sudo su -」を実行して root ユーザーに切り替えます。

    3.次のコマンドを実行します。"KUBECONFIG =/etc/kubernetes/admin.conf /usr/lib/vmware-wcpgc-manifests/generate_key_and_csr.sh"

    4.数分後に、すべての authsvc ポッドが実行されます。

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

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

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

  • スーパーバイザー クラスタの更新の直後にデプロイされた LoadBalancer タイプのサービスが外部 IP アドレスを受信しない

    スーパーバイザー クラスタの更新後に Tanzu Kubernetes クラスタにデプロイされた LoadBalancer タイプのサービスは、外部 IP アドレスを受信しません。スーパーバイザーの更新の完了後、ロード バランサ タイプのサービスは最終的に外部 IP アドレスを取得します。

    回避策:なし

  • 数字で始まる名前の Tanzu Kubernetes クラスタを作成できない、またはピリオドを含む場合は正常に作成されない

    名前が数字で始まるかピリオドを含む場合、Tanzu Kubernetes クラスタは、正常に作成されません。

    回避策:なし

  • Tanzu Kubernetes クラスタが正常に更新された後に古いクラスタ ノードがクラスタから削除されない

    Tanzu Kubernetes クラスタが正常に更新された後に古いクラスタ ノードがクラスタから削除されないことがあります。

    回避策:これらのノードは、コマンド「kubectl delete node <node_name>」を実行することで、手動で削除できます。これで、CrashLoopBackOff 内のポッドを削除し、実行状態に戻すことができます。

  • スーパーバイザー名前空間の削除が「削除中」の状態で停止する

    スーパーバイザー名前空間を削除すると、削除処理が「削除中」の状態で停止します。

    回避策:対象の名前空間内のすべての Tanzu Kubernetes クラスタが削除されるまで、スーパーバイザー名前空間の削除を試行しないでください。

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

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

    回避策

    影響を受けるノードで kubelet を再起動し、etcd ポッドを再起動して PodIP を受信します。その後、次のリカバリ手順を実行して失敗したアップグレードからリカバリします。これらの手順を実行する前に、VMware サポートにお問い合わせください。

    1)正常にアップグレードされたが、元のマシンが削除されなかったマシンの場合。

    • etcd のメンバー リストから元のマシンのノード リファレンスを削除します。
    • 元のマシンを削除します(新しくアップグレードされたマシンを残します)。 

    2)任意のマシンに対して、これは非健全です。

    • TanzuKubernetesCluster のリソース バージョン (.metadata.resourceVersion) を取得します。
    • 次の注釈が付いたマシンのリストを取得します。「upgrade.cluster-api.vmware.com/id」これらは、以前のアップグレードの試行からアップグレードされたノードです。
    • 注釈をリソース バージョンに一致するように更新します(差異がない場合は不要)。
    • クラスタに属するアップグレード ジョブを削除します。
    • アップグレードが再開されることを確認します。
NSX-T
  • vSphere Lifecycle Manager イメージが有効なクラスタでは、vSphere with Kubernetes および NSX-T を有効にできない

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

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

  • 「LoadBalancerIP」がサポートされていない

    LoadBalancer タイプの Kubernetes サービスでは、Tanzu Kubernetes クラスタに対して「LoadBalancerIP」構成はサポートされません。

    回避策:なし

  • 「ExternalTrafficPolicy: local」がサポートされていない

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

    回避策:なし。

  • Tanzu Kuberetes クラスタでサポート可能な LoadBalancer タイプのサービスの数がスーパーバイザー クラスタの NodePort 範囲によって制限される

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

    回避策:なし。