ワークロード クラスタの問題のトラブルシューティング

このセクションでは、ワークロード クラスタのトラブルシューティングに役立つヒントを示します。

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

一般的なタスク

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

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

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

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

   kubectl config unset users.USER-NAME
   

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

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

   kubectl config unset contexts.CONTEXT-NAME
   

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

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

   kubectl config unset clusters.CLUSTER-NAME
   

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

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

   kubectl config unset current-context
   

パッケージ

デフォルトの YAML ファイルから Grafana をインストールするときにシークレットが作成されない

問題

デフォルトの Grafana 構成ファイルを生成して Grafana のインストールを試みると、インストールが失敗し、「error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest)」というメッセージが表示される。

解決方法

シークレットを手動で作成し、シークレット タグなしで同じ YAML ファイルを使用して Grafana をインストールします。

1. 「ワークロード クラスタへの Grafana の展開」の手順を実行して、Grafana 構成用の構成ファイルを作成します。
2. 生成された構成ファイルから grafana.secret.* エントリを削除します。

3. シークレットを手動で作成します。

   kubectl create secret generic grafana -n tanzu-system-dashboards  --from-literal=admin=admin
   

4. パッケージをデプロイします。

   tanzu package install grafana \
   --package grafana.tanzu.vmware.com \
   --version AVAILABLE-PACKAGE-VERSION \
   --values-file grafana-data-values.yaml \
   --namespace TARGET-NAMESPACE
   

5. 「ワークロード クラスタへの Grafana の展開」の残りの手順を実行します。

tanzu package repository の実行中にエラーが発生しました

問題

tanzu package repository コマンドがエラーで失敗する。

解決方法

kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml​ を実行してエラーの詳細を取得します。

ここで、

• REPOSITORY-NAME はパッケージ リポジトリの名前です。
• NAMESPACE は、パッケージ リポジトリのターゲット名前空間です。

tanzu package repository コマンドが失敗し、次のようなエラーが表示されることがあります。

エラー	説明	解決方法
NOT_FOUND	リポジトリの URL パスが無効です。	パッケージ リポジトリの URL にクラスタからアクセスできることを確認します。
UNKNOWN または UNAUTHORIZED	このエラーは、リポジトリに接続しようとすると発生する可能性があります。
Ownership	同じパッケージ リポジトリ URL を持つリポジトリがすでにクラスタにインストールされています。	次のいずれかの処理を行います。 tanzu package available list -n NAMESPACE を実行して、インストールするパッケージがすでにインストールのために利用可能であるかどうかを確認します。現在失敗したリポジトリの追加を元に戻すには、tanzu package repository delete REPOSITORY-NAME -n NAMESPACE を実行します。 tanzu package repository list -A を実行して、同じ URL を持つ既存のパッケージ リポジトリを取得します。パッケージ リポジトリを取得した場合は、自己責任で削除を続行できます。

tanzu package installed の実行中にエラーが発生しました

問題

tanzu package installed コマンドがエラーで失敗する。

解決方法

kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml​ を実行してエラーの詳細を取得します。

ここで、

• INSTALLED-PACKAGE-NAME はインストール済みパッケージの名前です。
• NAMESPACE は、インストール済みパッケージの名前空間です。

tanzu package installed コマンドが失敗し、次のようなエラーが表示されることがあります。

エラー	説明	解決方法
Ownership	同じ名前のパッケージがすでにクラスタにインストールされています。	tanzu package installed list -A を実行して、インストールするパッケージがすでにインストールされているかどうかを確認します。インストールされている場合は、インストール済みのパッケージを使用するか、そのバージョンを更新するか、パッケージを削除してインストールを続行することができます。
Evaluating starlark template	このエラーは、リストされた構成値がない場合に発生する可能性があります。	tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE –values-schema を実行して、使用可能なすべての構成値を確認し、必要な構成値を tanzu package install コマンドに指定します。
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE	指定したパッケージおよびパッケージ メタデータは、ターゲット名前空間で使用できません。	指定したパッケージが、tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE​ の出力にリストされていることを確認します。リストされていない場合は、パッケージを包含するパッケージ リポジトリをターゲット名前空間に追加します。
Namespace NAMESPACE not found	パッケージをインストールする名前空間が存在しません。	TKG v2.2 では、tanzu package コマンドは kctrl をベースとし、—create-namespace フラグをサポートしないようになりました。パッケージまたはパッケージ リポジトリをインストールする前に、対象の名前空間がすでに存在している必要があります。
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE​	service-account-name フラグで指定されたサービス アカウントは、すでに別のインストール済みパッケージで使用されています。	パッケージ プラグインがサービス アカウントを作成できるようにするか、別のサービス アカウント名を選択します。

ポッド

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 8 リストを参照してください。

ストレージ

デフォルトの StorageClass オブジェクトを変更すると、ワークロード クラスタで調整エラーが発生する

問題

