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) クラスベースのワークロード クラスタは、割り当てられた 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 アプリケーション用に展開できます。
    • 占有量を最小限に抑える tiny TKr に基づいて、最小限の単一ノード クラスタを展開できます。
  • 「管理およびワークロード クラスタ インフラストラクチャのバックアップおよびリストア」（テクニカル プレビュー）で説明されているように、クラスタ インフラストラクチャをバックアップして展開できます。
  • ポッド セキュリティ アドミッション (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
インフラストラクチャ プラットフォーム
  • vSphere 6.7U3
  • vSphere 7
  • vSphere 8
  • VMware Cloud on AWS**
  • Azure VMware Solution
  • Oracle Cloud VMware Solution (OCVS)
  • Google Cloud VMware Engine (GCVE)
 ネイティブ 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 で管理されるパッケージ」のトピックを参照してください。

  • 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 operations
    • tanzu plugin list の出力の TARGET 列の 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 を展開できない

    CNI:none オプションは、スタンドアローン管理クラスタから展開されたワークロード クラスタでは動作しません。使用可能な選択肢は、antrea（デフォルト）と calico のみです。

  • TKG ユーザー アカウントがアイドル状態の vCenter Server セッションを作成する

    TKG の vSphere Server アカウントは、アイドル状態の vCenter セッションを作成します。これは、vSphere > [ホストおよびクラスタ (Hosts and Clusters)] インベントリ > 自分の vCenter Server > [監視 (Monitor)] タブ > [セッション (Sessions)] でリストされます。

    回避策：すべてのセッションを開始および停止して、アイドル状態の vCenter Server セッションを削除します。

    1. root として vCenter Server に ssh 接続します
    2. プロンプトが表示されたら、shell と入力します
    3. service-control --stop --all を実行します
    4. サービスが Stopped と表示するまで待機します
    5. service-control --start --all を実行します

  • Azure 上のクラスベースのワークロード クラスタの LoadBalancer サービスで、ゲートウェイまたはフロントエンドの手動構成が必要となる

    AzureClusterName と ClusterName の名前が一致しないため、クラスベースの Azure ワークロード クラスタ上のアプリケーションで使用するために展開された LoadBalancer タイプのサービスにインターネットからアクセスできません。

    回避策：NAT ゲートウェイ、プロキシ、またはその他の内部ルーティングなどを介してロード バランサ サービスに独自のルートを指定し、ロード バランサの背後にあるノードがインターネットにアクセスできるようにします。

    VMware は、送信接続に NAT ゲートウェイ（使用可能な場合）を使用することをお勧めします。NAT ゲートウェイを使用できない場合：

    1. Azure ポータルから、CAPZ によって作成された LoadBalancer リソースに移動します。これは、AzureCluster と同じ名前である必要があります。
    2. [フロントエンド IP アドレス (Frontend IP configuration)] を選択し、[追加 (Add)] をクリックします。
    3. ロード バランサ サービスの新しいパブリック IP アドレスを作成します。

    4. 以下の仕様を使用してサービスを構成および作成し、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

  • クラスタをアップグレードしても Kube-VIP のバージョンが更新されない

    スタンドアローン管理クラスタとワークロード クラスタを v2.1 にアップグレードしても、kube-vip が現在のバージョンにアップグレードされません。

    回避策：制御プレーン エンドポイントに Kube-VIP を使用するアップグレードされたクラスタの場合、AVI_CONTROL_PLANE_HA_PROVIDER = false で構成されているように、kube-vip コンポーネントを更新します。

    1. クラスタのアップグレードに使用されている現在の TKr BoM ファイルを取得します。このファイルのローカル コピーを ~/.config/tanzu/tkg/bom/ で探します。ファイル名の先頭は tkr- です。たとえば、tkr-bom-v1.24.10+vmware.1-tkg.1.yaml などです。

    2. 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

    3. クラスタの kcp オブジェクトを取得します。このオブジェクトの名前の形式は CLUSTER-NAME-control-plane です。

      • 管理クラスタ オブジェクトは、tkg-system 名前空間に作成されます。
      • ワークロード クラスタ オブジェクトはクラスタの作成に使用される名前空間内にあります（NAMESPACE が設定されていない場合は default）。

    4. 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 を実行する前に次を行います。

    1. 管理クラスタ コンテキストに切り替えます。

      kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER>

    2. AKO オペレータ シークレットを取得し、そのデータ値をデコードします。

      kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml

    3. テキスト エディタで values.yaml ファイルを開きます。avi_ingress_node_network_list 設定は以下のようになります。

      avi_ingress_node_network_list: '""'

    4. クラスタ ノード ネットワークの範囲を使用して、設定を次のように変更します。

      avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]'

    5. base64 で新しいデータ値をエンコードし、出力文字列を記録します。

      base64 -w 0 values.yaml

    6. AKO オペレータ シークレットを編集します。

      kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system

    7. シークレットの values.yaml の値として、エンコードされた新しいデータ値の文字列に貼り付けます。保存して終了します。

  • TMC は、サービス エンジンが Default-Group SEG にないクラスベースのクラスタを展開できません。

    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 パッチ リリースで解決されたものは、修正されたパッチ リリースの「解決した問題」に記載されています。

