ワークロード クラスタの問題のトラブルシューティング
このセクションでは、ワークロード クラスタのトラブルシューティングに役立つヒントを示します。
スタンドアローン管理クラスタの展開のトラブルシューティングの詳細については、「管理クラスタの問題のトラブルシューティング」を参照してください。このリリースの既知の問題に対するその他の回避策については、リリース ノートまたは VMware ナレッジベースの記事を参照してください。
一般的なタスク
kubectl を使用したユーザー、コンテキスト、およびクラスタの削除
ユーザー、コンテキスト、およびクラスタの一部またはすべてを削除して kubectl 状態をクリーンアップするには、以下の手順を実行します。
-
~/.kube/configファイルを開きます。 -
削除する
userオブジェクトに対して、次のコマンドを実行します。kubectl config unset users.USER-NAMEここで、
USER-NAMEは、configファイルにリストされている各トップレベルのuserオブジェクトのnameプロパティです。 -
削除する
contextオブジェクトに対して、次のコマンドを実行します。kubectl config unset contexts.CONTEXT-NAMEここで、
CONTEXT-NAMEは、configファイルにリストされている各トップレベルのcontextオブジェクトのnameプロパティで、通常はcontexts.mycontext-admin@mycontextの形式になります。 -
削除する
clusterオブジェクトに対して、次のコマンドを実行します。kubectl config unset clusters.CLUSTER-NAMEここで、
CLUSTER-NAMEは、configファイルにリストされている各トップレベルのclusterオブジェクトのnameプロパティです。 -
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 をインストールします。
- 「ワークロード クラスタへの Grafana の展開」の手順を実行して、Grafana 構成用の構成ファイルを作成します。
- 生成された構成ファイルから
grafana.secret.*エントリを削除します。 -
シークレットを手動で作成します。
kubectl create secret generic grafana -n tanzu-system-dashboards --from-literal=admin=admin -
パッケージをデプロイします。
tanzu package install grafana \ --package grafana.tanzu.vmware.com \ --version AVAILABLE-PACKAGE-VERSION \ --values-file grafana-data-values.yaml \ --namespace TARGET-NAMESPACE - 「ワークロード クラスタへの 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 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.1 以降では、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
-
ターゲット クラスタで、
avi-system名前空間で実行されている AKO の StatefulSet オブジェクトを削除します。kubectl delete sts ako -n avi-system
解決方法 2
-
クラスタにログインし、ワーカー マシンを削除します。
kubectl delete machine worker1 worker2 -
vCenter Server から、ワーカー ノード仮想マシンをパワーオフして削除します。
-
制御プレーン マシンを編集し、ファイナライザー リンクを削除します。
finalizers: - machine.cluster.x-k8s.io -
制御プレーン マシンを削除します。
kubectl delete machine controlplane1 controlplane2 -
vCenter Server から、制御プレーン仮想マシンをパワーオフして削除します。
MTU の不一致によってクラスタ ワーカー ノードが NotReady ステータスになる
問題
クラスタ内のワーカー ノードでの異なる最大転送ユニット (MTU) 設定により、TLS ハンドシェイクがタイムアウトになります。
ノードの journalctl -u kubelet からのログに、API サーバとの通信障害が表示されます。kubectl get nodes を実行すると、ワーカー ノードが NotReady ステータスに移行したことが示されます。
この問題を再確認するには、次の手順を実行します。
- 制御プレーン ノードおよびワーカー ノード マシンで、
ip linkを実行してeth0インターフェイスの MTU 値を比較します。これらが一致しない場合は、この問題があることを示しています。 - クラッシュ診断 (Crashd) を実行し、kubelet ログを確認して、接続がタイムアウトしたか、ワーカー ノードが NotReady ステータスにあるかを確認します。Crashd の実行の詳細については、「クラッシュ診断を使用したワークロード クラスタのトラブルシューティング」を参照してください
-
NotReady ノード ステータスのマシンでは次のコマンドを実行すると失敗することを確認します。
-
openssl s_client -connect IP:PORT -
curl IP:PORT -k /healthz
ここで、
IPおよびPORTは Kubernetes API サーバ制御プレーン エンドポイントの IP アドレスとポート番号です。デフォルトでは、PORTは6443に設定されます。 -
解決方法
-
クラスタに展開されている特権デーモンセットを確認し、ホスト OS のネットワーク構成を変更する可能性のあるサードパーティ ベンダーのデーモンセットを確認します。これに関しては、ソフトウェア ベンダーに問い合わせる必要がある可能性があります。ホスト OS を変更できるデーモンセットには、
.spec.template.spec.hostNetwork: trueがあるか、コンテナ セキュリティ コンテキストの機能フィールドにprivileged: trueまたはNET_ADMINがあります。 -
大規模な MTU 設定を構成する場合は、高い MTU 値の制御プレーンでクラスタをプロビジョニングします。
-
クラスタ ネットワークがパス MTU 検出を許可しているか、TCP MSS クランプを設定していて、vCenter Server やコンテナ レジストリなどの外部サービスに対する正しい MTU サイジングが可能であることを確認します。
-
クラスタ内のすべてのノードに対して同じ MTU 設定を構成していることを確認します。
-
ネットワーク ファイアウォール設定で、構成された 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 サポートにお問い合わせください。
クラスタが 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-proider-aws/cluster/CLUSTER-NAME、value: ownedを持つ、Tanzu によって管理されるロード バランサまたはセキュリティ グループを削除しないでください。
ストレージ ボリュームがプライベート エンドポイントを持つアカウントを使用すると、クラスタの削除に失敗する
問題
管理されていないリソース グループ内の 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 クラスタを削除する前に、ストレージ アカウントのプライベート エンドポイントのネットワーク インターフェイスを手動で削除します。
- ブラウザから、Azure Resource Explorer にログインします。
- 左側の [サブスクリプション (subscriptions)] をクリックし、サブスクリプションを展開します。
- サブスクリプションで、左側の [resourceGroups] を展開し、TKG 環境のリソース グループを展開します。
- リソース グループで、[プロバイダ (providers)] > [Microsoft.Network] > [networkinterfaces] を展開します。
networkinterfacesで、削除に失敗している NIC リソースを選択します。- 上部にある [読み取り/書き込み (Read/Write)] ボタンをクリックし、その下にある [アクション(POST、DELETE) (Actions(POST, DELETE))] タブをクリックします。
- [削除 (Delete)] をクリックします。
- NIC が削除されたら、Azure クラスタを削除します。
