管理クラスタの問題のトラブルシューティング

このトピックでは、スタンドアローン管理クラスタの展開のトラブルシューティングに役立つヒントを説明します。

ワークロード クラスタのトラブルシューティングの詳細については、「ワークロード クラスタの問題のトラブルシューティング」を参照してください。このリリースの既知の問題に対するその他の回避策については、リリース ノートまたは VMware ナレッジベースの記事を参照してください。

前提条件

以下の手順の一部では、kind CLI を使用します。kind をインストールするには、kind ドキュメントの「Installation」を参照してください。

一般的なタスク

SSH を使用したクラスタ ノードへの接続

SSH を使用して、スタンドアローン管理クラスタまたはワークロード クラスタの個々のノードに接続できます。これを行うには、管理クラスタを展開したときに作成した SSH キー ペアが、SSH コマンドを実行するマシンで使用可能である必要があります。このため、tanzu コマンドを実行するマシンで ssh コマンドを実行する必要があります。

管理クラスタに登録し、管理クラスタから展開するすべてのワークロード クラスタで使用される SSH キーは、次のユーザー アカウントに関連付けられます。

• Photon OS と Ubuntu の両方で実行されている vSphere 管理クラスタと Tanzu Kubernetes ノード：capv
• AWS Bastion ノード：ubuntu
• Ubuntu で実行されている AWS 管理クラスタと Tanzu Kubernetes ノード：ubuntu
• Amazon Linux で実行されている AWS 管理クラスタと Tanzu Kubernetes ノード：ec2-user
• Azure 管理クラスタと Tanzu Kubernetes ノード（常に Ubuntu）：capi

SSH を使用してノードに接続するには、ブートストラップ マシンとして使用するマシンから次のいずれかのコマンドを実行します。

• vSphere ノード：ssh capv@node-address
• Ubuntu 上の AWS Bastion ノード、管理クラスタ、およびワークロード ノード：ssh ubuntu@node-address
• Amazon Linux で実行されている AWS 管理クラスタと Tanzu Kubernetes ノード：ssh ec2-user@node-address
• Azure ノード：ssh capi@node-address

SSH キーは、ssh コマンドを実行しているシステムに存在するため、パスワードは不要です。

kubectl を使用したユーザー、コンテキスト、およびクラスタの削除

ユーザー、コンテキスト、およびクラスタの一部またはすべてを削除して kubectl 状態をクリーンアップするには、以下の手順を実行します。

1. ~/.kube-tkg/config ファイルを開きます。

2. 削除する user オブジェクトに対して、次のコマンドを実行します。

   kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
   

   ここで、USERNAME は、config ファイルにリストされている各トップレベルの user オブジェクトの name プロパティです。

3. 削除する context オブジェクトに対して、次のコマンドを実行します。

   kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
   

   ここで、CONTEXT-NAME は、config ファイルにリストされている各トップレベルの context オブジェクトの name プロパティで、通常は contexts.mycontext-admin@mycontext の形式になります。

4. 削除する cluster オブジェクトに対して、次のコマンドを実行します。

   kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
   

   ここで、CLUSTER-NAME は、config ファイルにリストされている各トップレベルの cluster オブジェクトの name プロパティです。

5. config ファイルに、現在のコンテキストが削除されたクラスタとして一覧表示されている場合は、コンテキストを設定解除します。

   kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
   

6. tanzu CLI によって追跡されている管理クラスタを削除した場合は、「Tanzu CLI 構成からの管理クラスタの削除」の記載どおりに tanzu config server delete を実行して、それらの管理クラスタを tanzu CLI の状態から削除します。

Photon OS ノードでの nfs-utils の無効化

問題

Tanzu Kubernetes Grid v1.1.2 以降では、nfs-utils はデフォルトで有効になっています。nfs-utils が不要な場合は、クラスタ ノード仮想マシンから削除できます。

解決方法

Tanzu Kubernetes Grid v1.1.2 以降を使用して展開するクラスタで nfs-utils を無効にするには、SSH を使用してクラスタ ノード仮想マシンにログインし、次のコマンドを実行します。

tdnf erase nfs-utils

ターゲット プラットフォーム

AWS での検証失敗、認証情報エラー

問題

tanzu management-cluster create または tanzu mc create を実行すると、次のようなエラーが表示されて失敗します。

Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain

Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request

解決方法

Tanzu Kubernetes Grid は、デフォルトの AWS 認証情報プロバイダ チェーンを使用します。AWS で管理クラスタまたはワークロード クラスタを作成する前に、「AWS の認証情報の構成」の記載どおりに、AWS アカウントの認証情報を構成する必要があります。

