本页面介绍了如何调查 Google Distributed Cloud 中的集群创建和升级问题。
如果您需要其他帮助，请与 Cloud Customer Care 联系。安装问题
以下部分可能有助于您排查与安装 Google Distributed Cloud 相关的问题。
使用引导集群调试问题
在安装期间，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将
POD_NAME替换为您要查看的 Pod 的名称。如需直接从引导集群中获取日志，请在集群创建、更新和升级期间运行以下命令：
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
检查引导集群的快照
如果您尝试创建或升级管理员集群，但该操作失败，则 Google Distributed Cloud 会截取引导集群的外部快照。该引导集群的快照类似于在管理员集群上运行 gkectl diagnose snapshot 命令所截取的快照，但该过程会自动触发。引导集群快照包含管理员集群创建和升级过程的重要调试信息。如果需要，您可以向 Cloud Customer Care 团队提供此快照。
外部快照包含来自 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
管理员控制平面启动后虚拟机未启动
如果虚拟机在管理员控制平面启动后无法启动，您可以通过在管理员集群中检查来自 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
已分配足够数量的 IP 地址，但 Machine 无法向集群注册
如果存在 IP 地址冲突，就可能会发生此问题。例如，您为机器指定的 IP 地址被用于负载均衡器。
如需解决此问题，请更新您的集群 IP 块文件，以使机器地址不与集群配置文件或 Seesaw IP 块文件中指定的地址冲突
集群升级问题
以下部分提供了有关如何解决集群升级期间可能遇到的问题的提示。
升级后回滚节点池
如果您在升级用户集群后发现集群节点存在问题，则可以将所选节点池回滚到先前版本。
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
升级到新的补丁程序版本
您可以将所有节点池和控制平面升级到新的补丁程序版本。如果您回滚到先前的版本并希望升级到包含修复程序的版本，上述做法可能会很有用。
如需升级到新版本，请完成以下步骤：
在用户集群配置文件中进行以下更改：
将
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: ""
按照升级 Google Distributed Cloud 中的说明运行
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 ```
健康检查会在集群升级失败时自动运行
如果您尝试升级管理员集群或用户集群，并且该操作失败，则 Google Distributed Cloud 会自动对集群运行 gkectl diagnose cluster 命令。
如需跳过自动诊断，请将 --skip-diagnose-cluster 标志传递给 gkectl upgrade。
升级过程卡住
Google Distributed Cloud 在升级期间在后台使用 Kubernetes drain 命令。只有一个副本（该副本使用 minAvailable: 1 为其创建了 PodDisruptionBudget (PDB)）的 Deployment 可以阻止此 drain 过程。
从 Google Distributed Cloud 1.13 版开始，您可以通过 Kubernetes Pod 事件检查失败情况。
找到 Machine 的名称：
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。
移除不受支持的更改以取消阻止升级
将集群升级到 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。
使用内部 kubeconfig 文件调试 F5 BIG-IP 问题
安装完成后，GKE on VMware 会在管理员工作站的主目录中生成一个名为 internal-cluster-kubeconfig-debug 的 kubeconfig 文件。此 kubeconfig 文件与管理员集群的 kubeconfig 文件完全相同，只是它直接指向管理员集群的控制层面节点（Kubernetes API 服务器在该节点上运行）。您可以使用 internal-cluster-kubeconfig-debug 文件调试 F5 BIG-IP 问题。
调试 vSphere 问题
您可以使用 govc 来调查 vSphere 的问题。例如，您可以确认 vCenter 用户帐号的权限和访问权限，并且可以收集 vSphere 日志。
重新创建缺失的用户集群 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文件的路径。
后续步骤
- 如果您需要其他帮助，请与 Cloud Customer Care 联系。