健康检查是一种测试和监控现有集群健康的方式。健康检查会自行定期运行。您还可以使用 bmctl 按需运行健康检查。本文档介绍了每项检查，以及在什么情况下会自动运行、如何以及何时手动运行以及如何解读结果。
检查了什么？
Google Distributed Cloud 健康检查分为两类：
节点机器检查
集群级检查
以下部分概述了每个类别的检查内容。这些检查既可用于定期健康检查，也可用于按需健康检查。
节点机器检查
本部分介绍了节点机器的健康检查会评估哪些内容。这些检查可确认节点机器配置正确，并且具有足够的资源和连接，以便创建集群、升级集群和操作集群。
这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源 bm-system-NODE_IP_ADDRESS-machine（例如 bm-system-192.0.2.54-machine）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
常规机器检查包括以下各项：
集群机器使用的是受支持的操作系统 (OS)。
操作系统版本。
操作系统使用的是受支持的内核版本。
内核已启用 BPF 即时 (JIT) 编译器选项 (
CONFIG_BPF_JIT=y)。对于 Ubuntu，Uncomplicated Firewall (UFW) 已停用。
节点机器满足最低 CPU 要求。
节点机器的可用 CPU 资源超过 20%。
节点机器满足最低内存要求。
节点机器满足最低磁盘存储空间要求。
时间同步是在节点机器上配置的。
节点中存在将数据包路由到默认网关的默认路由。
域名系统 (DNS) 正常运行（如果集群配置为在代理后运行，则跳过此检查）。
如果集群已配置为使用注册表镜像，则可以访问该注册表镜像。
机器 Google Cloud 检查包括以下内容：
Container Registry，
gcr.io可访问（如果集群配置为使用注册表镜像，则跳过此检查）。Google API 可访问。
机器健康检查包括以下各项：
kubelet处于活动状态，并在节点机器上运行。containerd处于活动状态，并在节点机器上运行。容器网络接口 (CNI) 健康端点状态为健康。
Pod CIDR 不会与节点机器 IP 地址重叠。
如需详细了解节点机器要求，请参阅集群节点机器前提条件。
集群级检查
本部分介绍了集群健康检查会评估哪些内容。
网络检查
以下客户端集群节点网络检查会在定期健康检查的过程中自动运行。无法按需运行网络检查。这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源 bm-system-network。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
如果集群使用捆绑式负载均衡，则负载均衡节点池中的节点必须具有第 2 层地址解析协议 (ARP) 连接。ARP 是 VIP 发现所必需的。
控制平面节点已开放端口 8443 和 8444，以供 GKE Identity Service 使用。
控制平面节点已打开端口 2382 和 2383，以供
etcd-events实例使用。
如需了解 Google Distributed Cloud 集群的协议和端口用量，请参阅网络要求。
预检检查的网络检查与网络健康检查不同。如需查看预检检查的网络检查列表，请参阅针对集群创建的预检检查或针对集群升级的预检检查。
Kubernetes
Kubernetes 检查会在预检和定期健康检查的过程中自动运行，也可以按需运行。如果列出的任何控制平面组件缺失，这些健康检查不会返回错误。只有在组件存在且在命令执行时存在错误时，检查才会返回错误。
这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源（bm-system-kubernetes 资源）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
API 服务器正常运行。
anetdOperator 已配置正确。所有控制平面节点均可正常运行。
以下控制平面组件正常运行：
anthos-cluster-operatorcontroller-managercluster-api-provideraiscapi-kubeadm-bootstrap-systemcert-managerkube-dns
插件
插件检查会在预检检查和定期健康检查的过程中自动运行，并且可以按需运行。如果列出的任何插件都缺失，此健康检查不会返回错误。只有在插件存在且在命令执行时存在错误时，检查才会返回错误。
这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源（bm-system-add-ons* 资源）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
Cloud Logging Stackdriver 组件和 Connect Agent 可正常运行：
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-connect-agent
Google Distributed Cloud 管理的资源显示未进行任何手动更改（配置偏移）：
字段值尚未更新
选填字段尚未添加或移除
资源尚未删除
如果健康检查检测到配置偏移，则 bm-system-add-ons 裸金属 HealthCheck 自定义资源 Status.Pass 值会设置为 false。Failures 部分中的 Description 字段包含有关已更改的任何资源的详细信息，包括以下信息：
Version：资源的 API 版本。Kind：资源的对象架构，例如Deployment。Namespace：资源所在的命名空间。Name：资源的名称。Diff：以字符串格式比较记录的资源清单与已更改资源的清单之间的差异。
HealthCheck 自定义资源
运行健康检查时，Google Distributed Cloud 会创建 HealthCheck 自定义资源。HealthCheck 自定义资源是持久的，并提供健康检查活动和结果的结构化记录。HeathCheck 自定义资源分为两类：
裸金属
HealthCheck自定义资源 (API Version: baremetal.cluster.gke.io/v1)：这些资源提供有关定期健康检查的详细信息。这些资源位于管理员集群的集群命名空间中。裸金属HealthCheck资源负责创建健康检查 Cron 作业和其他作业。这些资源会持续使用最新结果进行更新。Anthos
HealthCheck自定义资源 (API Version: anthos.gke.io/v1)：这些资源用于报告健康检查指标。这些资源位于每个集群的kube-system命名空间中。这些资源的更新会尽力而为。如果更新因某个问题而失败（例如临时网络错误），系统会忽略该失败。
下表列出了为两种 HealthCheck 类别创建的资源类型：
| 裸金属健康检查 | GKE Enterprise 健康检查 | 严重级别 |
|---|---|---|
|
类型：机器
姓名： |
类型：机器
姓名： |
严重 |
|
类型：网络
姓名： |
类型：网络
姓名： |
严重 |
|
类型：Kubernetes
姓名： |
类型：Kubernetes
姓名： |
严重 |
|
类型：插件
姓名： |
类型：插件
姓名：
姓名： |
可选 |
如需检索 HealthCheck 状态，请执行以下操作：
如需读取定期健康检查的结果，您可以获取关联的自定义资源：
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig ADMIN_KUBECONFIG --all-namespaces将
ADMIN_KUBECONFIG替换为管理员集群 kubeconfig 文件的路径。以下示例展示了定期健康检查以及检查在上次运行时是否通过：
NAMESPACE NAME PASS AGE cluster-test-admin001 bm-system-192.0.2.52-machine true 11d cluster-test-admin001 bm-system-add-ons true 11d cluster-test-admin001 bm-system-kubernetes true 11d cluster-test-admin001 bm-system-network true 11d cluster-test-user001 bm-system-192.0.2.53-machine true 56d cluster-test-user001 bm-system-192.0.2.54-machine true 56d cluster-test-user001 bm-system-add-ons true 56d cluster-test-user001 bm-system-kubernetes true 56d cluster-test-user001 bm-system-network true 56d如需读取特定健康检查的详细信息，请使用
kubectl describe：kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
HEALTHCHECK_NAME：健康检查的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
在您查看资源时，
Status:部分包含以下重要字段：Pass：指示上次健康检查作业是否通过。Checks：包含有关最近一次健康检查作业的信息。Failures：包含有关最近失败作业的信息。Periodic：包含上次安排和插桩健康检查作业的时间等信息。
以下
HealthCheck示例是针对成功的机器检查：Name: bm-system-192.0.2.54-machine Namespace: cluster-test-user001 Labels: baremetal.cluster.gke.io/periodic-health-check=true machine=192.0.2.54 type=machine Annotations: <none> API Version: baremetal.cluster.gke.io/v1 Kind: HealthCheck Metadata: Creation Timestamp: 2023-09-22T18:03:27Z ... Spec: Anthos Bare Metal Version: 1.16.0 Cluster Name: nuc-user001 Interval In Seconds: 3600 Node Addresses: 192.168.1.54 Type: machine Status: Check Image Version: 1.16.0-gke.26 Checks: 192.168.1.54: Job UID: 345b74a6-ce8c-4300-a2ab-30769ea7f855 Message: Pass: true ... Cluster Spec: Anthos Bare Metal Version: 1.16.0 Bypass Preflight Check: false Cluster Network: Bundled Ingress: true Pods: Cidr Blocks: 10.0.0.0/16 Services: Cidr Blocks: 10.96.0.0/20 ... Conditions: Last Transition Time: 2023-11-22T17:53:18Z Observed Generation: 1 Reason: LastPeriodicHealthCheckFinished Status: False Type: Reconciling Node Pool Specs: node-pool-1: Cluster Name: nuc-user001 ... Pass: true Periodic: Last Schedule Time: 2023-11-22T17:53:18Z Last Successful Instrumentation Time: 2023-11-22T17:53:18Z Start Time: 2023-09-22T18:03:28Z Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal HealthCheckJobFinished 6m4s (x2 over 6m4s) healthcheck-controller health check job bm-system-192.0.2.54-machine-28344593 finished以下
HealthCheck示例是针对失败的机器检查：Name: bm-system-192.0.2.57-machine Namespace: cluster-user-cluster1 ... API Version: baremetal.cluster.gke.io/v1 Kind: HealthCheck ... Status: Checks: 192.0.2.57: Job UID: 492af995-3bd5-4441-a950-f4272cb84c83 Message: following checks failed, ['check_kubelet_pass'] Pass: false Failures: Category: AnsibleJobFailed Description: Job: machine-health-check. Details: Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn]. Reason: following checks failed, ['check_kubelet_pass'] Pass: false Periodic: Last Schedule Time: 2023-10-24T23:04:21Z Last Successful Instrumentation Time: 2023-10-24T23:31:30Z ...如需获取指标健康检查的列表，请使用以下命令：
kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system将
CLUSTER_KUBECONFIG替换为目标集群 kubeconfig 文件的路径。以下示例展示了响应格式：
NAMESPACE NAME COMPONENT NAMESPACE STATUS LAST_COMPLETED kube-system bm-system-10.200.0.3-machine Healthy 56m kube-system bm-system-add-ons-add-ons Healthy 48m kube-system bm-system-add-ons-configdrift Healthy 48m kube-system bm-system-kubernetes Healthy 57m kube-system bm-system-kubernetes-1.16.1-non-periodic Healthy 25d kube-system bm-system-network Healthy 32m kube-system check-kubernetes-20231114-190445-non-periodic Healthy 3h6m kube-system component-status-controller-manager Healthy 5s kube-system component-status-etcd-0 Healthy 5s kube-system component-status-etcd-1 Healthy 5s kube-system component-status-scheduler Healthy 5s
健康检查 Cron 作业
对于定期健康检查，每个裸金属 HealthCheck 自定义资源都有一个名称相同的对应 CronJob。此 CronJob 负责安排相应的健康检查以在设定的间隔时间内运行。CronJob 还包含一个 ansible-runner 容器，该容器通过与节点建立安全 Shell (SSH) 连接来执行健康检查。
如需检索有关 Cron 作业的相关信息，请执行以下操作：
获取已为指定集群运行的 Cron 作业列表：
kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
以下示例显示了一个典型响应：
NAMESPACE NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE cluster-test-admin bm-system-10.200.0.3-machine 17 */1 * * * False 0 11m 25d cluster-test-admin bm-system-add-ons 25 */1 * * * False 0 3m16s 25d cluster-test-admin bm-system-kubernetes 16 */1 * * * False 0 12m 25d cluster-test-admin bm-system-network 41 */1 * * * False 0 47m 25dSCHEDULE列中的值表示按计划语法运行的每个健康检查作业的计划。例如，bm-system-kubernetes作业会在每天 (* * *) 的每个小时 (*/1) 的第 17 分钟 (17) 运行。定期健康检查的时间间隔不可修改，但了解它们应该在什么时候运行对于问题排查很有用。检索特定
CronJob自定义资源的详细信息：kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
以下示例展示了成功的
CronJob：Name: bm-system-network Namespace: cluster-test-admin Labels: AnthosBareMetalVersion=1.16.1 baremetal.cluster.gke.io/check-name=bm-system-network baremetal.cluster.gke.io/periodic-health-check=true controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613 type=network Annotations: target: node-network Schedule: 41 */1 * * * Concurrency Policy: Forbid Suspend: False Successful Job History Limit: 1 Failed Job History Limit: 1 Starting Deadline Seconds: <unset> Selector: <unset> Parallelism: <unset> Completions: 1 Active Deadline Seconds: 3600s Pod Template: Labels: baremetal.cluster.gke.io/check-name=bm-system-network Annotations: target: node-network Service Account: ansible-runner Containers: ansible-runner: Image: gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5 Port: <none> Host Port: <none> Command: cluster Args: -execute-command=network-health-check -login-user=root -controlPlaneLBPort=443 Environment: <none> Mounts: /data/configs from inventory-config-volume (ro) /etc/ssh-key from ssh-key-volume (ro) Volumes: inventory-config-volume: Type: ConfigMap (a volume populated by a ConfigMap) Name: bm-system-network-inventory-bm-system-ne724a7cc3584de0635099 Optional: false ssh-key-volume: Type: Secret (a volume populated by a Secret) SecretName: ssh-key Optional: false Last Schedule Time: Tue, 14 Nov 2023 18:41:00 +0000 Active Jobs: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 48m cronjob-controller Created job bm-system-network-28333121 Normal SawCompletedJob 47m cronjob-controller Saw completed job: bm-system-network-28333121, status: Complete Normal SuccessfulDelete 47m cronjob-controller Deleted job bm-system-network-28333061
健康检查日志
运行健康检查时，系统会生成日志。无论您是使用 bmctl 运行健康检查，还是在定期健康检查期间自动运行健康检查，日志都会发送到 Cloud Logging。按需运行健康检查时，系统会在管理员工作站上集群文件夹的 log/ 目录下、一个带时间戳的文件夹中创建日志文件。例如，如果您针对 test-cluster 集群运行 bmctl
check kubernetes 命令，则会在类似 bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923 这样的目录中找到日志。
在本地查看日志
您可以使用 kubectl 查看定期健康检查的日志：
获取 Pod 并查找您感兴趣的特定健康检查 Pod：
kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
以下示例响应显示了一些健康检查 Pod：
NAME READY STATUS RESTARTS AGE bm-system-10.200.0.4-machine-28353626-lzx46 0/1 Completed 0 12m bm-system-10.200.0.5-machine-28353611-8vjw2 0/1 Completed 0 27m bm-system-add-ons-28353614-gxt8f 0/1 Completed 0 24m bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c 0/1 Completed 0 75m bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk 0/1 Completed 0 74m bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj 0/1 Completed 0 67m bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj 0/1 Completed 0 77m bm-system-kubernetes-28353604-4tc54 0/1 Completed 0 34m bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn 0/1 Completed 0 63m bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z 0/1 Completed 0 77m ... bm-system-network-28353597-cbwk7 0/1 Completed 0 41m bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd 0/1 Completed 0 76m bm-system-network-preflight-check-create275a0fdda700cb2b44b264c 0/1 Completed 0 77m检索 Pod 日志：
kubectl logs POD_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
POD_NAME：健康检查 Pod 的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
以下示例展示了节点机器健康检查成功的 Pod 日志的一部分：
... TASK [Summarize health check] ************************************************** Wednesday 29 November 2023 00:26:22 +0000 (0:00:00.419) 0:00:19.780 **** ok: [10.200.0.4] => { "results": { "check_cgroup_pass": "passed", "check_cni_pass": "passed", "check_containerd_pass": "passed", "check_cpu_pass": "passed", "check_default_route": "passed", "check_disks_pass": "passed", "check_dns_pass": "passed", "check_docker_pass": "passed", "check_gcr_pass": "passed", "check_googleapis_pass": "passed", "check_kernel_version_pass": "passed", "check_kubelet_pass": "passed", "check_memory_pass": "passed", "check_pod_cidr_intersect_pass": "passed", "check_registry_mirror_reachability_pass": "passed", "check_time_sync_pass": "passed", "check_ubuntu_1804_kernel_version": "passed", "check_ufw_pass": "passed", "check_vcpu_pass": "passed" } } ...以下示例显示了失败的节点机器健康检查 Pod 日志的一部分。示例显示
kubelet检查 (check_kubelet_pass) 失败，这表明kubelet未在此节点上运行。... TASK [Reach a final verdict] *************************************************** Thursday 02 November 2023 17:30:19 +0000 (0:00:00.172) 0:00:17.218 ***** fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"} ...
在 Cloud Logging 中查看日志
健康检查日志会流式传输到 Cloud Logging，您可以在日志浏览器中查看。定期健康检查在控制台日志中被归类为 Pod。
在 Google Cloud 控制台中，转到 Logging 菜单中的日志浏览器页面。
在查询字段中，输入以下基本查询：
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"查询结果窗口会显示节点机器健康检查的日志。
以下是定期健康检查的查询列表：
节点机器
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"网络
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-network.*"Kubernetes
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-kubernetes.*"插件
resource.type="k8s_container" resource.labels.pod_name=~"bm-system-add-ons.*"
定期健康检查
默认情况下，定期健康检查每小时运行一次，并检查以下集群组件：
您可以通过查看管理员集群上的裸金属 HealthCheck (healthchecks.baremetal.cluster.gke.io) 自定义资源来检查集群健康。网络、Kubernetes 和插件检查是集群级检查，因此每个检查都有一个单独的资源。系统会针对目标集群中的每个节点运行机器检查，因此每个节点都有一个资源。
如需列出给定集群的裸金属
HealthCheck资源，请运行以下命令：kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：健康检查的目标集群的命名空间。
以下示例响应显示了格式：
NAMESPACE NAME PASS AGE cluster-test-user001 bm-system-192.0.2.53-machine true 56d cluster-test-user001 bm-system-192.0.2.54-machine true 56d cluster-test-user001 bm-system-add-ons true 56d cluster-test-user001 bm-system-kubernetes true 56d cluster-test-user001 bm-system-network true 56dhealthchecks.baremetal.cluster.gke.io的Pass字段表示上次健康检查是通过 (true) 还是失败 (false)。
如需详细了解如何检查定期健康检查的状态，请参阅 HealthCheck 自定义资源和健康检查日志。
停用定期健康检查
默认情况下，所有集群都会启用定期健康检查。您可以通过在集群资源中将 periodicHealthCheck.enable 字段设置为 false 来停用集群的定期健康检查。
如需停用定期健康检查，请执行以下操作：
修改集群配置文件，并将
periodicHealthCheck.enable字段添加到集群规范中，并将其值设置为false：apiVersion: v1 kind: Namespace metadata: name: cluster-user-basic --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user-basic namespace: cluster-user-basic spec: type: user profile: default ... periodicHealthCheck: enable: false ...通过运行
bmctl update命令来更新集群：bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要更新的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
如需验证是否已停用定期健康检查，请运行以下命令，确认已删除相应的
healthchecks.baremetal.cluster.gke.io资源：kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：健康检查的目标集群的命名空间。
重新启用定期健康检查
默认情况下，所有集群都会启用定期健康检查。如果您已停用定期健康检查，则可以通过在集群资源中将 periodicHealthCheck.enable 字段设置为 true 来重新启用它们。
如需重新启用定期健康检查，请执行以下操作：
修改集群配置文件，并将
periodicHealthCheck.enable字段添加到集群规范中，并将其值设置为true：apiVersion: v1 kind: Namespace metadata: name: cluster-user-basic --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: user-basic namespace: cluster-user-basic spec: type: user profile: default ... periodicHealthCheck: enable: true ...通过运行
bmctl update命令来更新集群：bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要更新的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
如需验证是否已启用定期健康检查，请运行以下命令，确认是否存在相应的
healthchecks.baremetal.cluster.gke.io资源：kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：健康检查的目标集群的命名空间。
这些资源可能需要几分钟才会显示。
按需健康检查
以下部分介绍了您可以使用 bmctl check 按需运行的健康检查。使用 bmctl check 运行健康检查时，请遵循以下规则：
使用
bmctl check命令检查用户集群时，请使用--kubeconfig标志指定管理员集群的 kubeconfig 文件的路径。日志会在管理员工作站上集群日志文件夹（默认情况下为
bmctl-workspace/CLUSTER_NAME/log）中带时间戳的目录中生成。健康检查日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
如需详细了解 bmctl 命令的其他选项，请参阅 bmctl 命令参考文档。
插件
检查指定集群的指定 Kubernetes 插件是否可操作。
如需检查集群的插件，请执行以下操作：
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要检查的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
如需查看已选内容的列表，请参阅本文档的“已选内容”部分中的插件。
此检查会在管理员工作站上的集群日志文件夹的 check-addons-TIMESTAMP 目录中生成日志文件。日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
集群
检查指定集群的所有集群节点、节点网络、Kubernetes 和插件。您提供集群名称，bmctl 默认会在 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml 中查找集群配置文件。
如需检查集群的健康状况，请执行以下操作：
bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要检查的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
如需查看已检查的内容列表，请参阅本文档的“已检查的内容”部分中的以下部分：
此检查会在管理员工作站上的集群日志文件夹的 check-cluster-TIMESTAMP 目录中生成日志文件。日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
配置
检查集群配置文件。 此检查要求您已生成配置文件并对其进行了修改，以指定集群的集群配置详细信息。此命令旨在确定是否存在任何配置设置错误、缺失或存在语法错误。您提供集群名称，bmctl 默认会在 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml 中查找集群配置文件。
如需检查集群配置文件，请执行以下操作：
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要检查的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
此命令会检查集群配置文件的 YAML 语法、Google Cloud 访问权限以及集群配置文件中指定的服务账号的权限。
此检查会在管理员工作站上的集群日志文件夹的 check-config-TIMESTAMP 目录中生成日志文件。日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
与 Google Cloud 的连接
检查所有集群节点机器是否可以访问 Container Registry (gcr.io) 和 Google API 端点 (googleapis.com)。
如需检查集群对所需 Google Cloud 资源的访问权限，请执行以下操作：
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要检查的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
此检查会在管理员工作站上的集群日志文件夹的 check-gcp-TIMESTAMP 目录中生成日志文件。日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
Kubernetes
检查在控制平面中运行的关键 Kubernetes Operator 的健康。此检查可验证关键 Operator 是否正常运行以及其 Pod 是否崩溃。如果缺少任何控制平面组件，此健康检查不会返回错误：仅当组件存在且在命令执行时存在错误时，才会返回错误。
如需检查集群中 Kubernetes 组件的健康，请执行以下操作：
bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：包含您要检查的节点的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
如需查看已检查的内容列表，请参阅本文档的“已检查的内容”部分中的 Kubernetes。
此检查会在管理员工作站上的集群日志文件夹的 check-kubernetes-TIMESTAMP 目录中生成日志文件。日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
节点
检查集群节点机器，确认它们配置正确，并且具有足够的资源和连接，以便进行集群升级和集群操作。
如需检查集群中节点机器的健康状况，请执行以下操作：
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：包含您要检查的节点的集群的名称。NODE_IP_ADDRESSES：节点机器的 IP 地址的英文逗号分隔列表。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
如需查看已检查的内容列表，请参阅本文档的“已检查的内容”部分中的节点机器检查。
此检查会在管理员工作站上的集群日志文件夹的 check-nodes-TIMESTAMP 目录中为每个集群节点机器生成日志文件。日志也会发送到 Cloud Logging。如需详细了解日志，请参阅健康检查日志。
预检
如需了解如何使用 bmctl 运行预检检查，请参阅针对集群创建运行按需预检检查和针对集群升级运行按需预检检查。
虚拟机运行时预检检查
使用 VM Runtime on Google Distributed Cloud 和虚拟机前，VM Runtime on Google Distributed Cloud 预检检查会验证一组节点机器前提条件。如果 VM Runtime on Google Distributed Cloud 预检检查失败，则系统会阻止创建虚拟机。当 VMRuntime 自定义资源中的 spec.enabled 设置为 true 时，VM Runtime on Google Distributed Cloud 预检检查会自动运行。
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
如需了解详情，请参阅 VM Runtime on Google Distributed Cloud 预检检查。
运行最新的健康检查
在发现已知问题后，系统会更新健康检查（和预检查）。如需指示 bmctl 从已安装的次要版本的最新补丁映像中运行检查，请使用 --check-image-version latest 选项标志：
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest
将 CLUSTER_NAME 替换为您要检查的集群的名称。
这有助于您发现最近发现的任何已知问题，而无需先升级集群。
您还可以在安装或升级集群之前执行最新的预检检查。如需了解详情，请参阅运行最新的预检检查。