クラスタのインストールやアップグレードに関する問題のトラブルシューティング

このページでは、GKE on Bare Metal クラスタのインストールまたはアップグレードで問題が発生した場合のトラブルシューティング情報について説明します。

ブートストラップ クラスタの問題

GKE on Bare Metal は、セルフマネージド（管理、ハイブリッド、スタンドアロン）クラスタを作成すると、Docker の Kubernetes（kind）クラスタをデプロイして、クラスタの作成に必要な Kubernetes コントローラを一時的にホストします。この一時的なクラスタは、ブートストラップ クラスタと呼ばれます。ユーザー クラスタは、ブートストラップ クラスタを使用せずに管理クラスタまたはハイブリッド クラスタを管理することによって作成およびアップグレードされます。

インストール時、デプロイに kind クラスタがすでに存在する場合、GKE on Bare Metal は既存の kind クラスタを削除します。削除は、インストールまたはアップグレードが成功した場合にのみ行われます。成功後も既存の kind クラスタを保持するには、bmctl の --keep-bootstrap-cluster フラグを使用します。

GKE on Bare Metal は、ブートストラップ クラスタの構成ファイルを WORKSPACE_DIR/.kindkubeconfig の下に作成します。ブートストラップ クラスタへの接続は、クラスタの作成とアップグレード中のみ可能です。

ブートストラップ クラスタは、イメージを pull するために Docker リポジトリにアクセスする必要があります。非公開レジストリを使用しない場合は、レジストリがデフォルトで Container Registry に設定されます。クラスタの作成中、bmctl が次のファイルを作成します。

  • bmctl-workspace/config.json: レジストリ アクセス用の Google Cloud サービス アカウントの認証情報が含まれます。この認証情報は、クラスタ構成ファイルの gcrKeyPath フィールドから取得されます。

  • bmctl-workspace/config.toml: kind クラスタ内の containerd 構成が含まれます。

ブートストラップ クラスタのデバッグ

ブートストラップ クラスタをデバッグするには、次の手順に沿って行います。

  • クラスタの作成やアップグレード中に、ブートストラップ クラスタに接続します。
  • ブートストラップ クラスタのログを取得します。

bmctl の実行に使用するマシンのログは、次のフォルダにあります。

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

CLUSTER_NAME と TIMESTAMP は、クラスタの名前と対応するシステムの時刻に置き換えます。

ブートストラップ クラスタから直接ログを取得するには、クラスタの作成やアップグレード中に次のコマンドを実行します。

docker exec -it bmctl-control-plane bash

このコマンドにより、ブートストラップ クラスタで実行される bmctl コントロール プレーン コンテナ内のターミナルが開かれます。

kubelet ログと containerd ログを検査するには、次のコマンドを使用して、出力でエラーや警告を探します。

journalctl -u kubelet
journalctl -u containerd

クラスタ アップグレードの問題

GDCV for Bare Metal をアップグレードすると、進行状況をモニタリングし、クラスタとノードのステータスを確認できます。

  • アップグレード中に問題が発生した場合は、障害が発生したステージを特定してみてください。アップグレード プロセス中のクラスタへの影響について詳しくは、クラスタ アップグレードのライフサイクルとステージをご覧ください。
  • クラスタ アップグレード中の問題による影響の詳細については、GDCV for Bare Metal の障害の影響を理解するをご覧ください。

次のガイダンスは、アップグレードが正常に行われているか、問題が発生しているかを判断する際にご活用いただけます。

アップグレードの進行状況をモニタリングする

アップグレード プロセス中のクラスタのステータスを表示するには、kubectl describe cluster コマンドを使用します。

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

次の値を置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • CLUSTER_NAMESPACE: クラスタの名前空間。
  • ADMIN_KUBECONFIG: 管理 kubeconfig ファイル。
    • デフォルトでは、管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタは、インプレース アップグレードを使用します。bmctl upgrade コマンドで --use-bootstrap=true フラグを使用すると、アップグレード オペレーションでブートストラップ クラスタが使用されます。ブートストラップ クラスタの使用時にアップグレードの進行状況をモニタリングするには、ブートストラップ クラスタの kubeconfig ファイル .kindkubeconfig へのパスを指定します。このファイルはワークスペース ディレクトリにあります。

