クラスタの作成やアップグレードのトラブルシューティング

このページでは、Google Distributed Cloud クラスタのインストールやアップグレードに関連する問題を解決する方法について説明します。

さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。

インストールに関する問題

以下のセクションでは、Google Distributed Cloud のインストールに関する問題のトラブルシューティングに役立つ情報を提供します。

一時的なエラーメッセージ

Google Distributed Cloud のインストールプロセスは、継続的な調整のループです。その結果、インストール中に、一時的なエラーメッセージがログに表示されることがあります。

インストールが正常に完了している限り、これらのエラーは無視してかまいません。一般的な一時的エラーログメッセージのリストは次のとおりです。

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF

  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"

  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

Google Cloud サービスアカウントキーの有効期限が切れている場合、bmctl から次のエラーメッセージが表示されます。

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

新しいサービスアカウントキーを生成する必要があります。

ブートストラップクラスタを使用して問題をデバッグする

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

注: Google Distributed Cloud バージョン 1.15.0 以降では、セルフマネージド（管理、ハイブリッド、スタンドアロン）クラスタのデフォルトのアップグレード動作はインプレースアップグレードです。インプレースアップグレードでは、ブートストラップクラスタではなくライフサイクルコントローラを使用してアップグレードオペレーション全体を管理します。この変更によりプロセスが簡素化され、リソースの要件が縮小されるため、クラスタのアップグレードの信頼性とスケーラビリティが向上します。推奨されませんが、bmctl upgrade コマンドで --use-bootstrap=true フラグを設定することで、ブートストラップクラスタを使用することもできます。

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

Google Distributed Cloud では、ブートストラップクラスタの構成ファイルが 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

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

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

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

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

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

アップグレードプロセス中のクラスタのステータスを表示するには、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 バージョンです。特定の Google Distributed Cloud のバージョンの Kubernetes バージョンを確認するには、バージョン履歴をご覧ください。

ノードに 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 からドレインされ、ノードが正常にアップグレードされるまでスケジューリングが無効になります。ドレインされているノードを確認するには、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 が存在してもアップグレードが続行されます。

リリース 1.29 以降では、ノードドレインプロセスでは PodDisruptionBudgets（PDB）を使用する Eviction API が使用されます。

次の PDB 設定では、ノードのドレインの問題が発生する可能性があります。

複数の PDB によって管理される Pod
次のような PDB の静的構成。
- maxUnavailable == 0
- minUnavailable >= レプリカの合計数
レプリカの合計数は、Deployment、ReplicaSet、StatefulSet などの上位レベルのリソースで定義されているため、PDB リソースから判断することは困難です。PDB は、構成のセレクタに基づいてのみ Pod と照合されます。静的 PDB 構成が問題の原因かどうかを診断するには、まず pdb.Status.ExpectPods が pdb.Status.DesiredHealthy 以下であるかどうかを調べ、前述の静的構成のいずれがこの問題を引き起こしてないかどうかを確認することをおすすめします。

ランタイム違反（計算済みファイルなど）DisruptionsAllowed PDB リソースの 0 ノードのドレインをブロックすることもあります。追加の中断を許可できない PodDisruptionBudget オブジェクトが構成されている場合、ノードのアップグレードを繰り返し試行しても、コントロールプレーンバージョンへのアップグレードが失敗する可能性があります。このエラーを回避するには、Deployment または HorizontalPodAutoscaler をスケールアップして、PodDisruptionBudget 構成を維持しながらノードをドレインすることをおすすめします。

中断を許可しないすべての PodDisruptionBudget オブジェクトを表示するには、次のコマンドを使用します。

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

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 コマンドを使用してログを確認します。

次のステップ

さらにサポートを必要とされる場合は、Cloud カスタマーケアにお問い合わせください。

クラスタの作成やアップグレードのトラブルシューティング

インストールに関する問題

一時的なエラー メッセージ

ブートストラップ クラスタを使用して問題をデバッグする

ブートストラップ クラスタのログを調べる

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

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

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

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

ドレイン プロセス中のノードを確認する

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

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

次のステップ

一時的なエラーメッセージ

ブートストラップクラスタを使用して問題をデバッグする

ブートストラップクラスタのログを調べる

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

ドレインプロセス中のノードを確認する