本节包含可帮助您对工作负载集群进行故障排除的提示。有关对独立管理集群部署进行故障排除的信息,请参见管理集群问题故障排除。
kubectl
删除用户、上下文和集群要通过删除 kubectl
的部分或全部用户、上下文和集群来清理其状态,请执行以下操作:
打开 ~/.kube/config
文件。
对于要删除的 user
对象,请运行:
kubectl config unset users.USER-NAME
其中,USER-NAME
是每个顶级 user
对象的 name
属性,如 config
文件中所列。
对于要删除的 context
对象,请运行:
kubectl config unset contexts.CONTEXT-NAME
其中,CONTEXT-NAME
是每个顶级 context
对象的 name
属性,如 config
文件所列,通常格式为 contexts.mycontext-admin@mycontext
。
对于要删除的 cluster
对象,请运行:
kubectl config unset clusters.CLUSTER-NAME
其中,CLUSTER-NAME
是每个顶级 cluster
对象的 name
属性,如 config
文件中所列。
如果 config
文件将当前上下文作为您删除的集群列出,请取消设置上下文:
kubectl config unset current-context
问题
如果尝试通过生成默认 Grafana 配置文件来安装 Grafana,安装将失败并显示 error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest)
。
解决方案
手动创建密钥,并使用不带密钥标记的同一 YAML 文件安装 Grafana。
grafana.secret.*
条目。手动创建秘钥。
kubectl create secret generic grafana -n tanzu-system-dashboards --from-literal=admin=admin
部署软件包。
tanzu package install grafana \
--package grafana.tanzu.vmware.com \
--version AVAILABLE-PACKAGE-VERSION \
--values-file grafana-data-values.yaml \
--namespace TARGET-NAMESPACE
tanzu package repository
时出现错误问题
tanzu package repository
命令失败并显示错误。
解决方案
运行 kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml
以获取有关错误的详细信息。
其中:
REPOSITORY-NAME
是软件包存储库的名称。NAMESPACE
是软件包存储库的目标命名空间。命令 tanzu package repository
可能会失败,并显示类似以下内容的错误:
错误 | 描述 | 解决方案 |
---|---|---|
NOT_FOUND |
存储库 URL 路径无效。 | 确保可从集群访问软件包存储库的 URL。 |
UNKNOWN 或 UNAUTHORIZED |
尝试连接到存储库时,可能会出现此错误。 | |
Ownership |
集群中已安装具有相同软件包存储库 URL 的存储库。 | 执行以下其中一项:
|
tanzu package installed
时出现错误问题
tanzu package installed
命令失败并显示错误。
解决方案
运行 kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml
以获取有关错误的详细信息。
其中:
INSTALLED-PACKAGE-NAME
是已安装软件包的名称。NAMESPACE
是已安装软件包的命名空间。命令 tanzu package installed
可能会失败,并显示类似以下内容的错误:
错误 | 描述 | 解决方案 |
---|---|---|
Ownership |
集群中已安装具有相同名称的软件包。 | 运行 tanzu package installed list -A 以检查是否已安装要安装的软件包。如果已安装,您可能希望使用已安装的软件包、更新其版本或删除软件包以继续安装。 |
Evaluating starlark template |
缺少列出的配置值时,可能会出现此错误。 | 运行 tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE –values-schema 以查看所有可用的配置值,并向 tanzu package install 命令提供所需的配置值。 |
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE |
指定的软件包和软件包元数据在目标命名空间中不可用。 | 确保指定的软件包列在 tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE 的输出中。如果没有,请将包含软件包的软件包存储库添加到目标命名空间。 |
Namespace NAMESPACE not found |
要在其中安装软件包的命名空间不存在。 | 在 TKG v2.1 中,tanzu package 命令基于 kctrl 并且不再支持 —create-namespace 标记。在安装软件包或软件包存储库之前,目标命名空间必须已存在。 |
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE |
带有 service-account-name 标记的服务帐户已由另一个已安装的软件包使用。 |
允许软件包插件为您创建服务帐户,或者选择其他服务帐户名称。 |
问题
在创建的集群上运行 kubectl get pods -A
时,某些 Pod 仍处于挂起状态。
在受影响的 pod 上运行 kubectl describe pod -n pod-namespace pod-name
并看到以下事件:
n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate
解决方案
确保已实施连接和防火墙规则,以确保集群与 vCenter 之间存在通信。有关防火墙端口和协议要求,请参阅 VMware Ports and Protocols 中的 vSphere8 列表。
问题
运行 tanzu cluster create
失败,并显示类似于以下内容的超时错误:
I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]
解决方案
使用 --timeout
标记指定等待集群创建完成的时间。默认等待时间为 30 分钟。
tanzu cluster create --timeout TIME
其中 TIME
是等待集群创建完成的时间长度(以分钟为单位)。例如,60m
。
问题
tanzu cluster delete
无法删除工作负载集群。
要手动删除集群,请参见下面的两个解决方案。
解决方案 1
在目标集群上,删除在 avi-system
命名空间中运行的 AKO 的 StatefulSet 对象:
kubectl delete sts ako -n avi-system
解决方案 2
登录到集群并删除工作线程计算机:
kubectl delete machine worker1 worker2
在 vCenter 中,关闭工作节点虚拟机的电源并将其删除。
编辑控制平面计算机并移除“完成器”链接:
finalizers:
- machine.cluster.x-k8s.io
删除控制平面计算机:
kubectl delete machine controlplane1 controlplane2
在 vCenter 中,关闭控制平面虚拟机的电源并将其删除
问题
集群中工作节点上的最大传输单元 (MTU) 设置不同会导致 TLS 握手超时。
节点上 journalctl -u kubelet
中的日志显示与 API 服务器的通信失败。运行 kubectl get nodes
显示工作节点已变为 NotReady 状态。
您可以通过执行以下操作重新确认该问题:
ip link
并比较 eth0
接口的 MTU 值。如果不匹配,则表明存在此问题。确认在处于 NotReady 节点状态的计算机上运行以下命令时,这些命令失败:
openssl s_client -connect IP:PORT
curl IP:PORT -k /healthz
其中,IP
和 PORT
是 Kubernetes API 服务器控制平面端点的 IP 地址和端口号。默认情况下,PORT
设置为 6443
。
解决方案
查看集群上部署的特权守护进程集,并查看可能修改主机操作系统的网络配置的第三方供应商提供的任何守护进程集。您可能需要咨询软件供应商以了解这一点。可以修改主机操作系统的守护进程集将在任何容器安全上下文的功能(capabilities) 字段中具有 .spec.template.spec.hostNetwork: true
或 privileged: true
或 NET_ADMIN
。
如果要配置较大的 MTU 设置,请使用具有较高 MTU 值的控制平面置备集群。
确保集群网络允许路径 MTU 发现或具有 TCP MSS 限制,以便对外部服务(如 vCenter 或容器注册表)进行正确的 MTU 大小调整。
确保为集群中的所有节点配置相同的 MTU 设置。
网络防火墙设置必须允许配置 MTU 大小的数据包。