问题排查

下面几个部分介绍使用 GKE On-Prem 时可能遇到的问题及其解决方法。

准备工作

在开始排查问题之前，请先查看以下部分。

使用 gkectl 诊断集群问题

使用 gkectl diagnose 命令识别集群问题并与 Google 共享集群信息。请参阅诊断集群问题。

默认日志记录行为

对于 gkectl 和 gkeadm，使用默认日志记录设置便已足够：

• 默认情况下，日志条目的保存方式如下：

  • 对于 gkectl，默认日志文件为 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log，该文件与运行 gkectl 的本地目录中的 logs/gkectl-$(date).log 文件进行符号链接。
  • 对于 gkeadm，默认日志文件是运行 gkeadm 的本地目录中的 logs/gkeadm-$(date).log。
• 所有日志条目都会保存在日志文件中，即使它们不输出到终端（当 --alsologtostderr 为 false 时）也是如此。
• -v5 详细程度（默认）涵盖支持团队所需的所有日志条目。
• 日志文件还包含已执行的命令和失败消息。

我们建议您在需要帮助时将日志文件发送给支持团队。

为日志文件指定非默认位置

要为 gkectl 日志文件指定非默认位置，请使用 --log_file 标志。您指定的日志文件不会与本地目录进行符号链接。

要为 gkeadm 日志文件指定非默认位置，请使用 --log_file 标志。

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

如果虚拟机在管理员控制层面启动后无法启动，您可以通过在管理员集群中检查 Cluster API 控制器的日志来尝试进行调试：

1. 在 kube-system 命名空间中找到 Cluster API 控制器 pod 的名称，其中 [ADMIN_CLUSTER_KUBECONFIG] 是管理员集群的 kubeconfig 文件的路径：

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

2. 打开 pod 的日志，其中 [POD_NAME] 是 pod 的名称。您可以选择使用 grep 或类似工具来搜索错误：

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

安装

使用管理员集群控制层面节点的 kubeconfig 调试 F5 BIG-IP 问题

安装完成后，GKE On-Prem 会在管理员工作站的主目录中生成一个名为 internal-cluster-kubeconfig-debug 的 kubeconfig 文件。此 kubeconfig 文件与管理员集群的 kubeconfig 完全相同，只是它直接指向管理员集群的控制层面节点（该节点上运行着管理员控制层面）。您可以使用 internal-cluster-kubeconfig-debug 文件调试 F5 BIG-IP 问题。

gkectl check-config 验证失败：找不到 F5 BIG-IP 分区

表现

验证失败，因为找不到 F5 BIG-IP 分区（即使分区存在）。

潜在原因

F5 BIG-IP API 的问题可能会导致验证失败。

解决方法

尝试再次运行 gkectl check-config。

gkectl prepare --validate-attestations 失败：无法验证版本证明

表现

如果使用可选的 --validate-attestations 标志运行 gkectl prepare，则系统会返回以下错误：

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY

潜在原因

受影响的映像可能没有证明。

解决方法

请按照创建管理员工作站中的说明，尝试重新下载并部署管理员工作站 OVA。如果问题仍然存在，请与 Google 联系以获取帮助。

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

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

如果在安装过程中出现问题，并且您确实向 gkectl create cluster 传递了 --cleanup-external-cluster=false，则使用引导集群的日志进行调试可能会有用。您可以找到 Pod，然后获取其日志：

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

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

管理员工作站

openssl 无法验证管理员工作站 OVA

表现

对管理员工作站 OVA 文件运行 openssl dgst 不会返回 Verified OK

潜在原因

OVA 文件存在问题，导致无法成功验证。

解决方法

按照下载管理员工作站 OVA 中的说明，尝试重新下载并部署管理员工作站 OVA。如果问题仍然存在，请与 Google 联系以获取帮助。

Connect

无法注册用户集群

如果您在注册用户集群时遇到问题，请与 Google 联系以获取帮助。

在 Alpha 版中创建的集群已取消注册

请参阅 Connect 文档中的注册用户集群。

您也可以选择删除和重新创建集群。

存储

无法挂接卷

表现

gkectl diagnose cluster 的输出如下所示：

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status
1 storage errors

一个或多个 pod 卡在 ContainerCreating 状态，并出现如下警告：

