健康检查是一种测试和监控现有集群运行情况的方法。健康检查会定期独立运行。您还可以使用 bmctl 按需运行健康检查。本文档介绍了每项检查、它在什么情况下会自动运行、如何以及何时手动运行，以及如何解释结果。
检查的内容
Google Distributed Cloud 健康检查有两种类别：
节点机器检查
集群范围的检查
以下各部分概述了每个类别需要检查的内容。这些检查同时用于定期健康检查和按需健康检查。
节点机器检查
本部分介绍节点机器健康检查的评估结果。这些检查旨在确认节点机器是否已正确配置，以及它们是否有足够的资源和连接来进行集群创建、集群升级和集群操作。
这些检查对应于集群命名空间的管理员集群中运行的名为 bm-system-NODE_IP_ADDRESS-machine 的 Bare Metal HealthCheck 自定义资源（例如 bm-system-192.0.2.54-machine）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
常见的机器检查包括以下内容：
集群机器使用的是受支持的操作系统 (OS)。
操作系统版本受支持。
操作系统使用的是受支持的内核版本。
内核启用了 BPF Just In Time (JIT) 编译器选项 (
CONFIG_BPF_JIT=y)。对于 Ubuntu，系统会停用 Uncomplicated Firewall (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。
控制平面节点对 8443 和 8444 开放端口，以供 GKE Identity Service 使用。
控制平面节点开放了端口 2382 和 2383，以供
etcd-events实例使用。
如需了解 Google Distributed Cloud 集群的协议和端口使用情况，请参阅网络要求。
预检检查的网络检查与网络健康检查不同。如需查看预检检查的网络检查列表，请参阅集群创建的预检检查或集群升级的预检检查。
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* 资源的 Bare Metal HealthCheck 自定义资源。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。
Cloud Logging Stackdriver 组件和 Connect Agent 可以运行：
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-connect-agent
Google Distributed Cloud 托管资源未显示任何手动更改（配置偏移）：
字段值尚未更新
尚未添加或移除选填字段
尚未删除资源
如果健康检查检测到配置偏移，则 bm-system-add-ons Bare Metal 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 负责按设定的时间间隔运行相应的健康检查。
如需检索 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，并可在 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 和插件检查是集群级检查，因此每项检查都只有一个资源。系统会为目标集群中的每个节点运行机器检查，因此每个节点都有一个资源。
如需列出给定集群的裸金属
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 上的 VM Runtime 预检检查会在 Google Distributed Cloud 和虚拟机上使用 VM Runtime 之前验证一组节点机器的前提条件。如果 Google Distributed Cloud 预检检查上的虚拟机运行时失败，系统会阻止虚拟机创建。在 VMRuntime 自定义资源中将 spec.enabled 设置为 true 时，Google Distributed Cloud 上的虚拟机运行时会自动运行预检检查。
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
如需了解详情，请参阅 Google Distributed Cloud 预检检查上的虚拟机运行时。