スタンドアローン管理クラスタで Tanzu Kubernetes Grid をアップグレードするには、まずスタンドアローン管理クラスタをアップグレードする必要があります。ワークロード クラスタは、それを管理する管理クラスタをアップグレードするまでアップグレードできません。
vSphere with Tanzu スーパーバイザーで TKG を実行している場合は、この手順を実行しないでください。代わりに、vSphere の一部としてスーパーバイザーをアップグレードし、TKr のアップグレードを通してスーパーバイザーの Kubernetes バージョンを更新します。
重要Tanzu Kubernetes Grid v2.4.x は、AWS および Azure 上の既存のスタンドアローン TKG 管理クラスタのアップグレードをサポートする TKG の最後のバージョンです。AWS および Azure 上のスタンドアローン TKG 管理クラスタをアップグレードする機能は、Tanzu Kubernetes Grid v2.5 リリースで削除される予定です。
VMware では、Tanzu Mission Control を使用してネイティブの AWS EKS クラスタと Azure AKS クラスタを作成することをお勧めします。ただし、AWS および Azure 上の既存のスタンドアローン TKG 管理クラスタのアップグレードは、TKG v2.4.x までのすべての TKG リリースで引き続き完全にサポートされます。
詳細については、『VMware Tanzu Kubernetes Grid v2.4 Release Notes』の「AWS および Azure での TKG 管理クラスタとワークロード クラスタの廃止」を参照してください。
管理クラスタをアップグレードすると、それが実行する自動管理パッケージも自動的にアップグレードされます。
注Tanzu CLI をインストールした後でも、スタンドアローンの管理クラスタがアップグレードされるまでは、コンテキスト固有のすべての CLI コマンド グループ(
tanzu cluster
,tanzu kubernetes-release
)は使用できず、Tanzu CLI--help
の出力にも含まれません。
管理クラスタとワークロード クラスタは、クライアント証明書を使用してクライアントを認証します。これらの証明書は 1 年間有効です。更新するには、クラスタを少なくとも年 1 回アップグレードするか、手動でローテーションします。これは、「クラスタ証明書の更新(スタンドアローン MC)」または VMware ナレッジベースの記事「Tanzu Kubernetes Grid クラスタでの証明書のローテーション方法」で説明されています。
ClusterClass
定義を使用するワークロード クラスタがある場合は、「カスタム クラスタのアップグレード」の手順を完了していること。Tanzu Kubernetes Grid v2.3 以降では、LDAP ID プロバイダを構成するときに LDAP_BIND_DN
変数と LDAP_BIND_PASSWORD
変数を設定する必要があります。LDAP ID プロバイダを使用するように構成された管理クラスタを Tanzu Kubernetes Grid v2.4 にアップグレードする前に、これらの変数をまだ設定していない場合は設定します。LDAP_BIND_DN
と LDAP_BIND_PASSWORD
を設定せずに管理クラスタをアップグレードすると、Pinniped App
の展開に失敗し、App
カスタム リソースがエラーを返します。これらの構成変数の詳細については、「構成ファイル変数リファレンス」の「ID プロバイダ - LDAP」を参照してください。
LDAP_BIND_DN
と LDAP_BIND_PASSWORD
を更新するには、管理クラスタのバージョンに対応する management-cluster
CLI プラグインのバージョンを使用する必要があります。管理クラスタをアップグレードする前に、次の手順を実行します。
管理クラスタの構成ファイルに LDAP_BIND_DN
と LDAP_BIND_PASSWORD
を追加します。
management-cluster
プラグインの正しいバージョンがマシンにインストールされていることを確認します。Tanzu Kubernetes Grid v2.4.0 の場合、正しいバージョンは v0.31.0
です。
tanzu plugin list
management-cluster
プラグインの正しいバージョンがインストールされていない場合は、次の手順を実行します。
使用可能なすべてのバージョンのリストで、管理クラスタのバージョンに対応する management-cluster
プラグインのバージョンを見つけます。
tanzu plugin search -n management-cluster --show-details
プラグインをインストールします。
tanzu plugin install management-cluster --version PLUGIN-VERSION
ここで、PLUGIN-VERSION
は前の手順で確認したバージョンです。
以下を実行して、Pinniped パッケージの新しいシークレットを生成します。
FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run -f YOUR-MANAGEMENT-CLUSTER-CONFIG-FILE.yaml > PINNIPED-PACKAGE-SECRET.yaml
ここで、YOUR-MANAGEMENT-CLUSTER-CONFIG-FILE.yaml
は前の手順で更新した構成ファイルで、PINNIPED-PACKAGE-SECRET.yaml
は Pinniped パッケージの新しいシークレットです。
生成されたシークレットに更新された設定が含まれていることを確認し、kubectl
コンテキストを管理クラスタに設定して、シークレットを適用します。
kubectl apply -f PINNIPED-PACKAGE-SECRET.yaml
tanzu context use
コマンドを実行して、アップグレード可能な管理クラスタのインタラクティブ リストを表示します。
tanzu context use
アップグレードする管理クラスタを選択します。詳細については、「管理クラスタの一覧表示とコンテキストの変更」を参照してください。
クラスタの管理者認証情報を取得します。tanzu CLI エイリアス mc
は、management-cluster
の省略形です。
tanzu mc kubeconfig get --admin
kubectl
を管理クラスタに接続します。
kubectl config use-context MGMT-CLUSTER-NAME-admin@MGMT-CLUSTER-NAME.
前の手順で実行した tanzu mc kubeconfig get --admin
コマンドの出力から、管理クラスタ コンテキストの名前を含む正確なコマンドをコピーできます。
管理クラスタが Azure で実行されている場合は、クラスタをアップグレードする前に AZURE_CLIENT_SECRET
環境変数を設定します。
export AZURE_CLIENT_SECRET=YOUR-AZURE-CLIENT-SECRET
tanzu mc upgrade
コマンドを実行し、y
と入力して確認します。
注このコマンドを実行すると、Pinniped ポッドの再起動が完了するまで、管理者以外のユーザーは、関連付けられたワークロード クラスタにログインできなくなります。
tanzu mc upgrade
IaaS アカウント内の複数のベース仮想マシン イメージに、アップグレード対象と同じバージョンの Kubernetes がある場合は、--os-name
オプションを使用して、必要な OS を指定します。詳細については、「クラスタをアップグレードする際の OS の選択」を参照してください。
たとえば、vSphere で Kubernetes v1.27.5 を持つ Photon OVA テンプレートと Ubuntu OVA テンプレートの両方をアップロードした場合は、--os-name ubuntu
を指定して、Ubuntu 仮想マシンで実行するように管理クラスタをアップグレードします。
tanzu mc upgrade --os-name ubuntu
クラスタをアップグレードするときに確認手順をスキップするには、--yes
オプションを指定します。
tanzu mc upgrade --yes
アップグレード プロセスでは、まず、管理クラスタで実行されている vSphere、Amazon Web Services (AWS)、または Azure のクラスタ API プロバイダがアップグレードされます。次に、管理クラスタのすべての制御プレーン ノードとワーカー ノードの Kubernetes のバージョンがアップグレードされます。
重要管理クラスタのアップグレード中は、管理クラスタまたは管理クラスタが管理するワークロード クラスタに対して、
tanzu cluster
またはtanzu mc
コマンドを実行しないでください(たとえば、別のブートストラップ マシンやシェル ウィンドウから)。
アップグレードが完了する前にタイムアウトした場合は、デフォルトの 30 分よりも大きい値を指定した --timeout
オプションを指定して、tanzu mc upgrade
を再度実行します。
tanzu mc upgrade --timeout 45m0s
注v2.4 CLI をインストールした後でも、スタンドアローンの管理クラスタがアップグレードされるまでは、コンテキスト固有のすべての CLI コマンド グループ(
tanzu cluster
、tanzu kubernetes-release
)、すべてのmanagement-cluster
プラグイン コマンド(tanzu mc upgrade
を除く)、およびtanzu mc create
は使用できず、Tanzu CLI--help
の出力にも含まれません。
アップグレードが完了したら、tanzu cluster list
コマンドを --include-management-cluster -A
オプションと一緒に再度実行して、管理クラスタがアップグレードされていることを確認します。
tanzu cluster list --include-management-cluster -A
管理クラスタで新しいバージョンの Kubernetes が実行されているが、ワークロード クラスタでは引き続き以前のバージョンの Kubernetes が実行されていることがわかります。
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLA TKR
k8s-1-25-10-cluster default running 1/1 1/1 v1.25.10+vmware.1 <none> dev v1.25.10---vmware.1-tkg.1
k8s-1-26-5-cluster default running 1/1 1/1 v1.26.5+vmware.1 <none> dev v1.26.5---vmware.1-tkg.1
mgmt-cluster tkg-system running 1/1 1/1 v1.27.5+vmware.1 management dev v1.27.5---vmware.2-tkg.1
管理者の kubeconfig
を再生成します。
tanzu management-cluster kubeconfig get --admin
次に示すのは、コマンドのサンプル出力です。
Credentials of cluster 'mgmt' have been saved
You can now access the cluster by running 'kubectl config use-context mgmt-admin@mgmt'
重要アップグレード後に
kubeconfig
を更新しない場合、有効期限が切れるとクラスタにアクセスできなくなります。
次の作業を実行できます。
この管理クラスタが管理するワークロード クラスタをアップグレードします。
新しいワークロード クラスタを作成します。デフォルトでは、この管理クラスタを使用して展開する新しいクラスタでは、Kubernetes の新しいデフォルト バージョンが実行されます。ただし、必要に応じて、tanzu cluster create
コマンドと --tkr
オプションを使用して、異なるバージョンの Kubernetes を実行する新しいクラスタを展開できます。詳細については、「複数の Kubernetes バージョン」を参照してください。