Events:
  Type     Reason              Age               From                     Message
  ----     ------              ----              ----                     -------
  Warning  FailedAttachVolume  6s (x6 over 31s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.

潜在原因

如果将虚拟磁盘挂接到错误的虚拟机，则可能是由于 Kubernetes 1.12 中的问题 #32727。

解决方法

如果虚拟磁盘挂接到了错误的虚拟机，您可能需要手动将其分离：

1. 排空节点。请参阅安全排空节点。您可能需要在 kubectl drain 命令中添加 --ignore-daemonsets 和 --delete-local-data 标志。
2. 关闭虚拟机电源。
3. 在 vCenter 中修改虚拟机的硬件配置以移除卷。
4. 开启虚拟机
5. 取消封锁节点。

卷丢失

表现

gkectl diagnose cluster 的输出如下所示：

Checking cluster object...PASS
Checking machine objects...PASS
Checking control plane pods...PASS
Checking gke-connect pods...PASS
Checking kube-system pods...PASS
Checking gke-system pods...PASS
Checking storage...FAIL
    PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found
1 storage errors

一个或多个 pod 卡在 ContainerCreating 状态，并出现如下警告：

Events:
  Type     Reason              Age                   From                                    Message
  ----     ------              ----                  ----                                    -------
  Warning  FailedAttachVolume  71s (x28 over 42m)    attachdetach-controller                 AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/
  kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found

潜在原因

如果您看到与 VMDK 文件相关的“未找到”错误，则可能是因为永久删除了虚拟磁盘。如果运维人员手动删除虚拟磁盘或其挂接的虚拟机，则可能会发生这种情况。为避免出现这种情况，请按照调整用户集群的大小和升级集群中的说明管理您的虚拟机

解决方法

如果虚拟磁盘已永久删除，您可能需要手动清理相关 Kubernetes 资源：

1. 通过运行 kubectl delete pvc [PVC_NAME]. 删除引用了 PV 的 PVC
2. 通过运行 kubectl delete pod [POD_NAME]. 删除引用了 PVC 的 pod
3. 重复第 2 步。（是的，请参阅 Kubernetes 问题 74374。）

vSphere CSI 卷分离失败

表现

如果您发现 pod 卡在 ContainerCreating 阶段并显示 FailedAttachVolume 警告，这可能是由于其他节点上的分离失败造成的。

运行以下命令以查找 CSI 分离错误：

kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message

输出应如下所示：

NAME                                                                   DETACH_ERROR
csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5   rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission
csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d   
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c   
csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8   

潜在原因

尚未向 vSphere 用户授予 CNS > Searchable 权限。

解决方法

将 CNS > Searchable 权限添加到您的 vCenter 用户帐号。分离操作会自动重试，直到取得成功。

升级

关于升级过程中的停机时间

资源	说明
管理员集群	当管理员集群关闭时，用户集群上的用户集群控制层面和工作负载会继续运行，除非它们受到导致停机的故障的影响
用户集群控制层面	通常情况下，用户集群控制层面应该不会出现较长的停机时间。但是，与 Kubernetes API 服务器的长时间运行的连接可能会中断，需要重新建立连接。在这些情况下，API 调用方应该重试，直到建立连接。在最糟糕的情况下，升级期间的停机时间可能长达一分钟。 注意：如果用户集群节点在升级过程中无法访问用户控制层面，则系统不会为集群安排新的工作负载。现有工作负载不受影响。
用户集群节点	如果升级需要更改用户集群节点，GKE On-Prem 会以滚动方式重新创建节点，并重新安排在这些节点上运行的 pod。您可以通过配置适当的 PodDisruptionBudget 和反亲和性规则来防止对工作负载产生影响。

调整用户集群的大小

无法调整用户集群的大小

表现

对用户集群执行的调整大小操作失败。

潜在原因

有几个因素可能会导致调整大小操作失败。

解决方法

如果调整大小失败，请按以下步骤操作：

1. 检查集群的 MachineDeployment 状态，看看是否有任何事件或错误消息：

   kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

2. 检查新创建的 Machine 上是否存在错误：

   kubectl describe machine [MACHINE_NAME]

错误：“无法分配任何地址”

表现

调整用户集群的大小后，kubectl describe machine [MACHINE_NAME] 会显示以下错误：

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
   

潜在原因

可用于用户集群的 IP 地址不足。

解决方法

为集群分配更多 IP 地址。然后，删除受影响的 Machine：

kubectl delete machine [MACHINE_NAME]

如果集群已正确配置，则会使用 IP 地址创建替换 Machine。

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

表现

网络分配了足够的地址，但 Machine 仍然无法向用户集群注册。

可能的原因

可能存在 IP 冲突。该 IP 可能被其他 Machine 或您的负载平衡器占用。

解决方法

确认受影响的 Machine 的 IP 地址未被占用。如果存在冲突，则需要解决您的环境中的冲突。

vSphere

使用 govc 进行调试

如果您遇到 vSphere 特有的问题，则可以使用 govc 进行问题排查。例如，您可以轻松确认 vCenter 用户帐号的权限和访问权限，并收集 vSphere 日志。

更改 vCenter 证书

如果您在评估或默认设置模式下运行 vCenter 服务器，并且该服务器具有生成的 TLS 证书，则此证书可能会随时间而更改。如果证书已更改，您需要让正在运行的集群知晓新证书：

1. 检索新的 vCenter 证书并保存到文件中：

   true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

2. 现在，对于每个集群，请删除包含每个集群的 vSphere 和 vCenter 证书的 ConfigMap，并使用新的证书创建新的 ConfigMap。例如：

   kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system

   kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1

   kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

   kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem  -o yaml  | kubectl --kubeconfig kubeconfig apply -f -

3. 删除每个集群的 clusterapi-controller pod。当 pod 重启时，它会开始使用新证书。例如：

   kubectl --kubeconfig kubeconfig -n kube-system get pods

   kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...

其他

Terraform vSphere 提供商会话数限制

GKE On-Prem 使用 Terraform 的 vSphere 提供商在您的 vSphere 环境中启动虚拟机。提供商的会话数上限为 1000。当前实现不会在使用后关闭活动会话。如果您运行的会话过多，则可能会遇到 503 错误。

会话会在 300 秒后自动关闭。

表现

如果您运行的会话过多，则可能会遇到以下错误：

Error connecting to CIS REST endpoint: Login failed: body:
  {"type":"com.vmware.vapi.std.errors.service_unavailable","value":
  {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is
  limited to 1000. Existing sessions are 1000.",
  "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}},
  status: 503 Service Unavailable

潜在原因

您的环境中运行的 Terraform 提供商会话过多。

解决方法

目前，此功能按预期运行。会话会在 300 秒后自动关闭。如需了解详情，请参阅 GitHub 问题 #618。

为 Docker 使用代理：oauth2: cannot fetch token

表现

使用代理时，您遇到以下错误：

oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527

潜在原因

您提供的可能是 HTTPS 代理，而不是 HTTP。

解决方法

在 Docker 配置中，将代理地址更改为 http:// 而不是 https://。

验证许可是否有效

请务必验证您的许可是否有效，特别是在使用试用许可的情况下。如果您的 F5、ESXi 主机或 vCenter 许可已过期，您可能会遇到意外故障。