Azure での検証失敗、法的条件に関するエラー

問題

Azure でスタンドアローン管理クラスタまたはワークロード クラスタを作成する前に、クラスタ ノードで使用される仮想マシン イメージに適用される法的条件に同意する必要があります。このライセンスに同意せずに tanzu mc create または tanzu cluster create を実行すると、次のようなエラーで失敗します。

User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.

解決方法

この問題が発生した場合は、法的条件に同意して再試行してください。

• 管理クラスタ：「基本イメージ ライセンスの同意」を参照してください
• ワークロード クラスタ：「デフォルト以外の Kubernetes バージョンを使用したクラスタの展開」の Azure に関する手順を参照してください。

管理クラスタ

管理クラスタの展開に失敗した後のクリーンアップ

問題

スタンドアローン管理クラスタの展開に失敗すると、クラウド インフラストラクチャとブートストラップ マシンに孤立したオブジェクトが残ります。

解決方法

1. ターミナルまたは Tanzu Kubernetes Grid インストーラ インターフェイスで tanzu mc create コマンド出力を監視します。コマンドが失敗すると、次のようなヘルプ メッセージが出力されます。「管理クラスタの展開中のエラー...管理クラスタによって作成されたリソースをクリーンアップするには: tkg delete mc... (Failure while deploying management cluster… To clean up the resources created by the management cluster: tkg delete mc…)」
2. tanzu mc delete YOUR-CLUSTER-NAME を実行します。このコマンドは、インフラストラクチャおよびローカルで作成されたオブジェクトを削除します。

次に示す代替方法を使用することもできます。

• ブートストラップ マシンのクリーンアップ：

  • kind クラスタを削除するには、kind CLI を使用します。例：

    kind get clusters
    kind delete cluster --name tkg-kind-example1234567abcdef
    

  • Docker オブジェクトを削除するには、docker CLI を使用します。たとえば、docker rm、docker rmi、docker system prune -a --volumes などです。

    注意

    システムで Tanzu Kubernetes Grid に関連しない Docker プロセスを実行している場合は、不要な Docker オブジェクトを個別に削除します。

• ターゲット プラットフォームのクリーンアップ：

  • vSphere：Tanzu Kubernetes Grid によって作成された仮想マシンおよびその他のリソースを見つけてパワーオフし、削除します。
  • AWS：Amazon EC2 ダッシュボードにログインし、リソースを手動で削除するか、自動化されたソリューションを使用します。
  • Azure：[リソース グループ (Resource Groups)] で、AZURE_RESOURCE_GROUP を開きます。チェックボックスを使用して、名前にタイムスタンプを含んでいる、Tanzu Kubernetes Grid によって作成されたリソースを選択して削除します。

AWS 上の管理クラスタを削除できない

問題

AWS で tanzu mc delete を実行した後、tanzu mc get およびその他の Tanzu CLI コマンドで削除済みの管理クラスタが一覧表示されなくなります。ただし以下のようになります。

• クラスタが AWS インフラストラクチャから削除されず、そのノードが Amazon EC2 ダッシュボードに表示されたままになる
• 管理クラスタのログに、「cluster infrastructure is still being provisioned: VpcReconciliationFailed」というエラーが表示される。

解決方法

この動作は、TKG が期限切れまたは無効な AWS アカウント認証情報を使用すると発生します。この状況を防止またはリカバリするには、次の手順を実行します。

• 防止: AWS 認証情報プロファイルまたはローカルの静的な環境変数を使用して、「 AWS アカウントの認証情報の構成」の説明に従って AWS アカウントの認証情報を更新します。

  • AWS インスタンス プロファイルの認証情報を使用して管理クラスタを削除することはできません。

• EC2 ダッシュボードを使用したリカバリ：EC2 ダッシュボードから管理クラスタ ノードを手動で削除します。

• CLI を使用したリカバリ：

  1. 管理クラスタの削除に失敗したためにブートストラップ マシンに残っている kind クラスタで、AWS 認証情報シークレットを修正します。

     kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
     

  2. シークレットを編集して、AWS 認証情報を含めます。

     [default]
     aws_access_key_id = <key id>
     aws_secret_access_key = <access_key>
     region = <region>
     

  3. tanzu mc delete を再度実行します。

管理クラスタの削除後も kind クラスタが残る

問題

tanzu mc delete を実行すると、管理クラスタは削除されますが、ブートストラップ マシンからのローカル kind クラスタの削除は失敗します。

解決方法

