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

このセクションでは、ワークロード クラスタのトラブルシューティングに役立つヒントを示します。スタンドアローン管理クラスタの展開のトラブルシューティングの詳細については、「管理クラスタの問題のトラブルシューティング」を参照してください。

一般的なタスク

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

ワークロード クラスタ

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

問題

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 アドレスとポート番号です。デフォルトでは、PORT6443 に設定されます。

解決方法

  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 サイズのパケットを許可する必要があります。

check-circle-line exclamation-circle-line close-line
Scroll to top icon