リリース ノートの概要

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

新機能

新機能 2022 年 12 月 15 日

VMware vSphere 8.0 | 2022 年 12 月 15 日

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

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

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

新機能

  • スーパーバイザー サービスとしての Harbor の追加 - スーパーバイザーで実行される、機能をすべて備えた Harbor(OCI イメージ レジストリ)インスタンスを提供します。Harbor インスタンスを使用すると、Harbor 管理者はプロジェクトとユーザーを作成/管理したり、イメージ スキャンを設定したりできます。

  • vRegistry の廃止 - vRegistry と呼ばれる組み込みの Harbor インスタンスは、今後のリリースで削除される予定です。代わりに、Harbor をスーパーバイザー サービスとして使用できます。移行の詳細については、Migrate Images from the Embedded Registry to Harborを参照してください。

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

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

  • vSphere Zone API - vSphere Zone は、可用性の高いスーパーバイザー クラスタと Tanzu Kubernetes クラスタを作成するために、アベイラビリティ ゾーンを vSphere クラスタに割り当てることができるようにする構造です。vSphere 8.0 では、vSphere Client から vSphere Zone 機能を作成および管理できていました。vSphere 8.0.0a リリースでは、ユーザーが DCLI または vSphere Client API Explorer を使用して、vSphere Zone を作成および管理できます。SDK バインドの完全なサポート(Java、Python など)については、今後のリリースで対応する予定です。

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

  • Tanzu Kubernetes クラスタのローリング アップデートは、次に示すスーパーバイザーのアップグレード シナリオで発生します。

    • 8.0 から 8.0.0a にアップグレードした後で、スーパーバイザーを任意の Kubernetes リリースからスーパーバイザー Kubernetes 1.24 にアップグレードし、次に示すいずれかの条件を満たした場合。

      • Tanzu Kubernetes クラスタで、空ではない noProxy リストを含むプロキシ設定を使用している場合

      • スーパーバイザーで vRegistry が有効になっている場合。この設定は、NSX ベースのスーパーバイザーでのみ使用できます。

    • vSphere 7.0 リリースから vSphere 8.0.0a にアップグレードする場合。

解決した問題:

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

    vCenter 8.0 では、Tanzu 8 ライセンス キーではなく Tanzu 7 ライセンス キーがサポートされます。この問題の有無に関係なく、vCenter Server 8.0 では Tanzu の機能を完全に使用できます。vCenter Server 8.0 のデプロイで Tanzu ライセンスを変更するには、事前に VMware ナレッジベースの記事KB89839で詳細を確認してください。

  • NSX-ALB に 2 つの SE グループが存在する場合に LoadBalancer とゲスト クラスタが作成されない

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

    get() returned more than one ServiceEngineGroup – it returned 2

    その結果、新しいロード バランサを使用できず、新しいワークロード クラスタを正常に作成できません。詳細については、VMware ナレッジベースの記事KB90386を参照してください。

新機能 2022 年 10 月 11 日

