您正在查看 GKE On-Prem 以前版本的文档。查看最新文档

问题排查

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

准备工作

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

使用 gkectl 诊断集群问题

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

以 verbose 模式运行 gkectl 命令

-v5

gkectl 错误记录到 stderr

--alsologtostderr

在管理员工作站中查找 gkectl 日志

即使未传入其调试标志,您也可以在以下管理员工作站目录中查看 gkectl 日志:

/home/ubuntu/.config/syllogi/logs

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

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

  1. kube-system 命名空间中找到集群 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]

管理员工作站

下载 OVA 时出现 AccessDeniedException

表现

尝试下载管理员工作站 OVA 和签名会返回以下错误:

AccessDeniedException: 403 whitelisted-service-account@project.iam.gserviceaccount.com does not have storage.objects.list access to gke-on-prem-release
潜在原因

您的白名单服务帐号未激活。

解决方法

确保您已激活白名单服务帐号。如果问题仍然存在,请与 Google 联系以获取帮助。

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

表现

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

潜在原因

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

解决方法

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

沟通

无法注册用户集群

如果您在注册用户集群时遇到问题,请与 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。)

升级

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

资源 说明
管理员集群

当管理员集群关停时,用户集群上的用户集群控制平面和工作负载会继续运行,除非它们受到导致停机的故障的影响。

用户集群控制平面

通常情况下,用户集群控制平面应该不会出现较长的停机时间。但是,与 Kubernetes API 服务器的长时间运行的连接可能会中断,需要重新建立连接。在这些情况下,API 调用方应该重试,直到建立连接。在最糟糕的情况下,升级期间的停机时间可能长达一分钟。

用户集群节点

如果升级需要更改用户集群节点,GKE On-Prem 会以滚动方式重新创建节点,并重新安排在这些节点上运行的 pod。您可以通过配置适当的 PodDisruptionBudget反亲和性规则来防止对工作负载产生影响。

调整用户集群的大小

无法调整用户集群的大小

表现

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

潜在原因

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

解决方法

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

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

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
  2. 检查新创建的机器上是否存在错误:

    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 地址。然后,删除受影响的机器:

kubectl delete machine [MACHINE_NAME]

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

已分配足够数量的 IP 地址,但机器无法向集群注册

表现

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

可能的原因

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

解决方法

检查受影响的机器的 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 许可已过期,您可能会遇到意外故障。