本主题包括可帮助您对独立管理集群部署进行故障排除的提示。
有关工作负载集群故障排除的信息,请参见工作负载集群问题故障排除。有关此版本中已知问题的其他解决办法,请参见发行说明或 VMware 知识库文章。
以下某些过程使用 kind
CLI。要安装 kind
,请参见 kind
文档中的安装。
可以使用 SSH 连接到独立管理集群或工作负载集群的各个节点。为此,部署管理集群时创建的 SSH 密钥对必须在运行 SSH 命令的计算机上可用。因此,必须在运行 ssh
命令的计算机上运行 tanzu
命令。
在管理集群中注册的 SSH 密钥以及从管理集群部署的任何工作负载集群所使用的 SSH 密钥与以下用户帐户相关联:
capv
ubuntu
ubuntu
ec2-user
capi
要使用 SSH 连接到节点,请从用作引导计算机的计算机运行以下命令之一:
ssh capv@node-address
ssh ubuntu@node-address
ssh ec2-user@node-address
ssh capi@node-address
由于 SSH 密钥位于运行 ssh
命令的系统上,因此不需要密码。
kubectl
删除用户、上下文和集群要通过删除 kubectl
的部分或全部用户、上下文和集群来清理其状态,请执行以下操作:
打开 ~/.kube-tkg/config
文件。
对于要删除的 user
对象,请运行:
kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
其中,USERNAME
是每个顶级 user
对象的 name
属性,如 config
文件中所列。
对于要删除的 context
对象,请运行:
kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
其中,CONTEXT-NAME
是每个顶级 context
对象的 name
属性,如config
文件所列,形式通常为 contexts.mycontext-admin@mycontext
。
对于要删除的 cluster
对象,请运行:
kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
其中,CLUSTER-NAME
是每个顶级 cluster
对象的 name
属性,如 config
文件中所列。
如果 config
文件将当前上下文作为您删除的集群列出,请取消设置上下文:
kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
如果删除了由 tanzu
CLI 跟踪的管理集群,请通过运行 tanzu config server delete
从 tanzu
CLI 中删除集群,如从 Tanzu CLI 配置中删除管理集群中所述。
nfs-utils
问题
在 Tanzu Kubernetes Grid v1.1.2 及更高版本中,默认启用 nfs-utils
。如果不需要 nfs-utils
,则可以将其从集群节点虚拟机中移除。
解决方案
要在使用 Tanzu Kubernetes Grid v1.1.2 或更高版本部署的集群上停用 nfs-utils
,使用 SSH 登录到集群节点虚拟机并运行以下命令:
tdnf erase nfs-utils
问题
运行 tanzu management-cluster create
或 tanzu mc create
失败,并显示类似以下内容的错误:
Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain
Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request
解决方案
Tanzu Kubernetes Grid 使用默认 AWS 凭据提供程序链。在 AWS 上创建管理集群或工作负载集群之前,必须按照配置 AWS 凭据中所述配置 AWS 帐户凭据。
问题
在 Azure 上创建独立管理集群或工作负载集群之前,必须接受涵盖集群节点所用虚拟机映像的法律条款。在未接受许可证的情况下运行 tanzu mc create
或 tanzu cluster create
失败,并显示类似以下内容的错误:
User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.
解决方案
如果发生这种情况,请接受法律条款,然后重试:
问题
如果尝试部署独立管理集群失败,则会在云基础架构和引导计算机上留下孤立的对象。
解决方案
tanzu mc create
命令输出。如果命令失败,则会输出一条包含以下内容的帮助消息:“部署管理集群时失败 (Failure while deploying management cluster)… 要清理管理集群创建的资源,请执行以下操作:tkg delete mc (To clean up the resources created by the management cluster: tkg delete mc.)…。”tanzu mc delete YOUR-CLUSTER-NAME
。此命令将移除它在基础架构和本地中创建的对象。您还可以使用下面所述的替代方法:
引导计算机清理:
要移除 kind
集群,请使用 kind
CLI。例如:
kind get clusters
kind delete cluster --name tkg-kind-example1234567abcdef
要移除 Docker 对象,请使用 docker
CLI。例如,docker rm
、docker rmi
和 docker system prune -a --volumes
。
注意如果运行的 Docker 进程与系统上的 Tanzu Kubernetes Grid 无关,请分别移除不需要的 Docker 对象。
目标平台清理:
AZURE_RESOURCE_GROUP
。使用复选框可选择和删除由 Tanzu Kubernetes Grid 创建的资源,其名称中包含时间戳。问题
在 AWS 上运行 tanzu mc delete
后,tanzu mc get
和其他 Tanzu CLI 命令不再列出已删除的管理集群,但:
cluster infrastructure is still being provisioned: VpcReconciliationFailed
。解决方案
当 TKG 使用过期或无效的 AWS 帐户凭据时,会出现此行为。要防止或从这种情况中恢复,请执行以下操作:
禁止:按照配置 AWS 帐户凭据中所述,使用 AWS 凭据配置文件或本地静态环境变量更新 AWS 帐户凭据。
使用 EC2 仪表板进行恢复:手动从 EC2 仪表板中删除管理集群节点
使用 CLI 进行恢复:
在由于管理集群删除失败而保留在引导计算机上的 kind
集群中,更正 AWS 凭据密钥:
kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
编辑密钥以包括 AWS 凭据:
[default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>
再次运行 tanzu mc delete
。
问题
运行 tanzu mc delete
会移除管理集群,但无法从引导计算机中删除本地 kind
集群。
解决方案
列出所有正在运行的 kind
集群,然后移除类似于 tkg-kind-unique_ID
的集群:
kind delete cluster --name tkg-kind-unique_ID
列出所有正在运行的集群,并确定kind
集群。
docker ps -a
复制 kind
集群的容器 ID 并将其移除。
docker kill container-ID
问题
独立管理集群无法部署,因为计算机停滞,正在等待修复。
解决方案
对于使用 dev
计划部署的管理集群(只有一个控制平面节点),必须重新部署管理集群。对于具有多个控制平面节点的管理集群,您可以确定并删除停滞的计算机。
检索管理集群的状态。例如:
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
从上一步的输出中查找停滞的计算机的名称。停滞的计算机被标记为 WaitingForRemediation
。例如,停滞的计算机的名称在以下输出中为 my-mgmt-cluster-zpc7t
:
status:
conditions:
- lastTransitionTime: "2021-08-25T15:44:23Z"
message: KCP can't remediate if current replicas are less or equal then 1
reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
severity: Warning
status: "False"
type: Ready
将控制平面节点的计算机运行状况检查超时值增加到大于默认值 5m
。例如:
tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
有关更新 MachineHealthCheck
对象的详细信息,请参见《配置工作负载集群的计算机运行状况检查》中的创建或更新 MachineHealthCheck
对象。
将 kubectl
设置为管理集群的上下文。例如:
kubectl config use-context mgmt-cluster-admin@mgmt-cluster
删除停滞的计算机。
kubectl delete machine MACHINE-NAME
其中,MACHINE-NAME
是在前面的步骤中找到的计算机的名称。
等待 KubeadmControlPlane
控制器重新部署计算机。
~/.config/tanzu
目录问题
引导计算机上的 ~/.config/tanzu
目录意外删除或损坏。Tanzu CLI 会创建并使用此目录,如果没有此目录,将无法正常运行。
解决方案
要还原 ~/.config/tanzu
目录的内容,请执行以下操作:
要确定现有 Tanzu Kubernetes Grid 管理集群,请运行:
kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
命令输出列出了 Tanzu CLI 创建或添加的所有管理集群的名称和上下文。
对于输出中列出的每个管理集群,通过运行以下命令将其还原到 ~/.config/tanzu
目录和 CLI:
tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
tanzu management-cluster
创建导致 kubectl 版本错误问题
如果在具有最新稳定版本的 Docker 桌面的 macOS 上运行 tanzu management-cluster create
或 tanzu mc create
命令,该命令将失败,并显示类似以下内容的错误消息:
Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.25.7
发生这种情况的原因是,Docker 桌面将旧版本的 kubectl
符号链接到路径中。
解决方案
将较新的受支持版本 kubectl
放置在 Docker 版本之前的路径中。
如果丢失了独立管理集群的凭据,例如,无意中删除了运行 tanzu
命令的系统上的 .kube-tkg/config
文件,则可以从管理集群控制平面节点恢复凭据。
tanzu mc create
以重新创建 .kube-tkg/config
文件。使用 SSH 登录到管理集群控制平面节点。
有关用于每个目标平台的凭据,请参见上面的使用 SSH 连接到集群节点。
访问管理集群的 admin.conf
文件。
sudo vi /etc/kubernetes/admin.conf
admin.conf
文件包含集群名称、集群用户名、集群上下文和客户端证书数据。
tanzu
命令的系统上的 .kube-tkg/config
文件中。VSPHERE_CONTROL_PLANE_ENDPOINT
值问题
要将外部身份提供程序与现有 TKG 部署集成在一起,可能需要在用于创建附加项密钥的管理集群配置文件中设置伪 VSPHERE_CONTROL_PLANE_ENDPOINT
值,如 为管理集群生成 Pinniped 附加项密钥中所述
Secret
问题
在管理集群上停用外部身份管理时,未使用的 Pinniped Secret
对象仍存在于旧版工作负载集群上。
如果用户随后尝试使用旧的 kubeconfig
访问集群,则会显示登录弹出窗口并失败。
解决办法
手动删除旧版集群的 Pinniped Secret
,如停用身份管理中所述。
问题
升级到 Tanzu Kubernetes Grid v2.2 会返回类似以下内容的错误:
Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again
解决方案
如果 Pinniped 部署后作业与组件的升级过程冲突,则可能会出现此错误。请按照以下步骤删除并重新部署作业。
删除 Pinniped 部署后作业。
kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
等待kapp-controller
大约 5 分钟,以对部署后作业重新部署。
检查 Prometheus 应用的状态。
kubectl get app -n tkg-system pinniped
NAME DESCRIPTION SINCE-DEPLOY AGE
pinniped Reconcile succeeded 5s 49m
如果 DESCRIPTION
显示 Reconciling
,请等待几分钟,然后再次检查。如果显示 ,Reconcile succeeded
,请继续执行下一步。
检查 Pinniped 部署后作业的状态。
kubectl get jobs -n pinniped-supervisor
NAME COMPLETIONS DURATION AGE
pinniped-post-deploy-job-ver-1 1/1 9s 62s
问题
您最近升级了管理集群。尝试对此管理集群关联的工作负载集群进行身份验证时,您会收到类似以下内容的错误消息:
Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority
解决方案
发生这种情况的原因是,工作负载集群正在使用的 Pinniped 主管 CA 包的副本已过期。要更新主管 CA 包,请执行以下步骤:
将 kubectl
上下文设置为管理集群。
从 pinniped-info
ConfigMap 中获取 base64 编码的 CA 包和 issuer
端点:
kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
从工作负载集群的 Pinniped 附加项密钥中获取 values.yaml
部分:
kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
此密钥位于管理集群上。
在上面创建的 values.yaml
文件中,更新 supervisor_ca_bundle_data
秘钥以匹配 pinniped-info
ConfigMap 中的 CA 包。此外,请确保 supervisor_svc_endpoint
与 issuer
端点相匹配。
通过对编辑的 values.yaml
文件进行 base64 编码应用更新,并在工作负载集群密钥中替换该文件。此命令因环境的操作系统而异:例如:
Linux:
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
MacOS:
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
在工作负载集群上,确认 Pinniped 应用已成功协调更改:
kubectl get app pinniped -n tkg-system
对集群进行身份验证:例如:
kubectl get pods -A --kubeconfig my-cluster-credentials
问题
在创建的集群上运行 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 中的 vSphere 列表。
问题
运行 tanzu
CLI 命令返回类似以下内容的错误:
Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying
解决方案
请参见更新 Tanzu CLI 配置中的管理集群证书和无法在 Tanzu Kubernetes Grid 中使用 tkg/tanzu cli 命令访问集群。
问题
在 Windows 命令提示符 (CMD) 中,Tanzu 列格式化的 CLI 命令输出在列标题中包含无关字符。Windows 终端或 PowerShell 中不会出现此问题。
解决方案
在 Windows 引导计算机上,从 Windows 终端运行 Tanzu CLI。
问题
停用计算机运行状况检查 (MHC) 后,Tanzu CLI 命令(如 tanzu cluster status
)在重新创建基础架构时可能不会报告最新的节点状态。
解决方案
无。
问题
在 Windows 系统上运行 tanzu management-cluster create --ui
或 tanzu mc create --ui
命令时,UI 将在默认浏览器中打开,但不会应用图形和样式。发生这种情况的原因是,Windows 注册表设置为 application/x-css
。
解决方案
regedit
以打开注册表编辑器实用程序。HKEY_CLASSES_ROOT
,然后选择 .js
。application/javascript
,然后单击确定 (OK)。tanzu mc create --ui
命令以重新启动 UI。问题
如果对工作负载 (AVI_ENABLE
) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER
) 使用 NSX Advanced Load Balancer,Avi 控制器可能无法区分名称相同的集群。
解决方案:
为每个集群设置唯一的 CLUSTER_NAME
值:即使从不同的引导计算机创建多个管理集群,也不要使用相同的 CLUSTER_NAME
值。
问题
如果 LoadBalancer
类型的服务总数很大,并且所有服务引擎都部署在同一 L2 网络中,则向 NSX Advanced Load Balancer VIP 发出的请求可能会失败,并显示消息“no route to host
”。
出现此问题的原因是,服务引擎上的默认 ARP 速率限制为 100。
解决方案
将 ARP 速率限制设置为更大的数字。此参数在 NSX Advanced Load Balancer Essentials 中不是可调参数,但在 NSX Advanced Load Balancer Enterprise Edition 中是可调参数。
AKODeploymentConfig
错误问题
运行 tanzu management-cluster create
以创建具有 NSX ALB 的管理集群,会输出错误 no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???
。
解决方案
可以忽略该错误。有关更多信息,请参见此知识库文章。
medium
和具有 NSX Advanced Load Balancer 的较小 Pod 上失败问题
在 vSphere 上,运行带有 NSX ALB 的 Multus CNI 软件包的 medium
或较小工作节点的工作负载群集可能会失败,并显示 Insufficient CPU
或其他错误。
解决方案
要将 Multus CNI 与 NSX ALB 结合使用,请部署具有 large
或 extra-large
的工作节点的工作负载集群。
问题
在 Azure 上,升级管理集群和工作负载集群失败,并显示 context deadline exceeded
或 unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane
等错误。发生这种情况的原因是,Azure 上的操作有时比其他平台上所需的时间长。
解决方案
再次运行 tanzu management-cluster upgrade
或 tanzu cluster upgrade
,在 --timeout
标记中指定更长的超时。默认超时为 30m0s。
问题
在 TKG v2.2 中,将通用集群转换为 TKG 独立管理集群的组件打包在 Carvel 软件包 tkg-pkg
中。最初在 TKG v1.3 或更低版本中创建的独立管理集群缺少升级过程中安装 tkg-pkg
所需的配置密钥,从而导致升级失败。
解决方案
对于在 TKG v1.3 或更低版本中创建的独立管理集群,请执行升级独立管理集群中列出的其他步骤。