VMware vSphere 8.0 | 2022 年 10 月 11 日

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

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

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

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

  • ワークロード管理構成の監視 - スーパーバイザーの有効化、無効化、およびアップグレードのステータスをより詳細に追跡できるようになりました。スーパーバイザーの有効化、無効化、またはアップグレードを開始すると、スーパーバイザーは、制御プレーン仮想マシンなどの各コンポーネントに関連付けられたさまざまな条件に到達することで、目的の状態への到達を試行します。各条件のステータスの追跡、関連する警告の表示、ステータスの再試行、到達した条件およびそのタイムスタンプの表示を行うことができます。

  • vSphere Zones - vSphere Zone は、アベイラビリティ ゾーンを vSphere クラスタに割り当てることができるようにする新しい構造です。複数の vSphere Zone にスーパーバイザーをデプロイすると、特定のアベイラビリティ ゾーンおよび障害ドメインに Tanzu Kubernetes Grid クラスタをプロビジョニングできます。これにより、複数のクラスタにわたってワークロードを実行することができ、ハードウェアとソフトウェアの障害に対する回復性が向上します。

  • マルチクラスタ スーパーバイザー - vSphere Zone を使用すると、スーパーバイザーを複数の vSphere クラスタにわたってデプロイし、Tanzu Kubernetes Grid クラスタに高可用性と障害ドメインを提供できます。このリリースは、Metro クラスタ環境を対象としていません。マルチクラスタ スーパーバイザーのユースケースでは、vSphere クラスタを単一の物理データセンター内の個別のラックに配置します。続いて、各 vSphere クラスタを個別の vSphere Zone に追加します。これにより、ローカライズされたハードウェアおよびソフトウェアの障害に対するフェイルオーバーと回復性が提供されます。ゾーン、ラック、または vSphere クラスタがオフラインになると、スーパーバイザーが障害を検出し、別の vSphere Zone でワークロードを再開します。

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

  • SecurityPolicy CRD による一貫したネットワーク ポリシーの提供 - SecurityPolicy カスタム リソース定義では、スーパーバイザー名前空間内の仮想マシンと vSphere Pod のネットワーク セキュリティ制御を構成できます。

  • Tanzu Kubernetes Grid 2.0 - Tanzu Kubernetes Grid がバージョン 2.0 に移行されました。Tanzu Kubernetes Grid 2.0 は、Tanzu および Kubernetes コミュニティにおける大きな技術革新の極致で、Tanzu Kubernetes Grid を使用してプライベート クラウドとパブリック クラウドを操作する場合の共通のインターフェイス セットの基盤となります。このリリースの新機能に、次の 2 つの主要機能があります。

    • ClusterClass - Tanzu Kubernetes Grid 2.0 で ClusterClass がサポートされるようになりました。ClusterClass はアップストリームに合わせたインターフェイスを提供し、Tanzu Kubernetes Grid プラットフォームにカスタマイズ機能を提供する Tanzu Kubernetes クラスタの代わりに使用されます。ClusterClass を使用すると、管理者はエンタープライズ環境の要件を満たすテンプレートを定義する一方で、ボイラープレートを減らし、委任されたカスタマイズを実行できます。

    • Carvel - Carvel では、アプリケーションの構築、構成、Kubernetes へのデプロイを支援する、信頼性の高い、単一用途の構成可能なツール セットが提供されます。特に、kapp および kapp-controller は、アップストリームに合わせた宣言型ツールのセットを介して、パッケージの管理、互換性、およびライフサイクルの機能を提供します。テンプレート化を行う ytt と組み合わせることで、柔軟で管理しやすいパッケージ管理機能が実現します。

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

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

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

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

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

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

