管理集群问题故障排除

本主题包括可帮助您对独立管理集群部署进行故障排除的提示。以下某些过程使用 kind CLI。要安装 kind，请参见 kind 文档中的安装。有关工作负载集群故障排除的信息，请参见工作负载集群问题故障排除。

常见任务

使用 SSH 连接到集群节点

可以使用 SSH 连接到独立管理集群或工作负载集群的各个节点。为此，部署管理集群时创建的 SSH 密钥对必须在运行 SSH 命令的计算机上可用。因此，必须在运行 ssh 命令的计算机上运行 tanzu 命令。

在管理集群中注册的 SSH 密钥以及从管理集群部署的任何工作负载集群所使用的 SSH 密钥与以下用户帐户相关联：

  • 在 Photon OS 和 Ubuntu 上运行 vSphere 管理集群和 Tanzu Kubernetes 节点： capv
  • AWS bastion 节点：ubuntu
  • 在 Ubuntu 上运行的 AWS 管理集群和 Tanzu Kubernetes 节点：ubuntu
  • 在 Amazon Linux 上运行的 AWS 管理集群和 Tanzu Kubernetes 节点：ec2-user
  • Azure 管理集群和 Tanzu Kubernetes 节点（始终为 Ubuntu）：capi

要使用 SSH 连接到节点，请从用作引导计算机的计算机运行以下命令之一：

  • vSphere 节点：ssh capv@node-address
  • Ubuntu 上的 AWS bastion 节点以及管理集群和工作负载节点：ssh ubuntu@node-address
  • 在 Amazon Linux 上运行的 AWS 管理集群和 Tanzu Kubernetes 节点：ssh ec2-user@node-address
  • Azure 节点：ssh capi@node-address

由于 SSH 密钥位于运行 ssh 命令的系统上，因此不需要密码。

使用 kubectl 删除用户、上下文和集群

要通过删除 kubectl 的部分或全部用户、上下文和集群来清理其状态，请执行以下操作：

  1. 打开 ~/.kube-tkg/config 文件。

  2. 对于要删除的 user 对象，请运行：

    kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config

    其中，USERNAME 是每个顶级 user 对象的 name 属性，如 config 文件中所列。

  3. 对于要删除的 context 对象，请运行：

    kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config

    其中，CONTEXT-NAME 是每个顶级 context 对象的 name 属性，如config文件所列，形式通常为 contexts.mycontext-admin@mycontext。

  4. 对于要删除的 cluster 对象，请运行：

    kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config

    其中，CLUSTER-NAME 是每个顶级 cluster 对象的 name 属性，如 config 文件中所列。

  5. 如果 config 文件将当前上下文作为您删除的集群列出，请取消设置上下文：

    kubectl config unset current-context --kubeconfig ~/.kube-tkg/config

  6. 如果删除了由 tanzu CLI 跟踪的管理集群，请通过运行 tanzu config server delete 从 tanzu CLI 中删除集群，如从 Tanzu CLI 配置中删除管理集群中所述。

在 Photon OS 节点上停用 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

目标平台

验证失败，AWS 上的凭据错误

问题

运行 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 上出现法律条款错误

问题

在 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.

解决方案

如果发生这种情况，请接受法律条款，然后重试：

管理集群

管理集群部署失败后清理

问题

如果尝试部署独立管理集群失败，则会在云基础架构和引导计算机上留下孤立的对象。

解决方案

  1. 在终端或 Tanzu Kubernetes Grid 安装程序界面中监控 tanzu mc create 命令输出。如果命令失败，则会输出一条包含以下内容的帮助消息：“部署管理集群时失败 (Failure while deploying management cluster)… 要清理管理集群创建的资源，请执行以下操作：tkg delete mc (To clean up the resources created by the management cluster: tkg delete mc.)…。”
  2. 运行 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 对象。

  • 目标平台清理：

    • vSphere：找到、关闭电源和删除由 Tanzu Kubernetes Grid 创建的虚拟机和其他资源。
    • AWS：登录到 Amazon EC2 仪表板，然后手动删除资源或使用自动化解决方案。
    • Azure：在资源组 (Resource Groups) 中，打开AZURE_RESOURCE_GROUP。使用复选框可选择和删除由 Tanzu Kubernetes Grid 创建的资源，其名称中包含时间戳。

