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

このページでは、Anthos clusters on VMware（GKE On-Prem）内でクラスタの作成、アップグレード、サイズ変更に関する問題を調査する方法について説明します。

`gkectl` と `gkeadm` のデフォルトのロギング動作

gkectl と gkeadm では、デフォルトのロギング設定を使用するだけで十分です。

gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカルディレクトリの logs/gkectl-$(date).log ファイルにシンボリックリンクされます。
gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカルディレクトリの logs/gkeadm-$(date).log です。
デフォルトの -v5 詳細レベルは、サポートチームが必要とするログエントリすべてを対象としています。

ログファイルには、実行されたコマンドとエラーメッセージが含まれます。

サポートが必要な場合は、サポートチームにログファイルを送信することをおすすめします。

ログファイルにデフォルト以外の場所を指定する

gkectl ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。指定したログファイルは、ローカルディレクトリにシンボリックリンクされません。

gkeadm ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。

管理クラスタで Cluster API ログを見つける

管理コントロールプレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラ Pod のログを調べて問題を調査できます。

Cluster API コントローラ Pod の名前を見つけます。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

vsphere-controller-manager からのログを表示します。まず、Pod を指定しますが、コンテナは指定しません。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

出力には、コンテナを指定する必要があることが示され、Pod 内のコンテナの名前が示されます。例:

... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

コンテナを選んで、そのログを表示します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

`govc` を使用して vSphere に関する問題を解決する

govc を使用すると、vSphere に関する問題を調査できます。たとえば、vCenter ユーザーアカウントの権限とアクセスを確認し、vSphere のログを収集できます。

ブートストラップクラスタのログを使用したデバッグ

インストール中、Anthos clusters on VMware により一時的なブートストラップクラスタが作成されます。インストールが正常に完了した後、Anthos clusters on VMware によってブートストラップクラスタが削除され、管理クラスタとユーザークラスタが残されます。通常、ブートストラップクラスタを操作する理由はありません。

--cleanup-external-cliuster=false を gkectl create cluster に渡した場合、ブートストラップクラスタは削除されず、ブートストラップクラスタのログを使用してインストールの問題をデバッグできます。

kube-system 名前空間で実行されている Pod の名前を確認します。

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

Pod のログを表示します。

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

内部 kubeconfig ファイルを使用して F5 BIG-IP の問題をデバッグする

インストール後、Anthos clusters on VMware は、管理ワークステーションのホームディレクトリに internal-cluster-kubeconfig-debug という名前の kubeconfig ファイルを生成します。この kubeconfig ファイルは、Kubernetes API サーバーが実行される管理クラスタのコントロールプレーンノードを直接参照することを除いて、管理クラスタの kubeconfig ファイルと同じです。この internal-cluster-kubeconfig-debug ファイルを使用して、F5 BIG-IP の問題をデバッグできます。

ユーザークラスタのサイズ変更に失敗する

ユーザークラスタのサイズ変更が失敗した場合:

MachineDeployments とマシンの名前を確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

ログを表示する MachineDeployment を記述します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

新しく作成したマシンでエラーを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

クラスタのサイズ変更にアドレスを割り振ることができない

この問題は、ユーザークラスタのサイズを変更するのに十分な IP アドレスが使用できない場合に発生します。

kubectl describe machine を実行すると、次のエラーが表示されます。

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

この問題を解決するには、クラスタに追加の IP アドレスを割り振ります。次に、影響を受けたマシンを削除します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

Anthos clusters on VMware によって、新しいマシンが作成され、新しく使用可能になった IP アドレスのいずれかが割り当てられます。

十分な数の IP アドレスが割り振られているが、クラスタにマシンを登録できない

この問題は、IP アドレスの競合が存在する場合に発生する可能性があります。たとえば、マシンに指定した IP アドレスがロードバランサで使用されている場合が該当します。

この問題を解決するには、クラスタ IP ブロックファイルを更新して、マシンのアドレスがクラスタ構成ファイル、またはSeesaw IP ブロックファイルで指定されたアドレスと競合しないようにします。

管理クラスタの作成またはアップグレードが失敗すると、自動的にスナップショットが作成される

管理クラスタの作成やアップグレードをしようとして、そのオペレーションが失敗した場合、Anthos clusters on VMware では、ブートストラップクラスタ（管理クラスタの作成やアップグレードに使用される一時的なクラスタ）の外部スナップショットが取得されます。このブートストラップクラスタのスナップショットは、管理クラスタで gkectl diagnose snapshot コマンドを実行すると実行されるスナップショットと似ていますが、自動的にトリガーされる点が異なります。このブートストラップクラスタのスナップショットには、管理クラスタの作成やアップグレードプロセスに関する重要なデバッグ情報が含まれています。必要な場合は、Google Cloud サポートにこのスナップショットを提供できます。

外部スナップショットには onprem-admin-cluster-controller の Pod ログが含まれます。このログを使用すると、クラスタの作成やアップグレードの問題をデバッグできます。ログは別のファイルに保存されます。次に例を示します。

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system

クラスタのアップグレードに失敗すると、ヘルスチェックが自動的に実行される

管理クラスタまたはユーザークラスタをアップグレードしようとして、そのオペレーションが失敗すると、Anthos clusters on VMware は自動的にクラスタ上で gkectl diagnose cluster コマンドを実行します。

自動診断をスキップするには、--skip-diagnose-cluster フラグを gkectl upgrade に渡します。

アップグレードプロセスが停止する

Anthos clusters on VMware はアップグレード時に、バックグラウンドで Kubernetes drain コマンドを使用します。この drain 手順は、minAvailable: 1 を使用して作成された PodDisruptionBudget（PDB）を持つ唯一のレプリカを含む Deployment によってブロックされます。

Anthos clusters on VMware バージョン 1.13 から、Kubernetes Pod イベントを使用してエラーを確認できます。

マシンの名前を確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

kubectl describe machine コマンドを使用してエラーを確認します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
```

出力例は次のとおりです。

Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

マシンオブジェクトのステータスの詳細分析を確認するには、gkectl diagnose cluster を実行します。

...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

この問題を解決するには、アップグレードを試みる前に PDB を保存してクラスタから削除します。アップグレードが完了したら、PDB を再度追加できます。

仮想マシンのステータスを診断する

仮想マシンの作成で問題が発生した場合は、gkectl diagnose cluster を実行して、仮想マシンのステータスの診断を取得します。

出力の例を次に示します。


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot

詳細については、診断をご覧ください。

欠落しているユーザークラスタの kubeconfig ファイルを再作成する

次のような状況では、ユーザークラスタの kubeconfig ファイルを再作成することをおすすめします。

ユーザークラスタの作成を試み、作成オペレーションが失敗し、ユーザークラスタの kubeconfig ファイルが必要な場合。
ユーザークラスタの kubeconfig ファイルが見つからない（削除後など）場合。

次のコマンドを実行して、ユーザークラスタの kubeconfig ファイルを再作成します。

KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1)

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \
  -o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig

以下を置き換えます。

USER_CLUSTER_VIP: ユーザーマスターの VIP 値。
USER_CLUSTER_NAME: ユーザークラスタの名前。
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。