排查集群创建或升级问题

本页面介绍如何解决与安装或升级 Google Distributed Cloud 集群相关的问题。

如果您需要其他帮助,请与 Cloud Customer Care 联系。

安装问题

以下部分可能有助于您排查与安装 Google Distributed Cloud 相关的问题。

暂时性错误消息

Google Distributed Cloud 的安装过程是一个持续的协调循环。因此,在安装时,您可能会在日志中看到暂时性错误消息。

只要安装成功,您就可以放心地忽略这些错误。下面列出了典型的暂时性错误日志消息:

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused
  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused
  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF
  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

如果您的 Google Cloud 服务帐号密钥已过期,您会看到 bmctl 发出的以下错误消息:

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

您需要生成新的服务帐号密钥

使用引导集群调试问题

当 Google Distributed Cloud 创建自行管理(管理员、混合或独立)集群时,它会部署 Docker in Docker(种类)集群,以临时托管创建集群所需的 Kubernetes 控制器。此暂时性集群称为引导集群。用户集群由其管理员或混合集群创建和升级,无需使用引导集群。

如果尝试安装时部署中已存在种类集群,Google Distributed Cloud 会删除现有的种类集群。只有在安装或升级成功后,系统才会执行删除操作。如需在成功后保留现有的 kind 集群,请使用 bmctl--keep-bootstrap-cluster 标志。

Google Distributed Cloud 会在 WORKSPACE_DIR/.kindkubeconfig 下为引导集群创建配置文件。您只能在集群创建和升级期间连接到引导集群。

引导集群需要访问 Docker 代码库以拉取映像。除非您使用私有注册表,否则注册表默认为 Container Registry。在集群创建期间,bmctl 会创建以下文件:

  • bmctl-workspace/config.json:包含注册表访问权限的 Google Cloud 服务账号凭据。凭据是从集群配置文件中的 gcrKeyPath 字段获取的。

  • bmctl-workspace/config.toml:包含 kind 集群中的 containerd 配置。

检查引导集群日志

如需调试引导集群,您可以执行以下步骤:

  • 在集群创建和升级期间连接到引导集群。
  • 获取引导集群的日志。

您可以在用于运行 bmctl 的机器的以下文件夹中找到日志:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

CLUSTER_NAMETIMESTAMP 替换为您的集群名称和相应系统的时间。

如需直接获取引导集群的日志,您可以在集群创建和升级期间运行以下命令:

docker exec -it bmctl-control-plane bash

该命令会在引导集群中运行的 bmctl 控制层面容器内打开一个终端。

要检查 kubeletcontainerd 日志,请使用以下命令并查找输出中的错误或警告:

journalctl -u kubelet
journalctl -u containerd

集群升级问题

在升级 Google Distributed Cloud 集群时,您可以监控进度并检查集群和节点的状态。

以下指南可帮助您确定升级是继续正常进行还是出现问题。

监控升级进度

使用 kubectl describe cluster 命令查看集群在升级过程中的状态:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

替换以下值:

  • CLUSTER_NAME:您的集群的名称。
  • CLUSTER_NAMESPACE:集群的命名空间。
  • ADMIN_KUBECONFIG:管理员 kubeconfig 文件。
    • 默认情况下,管理员集群、混合集群和独立集群使用就地升级。如果您将 --use-bootstrap=true 标志与 bmctl upgrade 命令结合使用,升级操作将使用引导集群。如需在使用引导集群时监控升级进度,请指定引导集群 kubeconfig 文件 .kindkubeconfig 的路径。此文件位于工作区目录中。

查看输出的 Status 部分,该部分显示集群升级状态的汇总。如果集群报告错误,请使用以下部分进行问题排查。

检查节点是否已准备就绪

在升级过程中,使用 kubectl get nodes 命令查看集群中节点的状态:

kubectl get nodes --kubeconfig KUBECONFIG

如需检查节点是否成功完成升级,请查看命令响应中的 VERSIONAGE 列。VERSION 是集群的 Kubernetes 版本。如需查看给定 Google Distributed Cloud 版本的 Kubernetes 版本,请参阅版本历史记录