TKG に含まれるデフォルトの StorageClass オブジェクトのプロパティを変更すると、ストレージ クラスを使用するワークロード クラスタでパッケージ調整エラーが発生します。

回避策：

ストレージ クラスをカスタマイズするには、デフォルトのオブジェクト定義を変更するのではなく、別の name を使用して新しい StorageClass 定義を作成し、新しいストレージ クラスを使用するようにクラスタを再構成します。

ワークロード クラスタ

クラスタの展開がタイムアウトするが、クラスタが作成される

問題

tanzu cluster create を実行すると、次のようなタイムアウト エラーで失敗します。

I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]

解決方法

--timeout フラグを使用して、クラスタの作成が完了するまでの待機時間を指定します。デフォルトの待機時間は 30 分です。

tanzu cluster create --timeout TIME

ここで、TIME は、クラスタの作成が完了するまでの待機時間（分単位）です。たとえば、60mです。

ワークロード クラスタが削除で停止する

問題

tanzu cluster delete がワークロード クラスタの削除に失敗します。

クラスタを手動で削除するには、次の 2 つの解決方法があります。

解決方法 1

1. ターゲット クラスタで、avi-system 名前空間で実行されている AKO の StatefulSet オブジェクトを削除します。

   kubectl delete sts ako -n avi-system
   

解決方法 2

1. クラスタにログインし、ワーカー マシンを削除します。

   kubectl delete machine worker1 worker2
   

2. vCenter Server から、ワーカー ノード仮想マシンをパワーオフして削除します。

3. 制御プレーン マシンを編集し、ファイナライザー リンクを削除します。

   finalizers:
    - machine.cluster.x-k8s.io
   

4. 制御プレーン マシンを削除します。

   kubectl delete machine controlplane1 controlplane2
   

5. vCenter Server から、制御プレーン仮想マシンをパワーオフして削除します。

MTU の不一致によってクラスタ ワーカー ノードが NotReady ステータスになる

問題

クラスタ内のワーカー ノードでの異なる最大転送ユニット (MTU) 設定により、TLS ハンドシェイクがタイムアウトになります。

ノードの journalctl -u kubelet からのログに、API サーバとの通信障害が表示されます。kubectl get nodes を実行すると、ワーカー ノードが NotReady ステータスに移行したことが示されます。

この問題を再確認するには、次の手順を実行します。

1. 制御プレーン ノードおよびワーカー ノード マシンで、ip link を実行して eth0 インターフェイスの MTU 値を比較します。これらが一致しない場合は、この問題があることを示しています。
2. クラッシュ診断 (Crashd) を実行し、kubelet ログを確認して、接続がタイムアウトしたか、ワーカー ノードが NotReady ステータスにあるかを確認します。Crashd の実行の詳細については、「クラッシュ診断を使用したワークロード クラスタのトラブルシューティング」を参照してください

3. NotReady ノード ステータスのマシンでは次のコマンドを実行すると失敗することを確認します。

   • openssl s_client -connect IP:PORT

   • curl IP:PORT -k /healthz

   ここで、IP および PORT は Kubernetes API サーバ制御プレーン エンドポイントの IP アドレスとポート番号です。デフォルトでは、PORT は 6443 に設定されます。

解決方法

1. クラスタに展開されている特権デーモンセットを確認し、ホスト OS のネットワーク構成を変更する可能性のあるサードパーティ ベンダーのデーモンセットを確認します。これに関しては、ソフトウェア ベンダーに問い合わせる必要がある可能性があります。ホスト OS を変更できるデーモンセットには、.spec.template.spec.hostNetwork: true があるか、コンテナ セキュリティ コンテキストの機能フィールドに privileged: true または NET_ADMIN があります。

2. 大規模な MTU 設定を構成する場合は、高い MTU 値の制御プレーンでクラスタをプロビジョニングします。

3. クラスタ ネットワークがパス MTU 検出を許可しているか、TCP MSS クランプを設定していて、vCenter Server やコンテナ レジストリなどの外部サービスに対する正しい MTU サイジングが可能であることを確認します。

4. クラスタ内のすべてのノードに対して同じ MTU 設定を構成していることを確認します。

5. ネットワーク ファイアウォール設定で、構成された MTU サイズのパケットを許可する必要があります。

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

問題

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

ソリューション:

クラスタごとに一意の CLUSTER_NAME 値を設定します。同じ CLUSTER_NAME を持ち、NAMESPACE 値で設定される同じ管理クラスタ名前空間に含まれる複数のワークロード クラスタを作成しないでください。

AVS での vSphere CSI ボリュームの削除に失敗することがある

問題

Azure vSphere Solution (AVS) で、vSphere CSI パーシステント ボリューム (PV) の削除に失敗することがあります。PV を削除するには、cns.searchable 権限が必要です。AVS のデフォルトの管理者アカウント <[email protected]> は、この権限で作成されていません。詳細については、「vSphere ロールと権限」を参照してください。

解決方法

AVS 上の vSphere CSI PV を削除するには、Azure サポートにお問い合わせください。