健康检查是测试和监控现有集群运行情况的一种方式。健康检查会定期自行运行。您也可以使用 bmctl 按需运行健康检查。本文档介绍了每项检查在何种情况下会自动运行、如何以及何时手动运行，以及如何解读结果。
检查的内容
用于裸金属健康检查的 GDCV 分为两类：
节点机器检查
集群范围的检查
以下部分概述了系统对各个类别检查的内容。这些检查用于定期和按需健康检查。
节点机器检查
本部分介绍了节点机器的健康检查会评估哪些内容。这些检查旨在确认节点机器是否配置正确，并且它们有足够的资源和连接来执行集群创建、集群升级和集群操作。
这些检查对应于在集群命名空间的管理员集群中运行的名为 bm-system-NODE_IP_ADDRESS-machine 的 Bare Metal HealthCheck 自定义资源（例如 bm-system-192.0.2.54-machine）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
常见的机器检查包括：
集群机器使用的是受支持的操作系统 (OS)。
操作系统版本受支持。
操作系统使用的是受支持的内核版本。
内核已启用 BPF 即时 (JIT) 编译器选项 (
CONFIG_BPF_JIT=y)。在 Ubuntu 中，停用了非复杂防火墙 (UFW)。
节点机器满足最低 CPU 要求。
节点机器有 20% 以上的可用 CPU 资源。
节点机器满足最低内存要求。
节点机器满足最低磁盘存储空间要求。
时间同步是在节点机器上配置。
节点中存在用于将数据包路由到默认网关的默认路由。
域名系统 (DNS) 正常运行（如果集群配置为通过代理运行，则跳过此检查）。
如果集群配置为使用注册表镜像，则可访问注册表镜像。
机器 Google Cloud 检查包括以下内容：
可访问 Container Registry
gcr.io（如果集群配置为使用注册表镜像，系统会跳过此检查）。可访问 Google API。
机器健康检查包括以下各项：
kubelet处于活跃状态，且正在节点机器上运行。containerd处于活跃状态，且正在节点机器上运行。容器网络接口 (CNI) 运行状况端点状态为良好。
Pod CIDR 与节点机器 IP 地址不重叠。
如需详细了解节点机器要求，请参阅集群节点机器前提条件。
集群范围的检查
本部分介绍了集群的健康检查会评估哪些内容。
网络检查
以下客户端集群节点网络检查会在定期健康检查中自动运行。网络检查不能按需运行。这些检查对应于在集群命名空间的管理员集群中运行的名为 bm-system-network 的 Bare Metal HealthCheck 自定义资源。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
- 如果集群使用捆绑式负载均衡，则负载均衡节点池中的节点必须具有第 2 层地理编码协议 (ARP) 连接。VIP 发现功能需要 ARP 功能。
如需了解 GKE on Bare Metal 集群的协议和端口使用情况，请参阅网络要求。
预检检查的网络检查与网络健康检查不同。如需查看预检检查的网络检查列表，请参阅针对集群创建的预检检查或针对集群升级的预检检查。
Kubernetes
Kubernetes 检查在预检和定期健康检查中自动运行，但也是按需运行的。如果缺少列出的任何控制平面组件，这些健康检查不会返回错误。仅当组件存在且在命令执行时发生错误时，该检查才会返回错误。
这些检查对应于集群命名空间的管理员集群中运行的名为 bm-system-kubernetes 资源的 Bare Metal HealthCheck 自定义资源。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
API 服务器运行正常。
anetd运算符已正确配置。所有控制平面节点均可操作。
以下控制平面组件正常运行：
anthos-cluster-operatorcontroller-managercluster-api-provideraiscapi-kubeadm-bootstrap-systemcert-managerkube-dns
附加内容
插件检查作为预检检查和定期健康检查的一部分自动运行，并且可以按需运行。如果缺少列出的任何插件，此健康检查不会返回错误。仅当插件存在且在命令执行时发生错误时，该检查才会返回错误。
这些检查对应于集群命名空间的管理员集群中运行的名为 bm-system-add-ons 资源的裸金属 HealthCheck 自定义资源。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
可操作 Cloud Logging Stackdriver 组件和 Connect Agent：
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-connect-agent
HealthCheck 项自定义资源
运行健康检查时，裸金属的 GDCV 会创建一个 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.15.0 Cluster Name: nuc-user001 Interval In Seconds: 3600 Node Addresses: 192.168.1.54 Type: machine Status: Check Image Version: 1.15.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.15.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-kubernetes Healthy 57m kube-system bm-system-kubernetes-1.15.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 负责安排相应的健康检查按设定的时间间隔运行。
如需检索 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) 每小时 (*/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.15.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.15.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，且可在 Logs Explorer 中查看。在控制台日志中，定期健康检查被归类为 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.*"
定期健康检查
默认情况下，定期健康检查每小时运行一次，并检查以下集群组件：
您可以通过查看管理员集群上的 Bare Metal HealthCheck (healthchecks.baremetal.cluster.gke.io) 自定义资源来检查集群健康状况。网络、Kubernetes 和插件检查是集群级别的检查，因此每项检查都对应一个资源。系统会针对目标集群中的每个节点运行机器检查，因此每个节点都有一个资源。
如需列出给定集群的 Bare Metal
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。如需详细了解日志，请参阅健康检查日志。
GCP
检查所有集群节点机器是否都可以访问 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 运算符的健康状况。此检查可验证关键运营商是否正常运行以及其 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 运行预检检查，请参阅针对集群创建运行按需预检检查和针对集群升级运行按需预检检查。
虚拟机运行时预检检查
在 Google Distributed Cloud 上的虚拟机运行时和虚拟机上使用虚拟机运行时，Google Distributed Cloud 上的虚拟机运行时预检检查会验证一组节点机器前提条件。如果 Google Distributed Cloud 上的 VM Runtime 预检检查失败，则无法创建虚拟机。在 VMRuntime 自定义资源中将 spec.enabled 设置为 true 时，Google Distributed Cloud 中的 VM Runtime 预检检查会自动运行。
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
如需了解详情，请参阅 Google Distributed Cloud 预检检查。