1. 実行中のすべての kind クラスタを一覧表示し、tkg-kind-unique_ID のようなクラスタを削除します。

   kind delete cluster --name tkg-kind-unique_ID
   

2. 実行中のすべてのクラスタを一覧表示し、kind クラスタを特定します。

   docker ps -a
   

3. kind クラスタのコンテナ ID をコピーして削除します。

   docker kill container-ID
   

管理クラスタの展開に失敗した後にマシンが停止する

問題

マシンが停止し、修正を待機しているため、スタンドアローン管理クラスタの展開に失敗します。

解決方法

制御プレーン ノードが 1 台しかない dev プランを使用して展開した管理クラスタの場合は、管理クラスタを再展開する必要があります。複数の制御プレーン ノードがある管理クラスタの場合は、停止したマシンを特定して削除できます。

1. 管理クラスタのステータスを取得します。例：

   kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
   

2. 前の手順の出力から、停止したマシンの名前を見つけます。停止したマシンは、WaitingForRemediation としてマークされます。たとえば、次の出力では、停止したマシンの名前は my-mgmt-cluster-zpc7t です。

   status:
     conditions:
     - lastTransitionTime: "2021-08-25T15:44:23Z"
       message: KCP can't remediate if current replicas are less or equal then 1
       reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
       severity: Warning
       status: "False"
       type: Ready
   

3. 制御プレーン ノードのマシン健全性チェックのタイムアウト値を、デフォルトの 5m よりも大きくします。例：

   tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
   

   MachineHealthCheck オブジェクトの更新の詳細については、「ワークロード クラスタのマシンの健全性チェックの構成」の「MachineHealthCheck オブジェクトの作成または更新」を参照してください。

4. kubectl を管理クラスタのコンテキストに設定します。例：

   kubectl config use-context mgmt-cluster-admin@mgmt-cluster
   

5. 停止しているマシンを削除します。

   kubectl delete machine MACHINE-NAME
   

   ここで、MACHINE-NAME は、前の手順で特定したマシンの名前です。

6. KubeadmControlPlane コントローラがマシンを再展開するまで待機します。

~/.config/tanzu ディレクトリのリストア

問題

ブートストラップ マシンの ~/.config/tanzu ディレクトリが誤って削除されているか、破損しています。Tanzu CLI は、このディレクトリを作成して使用します。このディレクトリがないと機能しません。

解決方法

~/.config/tanzu ディレクトリの内容をリストアするには、次の手順を実行します。

1. 既存の Tanzu Kubernetes Grid 管理クラスタを特定するために、次のコマンドを実行します。

   kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
   

   コマンド出力には、Tanzu CLI によって作成または追加されたすべての管理クラスタの名前とコンテキストが一覧表示されます。

2. 出力に一覧表示されている各管理クラスタについて、次のコマンドを実行して、~/.config/tanzu ディレクトリおよび CLI にリストアします。

   tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
   

tanzu management-cluster create を macOS で実行すると kubectl バージョン エラーが発生する

問題

tanzu management-cluster create または tanzu mc create コマンドを最新の安定したバージョンの Docker デスクトップを備えた macOS で実行すると、次のようなエラー メッセージが表示されて失敗します。

Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.25.7

これは、Docker デスクトップが古いバージョンの kubectl をパスにシンボリック リンクするために発生します。

解決方法

サポートされている新しいバージョンの kubectl を、パス内の Docker のバージョンより前に配置します。

管理クラスタの認証情報のリカバリ

スタンドアローン管理クラスタの認証情報を紛失した場合、たとえば tanzu コマンドを実行するシステムで .kube-tkg/config ファイルを誤って削除した場合には、管理クラスタの制御プレーン ノードから認証情報をリカバリできます。

1. tanzu mc create を実行して、.kube-tkg/config ファイルを再作成します。
2. vSphere、AWS、または Azure から、管理クラスタの制御プレーン ノードのパブリック IP アドレスを取得します。

3. SSH を使用して管理クラスタの制御プレーン ノードにログインします。

   各ターゲット プラットフォームで使用する認証情報については、上記の「SSH を使用したクラスタ ノードへの接続」を参照してください。

4. 管理クラスタの admin.conf ファイルにアクセスします。

   sudo vi /etc/kubernetes/admin.conf
   

   admin.conf ファイルには、クラスタ名、クラスタ ユーザー名、クラスタ コンテキスト、およびクライアント証明書データが含まれています。

5. tanzu コマンドを実行するシステムの .kube-tkg/config ファイルに、クラスタ名、クラスタ ユーザー名、クラスタ コンテキスト、およびクライアント証明書データをコピーします。

