Anthos 限定公開モードのインストールに関する問題

このページでは、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.0status.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

次のステップ