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

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

ワークロードクラスタのトラブルシューティングの詳細については、「ワークロードクラスタの問題のトラブルシューティング」を参照してください。このリリースの既知の問題に対するその他の回避策については、リリースノートまたは 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 状態をクリーンアップするには、以下の手順を実行します。

~/.kube-tkg/config ファイルを開きます。
削除する user オブジェクトに対して、次のコマンドを実行します。
```
kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
```
ここで、USERNAME は、config ファイルにリストされている各トップレベルの user オブジェクトの name プロパティです。
削除する context オブジェクトに対して、次のコマンドを実行します。
```
kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
```
ここで、CONTEXT-NAME は、config ファイルにリストされている各トップレベルの context オブジェクトの name プロパティで、通常は contexts.mycontext-admin@mycontext の形式になります。
削除する cluster オブジェクトに対して、次のコマンドを実行します。
```
kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
```
ここで、CLUSTER-NAME は、config ファイルにリストされている各トップレベルの cluster オブジェクトの name プロパティです。
config ファイルに、現在のコンテキストが削除されたクラスタとして一覧表示されている場合は、コンテキストを設定解除します。
```
kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
```
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 に関する手順を参照してください。

管理クラスタ

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

問題

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

解決方法

ターミナルまたは 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…)」
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 クラスタの削除は失敗します。

解決方法

実行中のすべての kind クラスタを一覧表示し、tkg-kind-unique_ID のようなクラスタを削除します。
```
kind delete cluster --name tkg-kind-unique_ID
```
実行中のすべてのクラスタを一覧表示し、kind クラスタを特定します。
```
docker ps -a
```
kind クラスタのコンテナ ID をコピーして削除します。
```
docker kill container-ID
```

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

問題

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

解決方法

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

管理クラスタのステータスを取得します。例：
```
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
```

前の手順の出力から、停止したマシンの名前を見つけます。停止したマシンは、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

制御プレーンノードのマシン健全性チェックのタイムアウト値を、デフォルトの 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 オブジェクトの作成または更新」を参照してください。
kubectl を管理クラスタのコンテキストに設定します。例：
```
kubectl config use-context mgmt-cluster-admin@mgmt-cluster
```
停止しているマシンを削除します。
```
kubectl delete machine MACHINE-NAME
```
ここで、MACHINE-NAME は、前の手順で特定したマシンの名前です。
KubeadmControlPlane コントローラがマシンを再展開するまで待機します。

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

問題

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

解決方法

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

既存の Tanzu Kubernetes Grid 管理クラスタを特定するために、次のコマンドを実行します。
```
kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
```
コマンド出力には、Tanzu CLI によって作成または追加されたすべての管理クラスタの名前とコンテキストが一覧表示されます。
出力に一覧表示されている各管理クラスタについて、次のコマンドを実行して、~/.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 ファイルを誤って削除した場合には、管理クラスタの制御プレーンノードから認証情報をリカバリできます。

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

各ターゲットプラットフォームで使用する認証情報については、上記の「SSH を使用したクラスタノードへの接続」を参照してください。
管理クラスタの admin.conf ファイルにアクセスします。
```
sudo vi /etc/kubernetes/admin.conf
```
admin.conf ファイルには、クラスタ名、クラスタユーザー名、クラスタコンテキスト、およびクライアント証明書データが含まれています。
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 の展開後ジョブがコンポーネントのアップグレードプロセスと競合する場合に発生する可能性があります。次の手順を実行して、ジョブを削除して再展開します。

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

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

kapp-controller が展開後ジョブを再展開するまで約 5 分間待機します。
Pinniped アプリケーションのステータスを確認します。
```
kubectl get app -n tkg-system pinniped
NAME       DESCRIPTION           SINCE-DEPLOY   AGE
pinniped   Reconcile succeeded   5s             49m
```
DESCRIPTION に Reconciling と表示される場合は、数分待ってから再度確認してください。Reconcile succeeded が表示されたら、次の手順に進みます。

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 バンドルを更新するには、次の手順を実行します。

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

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

ワークロードクラスタの Pinniped アドオンシークレットから values.yaml セクションを取得します。
```
kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
```
このシークレットは管理クラスタにあります。
上記で作成した values.yaml ファイルで、pinniped-info ConfigMap から取得した CA バンドルと一致するように supervisor_ca_bundle_data キーを更新します。また、supervisor_svc_endpoint が issuer エンドポイントと一致することを確認します。

編集した 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

ワークロードクラスタで、Pinniped アプリケーションが変更を正常に調整したことを確認します。
```
kubectl get app pinniped -n tkg-system
```

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

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 に設定されているために発生します。

解決方法

Windows 検索で、regedit と入力してレジストリエディタユーティリティを開きます。
HKEY_CLASSES_ROOT を展開し、.js を選択します。
[コンテンツタイプ (Content Type)] を右クリックして [変更 (Modify)] を選択します。
値を application/javascript に設定し、[OK] をクリックします。
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 以前で作成されたスタンドアローン管理クラスタの場合は、「スタンドアローン管理クラスタのアップグレード」に記載されている追加の手順を実行します。

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

前提条件

一般的なタスク

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

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

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

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

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

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

管理クラスタ

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

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

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

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

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

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

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

Pinniped

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

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

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

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

ポッド

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

Tanzu CLI

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

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

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

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

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

NSX Advanced Load Balancer

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

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

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

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

アップグレード

Azure でのクラスタのアップグレードに失敗する

最初に TKG v1.3 以前で作成されたスタンドアローン管理クラスタのアップグレードが失敗する

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

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

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

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

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

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

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

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

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

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

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

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

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