Pinniped

既存の環境に外部 ID 管理を追加するために、ダミーの VSPHERE_CONTROL_PLANE_ENDPOINT 値の設定が必要になる場合がある

問題

外部 ID プロバイダを既存の TKG 環境と統合するには、「管理クラスタの Pinniped アドオン シークレットの生成」で説明されているように、アドオン シークレットの作成に使用される管理クラスタ構成ファイルにダミーの VSPHERE_CONTROL_PLANE_ENDPOINT 値を設定する必要がある場合があります。

Pinniped を無効化する場合は、レガシー クラスタで手動で Secret を削除する必要がある

問題

管理クラスタで外部 ID 管理を無効にすると、未使用の Pinniped Secret オブジェクトがレガシー ワークロード クラスタに残ります。

ユーザーが古い kubeconfig を使用してクラスタにアクセスしようとすると、ログイン ポップアップが表示されて失敗します。

回避策

「ID 管理の無効化」の説明に従って、レガシー クラスタの Pinniped Secret を手動で削除します。

展開後の Pinniped ジョブが失敗する

問題

Tanzu Kubernetes Grid v2.2 にアップグレードすると、次のようなエラーが返されます。

 Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again

解決方法

このエラーは、Pinniped の展開後ジョブがコンポーネントのアップグレード プロセスと競合する場合に発生する可能性があります。次の手順を実行して、ジョブを削除して再展開します。

1. Pinniped の展開後ジョブを削除します。

   kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
   

2. kapp-controller が展開後ジョブを再展開するまで約 5 分間待機します。

3. Pinniped アプリケーションのステータスを確認します。

   kubectl get app -n tkg-system pinniped
   NAME       DESCRIPTION           SINCE-DEPLOY   AGE
   pinniped   Reconcile succeeded   5s             49m
   

   DESCRIPTION に Reconciling と表示される場合は、数分待ってから再度確認してください。Reconcile succeeded が表示されたら、次の手順に進みます。

4. Pinniped の展開後ジョブのステータスを確認します。

   kubectl get jobs -n pinniped-supervisor
   NAME                             COMPLETIONS   DURATION   AGE
   pinniped-post-deploy-job-ver-1   1/1           9s         62s
   

管理クラスタのアップグレード後にワークロード クラスタで Pinniped 認証エラーが発生する

問題

管理クラスタを最近アップグレードしました。この管理クラスタに関連付けられているワークロード クラスタへの認証を試みると、次のようなエラー メッセージが表示されます。

Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority

解決方法

これは、ワークロード クラスタが使用している Pinniped スーパーバイザー CA バンドルのコピーが古いために発生します。スーパーバイザー CA バンドルを更新するには、次の手順を実行します。

1. kubectl コンテキストを管理クラスタに設定します。

2. base64 でエンコードされた CA バンドルと issuer エンドポイントを pinniped-info ConfigMap から取得します。

   kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
   

3. ワークロード クラスタの Pinniped アドオン シークレットから values.yaml セクションを取得します。

   kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
   

   このシークレットは管理クラスタにあります。

4. 上記で作成した values.yaml ファイルで、pinniped-info ConfigMap から取得した CA バンドルと一致するように supervisor_ca_bundle_data キーを更新します。また、supervisor_svc_endpoint が issuer エンドポイントと一致することを確認します。

5. 編集した values.yaml ファイルを base64 でエンコードし、それをワークロード クラスタ シークレット内で置き換えて更新を適用します。このコマンドは、環境の OS によって異なります。例：

   Linux：

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
   

   macOS：

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
   

6. ワークロード クラスタで、Pinniped アプリケーションが変更を正常に調整したことを確認します。

   kubectl get app pinniped -n tkg-system
   

7. クラスタに対して認証します。例：

   kubectl get pods -A --kubeconfig my-cluster-credentials
   

ポッド

vCenter Server の接続により、クラスタでポッドが保留中のまま停止する

問題

作成されたクラスタで kubectl get pods -A を実行すると、一部のポッドが保留状態のままになります。

影響を受けるポッドで kubectl describe pod -n pod-namespace pod-name を実行すると、次のイベントが表示されます。

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

解決方法

クラスタと vCenter Server 間の通信を確実に行うために、接続ルールとファイアウォール ルールが指定されていることを確認します。ファイアウォール ポートとプロトコルの要件については、「VMware Ports and Protocols」の vSphere リストを参照してください。

Tanzu CLI

Tanzu CLI が管理クラスタにアクセスできない

問題

