管理集群问题故障排除

本主题包括可帮助您对独立管理集群部署进行故障排除的提示。

有关工作负载集群故障排除的信息，请参见工作负载集群问题故障排除。有关此版本中已知问题的其他解决办法，请参见发行说明或 VMware 知识库文章。

必备条件

以下某些过程使用 kind CLI。要安装 kind，请参见 kind 文档中的安装。

087bf3b4（更新 Ghost 的 RN (#1178)）

常见任务

使用 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 的部分或全部用户、上下文和集群来清理其状态，请执行以下操作：

打开 ~/.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 context 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 管理集群部署和升级期间，CAPA 资源标记问题导致协调失败

问题

由于上游集群 API 提供程序 AWS (CAPA) 中的资源标记问题，脱机部署无法访问 ResourceTagging API，从而导致在创建或升级管理集群期间出现协调失败。

解决方案

在脱机 AWS 环境中，先在本地环境或管理集群配置文件中设置 EXP_EXTERNAL_RESOURCE_GC=false，然后再运行 tanzu mc create 或 tanzu mc upgrade。

验证失败，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.

解决方案

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

管理集群：请参见接受基础映像许可证
工作负载集群：请参见部署具有非默认 Kubernetes 版本的集群中的 Azure 说明。

管理集群

管理集群部署失败后清理

问题

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

解决方案

在终端或 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.)…。”
运行 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 进行恢复：

在由于管理集群删除失败而保留在引导计算机上的 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。

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

问题

运行 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 context create --management-cluster --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.27.5

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

解决方案

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

恢复管理集群凭据

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

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

有关用于每个目标平台的凭据，请参见上面的使用 SSH 连接到集群节点。
访问管理集群的 admin.conf 文件。
```
sudo vi /etc/kubernetes/admin.conf
```
admin.conf 文件包含集群名称、集群用户名、集群上下文和客户端证书数据。
将集群名称、集群用户名、集群上下文和客户端证书数据复制到运行 tanzu 命令的系统上的 .kube-tkg/config 文件中。

Pinniped

将外部身份管理添加到现有部署可能需要设置伪 `VSPHERE_CONTROL_PLANE_ENDPOINT` 值

问题

要将外部身份提供程序与现有 TKG 部署集成在一起，可能需要在用于创建附加项密钥的管理集群配置文件中设置伪 VSPHERE_CONTROL_PLANE_ENDPOINT 值，如为管理集群生成 Pinniped 附加项密钥中所述

停用 Pinniped 需要在旧版集群上手动删除 `Secret`

问题

在管理集群上停用外部身份管理时，未使用的 Pinniped Secret 对象仍存在于旧版工作负载集群上。

如果用户随后尝试使用旧的 kubeconfig 访问集群，则会显示登录弹出窗口并失败。

解决办法

手动删除旧版集群的 Pinniped Secret，如停用身份管理中所述。

部署后 Pinniped 作业失败

问题

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

 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

升级管理集群后，工作负载集群上出现 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 包，请执行以下步骤：

将 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

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

解决方案

请参见更新 Tanzu CLI 配置中的管理集群证书和无法在 Tanzu Kubernetes Grid 中使用 tkg/tanzu cli 命令访问集群。

Windows CMD：CLI 输出列标题中的无关字符

问题

在 Windows 命令提示符 (CMD) 中，Tanzu 列格式化的 CLI 命令输出在列标题中包含无关字符。Windows 终端或 PowerShell 中不会出现此问题。

解决方案

在 Windows 引导计算机上，从 Windows 终端运行 Tanzu CLI。

在停用 MHC 时，CLI 暂时错误地报告最近删除的节点的状态

问题

停用计算机运行状况检查 (MHC) 后，Tanzu CLI 命令（如 tanzu cluster status）在重新创建基础架构时可能不会报告最新的节点状态。

解决方案

无。

Tanzu Kubernetes Grid 安装程序界面

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

问题

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

解决方案

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

NSX Advanced Load Balancer

