本页面介绍了如何调查 Anthos clusters on VMware (GKE On-Prem) 中与集群创建、升级和调整大小有关的问题。
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 的日志来调查问题。
找到 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
使用 govc
解决与 vSphere 相关的问题
您可以使用 govc
调查与 vSphere 相关的问题。例如,您可以确认 vCenter 用户帐号的权限和访问权限,并且可以收集 vSphere 日志。
使用引导集群的日志进行调试
在安装期间,Anthos clusters on VMware 会创建临时引导集群。成功安装后,Anthos clusters on VMware 会删除引导集群,保留您的管理员集群和用户集群。通常情况下,您应该无需与引导集群进行交互。
如果将 --cleanup-external-cliuster=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
更改 vCenter 证书
如果您在评估或默认设置模式下运行 vCenter 服务器,并且该服务器具有生成的 TLS 证书,则此证书可能会随时间而更改。如果证书已更改,您需要让正在运行的集群知道新证书:
检索新的 vCenter 证书并将其解压缩:
curl -k -o certs.zip https://VCENTER_IP_ADDRESS/certs/download.zip unzip certs.zip
-k
标志允许未知证书。这是为了避免您访问 vCenter 可能遇到的任何证书问题。将 Linux 证书保存到名为
vcenter-ca.pem
的文件中:cat certs/lin/*.0 > vcenter-ca.pem
在管理员集群配置文件中,将
vCenter.caCertPath
设置为新的vcenter-ca.pem
文件的路径。-
在该节点上,将
/etc/vsphere/certificate/ca.crt
的内容替换为vcenter.pem
的内容。退出 SSH 连接。
删除
vcenter-ca-certificate
ConfigMaps。kube-system
命名空间中有一个,并且每个用户集群命名空间中都有一个。例如:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \ --namespace kube-system ... kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \ --namespace user-cluster1
使用新证书创建新的 ConfigMaps。例如:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \ --namespace kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \ --output yaml | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f - ... kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \ --namespace user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \ --output yaml | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -
如需重启管理员控制层面中包含静态 Pod 的容器,请执行以下操作:
- 通过 SSH 连接到管理员主虚拟机。
- 运行
docker restart
。
接下来,更新管理员 create-config Secret 中的 CA 证书数据。
- 从输出中获取 Secret 并解码 data.cfg 值:
`kubectl get secret create-config -n kube-system -o jsonpath={.data.cfg} | base64 -d > admin-create-config.yaml
- 将
admincluster.spec.cluster.vsphere.cacertdata
中的值与新的 vCenter CA 证书进行比较。 - 如果这两个值不同,您必须修改管理员 create-config Secret 以添加新的 CA 证书。在 admin-create-config.yaml 文件中,复制 base-64 解码的结果,并将
admincluster.spec.cluster.vsphere.cacertdata
的值替换为新的 vCenter CA 证书。 - 对上一步中的值进行编码:
cat admin-create-config.yaml | base64 -w0 > admin-create-config.b64
- 修改 create-config Secret 并将
data.cfg
值替换为编码值:
kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n kube-system create-config
- 从输出中获取 Secret 并解码 data.cfg 值:
现在,更新用户集群的 create-config Secret 中的 CA 证书数据。
修改 create-config secret,并将
data.cfg
值替换为您在上一步中创建的 base64 编码的值。例如:kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n user-cluster-1 create-config
删除用户集群中的以下 Pod。
- clusterapi-controllers
- kube-controller-manager
- kube-apiserver
- vsphere-csi-controller
- vsphere-metrics-exporter
如需获取 Pod 的名称,请运行以下命令:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep clusterapi kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-controller-manager kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-apiserver kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-csi-controller kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-metrics-exporter
删除您在上一步中找到的 Pod:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace NAMESPACE \ delete pod POD_NAME
Pod 重启时将使用新证书。
使用内部 kubeconfig 文件调试 F5 BIG-IP 问题
安装完成后,Anthos clusters on VMware 会在管理员工作站的主目录中生成一个名为 internal-cluster-kubeconfig-debug
的 kubeconfig 文件。此 kubeconfig 文件与管理员集群的 kubeconfig 文件完全相同,只是它直接指向管理员集群的控制层面节点(Kubernetes API 服务器在该节点上运行)。您可以使用 internal-cluster-kubeconfig-debug
文件调试 F5 BIG-IP 问题。
无法调整用户集群的大小
如果调整用户集群的大小失败,请执行以下操作:
找到 MachineDeployments 和 Machines 的名称:
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 地址。然后,删除受影响的 Machine:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME
Anthos clusters on VMware 会创建一个新机器,并为其分配一个新的可用 IP 地址。
已分配足够数量的 IP 地址,但机器无法向集群注册
如果存在 IP 地址冲突,就可能会发生此问题。例如,您为机器指定的 IP 地址被用于负载平衡器。
如需解决此问题,请更新您的集群 IP 地址块文件,这样,机器地址就不会与集群配置文件或 Seesaw IP 地址块文件中指定的地址冲突。
快照会在管理员集群创建或升级失败时自动创建
如果您尝试创建或升级管理员集群,并且该操作失败,则 Anthos Clusters on VMware 会获取引导集群的外部快照,而引导集群是一个用于创建或升级管理员集群的暂时性集群。虽然引导集群的此快照与在管理员集群上运行 gkectl diagnose snapshot
命令截取的快照类似,但它会自动触发。该引导集群的快照包含对管理员集群创建和升级过程的重要调试信息。如果需要,您可以向 Google Cloud 支持团队提供此快照。
升级过程卡住
Anthos Clusters on VMware 在升级期间在后台使用 Kubernetes drain
命令。此 drain
过程可能会被一项部署阻止,该部署只有一个副本,且副本中包含通过 minAvailable: 1
为其创建的 PodDisruptionBudget (PDB)。
在这种情况下,请保存 PDB 并从集群中移除,然后再尝试升级。在升级完成后,您可以重新加回此 PDB。