无法删除 AWS 上的管理集群

问题

在 AWS 上运行 tanzu mc delete 后，tanzu mc get 和其他 Tanzu CLI 命令不再列出已删除的管理集群，但：

  • 不会从 AWS 基础架构中删除集群，并且其节点仍显示在 Amazon EC2 仪表板中
  • 管理集群日志显示错误 cluster infrastructure is still being provisioned: VpcReconciliationFailed。

解决方案

当 TKG 使用过期或无效的 AWS 帐户凭据时，会出现此行为。要防止或从这种情况中恢复，请执行以下操作：

  • 禁止：按照配置 AWS 帐户凭据中所述，使用 AWS 凭据配置文件或本地静态环境变量更新 AWS 帐户凭据。

    • 无法使用 AWS 实例配置文件凭据删除管理集群。

  • 使用 EC2 仪表板进行恢复：手动从 EC2 仪表板中删除管理集群节点

  • 使用 CLI 进行恢复：

    1. 在由于管理集群删除失败而保留在引导计算机上的 kind 集群中，更正 AWS 凭据密钥：

      kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d

    2. 编辑密钥以包括 AWS 凭据：

      [default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>

    3. 再次运行 tanzu mc delete。

删除管理集群后保留的 Kind 集群

问题

运行 tanzu mc delete会移除管理集群，但无法从引导计算机中删除本地 kind 集群。

解决方案

  1. 列出所有正在运行的 kind 集群，然后移除类似于 tkg-kind-unique_ID 的集群：

    kind delete cluster --name tkg-kind-unique_ID

  2. 列出所有正在运行的集群，并确定kind集群。

    docker ps -a

  3. 复制 kind 集群的容器 ID 并将其移除。

    docker kill container-ID

管理集群部署失败后计算机停滞

问题

独立管理集群无法部署，因为计算机停滞，正在等待修复。

解决方案

对于使用 dev 计划部署的管理集群（只有一个控制平面节点），必须重新部署管理集群。对于具有多个控制平面节点的管理集群，您可以确定并删除停滞的计算机。

  1. 检索管理集群的状态。例如：

    kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml

  2. 从上一步的输出中查找停滞的计算机的名称。停滞的计算机被标记为 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

  3. 将控制平面节点的计算机运行状况检查超时值增加到大于默认值 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 对象。

  4. 将 kubectl 设置为管理集群的上下文。例如：

    kubectl config use-context mgmt-cluster-admin@mgmt-cluster

  5. 删除停滞的计算机。

    kubectl delete machine MACHINE-NAME

    其中，MACHINE-NAME 是在前面的步骤中找到的计算机的名称。

  6. 等待 KubeadmControlPlane 控制器重新部署计算机。

还原 ~/.config/tanzu 目录

问题

引导计算机上的 ~/.config/tanzu 目录意外删除或损坏。Tanzu CLI 会创建并使用此目录，如果没有此目录，将无法正常运行。

解决方案

要还原 ~/.config/tanzu 目录的内容，请执行以下操作：

  1. 要确定现有 Tanzu Kubernetes Grid 管理集群，请运行：

    kubectl --kubeconfig ~/.kube-tkg/config config get-contexts

    命令输出列出了 Tanzu CLI 创建或添加的所有管理集群的名称和上下文。

  2. 对于输出中列出的每个管理集群，通过运行以下命令将其还原到 ~/.config/tanzu 目录和 CLI：

    tanzu login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER

在 macOS 上运行 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.24.10

发生这种情况的原因是，Docker 桌面将旧版本的 kubectl 符号链接到路径中。

解决方案

将较新的受支持版本 kubectl 放置在 Docker 版本之前的路径中。

恢复管理集群凭据

如果丢失了独立管理集群的凭据，例如，无意中删除了运行 tanzu 命令的系统上的 .kube-tkg/config 文件，则可以从管理集群控制平面节点恢复凭据。

  1. 运行 tanzu mc create 以重新创建 .kube-tkg/config 文件。
  2. 从 vSphere、AWS 或 Azure 获取管理集群控制平面节点的公用 IP 地址。

  3. 使用 SSH 登录到管理集群控制平面节点。

    有关用于每个目标平台的凭据，请参见上面的使用 SSH 连接到集群节点。

  4. 访问管理集群的 admin.conf 文件。

    sudo vi /etc/kubernetes/admin.conf

    admin.conf 文件包含集群名称、集群用户名、集群上下文和客户端证书数据。

  5. 将集群名称、集群用户名、集群上下文和客户端证书数据复制到运行 tanzu 命令的系统上的 .kube-tkg/config 文件中。

Pinniped

部署后 Pinniped 作业失败

问题

升级到 Tanzu Kubernetes Grid v2.1.1 返回类似以下内容的错误：

 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 部署后作业与组件的升级过程冲突，则可能会出现此错误。请按照以下步骤删除并重新部署作业。

  1. 删除 Pinniped 部署后作业。

    kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job

  2. 等待kapp-controller大约 5 分钟，以对部署后作业重新部署。

  3. 检查 Prometheus 应用的状态。

    kubectl get app -n tkg-system pinniped
NAME       DESCRIPTION           SINCE-DEPLOY   AGE
pinniped   Reconcile succeeded   5s             49m

    如果 DESCRIPTION 显示 Reconciling，请等待几分钟，然后再次检查。如果显示 ，Reconcile succeeded，请继续执行下一步。

  4. 检查 Pinniped 部署后作业的状态。

    kubectl get jobs -n pinniped-supervisor
NAME                             COMPLETIONS   DURATION   AGE
pinniped-post-deploy-job-ver-1   1/1           9s         62s

升级管理集群后，工作负载集群上出现 Pinniped 身份验证错误

问题

您最近升级了管理集群。尝试对此管理集群关联的工作负载集群进行身份验证时，您会收到类似以下内容的错误消息：

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 包，请执行以下步骤：

  1. 将 kubectl 上下文设置为管理集群。

  2. 从 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

  3. 从工作负载集群的 Pinniped 附加项密钥中获取 values.yaml 部分：

    kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

    此密钥位于管理集群上。

  4. 在上面创建的 values.yaml 文件中，更新 supervisor_ca_bundle_data 秘钥以匹配 pinniped-info ConfigMap 中的 CA 包。此外，请确保 supervisor_svc_endpoint 与 issuer 端点相匹配。

  5. 通过对编辑的 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

  6. 在工作负载集群上，确认 Pinniped 应用已成功协调更改：

    kubectl get app pinniped -n tkg-system

  7. 对集群进行身份验证：例如：

    kubectl get pods -A --kubeconfig my-cluster-credentials

Pod

由于 vCenter 连接，Pod 在集群上停滞在挂起状态

问题

在创建的集群上运行 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

Tanzu CLI 无法访问管理集群

问题

运行 tanzu CLI 命令返回类似以下内容的错误：

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

解决方案

这是一个影响 TKG v1.2 及更高版本的已知问题。有关解决办法，请参见更新 Tanzu CLI 配置中的管理集群证书和无法在 Tanzu Kubernetes Grid 中使用 tkg/tanzu cli 命令访问集群。

Tanzu Kubernetes Grid 安装程序界面

Tanzu Kubernetes Grid UI 在 Windows 上无法正确显示

问题

在 Windows 系统上运行 tanzu management-cluster create --ui 或 tanzu mc create --ui 命令时，UI 将在默认浏览器中打开，但不会应用图形和样式。发生这种情况的原因是，Windows 注册表设置为 application/x-css。

解决方案

  1. 在 Windows 搜索中，输入 regedit 以打开注册表编辑器实用程序。
  2. 展开 HKEY_CLASSES_ROOT，然后选择 .js。
  3. 右键单击内容类型 (Content Type) 并选择修改 (Modify)。
  4. 将该值设置为 application/javascript，然后单击确定 (OK)。
  5. 再次运行 tanzu mc create --ui 命令以重新启动 UI。

NSX Advanced Load Balancer

向 NSX Advanced Load Balancer VIP 发出的请求失败，并显示消息“没有到主机的路由 (no route to host)”

问题

如果 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 中是可调参数。

check-circle-line exclamation-circle-line close-line
Scroll to top icon