VMware Tanzu Kubernetes Grid v2.1 リリース ノート
特に記載がある場合を除き、これらのリリース ノートは、Tanzu Kubernetes Grid (TKG) のすべての v2.1.x パッチ バージョンに適用されます。
TKG v2.1 は、バージョン管理された TKG スタンドアローン管理クラスタを展開するダウンロード可能な Tanzu CLI パッケージとして配布されます。TKG v2.1 は、複数のインフラストラクチャ（vSphere、AWS、Azure など）で実行できるスタンドアローン管理クラスタを使用したクラスベースのワークロード クラスタの作成と管理をサポートする TKG の最初のバージョンです。
vSphere 8 の Tanzu Kubernetes Grid v2.x および 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 のすべてのリリースのスーパーバイザーでの使用が完全にサポートされています。
vSphere 7 の Tanzu Kubernetes Grid v2.1 および 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.1.x には、次の新機能が含まれています。
Tanzu Kubernetes Grid v2.1.1
Tanzu Kubernetes Grid v2.1.1 の新機能：
- TKG スタンドアローン管理クラスタとそのワークロード クラスタとともに、NSX Advanced Load Balancer v22.1.2 以降を vSphere 8 で使用することをサポート。
- FIPS バージョンの TKG v2.1.1 をインストールできます。詳細については、「FIPS 対応バージョン」を参照してください。
- 構成変数：
- マシンの健全性チェック：
MHC_MAX_UNHEALTHY_CONTROL_PLANEおよびMHC_MAX_UNHEALTHY_WORKER_NODE。詳細については、『構成ファイル変数リファレンス』の「マシンの健全性チェック」を参照してください。 - カスタム証明書を使用した tdnf サーバをサポート：
CUSTOM_TDNF_REPOSITORY_CERTIFICATE（テクニカル プレビュー）。詳細については、『構成ファイル変数リファレンス』の「ノード構成」を参照してください。 - ノード レベルのプロキシ設定をサポート：
TKG_NODE_SYSTEM_WIDE_PROXY（テクニカル プレビュー）。詳細については、『構成ファイル変数リファレンス』の「プロキシ構成」を参照してください。
- マシンの健全性チェック：
Tanzu Kubernetes Grid v2.1.0
Tanzu Kubernetes Grid v2.1.0 の新機能：
- TKG 2.x のサポート：スタンドアローン管理クラスタを使用する vSphere、AWS、または Azure で、「ワークロード クラスタ タイプ」の説明に従ってクラスベースのクラスタを構成および作成します。
- FIPS バージョン の TKG v2.1.0 をインストールできます。詳細については、「FIPS 対応バージョン」を参照してください。
- Tanzu CLI：
packageプラグインは、デフォルトでkctrlスタイルのコマンドを使用します。『Tanzu CLI コマンド リファレンス』の「tanzu パッケージ」を参照してください。isolated-clusterプラグインのdownload-bundleおよびupload-bundleコマンドは、「インターネットが制限された環境の準備」の説明に従って、TKG に必要なすべてのコンテナ イメージを取得して転送します。tanzu cluster listの-Aおよび--all-namespacesオプションには、デフォルトの名前空間だけでなく、管理クラスタによって管理され、ユーザーが表示権限以上の権限を持っているすべての名前空間のクラスタが含まれます。contextコマンド グループを使用すると、ユーザーは Tanzu CLI のコンテキストを設定および管理できます。これには、ターゲットとするサーバと適用するkubeconfigが含まれます。『Tanzu CLI コマンド リファレンス』の「tanzu コンテキスト」を参照してください。- 今後のバージョンでは、
tanzu loginコマンドが廃止され、tanzu contextコマンドが使用されます。
- 今後のバージョンでは、
- 以下の「Tanzu Kubernetes Grid v2.1 での動作の変更」で説明されているように、プラグインの
Targetカテゴリは CLI の動作を変更し、将来の使用のために予約されている機能を追加します。 auto-apply-generated-clusterclass-based-configuration機能は、レガシー クラスタ構成ファイルをtanzu cluster createに渡すときに、Tanzu CLI によって生成されたクラスベースのクラスタ構成を自動的に適用します。この機能は、デフォルトでfalseに設定されています。「Tanzu CLI のアーキテクチャと構成」の「機能」を参照してください。allow-legacy-cluster機能を使用すると、プランベースのクラスタを作成できます。この機能は、デフォルトでfalseに設定されています。「Tanzu CLI のアーキテクチャと構成」の「機能」を参照してください。tanzu mc credentials updateおよびtanzu cluster credentials updateコマンドは Azure のオプションを追加します。これには、--azure-client-id、--azure-client-secret、および--azure-tenant-idが含まれます。
- 次のクラスタ構成変数は、『構成ファイル変数リファレンス』で説明されているように、クラスベースのクラスタとスタンドアローン管理クラスタでサポートされています。
- ノード構成：
CONTROL_PLANE_NODE_LABELS、CONTROL_PLANE_NODE_NAMESERVERS、CONTROL_PLANE_NODE_SEARCH_DOMAINS、WORKER_NODE_NAMESERVERS、WORKER_NODE_SEARCH_DOMAINS ExtraArgsプロパティ：APISERVER_EXTRA_ARGS、CONTROLPLANE_KUBELET_EXTRA_ARGS、ETCD_EXTRA_ARGS、KUBE_CONTROLLER_MANAGER_EXTRA_ARGS、KUBE_SCHEDULER_EXTRA_ARGS、WORKER_KUBELET_EXTRA_ARGS- レート制限と同期：
NTP_SERVERS、APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
- ノード構成：
- クラスタは、制御プレーン ノード仮想マシンの証明書を自動的に更新できます。「制御プレーン ノード証明書の自動更新」を参照してください。
- (vSphere) 「マルチ OS ワークロード クラスタの展開」で説明されているように、Windows ベースと Linux ベースのワーカー ノードの両方を実行するマルチ OS ワークロード クラスタを展開できます。このリリースでは、Windows ワークロード クラスタはマルチ OS ワークロード クラスタに置き換えられます。詳細については、「Tanzu Kubernetes Grid v2.1 の動作の変更」を参照してください。
- 「複数のアベイラビリティ ゾーンへのワークロード クラスタの展開 (vSphere テクニカル プレビュー)」の説明に従って、複数のアベイラビリティ ゾーンにワーカーを含むマルチ OS ワークロード クラスタを展開できます。
- (vSphere) クラスベースのワークロード クラスタは、割り当てられた IP アドレス プールを介してクラスタ内 IP アドレス管理 (IPAM) を使用して構成できるため、ノード数またはインスタンスが変更されたときに DHCP 予約を構成する必要がなくなります。
- (vSphere) クラスタ ノードの
Machineオブジェクト ラベルは、nodeSelector を使用して特殊なハードウェアで特定のワークロードを実行できるように、ESXi ホストのアドレスを識別します。 - (vSphere) Ubuntu OVA イメージは、Unified Extensible Firmware Interface (UEFI) モードを使用して起動し、従来の BIOS ファームウェア モードを置き換えます。UEFI モードでは、グラフィック処理ユニット (GPU) ワークロードが有効になり、ノードのセキュリティが強化されます。Ubuntu での UEFI の詳細については、Ubuntu ドキュメントの「UEFI」を参照してください。
- Kube-VIP は、ワークロードの L4
LoadBalancerサービスとして使用できます。「Kube-VIP ロード バランサ」（テクニカル プレビュー）を参照してください。 - 「vSphere 上の単一ノード クラスタ（テクニカル プレビュー）」で説明されているように、単一の ESXi ホスト上で、ホストされたワークロードと制御プレーン インフラストラクチャの両方を実行する単一ノードのワークロード クラスタを Edge アプリケーション用に展開できます。
- 占有量を最小限に抑える
tinyTKr に基づいて、最小限の単一ノード クラスタを展開できます。
- 占有量を最小限に抑える
- 「管理およびワークロード クラスタ インフラストラクチャのバックアップおよびリストア」（テクニカル プレビュー）で説明されているように、クラスタ インフラストラクチャをバックアップして展開できます。
- ポッド セキュリティ アドミッション (PSA) コントローラをサポートし、「ポッド セキュリティ アドミッション コントローラ」（テクニカル プレビュー）で説明されている名前空間に記述されているように、ポッド セキュリティ ポリシーを置き換えます。
Tanzu Kubernetes Grid v2.1 でサポートされる Kubernetes バージョン
Tanzu Kubernetes Grid の各バージョンでは、管理クラスタの Kubernetes バージョンと、Tanzu Kubernetes リリース (TKr) として配布される追加の Kubernetes バージョンのサポートが追加されています。
Tanzu Kubernetes Grid のどのバージョンも、Kubernetes の 2 つ前のマイナー バージョンまでのすべての TKr バージョンをサポートします（ただし、既知の問題に記載されているものは除く）。たとえば、TKG v2.1.x は、以下にリストされている Kubernetes バージョン v1.23.x および v1.22.x をサポートしますが、v1.21.x 以前はサポートしません。
| Tanzu Kubernetes Grid バージョン | 管理クラスタの Kubernetes バージョン | 指定された Kubernetes (TKr) バージョン |
|---|---|---|
| 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 |
| 1.5.4 | 1.22.9 | 1.22.9、1.21.11、1.20.15 |
| 1.5.3 | 1.22.8 | 1.22.8、1.21.11、1.20.15 |
| 1.5.2、1.5.1、1.5.0 | 1.22.5 | 1.22.5、1.21.8、1.20.14 |
Tanzu Kubernetes Grid v2.1 の製品スナップショット
Tanzu Kubernetes Grid v2.1 は、次のインフラストラクチャ プラットフォームとオペレーティング システム (OS)、およびクラスタの作成と管理、ネットワーク、ストレージ、認証、バックアップと移行、および可観測性のコンポーネントをサポートします。括弧内にリストされているコンポーネントのバージョンは、Tanzu Kubernetes Grid v2.1.1 に含まれています。詳細については、「コンポーネントのバージョン」を参照してください。
| vSphere | AWS | Azure | |
| インフラストラクチャ プラットフォーム |
|
ネイティブ AWS | ネイティブ Azure |
| CLI、API、およびパッケージ インフラストラクチャ | Tanzu Framework v0.28.1 | ||
| クラスタの作成と管理 | コア クラスタ 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.6) | ||
| コンテナ ネットワーク | Antrea (v1.7.2)、Calico (v3.24.1) | ||
| コンテナ レジストリ | Harbor (v2.6.3) | ||
| Ingress | NSX Advanced Load Balancer Essentials および Avi Controller **** (v21.1.3 ～ v21.1.6、v22.1.1、v22.1.2)、Contour (v1.22.3) | Contour (v1.22.3) | Contour (v1.22.3) |
| ストレージ | vSphere コンテナ ストレージ インターフェイス (v2.5.2*) および vSphere クラウド ネイティブ ストレージ | Amazon EBS CSI ドライバ (v1.8.0) およびツリー内クラウド プロバイダ | Azure Disk CSI ドライバ (v1.19.0)、Azure File CSI ドライバ (v1.21.0)、およびツリー内クラウド プロバイダ |
| 認証 | 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.5) | ||
* vsphere_csi_driver のバージョン。Tanzu Kubernetes Grid v1.6 リリースに含まれる 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 以降が必要です。
Tanzu Kubernetes Grid v2.1 に付属する Kubernetes バージョンの完全なリストについては、上記の「Tanzu Kubernetes Grid v2.1 でサポートされる Kubernetes バージョン」を参照してください。
コンポーネントのバージョン
Tanzu Kubernetes Grid v2.1.x リリースには、次のソフトウェア コンポーネント バージョンが含まれています。
| コンポーネント | TKG v2.1.1 | TKG v2.1.0 |
|---|---|---|
| aad-pod-identity | v1.8.13+vmware.2* | v1.8.13+vmware.1* |
| addons-manager | v2.1+vmware.1-tkg.3 | v2.1+vmware.1-tkg.3 |
| ako-operator | v1.7.0+vmware.3 | v1.7.0+vmware.3* |
| alertmanager | v0.24.0+vmware.2* | v0.24.0+vmware.1 |
| antrea | v1.7.2+vmware.1-advanced | v1.7.2+vmware.1-advanced* |
| aws-ebs-csi-driver | v1.8.0+vmware.2 | v1.8.0+vmware.2* |
| azuredisk-csi-driver | v1.19.0+vmware.1 | v1.19.0+vmware.1* |
| azurefile-csi-driver* | v1.21.0+vmware.1 | v1.21.0+vmware.1 |
| calico_all | v3.24.1+vmware.1 | v3.24.1+vmware.1* |
| capabilities-package | v0.28.1-dev-capabilities* | v0.28.0-dev-capabilities* |
| carvel-secretgen-controller | v0.11.2+vmware.1 | v0.11.2+vmware.1* |
| cloud-provider-azure | v1.1.26+vmware.1、 v1.23.23+vmware.1、 v1.24.10+vmware.1 |
v1.1.26+vmware.1*、 v1.23.23+vmware.1*、 v1.24.9+vmware.1* |
| cloud_provider_vsphere | v1.24.3+vmware.1 | v1.24.3+vmware.1* |
| cluster-api-provider-azure | v1.6.3_vmware.1* | v1.6.1_vmware.1* |
| cluster_api | v1.2.8+vmware.1 | v1.2.8+vmware.1* |
| cluster_api_aws | v2.0.2+vmware.1 | v2.0.2+vmware.1* |
| cluster_api_vsphere | v1.5.3+vmware.1l* | v1.5.1+vmware.1l* |
| cni_plugins | v1.1.1+vmware.18* | v1.1.1+vmware.16* |
| configmap-reload | v0.7.1+vmware.2* | v0.7.1+vmware.1 |
| containerd | v1.6.6+vmware.3* | v1.6.6+vmware.1* |
| contour | v1.22.3+vmware.1 | v1.22.3+vmware.1* |
| coredns | v1.8.6+vmware.17* | v1.8.6+vmware.15* |
| crash-diagnostics | v0.3.7+vmware.6 | v0.3.7+vmware.6* |
| cri_tools | v1.23.0+vmware.8* | v1.23.0+vmware.7* |
| csi_attacher | v3.5.0+vmware.1、 v3.4.0+vmware.1、 v3.3.0+vmware.1 |
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 |
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 |
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 |
v3.2.1+vmware.1*、 v3.1.0+vmware.2、 v3.0.0+vmware.1 |
| dex | v2.35.3+vmware.2 | v2.35.3+vmware.2* |
| envoy | v1.23.3+vmware.2 | v1.23.3+vmware.2* |
| external-dns | v0.12.2+vmware.4 | v0.12.2+vmware.4* |
| external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
v6.0.1+vmware.1、 v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.6* | v3.5.6+vmware.3* |
| fluent-bit | v1.9.5+vmware.1 | v1.9.5+vmware.1* |
| gangway | v3.2.0+vmware.2 | v3.2.0+vmware.2 |
| grafana | v7.5.17+vmware.1* | v7.5.16+vmware.1 |
| guest-cluster-auth-service | v1.2.0* | v1.1.0* |
| harbor | v2.6.3+vmware.1 | v2.6.3+vmware.1* |
| image-builder | v0.1.13+vmware.2 | v0.1.13+vmware.2* |
| image-builder-resource-bundle | v1.24.10+vmware.1-tkg.1* | v1.24.9+vmware.1-tkg.1* |
| imgpkg | v0.31.1+vmware.1 | v0.31.1+vmware.1* |
| jetstack_cert-manager | v1.10.1+vmware.1 | v1.10.1+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.3*、 v1.12.1+vmware.5* |
v1.15.6+vmware.2、 v1.12.1+vmware.3* |
| k14s_kapp | v0.53.2+vmware.1 | v0.53.2+vmware.1* |
| k14s_ytt | v0.43.1+vmware.1 | v0.43.1+vmware.1* |
| kapp-controller | v0.41.5+vmware.1、 v0.38.5+vmware.2 |
v0.41.5+vmware.1*、 v0.38.5+vmware.2* |
| kbld | v0.35.1+vmware.1 | v0.35.1+vmware.1* |
| kube-state-metrics | v2.6.0+vmware.2* | v2.6.0+vmware.1* |
| kube-vip | v0.5.7+vmware.1 | v0.5.7+vmware.1* |
| kube-vip-cloud-provider* | v0.0.4+vmware.2 | v0.0.4+vmware.2 |
| kube_rbac_proxy | v0.11.0+vmware.2 | v0.11.0+vmware.2 |
| kubernetes | v1.24.10+vmware.1* | v1.24.9+vmware.1* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
v1.4.0+vmware.1*、 v1.3.0+vmware.1 |
| kubernetes-sigs_kind | v1.24.10+vmware.1-tkg.1_v0.17.0* | v1.24.9+vmware.1-tkg.1_v0.17.0* |
| kubernetes_autoscaler | v1.24.0+vmware.1 | v1.24.0+vmware.1* |
| load-balancer-and-ingress-service (AKO) | v1.8.2+vmware.1 | v1.8.2+vmware.1* |
| metrics-server | v0.6.2+vmware.1 | v0.6.2+vmware.1* |
| multus-cni | v3.8.0+vmware.2 | v3.8.0+vmware.2* |
| pinniped | v0.12.1+vmware.1-tkg.1 | v0.12.1+vmware.1-tkg.1 |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 | v0.12.1+vmware.2-tkg.3* |
| prometheus | v2.37.0+vmware.2* | v2.37.0+vmware.1* |
| prometheus_node_exporter | v1.4.0+vmware.2* | v1.4.0+vmware.1* |
| pushgateway | v1.4.3+vmware.2* | v1.4.3+vmware.1 |
| sonobuoy | v0.56.13+vmware.1 | v0.56.13+vmware.1* |
| standalone-plugins-package | v0.28.1-dev-standalone-plugins* | v0.28.1-dev-standalone-plugins* |
| tanzu-framework | v0.28.1* | v0.28.0* |
| tanzu-framework-addons | v0.28.1* | v0.28.0* |
| tanzu-framework-management-packages | v0.28.1-tf* | v0.28.0-tf* |
| tkg-bom | v2.1.1* | v2.1.0* |
| tkg-core-packages | v1.24.10+vmware.1-tkg.1* | v1.24.9+vmware.1-tkg.1* |
| tkg-standard-packages | v2.1.1* | v2.1.0* |
| tkg-storageclass-package | v0.28.1-tkg-storageclass* | v0.28.0-tkg-storageclass* |
| tkg_telemetry | v2.1.1+vmware.1* | v2.1.0+vmware.1* |
| velero | v1.9.5+vmware.1 | v1.9.5+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.3+vmware.1 | v1.5.3+vmware.1* |
| velero-plugin-for-csi | v0.3.3+vmware.1 | v0.3.3+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.3+vmware.1 | v1.5.3+vmware.1* |
| velero-plugin-for-vsphere | v1.4.2+vmware.1 | v1.4.2+vmware.1* |
| vendir | v0.30.1+vmware.1 | v0.30.1+vmware.1* |
| vsphere_csi_driver | v2.6.2+vmware.2 | v2.6.2+vmware.2* |
| whereabouts | v0.5.4+vmware.1 | v0.5.4+vmware.1* |
* 以前のリリース以降の新しいコンポーネントまたはバージョンアップを示します。TKG v2.1.0 は v2.1.1 より前、v1.6.1 は v2.1.0 より前です。
TKG v2.1 に同梱されているソフトウェア コンポーネント バージョンの完全なリストについては、imgpkg を使用してリポジトリ バンドルをプルし、その内容を一覧表示します。TKG v2.1.1 の場合、次に例を示します。
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.1 -o standard-2.1.1
cd standard-2.1.1/packages
tree
次のようなローカル BOM ファイルには、パッケージのバージョンも表示されますが、最新ではない可能性があります。
~/.config/tanzu/tkg/bom/tkg-bom-v2.1.yaml~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml
サポートされるアップグレード パス
TKG アップグレード パスでは、v2.1 が v1.6 のすぐ後に続きます。TKG v2.0 は TKG のダウンロード可能なバージョンではありません。これは、vSphere 8 の vSphere with Tanzu スーパーバイザーに組み込まれている TKG のバージョンです。
Tanzu Kubernetes Grid v2.1.x には v1.6.x からのみアップグレードできます。v1.6.x より前のバージョンから Tanzu Kubernetes Grid v2.1.x にアップグレードする場合は、まず v1.6.x にアップグレードする必要があります。
ワークロード クラスタの Kubernetes バージョンをアップグレードするときに、マイナー バージョンをスキップすることはできません。たとえば、Tanzu Kubernetes クラスタを v1.21.x から v1.23.x に直接アップグレードすることはできません。クラスタを v1.23.x にアップグレードする前に、v1.21.x クラスタを v1.22.x にアップグレードする必要があります。
リリース日
Tanzu Kubernetes Grid v2.1 のリリース日は次のとおりです。
- v2.1.0：2023 年 1 月 29 日
- v2.1.1：2023 年 3 月 21 日
Tanzu Kubernetes Grid v2.1 での動作の変更
Tanzu Kubernetes Grid v2.1 では、以前の最新リリースである v1.6.1 と比較して、次の新しい動作が導入されています。
tanzu cluster listの--include-management-clusterオプションには、スタンドアローン管理クラスタをリストするための-Aオプションが必要です。-Aオプションを使用すると、コマンドはすべての名前空間内のクラスタをリストします。-
Tanzu CLI の
packageプラグインは、デフォルトでkctrlスタイルのコマンドを使用します。『Tanzu CLI コマンド リファレンス』の「kctrl を使用する tanzu パッケージ」を参照してください。- TKG v1.6 では、
packageプラグインはデフォルトでkctrlモードが無効な状態で実行されます（以下レガシー モードと呼ばれます）。 -
kctrlモードとレガシー モードのコマンドは次のように異なります。- パッケージ構成のデフォルト値ファイルを作成するには、
kctrlスタイルのtanzu package available getコマンドで--default-values-file-outputフラグの代わりに--generate-default-values-fileフラグを使用します。 --create-namespaceフラグが削除されました。-nまたは--namespaceを使用してターゲット名前空間を指定する場合は、名前空間がすでに存在している必要があります。--createフラグは、package repository updateに対して削除されました。--package-nameフラグの名前が--packageに変更されました（package installed createおよびpackage installに対して）。--installフラグは、package installed updateに対して削除されました。--verboseグローバル フラグが削除されました。--poll-intervalおよび-poll-timeoutフラグの名前が--wait-intervalおよび--wait-timeoutに変更されました。package available getの出力で、パッケージで使用可能なバージョンが追加のテーブルに一覧表示されます。package available listの出力では、LATEST-VERSION列が削除され、SHORT-DESCRIPTIONがデフォルトでは表示されず、表示するには--wideフラグを使用します。package repository listの出力では、REPOSITORYおよびTAG列は、ソース タイプ (imgpkg)、リポジトリ URL、タグで構成されるSOURCE列に置き換えられます。
- パッケージ構成のデフォルト値ファイルを作成するには、
-
kctrlモードを無効化した状態でのtanzu packageプラグインの動作については、TKG v1.6 ドキュメントの「CLI で管理されるパッケージ」のトピックを参照してください。
- TKG v1.6 では、
tanzu-standardパッケージ リポジトリは、クラスベースのクラスタに事前にはインストールされません。パッケージ リポジトリを追加するには、「パッケージ リポジトリの追加」を参照してください。- Tanzu CLI 管理クラスタの作成プロセスでは、新しい VPC の作成はサポートされなくなりました。インストーラ インターフェイスには新しい VPC を作成するオプションが含まれていません。また、クラスタ構成ファイルでは、指定された CIDR に対する新しい VPC を作成するための
AWS_*オプションはサポートされなくなりました。新しい VPC を使用する場合は、AWS にスタンドアローン管理クラスタを展開する前に、AWS コンソールを使用して TKG 展開用の VPC を作成する必要があります。 -
Tanzu CLI は、新しいターゲット抽象化を使用して、コマンドが適用されるサーバのタイプに異なるコマンド グループを関連付けます。
--targetフラグを持つtanzu context listコマンドは、コンテキスト タイプと同じ概念を指します。コマンド グループは CLI プラグインに基づいているため、以下のようになります。- Kubernetes クラスタのコマンドを定義するプラグインには、次のターゲットがあります：
k8s - TMC コマンドのコマンドを定義するプラグインには、将来の使用のためにターゲット
tmcが予約されています - コンテキストに依存しないコマンドを定義するプラグインには、ターゲットがありません
- 異なるターゲットに同じ名前のプラグインを使用すると、Tanzu CLI は、
tanzu clusterなどのコマンド グループでコマンドをコンテキストに合わせて調整します。
TKG v2.1 では、サポートされているターゲットまたはコンテキスト タイプは
k8sのみです。これは、以下によっても示されます。tanzu helpコマンドの出力でのKubernetes cluster operationstanzu plugin listの出力のTARGET列のkubernetes
- Kubernetes クラスタのコマンドを定義するプラグインには、次のターゲットがあります：
- VMware は、TKG v1.6 ドキュメントで説明するように、Windows ベースのワーカーのみを持つ Windows ワークロード クラスタを展開することは推奨していません。代わりに、VMware は、「マルチ OS ワークロード クラスタの展開」で説明されているように、マルチ OS クラスタを作成することをお勧めします。マルチ OS クラスタは、Windows コンテナと Linux コンテナの両方を実行できるため、Linux ベースの TKG コンポーネントと Linux ワークロードの両方をサポートします。
- Go v1.18 での証明書処理の変更により、MacOS ブートストラップ マシンは、サムプリント検証を使用して
tanzu cluster createを実行する前に、キーチェーンに vCenter Server 証明書を追加する必要があります。「クラスタ展開の前提条件」を参照してください。
ユーザー ドキュメント
新しいドキュメント『TKG 2.1 スタンドアローン管理クラスタの展開と管理』には、スタンドアローン管理クラスタに固有のトピックが含まれています。これは TKG を vSphere with Tanzu スーパーバイザーとともに使用することには関連しません。
詳細については、「VMware Tanzu Kubernetes Grid のドキュメント」ページの「お客様の展開に適した TKG ドキュメントを見つける」を参照してください。
解決した問題
v2.1.1 で解決済み
Tanzu Kubernetes Grid v2.1.0 の「既知の問題」として記載された次の問題は、Tanzu Kubernetes Grid v2.1.1 で解決されています。
-
CNI:noneオプションは、スタンドアローン管理クラスタから展開されたワークロード クラスタでは動作しません。使用可能な選択肢は、antrea（デフォルト）とcalicoのみです。 -
TKG ユーザー アカウントがアイドル状態の vCenter Server セッションを作成する
TKG の vSphere Server アカウントは、アイドル状態の vCenter セッションを作成します。これは、vSphere > [ホストおよびクラスタ (Hosts and Clusters)] インベントリ > 自分の vCenter Server > [監視 (Monitor)] タブ > [セッション (Sessions)] でリストされます。
回避策：すべてのセッションを開始および停止して、アイドル状態の vCenter Server セッションを削除します。
rootとして vCenter Server にssh接続します- プロンプトが表示されたら、
shellと入力します service-control --stop --allを実行します- サービスが
Stoppedと表示するまで待機します service-control --start --allを実行します
-
Azure 上のクラスベースのワークロード クラスタの
LoadBalancerサービスで、ゲートウェイまたはフロントエンドの手動構成が必要となるAzureClusterNameとClusterNameの名前が一致しないため、クラスベースの Azure ワークロード クラスタ上のアプリケーションで使用するために展開されたLoadBalancerタイプのサービスにインターネットからアクセスできません。回避策：NAT ゲートウェイ、プロキシ、またはその他の内部ルーティングなどを介してロード バランサ サービスに独自のルートを指定し、ロード バランサの背後にあるノードがインターネットにアクセスできるようにします。
VMware は、送信接続に NAT ゲートウェイ（使用可能な場合）を使用することをお勧めします。NAT ゲートウェイを使用できない場合：
- Azure ポータルから、CAPZ によって作成された
LoadBalancerリソースに移動します。これは、AzureClusterと同じ名前である必要があります。 - [フロントエンド IP アドレス (Frontend IP configuration)] を選択し、[追加 (Add)] をクリックします。
- ロード バランサ サービスの新しいパブリック IP アドレスを作成します。
-
以下の仕様を使用してサービスを構成および作成し、
loadBalancerIP値をIP-ADDRESSで示されるパブリック IP アドレスに設定します。apiVersion: v1 kind: Service metadata: name: frontend labels: app: guestbook tier: frontend namespace: sample-app spec: # Add the frontend public IP here loadBalancerIP: IP-ADDRESS type: LoadBalancer ports: - port: 80 selector: app: guestbook tier: frontend
- Azure ポータルから、CAPZ によって作成された
-
クラスタをアップグレードしても Kube-VIP のバージョンが更新されない
スタンドアローン管理クラスタとワークロード クラスタを v2.1 にアップグレードしても、
kube-vipが現在のバージョンにアップグレードされません。回避策：制御プレーン エンドポイントに Kube-VIP を使用するアップグレードされたクラスタの場合、
AVI_CONTROL_PLANE_HA_PROVIDER = falseで構成されているように、kube-vipコンポーネントを更新します。-
クラスタのアップグレードに使用されている現在の TKr BoM ファイルを取得します。このファイルのローカル コピーを
~/.config/tanzu/tkg/bom/で探します。ファイル名の先頭はtkr-です。たとえば、tkr-bom-v1.24.10+vmware.1-tkg.1.yamlなどです。 -
BoM ファイルから現在の
kube-vipバージョンを一覧表示します。次に例を示します。$ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml | yq '.components.kube-vip' - version: v0.5.7+vmware.1 images: kubeVipImage: imagePath: kube-vip tag: v0.5.7_vmware.1 -
クラスタの
kcpオブジェクトを取得します。このオブジェクトの名前の形式はCLUSTER-NAME-control-planeです。- 管理クラスタ オブジェクトは、tkg-system 名前空間に作成されます。
- ワークロード クラスタ オブジェクトはクラスタの作成に使用される名前空間内にあります（
NAMESPACEが設定されていない場合はdefault）。
-
kubectl editを実行してkcpオブジェクトを編集し、kube-vipのパスを更新して、BoM イメージの現在のバージョンと一致させます。以下を実行して、この設定の場所を検索します。kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
-
-
管理クラスタを v1.5.x から v2.1.0 にアップグレードすると、AKO オペレータ シークレットの null の
avi_ingress_node_network_listが原因でノード ネットワーク エラーが発生するTKG v1.5 以前で作成されたスタンドアローン管理クラスタでは、v2.1.0 にアップグレードすると、AKO オペレータ シークレットの
avi_ingress_node_network_listに null 値が設定されます。これにより、v2.1.0 へのアップグレード時にノード ネットワーク エラーが発生し、Avi 構成の欠落を示すエラーがログに生成されます。回避策：Tanzu CLI v2.1.0 にアップグレードした後、
tanzu mc upgradeを実行する前に次を行います。-
管理クラスタ コンテキストに切り替えます。
kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER> -
AKO オペレータ シークレットを取得し、そのデータ値をデコードします。
kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml -
テキスト エディタで
values.yamlファイルを開きます。avi_ingress_node_network_list設定は以下のようになります。avi_ingress_node_network_list: '""' -
クラスタ ノード ネットワークの範囲を使用して、設定を次のように変更します。
avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]' -
base64 で新しいデータ値をエンコードし、出力文字列を記録します。
base64 -w 0 values.yaml -
AKO オペレータ シークレットを編集します。
kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system -
シークレットの
values.yamlの値として、エンコードされた新しいデータ値の文字列に貼り付けます。保存して終了します。
-
-
TMC は、サービス エンジンが
Default-GroupSEG にないクラスベースのクラスタを展開できません。TKG と統合された Tanzu Mission Control は、NSX ALB を使用し、NSX ALB の
Default-Groupサービス エンジン グループにないサービス エンジンで構成された新しいクラスベースのクラスタを展開できません。この制限は、カスタム サービス エンジンで構成された既存のワークロード クラスタのアップグレードには影響しません。詳細については、『Tanzu Mission Control リリース ノート』を参照してください。
-
TMC カタログではパッケージの一覧表示と展開がサポートされない
TMC ドキュメントの「View Packages」で説明されているように、Tanzu Mission Control (TMC) のカタログ機能を使用して、パッケージを一覧表示したり、TKG v2.1 ワークロード クラスタにパッケージをインストールすることはできません。TMC ユーザー インターフェイスには、パッケージ リポジトリが調整中の状態で停止している状態が表示されます。
v2.1.0 で解決済み
Tanzu Kubernetes Grid v1.6.1 の「既知の問題」として記載された次の問題は、Tanzu Kubernetes Grid v2.1.0 で解決されています。
-
DaemonSet がパーシステント ボリュームを自動リストアするように構成されている場合、ポッドを削除するクラスタおよびポッドの操作が失敗することがある
DaemonSet がパーシステント ボリューム (PV) を使用するインストールでは、デフォルトでドレイン プロセスが DaemonSet を無視し、システムがボリュームがノードから分離されるまで無期限に待機するため、マシンの削除に失敗することがあります。影響を受けるクラスタ操作には、アップグレード、スケール ダウン、削除が含まれます。
-
vSphere with Tanzu で
tanzu cluster listを実行すると DevOps ユーザーのエラーが生成されるDevOps エンジニア ロールを持つユーザーが、「vSphere with Tanzu のユーザー ロールとワークフロー」で説明されているように
tanzu cluster listを実行すると、「Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope」のようなエラーが表示される場合があります。これは、
-nオプションを指定せずにtanzu cluster commandを実行すると、すべての名前空間にアクセスしようとしますが、そのうちのいくつかには、DevOps エンジニア ユーザーがアクセスできない可能性があるためです。回避策：
tanzu cluster listを実行する場合は、--namespace値を含め、ユーザーがアクセスできる名前空間を指定します。
既知の問題
Tanzu Kubernetes Grid v2.1.x の既知の問題は次のとおりです。v2.1.1 の既知の問題で、それ以降の v2.1.x パッチ リリースで解決されたものは、修正されたパッチ リリースの「解決した問題」に記載されています。
- アップグレード
- パッケージ
- クラスタ操作
- ネットワーク
- ID およびアクセス管理
- ストレージ
- CLI
- vSphere
- AWS
- Windows およびマルチ OS ワークロード クラスタ
- Image Builder
- AVS
アップグレード
v2.1.1 での既知の問題
以下は、v2.1.1 でのアップグレードに関する既知の問題です。
-
vSphere での v2.1 から v2.1.1 へのアップグレードが失敗する
vSphere では、v2.1 から v2.1.1 へのアップグレードが「
Reconcile failed:Error」というエラーで失敗します。このエラーは、tkg-clusterclass-vsphereパッケージが調整されず、インストールがブロックされているために発生します。回避策：次の vSphere リソース変数がローカル環境で設定されている場合は、設定を解除します。
unset VSPHERE_CLONE_MODE unset VSPHERE_DATACENTER unset VSPHERE_DATASTORE unset VSPHERE_FOLDER unset VSPHERE_NETWORK unset VSPHERE_RESOURCE_POOL unset VSPHERE_SERVER unset VSPHERE_STORAGE_POLICY_ID unset VSPHERE_TEMPLATE unset VSPHERE_WORKER_DISK_GIB unset VSPHERE_WORKER_MEM_MIB unset VSPHERE_WORKER_NUM_CPUS
v2.1.x での既知の問題
以下は、v2.1.x でのアップグレードに関する既知の問題です。
-
Azure で、管理クラスタとワークロード クラスタのアップグレードが失敗し、「
context deadline exceeded」または「unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane」のようなエラーが表示される場合があります。これは、Azure での操作に他のプラットフォームよりも時間がかかる場合があるために発生します。回避策：
--timeoutフラグでより長いタイムアウトを指定して、tanzu management-cluster upgradeまたはtanzu cluster upgradeを再度実行します。デフォルトのタイムアウトは 30m0s です。 -
最初に TKG v1.3 以前で作成されたスタンドアローン管理クラスタのアップグレードが失敗する
TKG v2.1 では、汎用クラスタを TKG スタンドアローン管理クラスタに変換するコンポーネントは、Carvel パッケージ
tkg-pkgにパッケージ化されています。最初に TKG v1.3 以前で作成されたスタンドアローン管理クラスタには、tkg-pkgをインストールするためにアップグレード プロセスで必要な構成シークレットがないため、アップグレードが失敗します。回避策：TKG v1.3 以前で作成されたスタンドアローン管理クラスタの場合は、「スタンドアローン管理クラスタのアップグレード」に記載されている追加の手順を実行します。
-
TKG_NO_PROXY設定でワイルドカード文字 (*) を使用して作成されたクラスタのアップグレードに失敗するTKG v1.6 では、
TKG_NO_PROXYのクラスタ構成ファイル設定でワイルドカード文字 (*) を使用できません。この設定を使用して以前の TKG バージョンで作成されたクラスタは、エラー「workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY」を回避するためにアップグレード前に特別な処理が必要です。回避策：アップグレードするクラスタのタイプに応じて、次の手順を実行します。
-
管理クラスタ：
- 管理クラスタの
kubectlコンテキストに切り替えます。 -
configMap kapp-controller-config を編集します。
kubectl edit cm kapp-controller-config -n tkg-system -
data.noProxyフィールドを見つけ、*を削除してワイルドカード ホスト名を変更します。たとえば、次のように変更します：*.vmware.com to.vmware.com -
保存して終了します。クラスタをアップグレードする準備ができました。
- 管理クラスタの
-
ワークロード クラスタ：
- ワークロード クラスタの
kubectlコンテキストに切り替えます -
クラスタ名と名前空間の環境変数を設定します。次に例を示します。
CLUSTER_NAME=my-test-cluster NS=my-test-namespace -
ワークロード クラスタの kapp コントローラ データ値を取得してデコードします。
kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" -
${CLUSTER_NAME}-${NS}-kapp-controller-data-valuesファイルを編集して、そのkappController.config.noProxy設定から*を削除します。たとえば、*.vmware.com toを.vmware.comに変更します。 - 保存して終了します。
-
データ値ファイル
${CLUSTER_NAME}-${NS}-kapp-controller-data-valuesを再エンコードします。cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0 -
${CLUSTER_NAME}-${NS}-kapp-controller-data-valuesシークレットを編集し、新しくエンコードされたデータ値の文字列を貼り付けることでdata.value.yaml設定を更新します。kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}" -
保存して終了します。クラスタをアップグレードする準備ができました。
- ワークロード クラスタの
-
-
スタンドアローン管理クラスタのアップグレード直後に古いバージョンの TKr を使用できない
スタンドアローン管理クラスタを TKG v1.6 から v2.1 にアップグレードすると、TKr ソース コントローラがクラスベースのクラスタをサポートする新しいバージョンに置き換えられ、TKr が再同期されます。その結果、
tanzu mc upgradeコマンドが完了すると、tanzu cluster available-upgrades getおよびtanzu kubernetes-release getにすべての有効な TKr バージョンが表示されず、Tanzu CLI がワークロード クラスタをすぐにアップグレードできないことがあります。回避策：TKr が再ダウンロードされるまで数分待ちます。
パッケージ
-
次のバージョンでの既知の問題：v2.1.1
TKG v2.1.1 の Tanzu Standard パッケージ リポジトリには、v2.1.0 リポジトリにある次のパッケージ バージョンがありません。
cert-manager：1.10.1+vmware.1-tkg.1.yml、1.5.3+vmware.7-tkg.1.yml、および1.7.2+vmware.3-tkg.1.ymlexternal-dns：0.10.0+vmware.1-tkg.3.yml、0.11.0+vmware.1-tkg.3.yml、および0.12.2+vmware.4-tkg.1.ymlgrafana:7.5.16+vmware.1-tkg.2.yml
このため、ワークロード クラスタを TKG v2.1.0 から v2.1.1 にアップグレードした後で、
tanzu package installed updateを実行して、パッケージを最新バージョンにアップグレードせずにこれらのパッケージの構成を更新することはできません。cert-manager:1.10.1+vmware.1-tkg.2.ymlexternal-dns:0.12.2+vmware.4-tkg.2.ymlgrafana:7.5.17+vmware.1-tkg.1.yml
この問題は、パッケージ構成を変更する必要がある場合にのみ発生します。インストールされたパッケージは、アップグレードせずに引き続き実行されます。
回避策：次のいずれかの処理を行います。
-
cert-manager、external-dns、またはgrafanaパッケージ構成を更新する必要がある場合は、次の手順を実行します。tanzu package installed getを実行して、パッケージのバージョンを取得します。- 上記のように、インストール済みのパッケージのバージョンが v2.1.1 リポジトリにない場合は、
tanzu package installed updateを実行するときに最新バージョンを-vフラグに渡します。
-
ワークロード クラスタを TKG v2.1.1 にアップグレードした後、3 つのパッケージを上記のバージョンに更新します。
tanzu packageコマンドについては、「パッケージのインストールと管理」の説明を参照してください。 -
Multus CNI が NSX Advanced Load Balancer を備えた
mediumおよび小規模なポッドで失敗するvSphere では、NSX ALB を備えた Multus CNI パッケージを実行する
mediumまたは小規模なワーカー ノードを持つワークロード クラスタが、Insufficient CPUまたはその他のエラーで失敗することがあります。回避策：NSX ALB を備えた Multus CNI を使用するには、サイズが
largeまたはextra-largeのワーカー ノードを持つワークロード クラスタを展開します。 -
TKG BoM ファイルに無関係な cert-manager パッケージ バージョンが含まれている
Tanzu CLI が
~/.config/tanzu/tkgにインストールする TKG コンポーネント情報 (BoM) ファイルには、cert manager(jetstack_cert-manager) パッケージの v1.5.3 と v1.7.2 の両方のバージョンがリストされています。「cert-manager のインストール」で記載のとおり、インストールする正しいバージョンは v1.5.3 です。回避策：v1.5.3 の
cert-managerをインストールします。 -
Pinniped を無効化する場合は、レガシー クラスタで手動で
Secretを削除する必要がある管理クラスタで外部 ID 管理を無効にすると、未使用の Pinniped
Secretオブジェクトがレガシー ワークロード クラスタに残ります。ユーザーが古い
kubeconfigを使用してクラスタにアクセスしようとすると、ログイン ポップアップが表示されて失敗します。回避策：「ID 管理の無効化」の説明に従って、レガシー クラスタの Pinniped
Secretを手動で削除します。 -
実行 ID が 1000000 を超えると、Harbor CVE のエクスポートに失敗することがある
TKG v2.1 用にパッケージ化されたバージョンである Harbor v2.6.3 には、実行プライマリ キーの自動増分 ID が 1000000 を超えると、CVE レポートのエクスポートが「404 page not found」というエラーになるという既知の問題があります。
この Harbor の問題は、新しいバージョンの TKG に組み込まれる予定の新しいバージョンの Harbor で解決されています。
-
インターネットが制限された環境で、Tanzu Kubernetes Grid v2.1 を実行するために Harbor のプロキシ キャッシュ機能を使用することはできません。Harbor プロキシ キャッシュを使用して、以前のバージョンの Tanzu Kubernetes Grid のイメージや、アプリケーション イメージなどの Tanzu 以外のイメージをプロキシすることはできます。
回避策：なし
-
パッケージがデフォルトのベースライン PSA プロファイルに準拠していない
TKG の PSA コントローラで、サポートされていない「テクニカル プレビュー」状態の場合、一部の TKG パッケージがデフォルトの
baselineプロファイルに準拠していません。回避策：「ポッド セキュリティ アドミッション コントローラ（テクニカル プレビュー）」の説明に従って、影響を受けるパッケージの名前空間に
audit=privilegedおよびwarn=privilegedラベルを設定します。 -
tanzu package repository addを実行して、tanzu-standardリポジトリを、「vSphere 上の単一ノード クラスタ（テクニカル プレビュー）」で説明されているタイプの単一ノード クラスタに追加すると、失敗する場合があります。これは、単一ノード クラスタがコア アドオンとして
cert-managerを使用して起動するためです。これは、tanzu-standardリポジトリ内の別のcert-managerパッケージと競合します。回避策：
tanzu-standardリポジトリを追加する前に、「cert-manager のインストール」の説明に従って、cert-managerパッケージの注釈にパッチを適用してください。
クラスタ操作
v2.1.1 での既知の問題
以下は、v2.1.1 でのクラスタ操作に関する既知の問題です。
-
Antrea CNI を使用して、最新でない TKr バージョンに基づいた新しいワークロード クラスタの作成を実行できない
Antrea CNI を使用する新しいワークロード クラスタを作成して、「Tanzu Kubernetes Grid v2.1 でサポートされる Kubernetes バージョン」に記載されている、以前のバージョンの TKG に付属する Kubernetes バージョン（TKG v1.6.1 のデフォルトの Kubernetes バージョンである Kubernetes v1.23.10 など）を実行することはできません。
TKG v2.1.1 は、古いバージョンの Kubernetes を実行する既存のクラスタを完全にサポートします。
回避策：Kubernetes 1.24.10、1.23.16、または 1.22.17 を実行するワークロード クラスタを作成します。Kubernetes プロジェクトは、現在のマイナー バージョンの最新のパッチ バージョンでコンポーネントを実行することを推奨します。
v2.1 での既知の問題
-
tanzu cluster createで、デフォルト以外の Kubernetes バージョンで生成されたクラスタ仕様が正しく検証されない「クラスベースのクラスタを作成する」で説明されている 2 段階のプロセスのいずれかを使用して構成ファイルからクラスベースのワークロード クラスタを作成し、最初の手順で
--tkr値を指定してクラスタの基準をデフォルト以外のバージョンの Kubernetes にすると、2 番目の手順が検証エラーで失敗することがあります。回避策：2 番目の手順では、「クラスベースのクラスタを作成する」の説明に従って、
tanzu cluster createを 2 回目に実行し、生成されたクラスタ マニフェストを渡すときに、最初の手順で行ったのと同じ--tkr値とその他のオプションを指定します。 -
クラスタ 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」に変更されました。
-
レガシー構成ファイルから
ClusterClass構成ファイルを作成すると、--dry-runに空の Antrea 構成が含まれるANTREA_NODEPORTLOCALエントリが含まれているレガシー構成ファイルから、tanzu cluster create --dry-run -fを使用してClusterClass構成ファイルを作成すると、ラベルを含まない Antrea 構成が自動生成され、Antrea の調整が正常に行われません。これは、TKG 2.1.1 では、アドオン マネージャが指定されたワークロード クラスタに Antrea をインストールするためにAntreaConfigリソースにtkg.tanzu.vmware.com/package-name labelが必要であるために発生します。この問題は 2.1.0 には該当しません。回避策：見つからないラベルを
ClusterClass構成ファイルのAntreaConfigに追加し、もう一度クラスタを作成してみてください。labels: tkg.tanzu.vmware.com/cluster-name: rito tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced -
vSphere 8 で IPv6 ネットワークがサポートされない
TKG v2.1 は vSphere 8 で IPv6 ネットワークをサポートしませんが、「IPv6 ネットワーク」で説明するように、vSphere 7 の Kube-Vip を使用した単一スタック IPv6 ネットワークをサポートします。
回避策：vSphere の IPv6 環境で TKG が必要な場合、または現在使用している場合は、vSphere 8 をインストールしたり、vSphere 8 にアップグレードしたりしないでください。
-
管理クラスタで NSX ALB
NodePortLocal入力方向モードがサポートされないTKG v2.1 では、管理クラスタへのトラフィックに対して 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 管理を再構成します。
ストレージ
-
デフォルトの
StorageClassオブジェクトを変更すると、ワークロード クラスタで調整エラーが発生するTKG に含まれるデフォルトの
StorageClassオブジェクトのプロパティを変更すると、ストレージ クラスを使用するワークロード クラスタでパッケージ調整エラーが発生します。回避策：ストレージ クラスをカスタマイズするには、デフォルトのオブジェクト定義を変更するのではなく、別の
nameを使用して新しいStorageClass定義を作成し、新しいストレージ クラスを使用するようにクラスタを再構成します。 -
ワークロード クラスタが複数のデータストアにストレージを分散できない
「データストア クラスタを使用するクラスタの展開」で説明するように、ワークロード クラスタを有効にして複数のデータストアにストレージを分散することはできません。1 つのデータストア クラスタ内の複数のデータストアにタグを付ける場合、ワークロード クラスタのストレージ ポリシーの基準として、ワークロード クラスタはデータストアの 1 つのみを使用します。
回避策：なし
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 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に渡すときにも発生することがあります。回避策：エラー出力にリストされている構成パラメータまたはパラメータをローカル環境変数として設定します。または、このエラーを回避するため、
auto-apply-generated-clusterclass-based-configuration機能をtrueに設定してからtanzu cluster createを実行することで、構成をプレビューせずにクラスベースのクラスタをワンステップで作成できます。auto-apply-generated-clusterclass-based-configurationをtrueに設定するには、次を実行します。tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration trueこれにより、常にワンステップでクラスベースのクラスタを作成するように Tanzu CLI が構成されます。詳細については、「クラスベースのクラスタを作成する」を参照してください。
-
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コマンドを使用します。 -
Windows コマンド プロンプト (CMD) で、列でフォーマットされた Tanzu CLI コマンド出力の列見出しに無関係な文字が含まれています。
この問題は、Windows ターミナルまたは PowerShell では発生しません。
回避策：Windows ブートストラップ マシンで、Windows ターミナルから Tanzu CLI を実行します。
-
管理クラスタの作成中に無視可能な
AKODeploymentConfigエラーが発生するtanzu management-cluster createを実行して、NSX ALB を使用して管理クラスタを作成すると、次のエラーが出力されます。no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???。このエラーは無視してかまいません。詳細については、ナレッジベースのこの記事を参照してください。 -
vSphere でのワークロード クラスタの作成中に無視可能な
machinehealthcheckおよびclusterresourcesetエラーが発生するvSphere with Tanzu から
tanzu cluster createコマンドを使用してワークロード クラスタを vSphere に展開すると、以下に示すように、machinehealthcheckの実行とclusterresourcesetリソースへのアクセスに関連するエラーが出力に含まれることがあります。Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg" ... Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet" ...ワークロード クラスタが正常に作成されました。エラーは無視してかまいません。
-
MHC が無効な場合、CLI が最近削除されたノードのステータスを一時的に誤って報告する
マシンの健全性チェック (MHC) が無効になっている場合、
tanzu cluster statusなどの Tanzu CLI コマンドは、インフラストラクチャの再作成中に最新のノード状態を報告しない場合があります。回避策：なし
vSphere
-
smallノードで作成されたノード プールがProvisioningで停止することがあるsmallとして構成されたノードSIZEで作成されたノード プールは、Provisioning状態でスタックし、Runningに進まない場合があります。回避策：ノード プールに少なくとも
mediumサイズのノードを構成します。 -
ワークロード (
AVI_ENABLE) または制御プレーン (AVI_CONTROL_PLANE_HA_PROVIDER) に NSX Advanced Load Balancer を使用している場合、Avi Controller は同じ名前のクラスタを区別できないことがあります。回避策：クラスタごとに一意の
CLUSTER_NAME値を設定します。-
管理クラスタ：異なるブートストラップ マシンであっても、同じ
CLUSTER_NAME値を持つ複数の管理クラスタを作成しないでください。 -
ワークロード クラスタ：同じ
CLUSTER_NAMEを持ち、NAMESPACE値で設定される同じ管理クラスタ名前空間に含まれる複数のワークロード クラスタを作成しないでください。
-
-
既存の環境に外部 ID 管理を追加するために、ダミーの
VSPHERE_CONTROL_PLANE_ENDPOINT値の設定が必要になる場合がある外部 ID プロバイダを既存の TKG 環境と統合するには、「管理クラスタの Pinniped アドオン シークレットの生成」で説明されているように、アドオン シークレットの作成に使用される管理クラスタ構成ファイルにダミーの
VSPHERE_CONTROL_PLANE_ENDPOINT値を設定する必要がある場合があります。
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 およびマルチ OS ワークロード クラスタ
-
MacOS マシンに Windows マシン イメージを作成できない
Kubernetes Image Builder で使用されるオープンソースの
packerユーティリティの問題により、「Windows カスタム マシン イメージ」で説明されているように MacOS マシンで Windows マシン イメージをビルドできません。回避策：Linux マシンを使用して、カスタム Windows マシン イメージをビルドします。
-
Windows およびマルチ OS ワークロード クラスタでバックアップとリストアがサポートされない
Windows ベースのワーカー ノードを使用して、ワークロード クラスタをバックアップおよびリストアすることはできません。
回避策：なし
Image-Builder
-
イメージ ビルド プロセス中に無視可能な
gossテスト エラーが発生するKubernetes Image Builder を実行してカスタム Linux カスタム マシン イメージを作成すると、
gossテストのpython-netifaces、python-requests、およびebtablesが失敗します。コマンド出力はエラーを報告します。エラーは無視できます。正常なイメージのビルドを妨げるわけではありません。
AVS
-
AVS での vSphere CSI ボリュームの削除に失敗することがある
Azure vSphere Solution (AVS) で、vSphere CSI パーシステント ボリューム (PV) の削除に失敗することがあります。PV を削除するには、cns.searchable 権限が必要です。AVS のデフォルトの管理者アカウント [email protected] は、この権限で作成されていません。詳細については、「vSphere ロールと権限」を参照してください。
回避策：AVS 上の vSphere CSI PV を削除するには、Azure サポートにお問い合わせください。