既知の問題

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

  • スーパーバイザーをアップグレードせずに ESXi ホストを 7.0 Update 3 から 8.0 にアップグレードすると、ESXi ホストに「準備ができていません」と表示され、ワークロードがオフラインになる

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

    回避策:スーパーバイザーの Kubernetes バージョンを 1.21、1.22、または 1.23 以降にアップグレードします。

  • vCenter Server のワンクリック アップグレードを実行しても、スーパーバイザーが自動的にアップグレードされない

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

    回避策:vCenter Server を 8.0 にアップグレードする前に、スーパーバイザーの Kubernetes バージョンを 1.22 にアップグレードします。vCenter Server を 8.0 にすでにアップグレードしている場合は、スーパーバイザーの Kubernetes バージョンを 1.23 に手動でアップグレードします。

  • セキュリティ ポリシーのカスタム リソースでルールを変更したときに、古いルールが削除されないことがある

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

    回避策:セキュリティ ポリシーを削除してから、同じポリシーを作成します。

  • vCenter Server と vSphere with Tanzu のアップグレード後、クラスタのノードに接続されていると表示されるボリュームが原因で、Tanzu Kubernetes Grid クラスタがアップグレードを完了できない

    Tanzu Kubernetes Grid クラスタのアップグレードに失敗すると、ボリュームがクラスタのノードに接続されていると表示され、クリアされないことがあります。この問題は、アップストリーム Kubernetes の問題が原因で発生する可能性があります。

    回避策:

    1. 次のコマンドを使用して、スケジュール設定が無効になっている TKG クラスタ ノードに関する情報を取得します。

      kubectl get node tkc_node_name -o yaml

      例:

      # kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
      apiVersion: v1
      kind: Node
      metadata:
        annotations:
          cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
          cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
          cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
          cluster.x-k8s.io/owner-kind: MachineSet
          cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
          csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
          kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
          node.alpha.kubernetes.io/ttl: "0"
          volumes.kubernetes.io/controller-managed-attach-detach: "true"
      ….
      ….
        volumesAttached:
        - devicePath: ""
          name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

      status.volumeAttached プロパティで、このノードに vSphere CSI ボリュームがあるかどうかを確認します。ボリュームがある場合は、次の手順に進みます。

    2. 手順 1 で特定したノードでポッドが実行されていないことを確認します。次のコマンドを使用します。

      kubectl get pod -o wide | grep tkc_node_name

      例:

      kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      このコマンドの出力が空の場合は、ポッドがないことを示します。手順 1 の出力には、ポッドがないノードに接続されているボリュームが表示されているため、次の手順に進みます。

    3. すべてのノード オブジェクトに関する情報を取得して、同じボリュームが別のノードに接続されていることを確認します。

      kubectl get node -o yaml

      例:

      同じボリューム名が 2 つの TKG クラスタ ノード オブジェクトに表示されます。

      On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
        volumesAttached:
        - devicePath: ""
          name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
      
      On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
        volumesAttached:
        - devicePath: ""
          name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
          ...
        volumesInUse:
        - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
        ...
    4. ボリューム名のボリューム ハンドルに基づいて PV を検索します。

      上記の例では、ボリューム名は kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd です。ボリューム ハンドルは 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd です。

      次のコマンドを使用して、すべての PV を取得し、上記のボリューム ハンドルを検索します。

      kubectl get pv -o yaml

      上記の例では、そのボリューム ハンドルを使用する PV は pvc-59c73cea-4b75-407d-8207-21a9a25f72fd です。

    5. volumeattachment コマンドを使用して、前の手順で見つかった PV を検索します。

      kubectl get volumeattachment | grep pv_name

      例:

      # kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
      NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
      csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

      ノード gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 ではなく、ノード gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 に接続されているボリューム接続を確認できます。これは、gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95status.volumeAttached が正しくないことを示します。

    6. 古い volumeAttached エントリをノード オブジェクトから削除します。

      kubectl edit node tkc_node_name

      例:

      kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      古いボリューム エントリを status.volumeAttached から削除します。

    7. status.volumeAttached プロパティで、すべての古いボリュームに対して上記の手順を繰り返します。

    8. WCPMachines がまだ存在する場合は手動で削除し、数分間待ってからクラスタを調整します。

      # kubectl get wcpmachines -n c1-gcm-ns
      NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
      c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17
      
      # kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
      wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

  • クラスタのキャパシティを超えるリソース制限を持つセルフサービス名前空間テンプレートを vSphere 管理者が構成すると、アラートがトリガされない.

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

    回避策:なし

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

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

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

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

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

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

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

    回避策:

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

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

    kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

  • vSAN などの共有データストアから複数の FCD とボリュームを削除すると、パフォーマンスが変化する場合がある

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

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

  • vCenter Server の再起動中に DevOps ユーザーがボリューム操作またはステートフル アプリケーションのデプロイを開始すると、操作が失敗することがある

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

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

    Authentication failed: The account of the user trying to authenticate is locked.:: The account of the user trying to authenticate is locked.:: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})

    回避策:

    1. アカウントのロック解除時間を取得します。

      1. vSphere Client で、[管理] に移動し、[Single Sign-On] の下の [構成] をクリックします。

      2. [ローカル アカウント] タブをクリックします。

      3. [ロックアウト ポリシー] で、ロック解除時間(秒単位)を取得します。

    2. kubectl 向けの vSphere プラグインを使用してスーパーバイザーで認証します。

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

    3. vmware-system-csi- 名前空間内の vsphere-csi-controller のデプロイの元のレプリカ数をメモします。

      kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'

      original-replica-count

    4. vsphere-csi-controller のデプロイのレプリカ数をゼロにスケールダウンします。

      kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi

    5. [ロック解除時間] に示されている秒数だけ待機します。

    6. vsphere-csi-controller のデプロイのレプリカ数を元の値にスケールアップします。

      kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

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

  • vSphere with Tanzu 8.0.0a で v1alpha1 API と v1.23.8 TKR を使用して TKC をプロビジョニングできない

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

    TKC のプロビジョニング時に TKC v1alpha2 または v1alpha3 API に切り替えてください。

  • vSphere with Tanzu 8.0.0a のゲスト クラスタで tanzu-capabilities-controller-manager ポッドが再起動を繰り返して CLBO が発生する

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

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

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

      kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi
    2. 次のデータを使用して、capabilities-rbac-patch.yaml という新しいファイルを作成します。

      - apiGroups:
      - core.tanzu.vmware.com
      resources:
      - capabilities
      verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
      - apiGroups:
      - core.tanzu.vmware.com
      resources:
      - capabilities/status
      verbs:
      - get
      - patch
      - update
    3. TKC で機能クラスタ ロールにパッチを適用します。

      kubectl patch clusterrole tanzu-capabilities-manager-clusterrole --patch-file capabilities-rbac-patch.yaml --type=merge
    4. TKC で tanzu-capabilities-controller-manager を削除します。

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

    TKR イメージのコンテンツ ライブラリには TKR v1.22.9 がリストされます。「kubectl get tkr」コマンドでは、このイメージが使用可能なイメージとしてリストされません。これは、TKR v1.22.9 を使用できない、および使用すべきではないためです。このイメージがコンテンツ ライブラリに表示されるのは誤りです。

    TKR v1.22.9 以外の TKR を使用してください。使用可能な TKR のリストについては、TKR リリース ノートを参照してください。

  • v1beta1 クラスタでノードのドレイン タイムアウトが正しく伝達されない

    Tanzu Kubernetes リリース リゾルバは、制御プレーン マシンのデプロイ トポロジに nodedzutimeout が含まれていないクラスタ タイプに基づいてクラスタを変更するため、nodedzutimeout は正しく伝達されません。

    回避策:

    root ユーザーとしてスーパーバイザーにログインします。

    ワーカー ノードにノードのドレイン タイムアウトを追加するには、次のコマンドを実行して、nodeDrainTimeout 値を machineDeployment.spec.template.spec.nodeDrainTimeout に追加します。

    kubectl edit md <machine-deployment> -n <namespace>

    制御プレーン ノードについては、次のコマンドを使用して、Kubernetes 制御プレーンのすべての制御プレーン マシンを取得します。

    kubectl get machine -n ns01 -l cluster.x-k8s.io/control-plane=

    結果の例(わかりやすい形式に変更しています):

    NAME | CLUSTER| NODENAME | PROVIDERID | PHASE | AGE | VERSION

    tkc-minimal-xz9vm-6bnqf | tkc-minimal | tkc-minimal-xz9vm-6bnqf | vsphere://422cc83a-81d9-55c7-402b-3d3510c52967 | Running | 75m | v1.22.6+vmware.1

    次に、machine.spec.nodeDrainTimeout を編集して nodeDrainTimeout 値を追加します。また、Kubernetes 制御プレーンの spec セクションを編集して、ノードのドレイン タイムアウト値を kcp.spec.machineTemplate.nodeDrainTimeout に追加します。

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

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

    回避策:なし

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

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

    回避策:なし

  • Tanzu Kubernetes Grid クラスタ v1.21.6 が FALSE 状態になり、一部のマシンが移行されないことがある

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

    回避策:なし

  • antrea-resource-init ポッドが保留状態でハングする。

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

    回避策:スーパーバイザーでポッドを再起動します。

  • プロキシ サーバを使用して構成された既存の Tanzu Kubernetes Grid クラスタを vSphere 8 スーパーバイザーにアップグレードできない

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

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

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

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