このページでは、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
)を指定します。
- ブートストラップ クラスタが管理アップグレード、ハイブリッド アップグレード、またはスタンドアロン アップグレードに使用される場合は、ブートストラップ クラスタの kubeconfig ファイル(
次の出力例は、アップグレード対象のノードに 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
)を指定します。
- ブートストラップ クラスタが管理、ハイブリッド、スタンドアロンのアップグレードに使用される場合は、ブートストラップ クラスタの kubeconfig ファイル(
ドレインされたノードのステータスは、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 が正常ではないためです。
crictl ps -a
コマンドを使用して静的 Pod をチェックし、クラッシュした Kubernetes Pod またはetcd
Pod を探します。失敗した Pod がある場合は、Pod のログを確認して、クラッシュした理由を確認します。クラッシュ ループの動作には、次のものがあります。
- 静的 Pod にマウントされたファイルの権限またはオーナーが正しくない。
- 仮想 IP アドレスへの接続が機能しない。
etcd
に問題がある。
crictl ps
コマンドが機能しないか、何も返されない場合は、kubelet
とcontainerd
のステータスを確認します。systemctl status SERVICE
コマンドとjournalctl -u SERVICE
コマンドを使用してログを確認します。