tanzu CLI コマンドを実行すると、次のようなエラーが返されます。

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

解決方法

「Tanzu CLI 構成での管理クラスタ証明書の更新」および「Tanzu Kubernetes Grid の tkg/tanzu CLI コマンドを使用してクラスタにアクセスできない」を参照してください。

Windows CMD：CLI 出力列見出しの無関係な文字

問題

Windows コマンド プロンプト (CMD) で、列でフォーマットされた Tanzu CLI コマンド出力の列見出しに無関係な文字が含まれています。この問題は、Windows ターミナルまたは PowerShell では発生しません。

解決方法

Windows ブートストラップ マシンで、Windows ターミナルから Tanzu CLI を実行します。

MHC が無効な場合、CLI が最近削除されたノードのステータスを一時的に誤って報告する

問題

マシンの健全性チェック (MHC) が無効になっている場合、tanzu cluster status などの Tanzu CLI コマンドは、インフラストラクチャの再作成中に最新のノード状態を報告しない場合があります。

解決方法

なし。

Tanzu Kubernetes Grid インストーラ インターフェイス

Tanzu Kubernetes Grid インストーラ インターフェイスが Windows で正しく表示されない

問題

tanzu management-cluster create --ui または tanzu mc create --ui コマンドを Windows システムで実行すると、ユーザー インターフェイスはデフォルトのブラウザで開きますが、グラフィックとスタイルは適用されません。これは、Windows レジストリが application/x-css に設定されているために発生します。

解決方法

1. Windows 検索で、regedit と入力してレジストリ エディタ ユーティリティを開きます。
2. HKEY_CLASSES_ROOT を展開し、.js を選択します。
3. [コンテンツ タイプ (Content Type)] を右クリックして [変更 (Modify)] を選択します。
4. 値を application/javascript に設定し、[OK] をクリックします。
5. tanzu mc create --ui コマンドをもう一度実行して、ユーザー インターフェイスを再起動します。

NSX Advanced Load Balancer

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

問題

ワークロード (AVI_ENABLE) または制御プレーン (AVI_CONTROL_PLANE_HA_PROVIDER) に NSX Advanced Load Balancer を使用している場合、Avi Controller は同じ名前のクラスタを区別できないことがあります。

ソリューション:

クラスタごとに一意の CLUSTER_NAME 値を設定します。異なるブートストラップ マシンであっても、同じ CLUSTER_NAME 値を持つ複数の管理クラスタを作成しないでください。

NSX Advanced Load Balancer 仮想 IP アドレスに対する要求が「ホストへのルートがありません (no route to host)」というメッセージが表示されて失敗する

問題

LoadBalancer タイプのサービスの合計数が大きく、すべてのサービス エンジンが同じ L2 ネットワークに展開されている場合、NSX Advanced Load Balancer 仮想 IP アドレスへの要求が失敗し、no route to host というメッセージが表示されることがあります。

これは、サービス エンジンのデフォルトの ARP レート制限が 100 であるために発生します。

解決方法

ARP レート制限を大きな数値に設定します。このパラメータは、NSX Advanced Load Balancer Essentials では調整可能ではありませんが、NSX Advanced Load Balancer Enterprise Edition では調整可能です。

管理クラスタの作成中に無視可能な AKODeploymentConfig エラーが発生する

問題

tanzu management-cluster create を実行して、NSX ALB を使用して管理クラスタを作成すると、エラー「no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???」が出力されます。

解決方法

このエラーは無視してかまいません。詳細については、こちらのナレッジベースの記事を参照してください。

Multus CNI が NSX Advanced Load Balancer を備えた medium および小規模なポッドで失敗する

問題

vSphere では、NSX ALB を備えた Multus CNI パッケージを実行する medium または小規模なワーカー ノードを持つワークロード クラスタが、Insufficient CPU またはその他のエラーで失敗することがあります。

解決方法

NSX ALB を備えた Multus CNI を使用するには、サイズが large または extra-large のワーカー ノードを持つワークロード クラスタを展開します。

アップグレード

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.2 では、汎用クラスタを TKG スタンドアローン管理クラスタに変換するコンポーネントは、Carvel パッケージ tkg-pkg にパッケージ化されています。最初に TKG v1.3 以前で作成されたスタンドアローン管理クラスタには、tkg-pkg をインストールするためにアップグレード プロセスで必要な構成シークレットがないため、アップグレードが失敗します。

解決方法

TKG v1.3 以前で作成されたスタンドアローン管理クラスタの場合は、「スタンドアローン管理クラスタのアップグレード」に記載されている追加の手順を実行します。