アップグレード

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 でのクラスタのアップグレードに失敗する

    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」を回避するためにアップグレード前に特別な処理が必要です。

    回避策：アップグレードするクラスタのタイプに応じて、次の手順を実行します。

    • 管理クラスタ：

      1. 管理クラスタの kubectl コンテキストに切り替えます。

      2. configMap kapp-controller-config を編集します。

        kubectl edit cm kapp-controller-config -n tkg-system

      3. data.noProxy フィールドを見つけ、* を削除してワイルドカード ホスト名を変更します。たとえば、次のように変更します：*.vmware.com to .vmware.com

      4. 保存して終了します。クラスタをアップグレードする準備ができました。

    • ワークロード クラスタ：

      1. ワークロード クラスタの kubectl コンテキストに切り替えます

      2. クラスタ名と名前空間の環境変数を設定します。次に例を示します。

        CLUSTER_NAME=my-test-cluster
NS=my-test-namespace

      3. ワークロード クラスタの 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"

      4. ${CLUSTER_NAME}-${NS}-kapp-controller-data-values ファイルを編集して、その kappController.config.noProxy 設定から * を削除します。たとえば、*.vmware.com to を .vmware.com に変更します。

      5. 保存して終了します。

      6. データ値ファイル ${CLUSTER_NAME}-${NS}-kapp-controller-data-values を再エンコードします。

        cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0

      7. ${CLUSTER_NAME}-${NS}-kapp-controller-data-values シークレットを編集し、新しくエンコードされたデータ値の文字列を貼り付けることで data.value.yaml 設定を更新します。

        kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"

      8. 保存して終了します。クラスタをアップグレードする準備ができました。

  • スタンドアローン管理クラスタのアップグレード直後に古いバージョンの 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.yml
    • external-dns：0.10.0+vmware.1-tkg.3.yml、0.11.0+vmware.1-tkg.3.yml、および 0.12.2+vmware.4-tkg.1.yml
    • grafana: 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.yml
    • external-dns: 0.12.2+vmware.4-tkg.2.yml
    • grafana: 7.5.17+vmware.1-tkg.1.yml

    この問題は、パッケージ構成を変更する必要がある場合にのみ発生します。インストールされたパッケージは、アップグレードせずに引き続き実行されます。

    回避策：次のいずれかの処理を行います。

    • cert-manager、external-dns、または grafana パッケージ構成を更新する必要がある場合は、次の手順を実行します。

      1. tanzu package installed get を実行して、パッケージのバージョンを取得します。
      2. 上記のように、インストール済みのパッケージのバージョンが 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 で解決されています。

  • 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 基本イメージを使用します。

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：CLI 出力列見出しの無関係な文字

    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 サイズのノードを構成します。

  • NSX ALB で同じ名前のクラスタを作成できない

    ワークロード (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) のリソース タギングの問題により、オフライン展開では ResourceTagging API にアクセスできないため、管理クラスタの作成またはアップグレード中に調整エラーが発生します。

    回避策：オフラインの 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 クラスタを削除する前に、ストレージ アカウントのプライベート エンドポイントのネットワーク インターフェイスを手動で削除します。

    1. ブラウザから、Azure Resource Explorer にログインします。
    2. 左側の [サブスクリプション (subscriptions)] をクリックし、サブスクリプションを展開します。
    3. サブスクリプションで、左側の [resourceGroups] を展開し、TKG 環境のリソース グループを展開します。
    4. リソース グループで、[プロバイダ (providers)] > [Microsoft.Network] > [networkinterfaces] を展開します。
    5. networkinterfaces で、削除に失敗している NIC リソースを選択します。
    6. 上部にある [読み取り/書き込み (Read/Write)] ボタンをクリックし、その下にある [アクション(POST、DELETE) (Actions(POST, DELETE))] タブをクリックします。
    7. [削除 (Delete)] をクリックします。
    8. 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 サポートにお問い合わせください。

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