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

Version 1.11 

• Version 1.28 (latest)
• Version 1.16
• Version 1.15
• Earlier versions (unsupported)

このページでは、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 のログを調べて問題を調査できます。

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

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

2. 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 に渡した場合、ブートストラップ クラスタは削除されず、ブートストラップ クラスタのログを使用してインストールの問題をデバッグできます。

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

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

2. 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 の問題をデバッグできます。

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

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

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

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

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

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
   

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

   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 サポートにこのスナップショットを提供できます。

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

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

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

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

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

その場合は PDB を保存して、クラスタから削除してからアップグレードを試してください。アップグレードが完了したら、PDB を再度追加できます。

欠落しているユーザー クラスタの 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 ファイルのパス。