このページでは、GKE on VMware でクラスタの作成、アップグレード、サイズ変更に関する問題を調査する方法について説明します。
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-controllersvsphere-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 のログを収集できます。
ブートストラップ クラスタのログを使用したデバッグ
インストール時、GKE on VMware により一時的なブートストラップ クラスタが作成されます。インストールが正常に完了した後、GKE on VMware によってブートストラップ クラスタが削除され、管理クラスタとユーザー クラスタが残されます。通常、ブートストラップ クラスタを操作する理由はありません。
--cleanup-external-cluster=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
ブートストラップ クラスタから直接ログを取得するには、クラスタの作成、更新、アップグレード中に次のコマンドを実行します。
docker exec -it gkectl-control-plane bash
このコマンドにより、ブートストラップ クラスタで実行される gkectl コントロール プレーン コンテナ内のターミナルが開かれます。
kubelet と containerd のログを調べるには、次のコマンドを使用して、出力でエラーや警告を探します。
systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
ノードプールのアップグレード後のロールバック
ユーザー クラスタをアップグレードした後にクラスタノードで問題が見つかった場合は、選択したノードプールを以前のバージョンにロールバックできます。
選択したノードプールのロールバックは、Ubuntu ノードプールと COS ノードプールではサポートされていますが、Windows ノードプールではサポートされていません。
対応するノードプールのバージョンは、ユーザー クラスタ コントロール プレーンのバージョンと同じか、1 つ古いマイナー バージョンです。たとえば、コントロール プレーンがバージョン 1.14 の場合、ノードプールはバージョン 1.14 または 1.13 に設定できます。
使用可能なノードプールのバージョンを表示する
最近、ユーザー クラスタのワーカーノードとコントロール プレーンをバージョン 1.13.1-gke.35 からバージョン 1.14.0 にアップグレードし、アップグレードしたワーカーノードで問題が見つかったとします。そのため、あなたは 1 つ以上のノードプールを以前実行していたバージョン（1.13.1-gke.35）にロールバックすることにしました。
以前のバージョンがロールバックに使用できることを確認します。
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
ノードプールのロールバック
一度に 1 つのノードプールをロールバックすることも、複数のノードプールを 1 つのステップでロールバックすることもできます。
ユーザー クラスタ構成ファイルの 1 つ以上のノードプールで、gkeOnPremVersion の値を以前のバージョン（この例では 1.13.1-gke.35）に設定します。
nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...
ノードプールをロールバックするようにクラスタを更新します。
gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ロールバックが以下の状態であることを確認します。
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
pool-1 がバージョン 1.13.1-gke.35 にロールバックされたことを示しています。user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.13.1-gke.35 - previous version: 1.14.0-gke.x - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
新しいパッチ バージョンにアップグレードする
問題が新しいパッチ バージョン（1.14.1 など）で修正されたとします。これで、すべてのノードプールとコントロール プレーンを新しいパッチ バージョンにアップグレードできるようになりました。
ユーザー クラスタの構成ファイルで、次の操作を行います。
gkeOnPremVersionの値を新しいパッチ バージョン（この例では 1.14.1-gke.x）に設定します。ノードプールごとに、
gkeOnPremVersionフィールドを削除するか、空の文字列に設定します。ノードプールにバージョンが指定されていない場合、ノードプールのバージョンは、デフォルトでクラスタに指定されたバージョンになります。
例:
gkeOnPremVersion: 1.14.1-gke.x nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: "" - name: pool-2 cpus: 8 memoryMB: 8192 replicas: 2 gkeOnPremVersion: ""
GKE on VMware のアップグレードの説明に沿って、gkectl prepare と gkectl upgrade cluster を実行します。
新しいクラスタ バージョンを確認し、ロールバックに使用できるバージョンを確認します。
gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
user cluster version: 1.14.1-gke.y node pools: - pool-1: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x - 1.14.1-gke.y
内部 kubeconfig ファイルを使用して F5 BIG-IP の問題をデバッグする
インストール後、GKE 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
GKE on VMware によって、新しいマシンが作成され、新しく使用可能になった IP アドレスのいずれかが割り当てられます。
十分な数の IP アドレスが割り振られているが、クラスタにマシンを登録できない
この問題は、IP アドレスの競合が存在する場合に発生する可能性があります。たとえば、マシンに指定した IP アドレスがロードバランサで使用されている場合が該当します。
この問題を解決するには、クラスタ IP ブロック ファイルを更新して、マシンのアドレスがクラスタ構成ファイル、またはSeesaw IP ブロック ファイルで指定されたアドレスと競合しないようにします。
管理クラスタの作成またはアップグレードが失敗すると、自動的にスナップショットが作成される
管理クラスタの作成やアップグレードをしようとして、そのオペレーションが失敗した場合、GKE 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
クラスタのアップグレードに失敗すると、ヘルスチェックが自動的に実行される
管理クラスタまたはユーザー クラスタをアップグレードしようとして、そのオペレーションが失敗した場合、GKE on VMware は、クラスタに対して gkectl diagnose cluster コマンドを自動的に実行します。
自動診断をスキップするには、--skip-diagnose-cluster フラグを gkectl upgrade に渡します。
アップグレード プロセスが停止する
GKE on VMware はアップグレード時に、バックグラウンドで Kubernetes drain コマンドを使用します。この drain 手順は、minAvailable: 1 を使用して作成された PodDisruptionBudget（PDB）を持つ唯一のレプリカを含む Deployment によってブロックされます。
GKE 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/1.16/diagnose#overview_diagnose_snapshot
詳細については、クラスタの問題を診断するをご覧ください。
欠落しているユーザー クラスタの kubeconfig ファイルを再作成する
次のような場合は、ユーザー クラスタ kubeconfig ファイルを再作成することをおすすめします。
- ユーザー クラスタを作成しようとして、作成オペレーションが失敗し、ユーザー クラスタ kubeconfig ファイルが必要な場合。
- ユーザー クラスタの kubeconfig ファイルが見つからない（削除後など）場合。
次のコマンドを実行して、ユーザー クラスタ kubeconfig ファイルを再作成します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
-o jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG
次のように置き換えます。
- USER_CLUSTER_KUBECONFIG: ユーザー クラスタの新しい kubeconfig ファイルの名前。
- ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
サポートされていない変更を削除してアップグレードを解除します
クラスタを 1.16 以前のバージョンにアップグレードすると、ほとんどのフィールドに対する変更はアップグレード中に通知なく無視されます。つまり、これらの変更はアップグレード中とアップグレード後に有効になりません。
ユーザー クラスタを 1.28 以降のバージョンにアップグレードする場合は、構成ファイルで行われたすべての変更を検証し、サポートされていない変更を無視するのではなくエラーを返します。たとえば、ユーザー クラスタを 1.28 にアップグレードする際にノードの自動修復を無効にしようとすると、アップグレードが失敗し、次のエラー メッセージが表示されます。
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
UsageMetering: nil,
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
このエラーを回避する必要がある場合は、次の回避策があります。
- 試みた変更を元に戻して、アップグレードを再実行します。たとえば、上記のシナリオでは、
AutoRepair構成に加えた変更を元に戻してgkectl upgradeを再実行します。 - または、
gkectl get-configを実行して、クラスタの現在の状態と一致する構成ファイルを生成し、構成ファイルのクラスタおよびノードプールのgkeOnPremVersionフィールドを更新してから、gkectl upgradeを再実行します。