排查集群创建和升级问题

本页面介绍了如何调查 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 标志。

在管理员集群中查找集群 API 日志

如果虚拟机在管理员控制层面启动后无法启动，您可以通过在管理员集群中检查 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 日志。

使用引导集群的日志进行调试

在安装期间，GKE on VMware 会创建临时引导集群。成功安装后，GKE on VMware 会删除引导集群，留下您的管理员集群和用户集群。通常情况下，您应该无需与引导集群进行交互。

如果将 --cleanup-external-cluster=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

  3. 如需直接获取引导集群的日志，您可以在集群创建、更新和升级期间运行以下命令：

    docker exec -it gkectl-control-plane bash

    该命令会在引导集群中运行的 gkectl-control-plane 容器内打开一个终端。

    如需检查 kubelet 和 containerd 日志，请使用以下命令并查找输出中的错误或警告：

    systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd

在升级后回滚节点池

如果您在升级用户集群后发现集群节点存在问题，则可以将所选节点池回滚到先前版本。

Ubuntu 和 COS 节点池支持回滚所选节点池，但 Windows 节点池不支持回滚。

节点池的版本可以与用户集群控制平面的版本相同，也可以低一个次要版本。例如，如果控制平面为 1.14 版，则节点池可以为 1.14 版或 1.13 版。

查看可用的节点池版本

假设您最近将用户集群工作器节点和控制平面从 1.13.1-gke.35 版升级到 1.14.0 版，但后来发现升级后的工作器节点存在问题。因此，您决定将一个或多个节点池回滚到您之前运行的版本：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

回滚节点池

您可以一次回滚一个节点池，也可以一步回滚多个节点池。

在用户集群配置文件中，将一个或多个节点池的 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 文件与管理员集群的 kubeconfig 文件完全相同，只是它直接指向管理员集群的控制层面节点（Kubernetes API 服务器在该节点上运行）。您可以使用 internal-cluster-kubeconfig-debug 文件调试 F5 BIG-IP 问题。

无法调整用户集群的大小

如果调整用户集群的大小失败，请执行以下操作：

  1. 找到 MachineDeployments 和 Machines 的名称：

    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 地址。然后，删除受影响的 Machine：

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

GKE on VMware 会创建一个新 Machine，并为其分配一个新的可用 IP 地址。

已分配足够数量的 IP 地址，但 Machine 无法向集群注册

如果存在 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)。

在 GKE on VMware 1.13 版中，您可以通过 Kubernetes Pod 事件检查失败。

  1. 找到 Machine 的名称：

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

  2. 使用 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.15/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 文件的路径。