本页面介绍如何解决与安装或升级 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_NAME
和 TIMESTAMP
替换为您的集群名称和相应系统的时间。
如需直接获取引导集群的日志,您可以在集群创建和升级期间运行以下命令:
docker exec -it bmctl-control-plane bash
该命令会在引导集群中运行的 bmctl 控制层面容器内打开一个终端。
要检查 kubelet
和 containerd
日志,请使用以下命令并查找输出中的错误或警告:
journalctl -u kubelet
journalctl -u containerd
集群升级问题
在升级 Google Distributed Cloud 集群时,您可以监控进度并检查集群和节点的状态。
- 如果您在升级期间遇到问题,请尝试确定发生故障的阶段。如需详细了解集群在升级过程中会发生什么,请参阅集群升级的生命周期和阶段。
- 如需详细了解集群升级期间问题的影响,请参阅了解 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
如需检查节点是否成功完成升级,请查看命令响应中的 VERSION
和 AGE
列。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
)。
- 如果引导集群用于管理员、混合或独立升级,请指定引导集群 kubeconfig 文件 (
以下示例输出显示要升级的节点的 ABM VERSION
与 DESIRED 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
)。
- 如果引导集群用于管理员、混合或独立升级,请指定引导集群 kubeconfig 文件 (
排空的节点显示 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 资源确定副本总数,因为它是在
Deployment
、ReplicaSet
或StatefulSet
等更高级别的资源中定义的。PDB 仅根据配置中的选择器来匹配 Pod。诊断静态 PDB 配置是否导致问题的一个好方法是先检查pdb.Status.ExpectPods
<=pdb.Status.DesiredHealthy
,看看上述某个静态配置是否允许发生这种情况。
运行时违规行为(例如为 PDB 资源计算出的 DisruptionsAllowed
值为 0
)也可能阻止节点排空。如果您配置了无法允许任何其他中断的 PodDisruptionBudget
对象,则在反复尝试后,节点升级可能无法升级到控制平面版本。为防止出现此故障,我们建议您纵向扩容 Deployment
或 HorizontalPodAutoscaler
,以允许节点排空,同时仍然遵循 PodDisruptionBudget
配置。
如需查看不允许任何中断的所有 PodDisruptionBudget
对象,请使用以下命令:
kubectl get poddisruptionbudget --all-namespaces \
-o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
检查 Pod 运行状况不佳的原因
如果 Pod 包含 upgrade-first-node
或 upgrade-node
控制平面 IP 地址,升级可能会失败。此行为通常是因为静态 Pod 运行状况不佳。
使用
crictl ps -a
命令检查静态 Pod,并查找任何崩溃的 Kubernetes 或etcd
Pod。如果您的 Pod 发生故障,请查看 Pod 的日志,了解 Pod 崩溃的原因。崩溃循环行为的一些可能原因包括:
- 装载到静态 Pod 的文件的权限或所有者不正确。
- 与虚拟 IP 地址的连接不起作用。
- 与
etcd
有关的问题。
如果
crictl ps
命令不起作用或未返回任何内容,请检查kubelet
和containerd
状态。使用systemctl status SERVICE
和journalctl -u SERVICE
命令查看日志。
后续步骤
- 如果您需要其他帮助,请与 Cloud Customer Care 联系。