VMware Tanzu Kubernetes Grid v2.2 リリース ノート
特に記載がある場合を除き、これらのリリース ノートは、Tanzu Kubernetes Grid (TKG) のすべての v2.2.x パッチ バージョンに適用されます。
TKG v2.2 は、バージョン管理された TKG スタンドアローン管理クラスタを展開するダウンロード可能な Tanzu CLI パッケージとして配布されます。TKG v2.2 は、vSphere 6.7、7、8、AWS、Azure など、複数のインフラストラクチャで実行できるスタンドアローン管理クラスタを使用したワークロード クラスタの作成と管理をサポートします。
Tanzu Kubernetes Grid v2.0、v2.2、および vSphere 8 の vSphere with Tanzu スーパーバイザー
重要vSphere 8.0.1c 以降の vSphere with Tanzu スーパーバイザーは TKG v2.2 を実行します。vSphere 8 の以前のバージョンでは TKG v2.0 が実行されますが、これはスーパーバイザーからは独立してリリースされていませんでした。TKG 2.x を実行するスタンドアローン管理クラスタは、TKG 2.1 以降で使用できます。以降の TKG リリースは、今後の vSphere アップデート リリースでスーパーバイザーに組み込まれる予定です。その結果、特定の時点で最新の vSphere with Tanzu バージョンに組み込まれた TKG のバージョンは、使用している TKG のスタンドアローン バージョンと同じではない可能性があります。ただし、すべての TKG v2.x リリースと互換性のある Tanzu CLI のバージョンは、vSphere 8 のすべてのリリースのスーパーバイザーでの使用が完全にサポートされています。
Tanzu Kubernetes Grid v2.2 および vSphere 7 の vSphere with Tanzu
注意TKG 2.x および vSphere 8 の vSphere with Tanzu スーパーバイザーと互換性のある Tanzu CLI のバージョンは、vSphere 7 のスーパーバイザー クラスタと互換性がありません。vSphere 7 の vSphere with Tanzu スーパーバイザー クラスタで Tanzu CLI を使用するには、TKG v1.6 の Tanzu CLI バージョンを使用します。スーパーバイザーで TKG 2.x と互換性のある Tanzu CLI のバージョンを使用するには、vSphere 8 にアップグレードします。vSphere with Tanzu スーパーバイザー クラスタが存在しない場合は、スタンドアローン TKG 2.x 管理クラスタを vSphere 7 に展開できます。Tanzu CLI と VMware 製品の互換性の詳細については、Tanzu CLI のドキュメントを参照してください。
新機能
Tanzu Kubernetes Grid v2.2.x には、次の新機能が含まれています。
- Kubernetes v1.25.7、1.24.11、および 1.23.17 のサポート。以下の「Tanzu Kubernetes Grid v2.2 でサポートされている Kubernetes バージョン」を参照してください。
- スタンドアローン管理クラスタとクラスベースのワークロード クラスタの場合、クラスタ構成ファイルの
ADDITIONAL_IMAGE_REGISTRY*変数またはClusterオブジェクト仕様のadditionalImageRegistries設定を使用して、複数のプライベート イメージ レジストリの信頼を構成できます。「クラスベースのクラスタの信頼できるレジストリ」を参照してください。 - Harbor v2.7.1 から
jobservice.scandataExportsパーシステント ボリュームの要求を削除します。以前に Harbor スキャンデータ ボリュームの EmptyDir オーバーレイを Harbor パッケージに適用した場合は、Harbor パッケージを v2.7.1 に更新する前に「実行中の Harbor 展開の更新」を参照してください。 - TKG 2.2.0 以降、VMware は、Harbor、Contour、Velero などの VMware がサポートするパッケージが Tanzu Kubernetes Grid に展開されるときに、ランタイム レベルのサポートを提供します。
- vSphere CSI パッケージは、
vsphereCSI.netpermissions構成をサポートします。
サポートされている Kubernetes および TKG バージョン
TKG v2.2 では、TKG の Kubernetes バージョンをパッケージ化した TKG および TKr の古いパッチ バージョンに対する VMware のサポート ポリシーが変更されました。TKG v2.1 以前のマイナー バージョンの TKG のサポート ポリシーには変更はありません。
以下のセクションでは、現在サポートされているすべてのバージョンの TKG および TKrs のサポートを、それぞれに適用されるサポート ポリシーに基づいてまとめています。
サポート対象の Kubernetes バージョン
Tanzu Kubernetes Grid の各バージョンでは、管理クラスタの Kubernetes バージョンと、Tanzu Kubernetes リリース (TKr) として配布される追加の Kubernetes バージョンのサポートが追加されています（ただし、既知の問題に記載されているものは除く）。
マイナー バージョン: VMware は、リリース時および TKG v2.1 もサポートされている限り、Kubernetes v1.25、v1.24、および v1.23 を使用する TKG v2.2 をサポートします。TKG v2.1 がジェネラル サポート終了のマイルストーンに達すると、VMware は TKG で Kubernetes v1.23 および v1.24 をサポートしなくなります。
パッチ バージョン: VMware は、マイナー バージョンの新しい TKr パッチを公開した後も、古いパッチ バージョンのサポートを 2 か月間保持します。これにより、ユーザーは 2 か月以内に新しい TKr パッチ バージョンにアップグレードすることになります。TKG v2.2 の時点で、VMware は、Kubernetes の以前のマイナー バージョンの TKr パッチをすべてサポートしているわけではありません。
サポートされている TKG および TKr のバージョン
現在サポートされている TKG パッチ バージョンがサポートする TKr パッチ バージョンは以下のとおりです。
| Tanzu Kubernetes Grid バージョン | 管理クラスタの Kubernetes バージョン | 指定された Kubernetes (TKr) バージョン |
|---|---|---|
| 2.2.0 | 1.25.7 | 1.25.7、1.24.11、1.23.17 |
| 2.1.1 | 1.24.10 | 1.24.10、1.23.16、1.22.17 |
| 2.1.0 | 1.24.9 | 1.24.9、1.23.15、1.22.17 |
| 1.6.1 | 1.23.10 | 1.23.10、1.22.13、1.21.14 |
| 1.6.0 | 1.23.8 | 1.23.8、1.22.11、1.21.14 |
TKG v2.2.0 でサポートされる TKr バージョン
TKG v2.2.0 は、以下のリリース日に基づいて、この表に記載されている TKr パッチ バージョンをサポートします。
- v2.2.0：2023 年 5 月 18 日
- v2.1.1：2023 年 3 月 21 日
| Kubernetes マイナー | Kubernetes パッチ | TKG でリリース | サポート終了日 （最新でない場合） |
|---|---|---|---|
| v1.25 | v1.25.7 | v2.2.0 | サポート対象の最新バージョン |
| v1.24 | v1.24.11 | v2.2.0 | サポート対象の最新バージョン |
| v1.24.10 | v2.1.1 | 2023 年 7 月 11 日 | |
| v1.24.9 | v2.1.0 | 2023 年 5 月 21 日 | |
| v1.23 | v1.23.17 | v2.2.0 | サポート対象の最新バージョン |
| v1.23.16 | v2.1.1 | 2023 年 7 月 11 日 | |
| v1.23.15 | v2.1.0 | 2023 年 5 月 21 日 |
サポートされている Tanzu Kubernetes Grid バージョン
VMware は、次のように TKG バージョンをサポートします。
マイナー バージョン: VMware は、TKG の最新バージョンと 2 つ前のマイナー バージョンまでに適用される N-2 ライフサイクル ポリシーに従って TKG をサポートします。TKG v2.2.0 のリリースでは、TKG v1.5 はサポートされなくなりました。詳細については、『VMware Product Lifecycle Matrix』を参照してください。
パッチ バージョン: VMware は、以前のすべての TKG パッチ バージョンをサポートしているわけではありません。VMware が TKG の新しいパッチ バージョンをリリースした後も、古いパッチ バージョンのサポートは 2 か月間保持されます。これにより、ユーザーは 2 か月以内に新しい TKG パッチ バージョンにアップグレードすることになります。
- たとえば、TKG v2.2.0 のサポートは、TKG v2.2.1 の一般提供から 2 か月後に終了します。
Tanzu Standard リポジトリ パッケージのサポートの明確化
VMware は、VMware Tanzu Standard リポジトリで提供されるオプションのパッケージに対して次のことをサポートします。
- オプションの VMware Tanzu Standard リポジトリに含まれているパッケージが Tanzu Kubernetes Grid に展開されるときに、VMware がパッケージのインストールとアップグレードの検証を行います。この検証は、パッケージのインストールとアップグレードに限定されますが、CVE に対処するために利用可能な更新が含まれます。バグ修正、機能強化、およびセキュリティ修正は、アップストリーム パッケージ プロジェクトで使用可能になった時点で新しいパッケージ バージョンで提供されます。
- VMware は、Tanzu Standard リポジトリによって提供されるコンポーネントに対して、ランタイム レベルのサポートを提供しません。構成やパフォーマンスに関する問題のデバッグ、またはパッケージ自体のデバッグや修正は、VMware が提供するものではありません。
Tanzu Standard パッケージに対する VMware サポートの詳細については、上記の「新機能」および以下の「将来の動作変更についての通知」を参照してください。
Tanzu Kubernetes Grid v2.2 の製品スナップショット
Tanzu Kubernetes Grid v2.2 は、次のインフラストラクチャ プラットフォームとオペレーティング システム (OS)、およびクラスタの作成と管理、ネットワーク、ストレージ、認証、バックアップと移行、および可観測性のコンポーネントをサポートします。括弧内にリストされているコンポーネントのバージョンは、Tanzu Kubernetes Grid v2.2.0 に含まれています。詳細については、「コンポーネントのバージョン」を参照してください。
| vSphere | AWS | Azure | |
| インフラストラクチャ プラットフォーム |
|
ネイティブ AWS | ネイティブ Azure |
| CLI、API、およびパッケージ インフラストラクチャ | Tanzu Framework v0.29.0 | ||
| クラスタの作成と管理 | コア クラスタ API (v1.2.8)、クラスタ API プロバイダ vSphere (v1.5.3) | コア クラスタ API (v1.2.8)、クラスタ API プロバイダ AWS (v2.0.2) | コア クラスタ API (v1.2.8)、クラスタ API プロバイダ Azure (v1.6.3) |
| TKG で配布された Kubernetes ノード OS | Photon OS 3、Ubuntu 20.04 | Amazon Linux 2、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
| 独自のイメージのビルド | Photon OS 3、Red Hat Enterprise Linux 7*** および 8、Ubuntu 18.04、Ubuntu 20.04、Windows 2019 | Amazon Linux 2、Ubuntu 18.04、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
| コンテナ ランタイム | Containerd (v1.6.18) | ||
| コンテナ ネットワーク | Antrea (v1.9.0)、Calico (v3.24.1) | ||
| コンテナ レジストリ | Harbor (v2.7.1) | ||
| Ingress | NSX Advanced Load Balancer Essentials および Avi Controller **** (v21.1.5 ～ v21.1.6、v22.1.2、v22.1.3)、Contour (v1.23.5) | Contour (v1.23.5) | Contour (v1.23.5) |
| ストレージ | vSphere コンテナ ストレージ インターフェイス (v2.7.1*) および vSphere クラウド ネイティブ ストレージ | Amazon EBS CSI ドライバ (v1.16.0) およびツリー内クラウド プロバイダ | Azure Disk CSI ドライバ (v1.27.0)、Azure File CSI ドライバ (v1.26.1)、およびツリー内クラウド プロバイダ |
| 認証 | Pinniped 経由の OIDC (v0.12.1)、Pinniped 経由の LDAP (v0.12.1)、および Dex | ||
| 可観測性 | Fluent Bit (v1.9.5)、Prometheus (v2.37.0)*****、Grafana (v7.5.17) | ||
| バックアップと移行 | Velero (v1.9.7) | ||
* vsphere_csi_driver のバージョン。Tanzu Kubernetes Grid v2.2 リリースに含まれる vSphere コンテナ ストレージ インターフェイス コンポーネントの完全なリストについては、「コンポーネントのバージョン」を参照してください。
** このリリースと互換性のある VMware Cloud on AWS SDDC バージョンのリストについては、「VMware 製品の相互運用性マトリックス」を参照してください。
*** Tanzu Kubernetes Grid v1.6 は、Red Hat Enterprise Linux 7 イメージのビルドをサポートする最後のリリースです。
**** vSphere 8 で、TKG スタンドアローン管理クラスタとそのワークロード クラスタを使用して NSX Advanced Load Balancer を使用するには、NSX ALB v22.1.2 以降と TKG v2.1.1 以降が必要です。
***** クラスタを Kubernetes v1.25 にアップグレードする場合は、Prometheus をバージョン 2.37.0+vmware.3-tkg.1 にアップグレードする必要があります。Prometheus パッケージの以前のバージョン（バージョン 2.37.0+vmware.1-tkg.1 など）は、Kubernetes 1.25 と互換性がありません。
Tanzu Kubernetes Grid v2.2 に付属する Kubernetes バージョンの完全なリストについては、上記の「Tanzu Kubernetes Grid v2.2 でサポートされる Kubernetes バージョン」を参照してください。
コンポーネントのバージョン
Tanzu Kubernetes Grid v2.2.x リリースには、次のソフトウェア コンポーネント バージョンが含まれています。
| コンポーネント | TKG v2.2 |
|---|---|
| aad-pod-identity | v1.8.15+vmware.1* |
| addons-manager | v2.2+vmware.1* |
| ako-operator | v1.8.0_vmware.1* |
| alertmanager | v0.25.0_vmware.1* |
| antrea | v1.9.0_vmware.2-tkg.1-advanced* |
| aws-ebs-csi-driver | v1.16.0_vmware.1-tkg.1* |
| azuredisk-csi-driver | v1.27.0_vmware.2-tkg.1* |
| azurefile-csi-driver | v1.26.1_vmware.2-tkg.1* |
| calico | v3.24.1_vmware.1-tkg.2* |
| capabilities-package | v0.29.0-dev-capabilities* |
| carvel-secretgen-controller | v0.11.2+vmware.1 |
| cloud-provider-azure | v1.1.26+vmware.1、 v1.23.23+vmware.1、 v1.24.10+vmware.1 |
| cloud_provider_vsphere | v1.25.1+vmware.2* |
| cluster-api-provider-azure | v1.6.3_vmware.2* |
| cluster_api | v1.2.8+vmware.2* |
| cluster_api_aws | v2.0.2+vmware.2* |
| cluster_api_vsphere | v1.5.3+vmware.2* |
| cni_plugins | v1.1.1+vmware.20* |
| configmap-reload | v0.7.1+vmware.2 |
| containerd | v1.6.18+vmware.1* |
| contour | v1.23.5+vmware.1-tkg.1* |
| coredns | v1.9.3_vmware.8* |
| crash-diagnostics | v0.3.7+vmware.6 |
| cri_tools | v1.24.2+vmware.8* |
| csi_attacher | v3.5.0+vmware.1、 v3.4.0+vmware.1、 v3.3.0+vmware.1 |
| csi_livenessprobe | v2.7.0+vmware.1、 v2.6.0+vmware.1、 v2.5.0+vmware.1、 v2.4.0+vmware.1 |
| csi_node_driver_registrar | v2.5.1+vmware.1、 v2.5.0+vmware.1、 v2.3.0+vmware.1 |
| csi_provisioner | v3.2.1+vmware.1、 v3.1.0+vmware.2、 v3.0.0+vmware.1 |
| dex | v2.35.3_vmware.3* |
| envoy | v1.24.5_vmware.1* |
| external-dns | v0.12.2+vmware.5* |
| external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.9* |
| fluent-bit | v1.9.5+vmware.1 |
| gangway | v3.2.0+vmware.2 |
| grafana | v7.5.17+vmware.2 |
| guest-cluster-auth-service | v1.3.0* |
| harbor | v2.7.1+vmware.1* |
| image-builder | v0.1.13+vmware.3* |
| image-builder-resource-bundle | v1.25.7+vmware.2-tkg.1* |
| imgpkg | v0.31.1+vmware.1 |
| jetstack_cert-manager | v1.10.2+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.5*、 v1.12.1+vmware.6* |
| k14s_kapp | v0.53.2+vmware.1 |
| k14s_ytt | v0.43.1+vmware.1 |
| kapp-controller | v0.41.7_vmware.1-tkg.1* |
| kbld | v0.35.1+vmware.1 |
| kube-state-metrics | v2.7.0+vmware.2* |
| kube-vip | v0.5.7+vmware.2* |
| kube-vip-cloud-provider* | v0.0.4+vmware.4* |
| kube_rbac_proxy | v0.11.0+vmware.2 |
| kubernetes | v1.25.7+vmware.2* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
| kubernetes-sigs_kind | v1.25.7+vmware.2-tkg.2_v0.17.0* |
| kubernetes_autoscaler | v1.25.0+vmware.1* |
| load-balancer-and-ingress-service (AKO) | v1.9.3_vmware.1-tkg.1* |
| metrics-server | v0.6.2+vmware.1 |
| multus-cni | v3.8.0+vmware.3* |
| pinniped | v0.12.1_vmware.3-tkg.4* |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 |
| prometheus | v2.37.0+vmware.3* |
| prometheus_node_exporter | v1.4.0+vmware.3* |
| pushgateway | v1.4.3+vmware.3* |
| sonobuoy | v0.56.16+vmware.1* |
| standalone-plugins-package | v0.29.0-dev-standalone-plugins* |
| tanzu-framework | v0.29.0* |
| tanzu-framework-addons | v0.29.0* |
| tanzu-framework-management-packages | v0.29.0-tf* |
| tkg-bom | v2.2.0* |
| tkg-core-packages | v1.25.7+vmware.2-tkg.1* |
| tkg-standard-packages | v2.2.0* |
| tkg-storageclass-package | v0.29.0-tkg-storageclass* |
| tkg_telemetry | v2.2.0+vmware.1* |
| velero | v1.9.7+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.5+vmware.1* |
| velero-plugin-for-csi | v0.3.5+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.5+vmware.1* |
| velero-plugin-for-vsphere | v1.4.3+vmware.1* |
| vendir | v0.30.1+vmware.1 |
| vsphere_csi_driver | v2.7.1+vmware.2* |
| whereabouts | v0.5.4+vmware.2* |
* 以前のリリース以降の新しいコンポーネントまたはバージョンアップを示します。TKG v2.1.1 は v2.2.0 より前です。
TKG v2.2 に同梱されているソフトウェア コンポーネント バージョンの完全なリストについては、imgpkg を使用してリポジトリ バンドルをプルし、その内容を一覧表示します。TKG v2.2.0 の場合、次に例を示します。
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree
次のようなローカル BOM ファイルには、パッケージのバージョンも表示されますが、最新ではない可能性があります。
~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml
サポートされるアップグレード パス
TKG アップグレード パスでは、v2.2 が v2.1.1 のすぐ後に続きます。
Tanzu Kubernetes Grid v2.2.x には v2.1.x からのみアップグレードできます。v2.1.x より前のバージョンから Tanzu Kubernetes Grid v2.2.x にアップグレードする場合は、まず v2.1.x にアップグレードする必要があります。
ワークロード クラスタの Kubernetes バージョンをアップグレードするときに、マイナー バージョンをスキップすることはできません。たとえば、Tanzu Kubernetes クラスタを v1.23.x から v1.25.x に直接アップグレードすることはできません。クラスタを v1.25.x にアップグレードする前に、v1.23.x クラスタを v1.24.x にアップグレードする必要があります。
リリース日
Tanzu Kubernetes Grid v2.2 のリリース日は次のとおりです。
- v2.2.0：2023 年 5 月 9 日
Tanzu Kubernetes Grid v2.2 での動作の変更
Tanzu Kubernetes Grid v2.2 では、以前の最新リリースである v2.1.1 と比較して、新しい動作は導入されていません。
将来の動作変更についての通知
このセクションでは、TKG v2.2 リリース以降の将来のリリースで有効になる動作の変更について、事前に通知します。
VMware Tanzu Standard リポジトリ
重要Tanzu Kubernetes Grid v2.2.x は、VMware Tanzu Standard リポジトリがリリースの一部としてパッケージ化される TKG の最後のマイナー リリースです。TKG v2.2.x およびそれ以前のリリースには、Tanzu Standard リポジトリに一連のオプション パッケージが含まれています。このパッケージをクラスタに展開して、ログ転送、入力方向制御、コンテナ レジストリなどの機能を追加できます。今後の TKG v2.x マイナー リリースでは、Tanzu CLI をインストールして管理クラスタを展開するときに、Tanzu Standard リポジトリは自動的にダウンロードされません。このオプションのパッケージ セットを使用するには、Tanzu CLI を使用して手動でダウンロードして追加します。オプションのパッケージを TKG リリースから分離すると、VMware は TKG リリースの外部でパッケージの増分更新を提供し、CVE に対する応答性を高めることができます。
非推奨に関する通知
- TKG の今後のリリースでは、Pinniped が LDAP プロバイダと連携する必要がなくなっているため、Dex コンポーネントは削除されます。この変更により、LDAP 認証の次のクラスタ構成変数が必要になります。
LDAP_BIND_DNおよびLDAP_BIND_PASSWORD。詳細については、『構成ファイル変数リファレンス』の「ID プロバイダ - LDAP」を参照してください。
ユーザー ドキュメント
『TKG 2.2 スタンドアローン管理クラスタの展開と管理』には、スタンドアローン管理クラスタに固有のトピックが含まれています。これは TKG を vSphere with Tanzu スーパーバイザーとともに使用することには関連しません。
詳細については、「VMware Tanzu Kubernetes Grid のドキュメント」ページの「お客様の展開に適した TKG ドキュメントを見つける」を参照してください。
解決した問題
以前の Tanzu Kubernetes Grid リリースの「既知の問題」として記載された次の問題は、Tanzu Kubernetes Grid v2.2.0 で解決されています。
-
レガシー構成ファイルから
ClusterClass構成ファイルを作成すると、--dry-runに空の Antrea 構成が含まれるANTREA_NODEPORTLOCALエントリが含まれているレガシー構成ファイルから、tanzu cluster create --dry-run -fを使用してClusterClass構成ファイルを作成すると、ラベルを含まない Antrea 構成が自動生成され、Antrea の調整が正常に行われません。 -
パッケージがデフォルトのベースライン PSA プロファイルに準拠していない
TKG の PSA コントローラで、サポートされていない「テクニカル プレビュー」状態の場合、一部の TKG パッケージがデフォルトの
baselineプロファイルに準拠していません。 -
tanzu cluster createの実行中に検証エラーが発生するデフォルトでは、フラットなキー/値の構成ファイルを
tanzu cluster createの--fileオプションに渡すと、構成ファイルが Kubernetes スタイルのオブジェクト仕様ファイルに変換されてから終了します。この動作は、デフォルトでfalseに設定されているauto-apply-generated-clusterclass-based-configuration機能によって制御されます。場合によっては、--fileオプションによって生成された Kubernetes スタイルのオブジェクト仕様ファイルをtanzu cluster createに渡すと、次のようなエラーでコマンドが失敗します。Error: workload cluster configuration validation failed...このエラーは、
--dry-runオプションによって生成された Kubernetes スタイルのオブジェクト仕様ファイルをtanzu cluster createに渡すときにも発生することがあります。 -
tanzu cluster createで、デフォルト以外の Kubernetes バージョンで生成されたクラスタ仕様が正しく検証されない「クラスベースのクラスタを作成する」で説明されている 2 段階のプロセスのいずれかを使用して構成ファイルからクラスベースのワークロード クラスタを作成し、最初の手順で
--tkr値を指定してクラスタの基準をデフォルト以外のバージョンの Kubernetes にすると、2 番目の手順が検証エラーで失敗することがあります。
既知の問題
Tanzu Kubernetes Grid v2.2.x の既知の問題は次のとおりです。v2.2.0 の既知の問題で、それ以降の v2.2.x パッチ リリースで解決されたものは、修正されたパッチ リリースの「解決した問題」に記載されています。
頻繁に発生する問題の解決策については、「管理クラスタの問題のトラブルシューティング」、「ワークロード クラスタの問題のトラブルシューティング」、または「VMware ナレッジベースの記事」を参照してください。
パッケージ
-
NSX ALB v21.1.4 以前を使用する vSphere 6.7 で Grafana のインストールに失敗する
ロード バランサ サービスとして NSX ALB v21.1.4 以前を使用する vSphere v6.7U3 上の TKG v2.2 ワークロード クラスタに Grafana v7.5.17 パッケージをインストールすることはできません。
回避策：ワークロード クラスタで Grafana と NSX ALB を使用している場合は、TKG を v2.2 にアップグレードする前に、vSphere を v7.0 以降にアップグレードし、NSX ALB を v21.1.5 以降にアップグレードします。
-
実行 ID が 1000000 を超えると、Harbor CVE のエクスポートに失敗することがある
TKG v2.2 用にパッケージ化されたバージョンである Harbor v2.7.1 には、実行プライマリ キーの自動増分 ID が 1000000 を超えると、CVE レポートのエクスポートが「404 page not found」というエラーになるという既知の問題があります。
この Harbor の問題は、新しいバージョンの TKG に組み込まれる予定の新しいバージョンの Harbor で解決されています。
-
Harbor の Notary コンポーネントにおける Golang の脆弱性
Notary では、CVE-2021-33194 が存在します。Notary コンポーネントは Harbor v2.6 以降では廃止され、Harbor v2.6.0 リリース ノートに記載されているように、今後のリリースでは削除される予定です。VMware は、コンテナの署名と検証に Notary ではなく Sigstore Cosign を使用することをお勧めしています。
-
tanzu package repository addを実行して、tanzu-standardリポジトリを、「vSphere 上の単一ノード クラスタ（テクニカル プレビュー）」で説明されているタイプの単一ノード クラスタに追加すると、失敗する場合があります。これは、単一ノード クラスタがコア アドオンとして
cert-managerを使用して起動するためです。これは、tanzu-standardリポジトリ内の別のcert-managerパッケージと競合します。回避策：
tanzu-standardリポジトリを追加する前に、「cert-manager のインストール」の説明に従って、cert-managerパッケージの注釈にパッチを適用してください。
クラスタ操作
-
Antrea CNI を使用して、最新でない TKr バージョンに基づいた新しいワークロード クラスタの作成を実行できない
Antrea CNI を使用する新しいワークロード クラスタを作成して、「Tanzu Kubernetes Grid v2.2 でサポートされる Kubernetes バージョン」に記載されている以前のバージョンの TKG に付属する Kubernetes バージョン（TKG v1.6.1 のデフォルトの Kubernetes バージョンであった Kubernetes v1.23.10 など）を実行することはできません。
回避策：Kubernetes 1.25.7、1.24.11、または 1.23.17 を実行するワークロード クラスタを作成します。Kubernetes プロジェクトは、現在のマイナー バージョンの最新のパッチ バージョンでコンポーネントを実行することを推奨します。
-
クラスタ API のラベル伝達の問題により、クラスベースのワークロード クラスタのクラスタ構成ファイルの
AUTOSCALER_MIN_SIZE_*およびAUTOSCALER_MAX_SIZE_*設定がクラスタのMachineDeploymentオブジェクトに設定されません。回避策：クラスタ オートスケーラが有効になっているクラスベースのワークロード クラスタを作成した後、「最小および最大サイズの注釈を手動で追加する」の説明に従って、各 AZ の最小および最大マシン数の設定を手動で追加します。
-
ノード プール
labelsおよびその他の構成プロパティを変更できない「構成プロパティ」に記載されている既存のノード プールの
labels、az、nodeMachineTypeまたは vSphere プロパティは、追加したり変更したりすることはできません。回避策：目的のプロパティを使用してクラスタに新しいノード プールを作成し、ワークロードを新しいノード プールに移行して、元のノード プールを削除します。
-
管理クラスタの制御プレーン ノードを偶数にスケーリングできない
管理クラスタで
tanzu cluster scaleを実行し、--controlplane-machine-countオプションに偶数を渡すと、TKG は制御プレーン ノードをスケーリングせず、CLI はエラーを出力しません。クォーラムを維持するには、制御プレーン ノードの数を常に奇数にする必要があります。回避策：制御プレーン ノードの数を偶数にスケーリングしないでください。
-
クラスベースのクラスタ名には、NSX ALB をロード バランサ サービスまたは入力方向コントローラとした、25 文字の制限がある
NSX Advanced Load Balancer (ALB) が、スタンドアローン管理クラスタで、クラスベースのクラスタのロード バランサ サービスまたは入力方向コントローラとして使用されている場合、そのアプリケーション名には、クラスタ名と、AKO パッケージの内部名である
load-balancer-and-ingress-serviceの両方が含まれます。組み合わせた名前が Avi Controller アプリケーションの 64 文字の制限を超えると、tanzu cluster createコマンドが、avi-system名前空間が見つからなかったことを示すエラーで失敗することがあります。回避策：NSX ALB をロード バランサまたは入力方向コントローラとして使用する場合は、クラスベースのクラスタ名の長さを 25 文字以下に制限します。
ネットワーク
注v4.0 以降では、VMware NSX-T Data Center の名前が「VMware NSX」に変更されました。
-
vSphere 8 で IPv6 ネットワークがサポートされない
TKG v2.2 は vSphere 8 で IPv6 ネットワークをサポートしませんが、「IPv6 ネットワーク」で説明するように、vSphere 7 の Kube-Vip を使用した単一スタック IPv6 ネットワークをサポートします。
回避策：vSphere の IPv6 環境で TKG が必要な場合、または現在使用している場合は、vSphere 8 をインストールしたり、vSphere 8 にアップグレードしたりしないでください。
-
管理クラスタで NSX ALB
NodePortLocal入力方向モードがサポートされないTKG v2.2 では、管理クラスタへのトラフィックに対して NSX Advanced Load Balancer (ALB) を入力方向モード
NodePortLocalのサービス タイプとして実行することはできません。この問題は、「NodePortLocal モードでの L7 入力方向」で説明されているように、ワークロード クラスタへの
NodePortLocal入力方向のサポートには影響しません。回避策：
AVI_INGRESS_SERVICE_TYPEをNodePortまたはClusterIPに設定して管理クラスタを構成します。デフォルトはNodePortです。 -
古いバージョンの NSX-T と Linux カーネル 5.8 を使用する Photon 3 または Ubuntu 仮想マシンで、管理クラスタの作成が失敗するか、パフォーマンスが低下する
次のインフラストラクチャと構成を使用して管理クラスタを展開すると、失敗したり、ポッド間のトラフィックが制限されたりすることがあります。
- 次のいずれかのバージョンの NSX-T を使用した vSphere：
- 拡張データパスが有効な NSX-T v3.1.3
- v3.1.3 以前の NSX-T v3.1.x
- v3.0.2 ホット パッチ以前の NSX-T v3.0.x
- NSX-T v2.x。これには、NSX-T v2.5 を使用する Azure VMware Solution (AVS) v2.0 が含まれます。
- 基本イメージ：Linux カーネル 5.8 を使用する Photon 3 または Ubuntu
この組み合わせにより、古いバージョンの NSX-T と Antrea CNI の間でチェックサムの問題が発生します。
TMC：管理クラスタが Tanzu Mission Control (TMC) に登録されている場合、この問題の回避策はありません。それ以外の場合は、以下の回避策を参照してください。
回避策：
ANTREA_DISABLE_UDP_TUNNEL_OFFLOADを"true"に設定して構成されたワークロード クラスタを展開します。この設定により、Antrea の UDP チェックサム オフロードが無効化され、一部のアンダーレイ ネットワークおよび物理 NIC ネットワーク ドライバに関する既知の問題が回避されます。- 拡張データパスを有効にせずに、NSX-T v3.0.2 ホット パッチ、v3.1.3、またはそれ以降にアップグレードします。
- Linux カーネル 5.9 以降を使用する Ubuntu 基本イメージを使用します。
- 次のいずれかのバージョンの NSX-T を使用した vSphere：
ID およびアクセス管理
-
スタンドアローン管理クラスタを再作成しても Pinniped 認証がリストアされない
「管理およびワークロード クラスタ インフラストラクチャのバックアップおよびリストア（テクニカル プレビュー）」の説明に従ってスタンドアローン管理クラスタを再作成すると、ユーザーは Pinniped 認証を介してワークロード クラスタにログインできなくなります。
回避策：管理クラスタを再作成した後、「既存の環境での ID 管理の有効化と構成」の説明に従って ID 管理を再構成します。
-
Pinniped コンポーネントにおける Golang の脆弱性
CVE-2022-41723 は Pinniped v0.12.1 に存在します。この脆弱性を悪用すると、Pinniped サービスの DDoS 攻撃が発生する可能性があります。悪用の可能性を低くするために、入力方向フィルタリングを使用して、企業の VPN CIDR などの既知の IP アドレスからのトラフィックのみを許可できます。この脆弱性は、Tanzu Kubernetes Grid の今後のリリースで解決される予定です。
-
スーパーバイザーが展開されたワークロード クラスタに kubeconfig を生成して使用すると、「不明なフラグ」エラーが発生する
Tanzu CLI v0.25.0 以前では、
clusterプラグインは、引数--concierge-is-cluster-scopedを含む可能性があるkubeconfigファイルを生成します。Tanzu CLI v0.29.0pinniped-authプラグインはこの引数を認識しません。この一時的な回帰は、以降のバージョンで修正されました。vSphere 8.0 には v0.25.0
clusterプラグインが組み込まれているため、CLI v0.29.0（TKG v2.2 のバージョン）からスーパーバイザーにより展開されたクラスタに接続すると、次のエラーが生成されることがあります。Error: unknown flag: --concierge-is-cluster-scoped Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1回避策：
kubeconfigファイルで、argsの下にある、--concierge-is-cluster-scopedを設定する行を削除します。
ストレージ
-
ワークロード クラスタが複数のデータストアにストレージを分散できない
「データストア クラスタを使用するクラスタの展開」で説明するように、ワークロード クラスタを有効にして複数のデータストアにストレージを分散することはできません。1 つのデータストア クラスタ内の複数のデータストアにタグを付ける場合、ワークロード クラスタのストレージ ポリシーの基準として、ワークロード クラスタはデータストアの 1 つのみを使用します。
回避策：なし
Tanzu CLI
-
HTTP/HTTPS プロキシ パスワードで英数字以外の文字を使用できない
CLI を使用して管理クラスタを展開する場合、英数字以外の文字 (
# ` ^ | / ? % ^ { [ ] } \ " < >) をパスワードに使用することはできません。また、ユーザー インターフェイスを使用して管理クラスタを展開する場合、HTTP/HTTPS プロキシ パスワードに英数字以外の文字を使用することはできません。回避策：CLI を使用して管理クラスタを展開する場合、
# ` ^ | / ? % ^ { [ ] } \ " < >を除く英数字以外の文字をパスワードに使用できます。 -
ARM プロセッサを搭載した macOS マシンで Tanzu CLI が機能しない
Tanzu CLI v0.11.6 は、ARM (Apple M1) チップを搭載した macOS マシン（[Finder] > [この Mac について (About This Mac)] > [概要 (Overview)] で特定）では動作しません。
回避策：Linux または Windows OS のブートストラップ マシン、または Intel プロセッサを搭載した macOS マシンを使用します。
-
Tanzu CLI が tanzu management-cluster osimage を一覧表示する
management-clusterコマンド グループは、tanzu management-cluster osimageを一覧表示します。この機能は現在開発中で、今後の使用のために予約されています。回避策：
tanzu management-cluster osimageは使用しないでください。 -
tanzu package available getの--default-values-file-outputオプションによって、Harbor パッケージ用の不完全な構成テンプレート ファイルが出力されるtanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATHを実行すると、Harbor パッケージ用の不完全な構成テンプレート ファイルが作成されます。完全なファイルを取得するには、「サービス レジストリ用の Harbor のインストール」の説明に従ってimgpkg pullコマンドを使用します。
vSphere
-
smallノードで作成されたノード プールがProvisioningで停止することがあるsmallとして構成されたノードSIZEで作成されたノード プールは、Provisioning状態でスタックし、Runningに進まない場合があります。回避策：ノード プールに少なくとも
mediumサイズのノードを構成します。
AWS
-
CAPA リソース タギングの問題により、AWS 管理クラスタの展開およびアップグレード中に調整エラーが発生する。
アップストリーム クラスタ API プロバイダ AWS (CAPA) のリソース タギングの問題により、オフライン展開では
ResourceTaggingAPI にアクセスできないため、管理クラスタの作成またはアップグレード中に調整エラーが発生します。回避策：オフラインの AWS 環境では、ローカル環境または管理クラスタ構成ファイルで
EXP_EXTERNAL_RESOURCE_GC=falseを設定してから、tanzu mc createまたはtanzu mc upgradeを実行します。 -
AWS のワークロード クラスタ ノード プールは、スタンドアローン管理クラスタと同じアベイラビリティ ゾーンにある必要があります。
管理クラスタが配置されている場所とは異なる
azで構成されたノード プールを作成すると、tanzu cluster node-pool listによって一覧表示されるように、新しいノード プールがステータスScalingUpで停止したままになり、Ready状態に到達しない場合があります。回避策：ノード プールをスタンドアローン管理クラスタと同じ AZ 内にのみ作成します。
-
クラスタが Tanzu Kubernetes Grid で展開されていないネットワーク リソースを使用している場合、AWS でのクラスタの削除に失敗する。
tanzu cluster deleteおよびtanzu management-cluster deleteコマンドが、Tanzu Kubernetes Grid 展開プロセスとは別に AWS Cloud Controller Manager によって作成されたネットワーク リソースを使用するクラスタでハングすることがあります。このようなリソースには、Kubernetes AWS クラウド プロバイダのドキュメントの「サービス コントローラ」に記載されているロード バランサやその他のネットワーク サービスが含まれる場合があります。詳細については、クラスタ API の問題（Drain workload clusters of service Type=Loadbalancer on teardown）を参照してください。
回避策：
kubectl deleteを使用して、クラスタからLoadBalancerタイプのサービスを削除します。それでも失敗した場合は、AWS コンソールを使用して、Cloud Controller Manager によってこのサービス用に作成されたLoadBalancerおよびSecurityGroupオブジェクトを手動で削除します。注意
タグ
key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME、value: ownedを持つ、Tanzu によって管理されるロード バランサまたはセキュリティ グループを削除しないでください。
Azure
-
ストレージ ボリュームがプライベート エンドポイントを持つアカウントを使用すると、クラスタの削除に失敗する
管理されていないリソース グループ内の Azure ワークロード クラスタでは、Azure CSI ドライバがプライベート エンドポイントを持つストレージ アカウントを使用するパーシステント ボリューム (PV) を作成すると、PV の削除時に削除されない
privateEndpointとvNetリソースが作成されます。その結果、クラスタの削除に失敗し、「subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use」のようなエラーが表示されます。回避策：Azure クラスタを削除する前に、ストレージ アカウントのプライベート エンドポイントのネットワーク インターフェイスを手動で削除します。
- ブラウザから、Azure Resource Explorer にログインします。
- 左側の [サブスクリプション (subscriptions)] をクリックし、サブスクリプションを展開します。
- サブスクリプションで、左側の [resourceGroups] を展開し、TKG 環境のリソース グループを展開します。
- リソース グループで、[プロバイダ (providers)] > [Microsoft.Network] > [networkinterfaces] を展開します。
networkinterfacesで、削除に失敗している NIC リソースを選択します。- 上部にある [読み取り/書き込み (Read/Write)] ボタンをクリックし、その下にある [アクション(POST、DELETE) (Actions(POST, DELETE))] タブをクリックします。
- [削除 (Delete)] をクリックします。
- NIC が削除されたら、Azure クラスタを削除します。
Windows
-
インターネットが制限された環境で Windows ワーカーがサポートされない
VMware は、プロキシが設定された環境またはエアギャップされた環境での Windows ワーカー ノードを持つ TKG ワークロード クラスタをサポートしていません。
回避策：VMware の担当者にお問い合わせください。一部の TKG ユーザーは、たとえばこの非公式リポジトリで説明されているように、Windows カスタム イメージをビルドし、オフライン環境で Windows ワーカーを使用してワークロード クラスタを実行しています。
Image-Builder
-
イメージ ビルド プロセス中に無視可能な
gossテスト エラーが発生するKubernetes Image Builder を実行してカスタム Linux カスタム マシン イメージを作成すると、
gossテストのpython-netifaces、python-requests、およびebtablesが失敗します。コマンド出力はエラーを報告します。エラーは無視できます。正常なイメージのビルドを妨げるわけではありません。
AVS
Azure vSphere Solution (AVS) で、vSphere CSI パーシステント ボリューム (PV) の削除に失敗することがあります。PV を削除するには、cns.searchable 権限が必要です。AVS のデフォルトの管理者アカウント [email protected] は、この権限で作成されていません。詳細については、「vSphere ロールと権限」を参照してください。
回避策：AVS 上の vSphere CSI PV を削除するには、Azure サポートにお問い合わせください。