出力の Status セクションを確認します。ここには、クラスタのアップグレード ステータスの集計が表示されます。クラスタがエラーを報告した場合は、次の各セクションを使用して問題箇所のトラブルシューティングを行います。

ノードの準備が完了しているかどうかを確認する

アップグレード プロセス中にクラスタ内のノードのステータスを表示するには、kubectl get nodes コマンドを使用します。

kubectl get nodes --kubeconfig KUBECONFIG

ノードでアップグレード プロセスが正常に完了したかどうかを確認するには、コマンド レスポンスの VERSION 列と AGE 列を確認します。VERSION は、クラスタの Kubernetes バージョンです。特定の GDCV for Bare Metal バージョンを確認するには、バージョン サポート ポリシーの表をご覧ください。

ノードに NOT READY が表示されている場合は、ノードを接続して kubelet のステータスを確認してみてください。

systemctl status kubelet

kubelet のログを確認することもできます。

journalctl -u kubelet

kubelet のステータスとログの出力を確認し、ノードに問題がある理由を示すメッセージを探します。

現在アップグレード中のノードを確認する

アップグレード中のクラスタ内のノードを確認するには、kubectl get baremetalmachines コマンドを使用します。

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

次の値を置き換えます。

  • CLUSTER_NAMESPACE: クラスタの名前空間。
  • ADMIN_KUBECONFIG: 管理 kubeconfig ファイル。
    • ブートストラップ クラスタが管理アップグレード、ハイブリッド アップグレード、またはスタンドアロン アップグレードに使用される場合は、ブートストラップ クラスタの kubeconfig ファイル（bmctl-workspace/.kindkubeconfig）を指定します。

次の出力例は、アップグレード対象のノードに DESIRED ABM VERSION とは異なる ABM VERSION があることを示しています。

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

ドレインされているノードを確認する

アップグレード プロセス中は、ノードが Pod からドレインされ、ノードが正常にアップグレードされるまでスケジューリングが無効になります。現在 Pod からドレインされているノードを確認するには、kubectl get nodes コマンドを使用します。

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

USER_CLUSTER_KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。

STATUS 列は grep を使用してフィルタリングされ、SchedulingDisabled を報告するノードのみを表示します。このステータスは、ノードがドレインされていることを示します。

管理クラスタからノードのステータスを確認することもできます。

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

次の値を置き換えます。

  • CLUSTER_NAMESPACE: クラスタの名前空間。
  • ADMIN_KUBECONFIG: 管理 kubeconfig ファイル。
    • ブートストラップ クラスタが管理、ハイブリッド、スタンドアロンのアップグレードに使用される場合は、ブートストラップ クラスタの kubeconfig ファイル（bmctl-workspace/.kindkubeconfig）を指定します。

ドレインされたノードのステータスは、MAINTENANCE 列に表示されます。

ノードが長期間ドレインされている状態にある理由を確認する

前のセクションのいずれかの方法で、kubectl get nodes コマンドを使用してドレインされたノードを特定します。追加の詳細を表示するには、kubectl get pods コマンドを使用して、このノード名をフィルタリングします。

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

NODE_NAME は、ドレインするノードの名前に置き換えます。出力は停止している、またはドレインの処理速度が遅い Pod のリストを返します。ノードのドレイン プロセスに 20 分を超える時間を要する場合は、停止した Pod が存在してもアップグレードが続行されます。

Pod が異常である理由を確認する

Pod に upgrade-first-node または upgrade-node のコントロール プレーンの IP アドレスが含まれている場合は、アップグレードが失敗する可能性があります。これは通常、静的 Pod が正常ではないためです。

  1. crictl ps -a コマンドを使用して静的 Pod をチェックし、クラッシュした Kubernetes Pod または etcd Pod を探します。失敗した Pod がある場合は、Pod のログを確認して、クラッシュした理由を確認します。

    クラッシュ ループの動作には、次のものがあります。

    • 静的 Pod にマウントされたファイルの権限またはオーナーが正しくない。
    • 仮想 IP アドレスへの接続が機能しない。
    • etcd に問題がある。

  2. crictl ps コマンドが機能しないか、何も返されない場合は、kubelet と containerd のステータスを確認します。systemctl status SERVICE コマンドと journalctl -u SERVICE コマンドを使用してログを確認します。