使用 NSX ALB 时，您无法创建具有相同名称的集群

问题

如果对工作负载 (AVI_ENABLE) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER) 使用 NSX Advanced Load Balancer，Avi 控制器可能无法区分名称相同的集群。

解决方案:

为每个集群设置唯一的 CLUSTER_NAME 值：即使从不同的引导计算机创建多个管理集群，也不要使用相同的 CLUSTER_NAME 值。

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

创建管理集群期间出现可忽略的 `AKODeploymentConfig` 错误

问题

运行 tanzu management-cluster create 以创建具有 NSX ALB 的管理集群，会输出错误 no matches for kind AKODeploymentConfig in version networking.tkg.tanzu.vmware.com/v1alpha1。

解决方案

可以忽略该错误。有关更多信息，请参见此知识库文章。

Multus CNI 在 `medium` 和具有 NSX Advanced Load Balancer 的较小 Pod 上失败

问题

在 vSphere 上，运行带有 NSX ALB 的 Multus CNI 软件包的 medium 或较小工作节点的工作负载群集可能会失败，并显示 Insufficient CPU 或其他错误。

解决方案

要将 Multus CNI 与 NSX ALB 结合使用，请部署具有 large 或 extra-large 的工作节点的工作负载集群。

升级

在 Azure 上升级集群失败

问题

在 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 v1.3 或更低版本中创建的独立管理集群，升级失败

问题

在 TKG v2.4 中，将通用集群转换为 TKG 独立管理集群的组件打包在 Carvel 软件包 tkg-pkg 中。最初在 TKG v1.3 或更低版本中创建的独立管理集群缺少升级过程中安装 tkg-pkg 所需的配置密钥，从而导致升级失败。

解决方案

对于在 TKG v1.3 或更低版本中创建的独立管理集群，请执行升级独立管理集群中列出的其他步骤。

管理集群问题故障排除

必备条件

常见任务

使用 SSH 连接到集群节点

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

在 Photon OS 节点上停用 nfs-utils

目标平台

在 AWS 管理集群部署和升级期间，CAPA 资源标记问题导致协调失败

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

验证失败，Azure 上出现法律条款错误

管理集群

管理集群部署失败后清理

无法删除 AWS 上的管理集群

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

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

还原 ~/.config/tanzu 目录

在 macOS 上运行 tanzu management-cluster 创建导致 kubectl 版本错误

恢复管理集群凭据

Pinniped

将外部身份管理添加到现有部署可能需要设置伪 VSPHERE_CONTROL_PLANE_ENDPOINT 值

停用 Pinniped 需要在旧版集群上手动删除 Secret

部署后 Pinniped 作业失败

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

Pod

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

Tanzu CLI

Tanzu CLI 无法访问管理集群

Windows CMD：CLI 输出列标题中的无关字符

在停用 MHC 时，CLI 暂时错误地报告最近删除的节点的状态

Tanzu Kubernetes Grid 安装程序界面

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

NSX Advanced Load Balancer

使用 NSX ALB 时，您无法创建具有相同名称的集群

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

创建管理集群期间出现可忽略的 AKODeploymentConfig 错误

Multus CNI 在 medium 和具有 NSX Advanced Load Balancer 的较小 Pod 上失败

升级

在 Azure 上升级集群失败

对于最初在 TKG v1.3 或更低版本中创建的独立管理集群，升级失败

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

在 Photon OS 节点上停用 `nfs-utils`

还原 `~/.config/tanzu` 目录

在 macOS 上运行 `tanzu management-cluster` 创建导致 kubectl 版本错误

将外部身份管理添加到现有部署可能需要设置伪 `VSPHERE_CONTROL_PLANE_ENDPOINT` 值

停用 Pinniped 需要在旧版集群上手动删除 `Secret`

创建管理集群期间出现可忽略的 `AKODeploymentConfig` 错误

Multus CNI 在 `medium` 和具有 NSX Advanced Load Balancer 的较小 Pod 上失败