如果节点显示 NOT READY,请尝试连接节点并检查 kubelet 状态:

systemctl status kubelet

您还可以查看 kubelet 日志:

journalctl -u kubelet

查看 kubelet 状态的输出和日志消息(指示节点出现问题的原因)。

检查正在升级的节点

如需检查集群中的哪个节点正在升级,请使用 kubectl get baremetalmachines 命令:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

替换以下值:

  • CLUSTER_NAMESPACE:集群的命名空间。
  • ADMIN_KUBECONFIG:管理员 kubeconfig 文件。
    • 如果引导集群用于管理员、混合或独立升级,请指定引导集群 kubeconfig 文件 (bmctl-workspace/.kindkubeconfig)。

以下示例输出显示要升级的节点的 ABM VERSIONDESIRED ABM VERSION 不同:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

查看哪些节点正在排空

在升级过程中,节点会排空 Pod,并且调度会停用,直到节点成功升级。如需查看哪些节点正在排空,请使用 kubectl get nodes 命令:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

使用 grep 过滤 STATUS 列,以仅显示报告 SchedulingDisabled 的节点。此状态表示节点正在排空。

您还可以检查管理员集群中的节点状态:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

替换以下值:

  • CLUSTER_NAMESPACE:集群的命名空间。
  • ADMIN_KUBECONFIG:管理员 kubeconfig 文件。
    • 如果引导集群用于管理员、混合或独立升级,请指定引导集群 kubeconfig 文件 (bmctl-workspace/.kindkubeconfig)。

排空的节点显示 MAINTENANCE 列下的状态。

检查节点长时间处于排空状态的原因

通过上一部分中的其中一种方法,使用 kubectl get nodes 命令识别正在排空的节点。使用 kubectl get pods 命令并依据此节点名称进行过滤以查看其他详细信息:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

NODE_NAME 替换为正在排空的节点的名称。输出结果会返回卡住或排空速度缓慢的 Pod 列表。当节点上的排空过程花费超过 20 分钟时,即使 Pod 卡住,升级也会继续。

从版本 1.29 开始,节点排空过程使用 Eviction API,该 API 支持 PodDisruptionBudgets (PDB)。

以下 PDB 设置可能会导致节点排空问题:

  • 由多个 PDB 管理的 Pod

  • PDB 静态配置,如下所示:

    • maxUnavailable == 0
    • minUnavailable >= 副本总数

    很难通过 PDB 资源确定副本总数,因为它是在 DeploymentReplicaSetStatefulSet 等更高级别的资源中定义的。PDB 仅根据配置中的选择器来匹配 Pod。诊断静态 PDB 配置是否导致问题的一个好方法是先检查 pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy,看看上述某个静态配置是否允许发生这种情况。

运行时违规行为(例如为 PDB 资源计算出的 DisruptionsAllowed 值为 0)也可能阻止节点排空。如果您配置了无法允许任何其他中断的 PodDisruptionBudget 对象,则在反复尝试后,节点升级可能无法升级到控制平面版本。为防止出现此故障,我们建议您纵向扩容 DeploymentHorizontalPodAutoscaler,以允许节点排空,同时仍然遵循 PodDisruptionBudget 配置。

如需查看不允许任何中断的所有 PodDisruptionBudget 对象,请使用以下命令:

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

检查 Pod 运行状况不佳的原因

如果 Pod 包含 upgrade-first-nodeupgrade-node 控制平面 IP 地址,升级可能会失败。此行为通常是因为静态 Pod 运行状况不佳。

  1. 使用 crictl ps -a 命令检查静态 Pod,并查找任何崩溃的 Kubernetes 或 etcd Pod。如果您的 Pod 发生故障,请查看 Pod 的日志,了解 Pod 崩溃的原因。

    崩溃循环行为的一些可能原因包括:

    • 装载到静态 Pod 的文件的权限或所有者不正确。
    • 与虚拟 IP 地址的连接不起作用。
    • etcd 有关的问题。
  2. 如果 crictl ps 命令不起作用或未返回任何内容,请检查 kubeletcontainerd 状态。使用 systemctl status SERVICEjournalctl -u SERVICE 命令查看日志。

后续步骤