このページでは、Anthos プライベート モードのインストールやアップグレード中に発生する可能性のある問題のトラブルシューティングについて説明します。
トラブルシューティングの前提条件
Anthos 限定公開モードでは、トラブルシューティングを開始できるように管理ワークステーションにログインする必要があります。管理ワークステーションにログインするには、次のコマンドを実行します。
ssh <USERNAME>@<WORKSTATION>
cd ./anthos-baremetal-private-mode
export PATH=$PWD/bin:$PATH
クラスタを作成
このセクションでは、Anthos プライベート モードのクラスタを作成する際の問題のトラブルシューティングと解決方法について説明します。
管理クラスタの作成に失敗する
このセクションでは、よく発生する管理クラスタの構成エラーとプリフライト エラー、およびその修正方法について説明します。
構成エラー
管理クラスタ構成でよく発生する問題には、構成ファイルにアノテーションがない、レジストリの認証構成がない、ブートストラップ クラスタの作成時のエラーなどがあります。
構成ファイルにアノテーションがない
ノードプール リソースの作成中に、構成ファイルにアノテーションが含まれていない場合は、次のエラーが表示されることがあります。
Cluster.baremetal.cluster.gke.io "admin" is invalid: [Spec.LoadBalancer.AddressPools: Forbidden: Field not allowed for admin clusters, Spec.GKEConnect: Required value: Field is required].
この問題を修正するには、管理クラスタの構成ファイルにアノテーションを追加し、そのアノテーションを true
に設定します。
annotations:
baremetal.cluster.gke.io/private-mode: "true"
管理クラスタ構成ファイルに適用されているアノテーションの例については、管理クラスタとノードプールをご覧ください。
レジストリの認証構成がない
認証構成がない場合、「no auth config found for the registry
」エラーが発生することがあります。
admin.yaml
ファイルで指定された pullCredentialConfigPath
にエンドポイントの認証構成が含まれていることを確認します。たとえば、エンドポイントが https://10.200.0.2
で、pullCredentialConfigPath
が /root/.docker/config.json
の場合、config.json
ファイルには次の認証エントリがあります。
{
"auths": {
"10.200.0.2": {
"auth": "<base64 encoded auth>"
}
}
}
レジストリの認証エントリが存在しない場合は、レジストリにログインして config.json
ファイルを更新します。
docker login <registry> -u <username> -p <password>
ブートストラップ クラスタの作成エラー
クラスタの作成中に次のエラーが発生することがあります。
failed: error creating bootstrap cluster: failed to pull kind image kindest/node:v0.11.1-gke.7-v1.20.9-gke.101 from registry mirror(s)
ブートストラップ クラスタの作成エラーが表示された場合は、すべてのイメージが非公開レジストリにアップロードされていることを確認してください。
actl images push --private-registry=<registry>
コマンドの例を次に示します。
actl images push --private-registry=10.200.0.2/library
プリフライトの失敗
Anthos プライベート モードで管理クラスタを作成する場合は、プリフライト エラーによるクラスタ作成の失敗やクラスタ作成の停止を修正することや、一般的なトラブルシューティングを行う必要が生じる場合があります。
プリフライト エラーによるクラスタ作成の失敗
プリフライト チェックに失敗した場合は、次のエラー メッセージが表示されることがあります。
unable to create cluster: unable to create cluster: preflight check failed
Anthos プライベート モードでは、actl-workspace/admin/log/preflight-<timestamp>/
ディレクトリに対応するエラーログを収集します(例: actl-workspace/admin/log/preflight-20210907-205726/
)。
この問題を解決するには、次の点を確認してください。
- 失敗した各ノードのログ(ファイル名はノードの IP アドレス)
node-network
ファイル内のネットワーク関連のログ
ログデータに基づき、マシンの最小要件が満たされていない、ポートが競合しているなど、明らかなエラーがないかどうかを確認します。マシンを更新して再試行します。
クラスタ作成の停止
クラスタの作成に時間がかかる(たとえば、3 ノードクラスタで、30 分を超えるなど)場合は、ローカル ブートストラップ クラスタをチェックして、イメージを pull しているエラーがないか確認してください。
kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -A
Pod が ImagePullErr
ステータスの場合は、そのイメージがレジストリにアップロードされていることを確認します。
actl images push --private-registry=<registry>
コマンドの例を次に示します。
actl images push --private-registry=10.200.0.2/library
特定のクラスタ作成ジョブが Error
ステータスの場合は、対応する Pod のログを確認します。
kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -n cluster-admin
kubectl --kubeconfig actl-workspace/.kindkubeconfig logs <pod-name> -n cluster-admin
ログを調べて、マシン上で手動で修正できるエラーがあるかどうかを確認します。SSH を使用してマシンにログインし、journalctl --no-pager -l
を実行すると、マシン自体から追加のエラーを取得できます。重要なサービスが動作していることを確認するため、次のコマンドを実行します。
service containerd status
service kubelet status
journalctl -u containerd
journalctl -u kubelet
# If needed sudo systemctl restart <service> to fix issues.
# sudo service <service> restart
# e.g.,
# sudo service containerd restart
一般的な問題
通常、ノードのトラブルシューティングを行うには、SSH を使用してノードに接続し、次のコマンドを実行します。
journalctl --no-pager -l
ログでエラーを確認します。
クラスタの作成に失敗する
SSH を使用してコントロール プレーン マシンに接続し、クラスタの Pod を確認します。
sudo kubectl --kubeconfig /etc/kubernetes/admin.conf get po -A
ネットワークに関する問題
このセクションでは、Anthos プライベート モードでの最もよく見られるネットワーク関連の問題と、その解決方法について説明します。
- 各ノード間の接続を確認してネットワーク関連エラーをチェックするには、
ip route
を使用します。 コントロール プレーンの VIP に到達できない場合は、SSH を使用してコントロール プレーン ノードに接続し、次のコマンドを実行します。
journalctl -u containerd --no-pager -l # Check the logs of those pods as well. sudo kubectl --kubeconfig /etc/kubernetes/admin.conf -n kube-system get po | grep -E "haproxy|keepalived" sudo crictl logs `sudo crictl ps | grep anthos-baremetal-haproxy | awk '{print $1}'` sudo crictl logs `sudo crictl ps | grep anthos-baremetal-keepalived | awk '{print $1}'`
この問題は、
keepalived
イメージとhaproxy
イメージが非公開レジストリに読み込まれていない場合に発生することがあります。(管理クラスタが正常に作成された後にのみ使用)サービス IP に到達できない場合は、
metallb
Pod のログを確認します。kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=controller -n kube-system kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=speaker -n kube-system
すべての Pod がコンテナの作成で滞っている場合は、次のいずれかを行います。
- anetd-operator Deployment と anetd daemonset のログを確認します。
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l name=cilium-operator -n kube-system kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l name=cilium-operator -n kube-system kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l k8s-app=cilium -n kube-system kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l k8s-app=cilium -n kube-system
- デフォルト ゲートウェイが定義されていない場合、iptable が正常に機能せず、anetd-operator が kube-api サーバーにアクセスできないことがあります。
ip route add default via <some-ip> iptables-save -t nat iptables-save -t filter
ノードを再起動して、問題が解決するかどうかを確認します。
よくある間違い
kubectl コマンドが動作しない
kubectl コマンドライン ツールをリモート コマンドライン API サーバーに接続するように構成していない場合は、次のエラー メッセージが表示されます。
$ kubectl ...
The connection to the server localhost:8080 was refused - did you specify the right host or port?
kubeconfig セットがあることを確認します。これを行うには、KUBECONFIG 環境変数を設定するか、--kubeconfig
フラグを指定してコマンドを実行します。
たとえば、管理 kubeconfig を設定するには、次のいずれかを行います。
- 環境変数に admin kubeconfig を設定する。
export KUBECONFIG=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig
- kubeconfig コマンドライン オプションを使用する。
kubectl --kubeconfig=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig
詳細については、kubeconfig ファイルを使用してクラスタ アクセスを整理するをご覧ください。
ユーザー クラスタの作成が失敗する
ワークステーションで、管理クラスタにアクセスしてユーザー クラスタ関連の Pod を表示するために、次のコマンドを使用します。
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get po -n cluster-CLUSTER_NAME
CLUSTER_NAME
をクラスタ名で置き換えます。
引き続きユーザー クラスタに異常がある場合は、ユーザー クラスタを削除し、次の構成を適用してみてください。
# Delete user cluster export ADMIN_KUBECONFIG=$(pwd)/actl-workspace/admin/admin-kubeconfig export USER_CLUSTER_NAME=user-1 kubectl -n cluster-${USER_CLUSTER_NAME} delete Cluster $USER_CLUSTER_NAME --kubeconfig=${ADMIN_KUBECONFIG} # Re-apply the user cluster YAML file KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f user.yaml # Wait until client config ready and stored in the path "$(pwd)/${USER_CLUSTER_NAME}-kubeconfig" export USER_KUBECONFIG=$(pwd)/${USER_CLUSTER_NAME}-kubeconfig waittime="5 minutes" endtime=$(date -ud "$waittime" +%s) while ! KUBECONFIG=${ADMIN_KUBECONFIG} actl clusters baremetal get-credentials -c "${USER_CLUSTER_NAME}" -o "${USER_KUBECONFIG}"; do if [[ $endtime -le $(date -u +%s) ]]; then echo "Client config not ready in $waittime, terminating" exit 1 fi echo "client config not ready, sleeping 30s" sleep 30 done # Check the user cluster status until all nodes are ready KUBECONFIG=${USER_KUBECONFIG} kubectl get nodes
Anthos Management Center の作成
管理クラスタのリソースが不足している
Anthos Management Center のインストールは、AdminOperator
カスタム リソースにより構成されます。コントローラによる Management Center のインストールで問題が発生したかどうかを確認するには、このカスタム リソースとコントローラの Google Kubernetes Engine のイベントとログを確認します。
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe adminoperator admin-operator
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -n anthos-management-center-operator -l control-plane=admin-operator
Image pull のエラー
クラスタで Pod を起動すると、AdminOperator
が成功を報告できなくなる問題が発生することがあります。
# Get all pods that aren't in a Running state or have succeeded.
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods --field-selector=status.phase!=Running,status.phase!=Succeeded -A
# Examine the pods of interest that are failing...
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe pod --namespace [NAMESPACE] [POD_OF_INTEREST]
アップグレード
ベアメタル版 Anthos
ベアメタル版 Anthos でのアップグレードに関連する問題の修正についての詳細は、ベアメタル版 Anthos でのアップグレード失敗の復旧をご覧ください。
Anthos Management Center
インストールされているコンポーネントのバージョンを確認するには、次のコマンドを使用します。
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get adminoperator admin-operator -o yaml
出力例を次に示します。
apiVersion: managementcenter.anthos.cloud.google.com/v1
kind: AdminOperator
spec:
updateConfigOverride:
policies:
- name: anthos-config-management
versionConstraint: <=1.8.0-gke.0
status:
components:
- name: anthos-bare-metal
version: 1.8.0-gke.0
versionConstraint: <=1.8.0-gke.0
- name: anthos-config-management
version: 1.8.0-gke.0
versionConstraint: <=1.8.0-gke.0
- name: anthos-service-mesh
version: 1.8.0-gke.0
versionConstraint: <=1.8.0-gke.0
version: 1.8.0-gke.0
デプロイされた Anthos プライベート モード環境では、AdminOperator
オブジェクトの status.version
は、Anthos プライベート モードのリリース バージョンを示します。
例: 1.8.0-gke.0
status.components
には、各コンポーネントのバージョン ステータスが表示されます。デプロイされた各コンポーネントについて、確認されたバージョンとバージョン制約が一覧表示されます。
status.version
と status.components
の両方が常に使用可能である必要があります。そうしないと、インストールが破損します。spec.updateConfigOverride
は任意です。インフラストラクチャ オペレーターが特定のコンポーネントをアップグレードするためにフィールドを手動で設定した場合にのみ存在します。このフィールドを省略すると、すべてのコンポーネントは AdminOperator
と同じバージョンで実行されます。
更新センターでパッケージを確認する
Management Center には、更新センターで提供されるパッケージのみがデプロイされます。
たとえば、最初に 1.8.0-gke.0
リリースで管理クラスタをインストールし、その後 1.8.1-gke.0
にアップグレードすると、更新センターには 2 セットのパッケージが含まれます。実際に使用されているコンポーネントの UpdateItem
リソースを削除すると、Anthos プライベート モードのインストールが破損する可能性があります。
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get updateitems -n anthos-management-center
出力例を次に示します。
NAME AGE
anthos-config-management-1.8.0-gke.0 13d
anthos-service-mesh-1.8.0-gke.0 13d