このページでは、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 サポートにこのスナップショットを提供できます。
アップグレード プロセスが停止する
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 ファイルのパス。