健康检查

健康检查是一种测试和监控现有集群健康的方式。健康检查会自行定期运行。您还可以使用 bmctl 按需运行健康检查。本文档介绍了每项检查，以及在什么情况下会自动运行、如何以及何时手动运行以及如何解读结果。

检查了什么？

Google Distributed Cloud 健康检查分为两类：

  • 节点机器检查

  • 集群级检查

以下部分概述了每个类别的检查内容。这些检查既可用于定期健康检查，也可用于按需健康检查。

节点机器检查

本部分介绍了节点机器的健康检查会评估哪些内容。这些检查可确认节点机器配置正确，并且具有足够的资源和连接，以便创建集群、升级集群和操作集群。

这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源 bm-system-NODE_IP_ADDRESS-machine（例如 bm-system-192.0.2.54-machine）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。

注意：常规机器检查和机器 Google Cloud 检查也会在预检检查中使用。

常规机器检查包括以下各项：

  • 集群机器使用的是受支持的操作系统 (OS)。

  • 操作系统版本。

  • 操作系统使用的是受支持的内核版本。

  • 内核已启用 BPF 即时 (JIT) 编译器选项 (CONFIG_BPF_JIT=y)。

  • 对于 Ubuntu，Uncomplicated Firewall (UFW) 已停用。

  • 节点机器满足最低 CPU 要求。

  • 节点机器的可用 CPU 资源超过 20%。

  • 节点机器满足最低内存要求。

  • 节点机器满足最低磁盘存储空间要求。

  • 时间同步是在节点机器上配置的。

  • 节点中存在将数据包路由到默认网关的默认路由。

  • 域名系统 (DNS) 正常运行（如果集群配置为在代理后运行，则跳过此检查）。

  • 如果集群已配置为使用注册表镜像，则可以访问该注册表镜像。

机器 Google Cloud 检查包括以下各项：

  • Artifact Registry，gcr.io 可访问（如果集群配置为使用注册表镜像，则跳过此检查）。

  • Google API 可访问。

机器健康检查包括以下各项：

  • kubelet 处于活动状态，并在节点机器上运行。

  • containerd 处于活动状态，并在节点机器上运行。

  • 容器网络接口 (CNI) 健康端点状态为健康。

  • Pod CIDR 不会与节点机器 IP 地址重叠。

如需详细了解节点机器要求，请参阅集群节点机器前提条件。

集群级检查

本部分介绍了集群健康检查会评估哪些内容。

默认检查

默认集群检查会在定期健康检查过程中自动运行，也可以在集群健康检查过程中按需运行。这些检查可确保 Kubernetes 集群资源配置正确且正常运行。

这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源（bm-system-default-* 资源）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。

默认集群检查会审核以下资源类型和条件：

  • DaemonSet

    • 配置有效
    • DaemonSet 运行状况良好

  • 部署

    • 配置有效
    • 部署运行状况良好

  • 节点（以下都为节点条件）

    • 节点就绪状态
    • kubelet 磁盘压力
    • kubelet 内存压力
    • kubelet 进程 ID (PID) 压力
    • kubelet 重启频率
    • kubelet 运行状况良好
    • 网络可用性
    • containerd 函数
    • containerd 重启频率
    • Docker Overlay2 功能
    • Docker 重启频率
    • 网络设备取消注册事件频率
    • 内核死锁
    • KubeProxy 运行状况良好
    • 只读文件系统

  • Pod

    • 配置有效
    • Pod 运行状况良好
    • 容器运行状况良好

  • PodDisruptionBudget (PDB)

    • 配置有效
    • PDB 运行时函数
    • PDB 与 Pod 匹配
    • 不受多个 PDB 管理的 Pod

  • 资源请求量

    • 目标节点上的 Pod 已设置 CPU 和内存请求
    • 每个节点的平均资源请求在跟踪的限制范围内

  • 服务

    • 配置有效
    • 服务运行状况良好

  • StatefulSet

    • 配置有效
    • StatefulSet

网络检查

以下客户端集群节点网络检查会在定期健康检查的过程中自动运行。无法按需运行网络检查。这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源 bm-system-network。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。

  • 如果集群使用捆绑式负载均衡，则负载均衡节点池中的节点必须具有第 2 层地址解析协议 (ARP) 连接。ARP 是 VIP 发现所必需的。

  • 控制平面节点已开放端口 8443 和 8444，以供 GKE Identity Service 使用。

  • 控制平面节点已打开端口 2382 和 2383，以供 etcd-events 实例使用。

如需了解集群的协议和端口用量，请参阅网络要求。 预检检查的网络检查与网络健康检查不同。如需查看预检检查的网络检查列表，请参阅针对集群创建的预检检查或针对集群升级的预检检查。

Kubernetes

Kubernetes 检查会在预检和定期健康检查的过程中自动运行，也可以按需运行。如果列出的任何控制平面组件缺失，这些健康检查不会返回错误。只有在组件存在且在命令执行时存在错误时，检查才会返回错误。

这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源（bm-system-kubernetes 资源）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。

  • API 服务器正常运行。

  • anetd Operator 已配置正确。

  • 所有控制平面节点均可正常运行。

  • 以下控制平面组件正常运行：

    • anthos-cluster-operator

    • controller-manager

    • cluster-api-provider

    • ais

    • capi-kubeadm-bootstrap-system

    • cert-manager

    • kube-dns

插件

插件检查会在预检检查和定期健康检查的过程中自动运行，并且可以按需运行。如果列出的任何插件都缺失，此健康检查不会返回错误。只有在插件存在且在命令执行时存在错误时，检查才会返回错误。

这些检查对应于在集群命名空间内管理员集群中运行的裸金属 HealthCheck 自定义资源（bm-system-add-ons* 资源）。如需详细了解健康检查资源，请参阅 HealthCheck 自定义资源。

  • Cloud Logging Stackdriver 组件和 Connect Agent 可正常运行：

    • stackdriver-log-aggregator

    • stackdriver-log-forwarder

    • stackdriver-metadata-agent

    • stackdriver-prometheus-k8

    • gke-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 类别创建的资源类型：

裸金属健康检查 Anthos HealthChecks 严重级别

类型：默认

名称：bm-system-default-daemonset

名称：bm-system-default-deployment

名称：bm-system-default-node

名称：bm-system-default-pod

名称：bm-system-default-poddisruptionbudget

名称：bm-system-default-resource

名称：bm-system-default-service

名称：bm-system-default-statefulset

类型：默认

名称：bm-system-default-daemonset

名称：bm-system-default-deployment

名称：bm-system-default-node

名称：bm-system-default-pod

名称：bm-system-default-poddisruptionbudget

名称：bm-system-default-resource

名称：bm-system-default-service

名称：bm-system-default-statefulset

 严重

类型：机器

姓名：bm-system-NODE_IP_ADDRESS-machine

类型：机器

姓名：bm-system-NODE_IP_ADDRESS-machine

严重

类型：网络

姓名：bm-system-network

类型：网络

姓名：bm-system-network

严重

类型：Kubernetes

姓名：bm-system-kubernetes

类型：Kubernetes

姓名：bm-system-kubernetes

严重

类型：插件

姓名：bm-system-add-ons

类型：插件

姓名：bm-system-add-ons-add-ons

姓名：bm-system-add-ons-configdrift

可选

如需检索 HealthCheck 状态，请执行以下操作：

  1. 如需读取定期健康检查的结果，您可以获取关联的自定义资源：

    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

  2. 如需读取特定健康检查的详细信息，请使用 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
  ...

  3. 如需获取指标健康检查的列表，请使用以下命令：

    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-add-ons-add-ons                                               Healthy   48m
kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
kube-system   bm-system-default-daemonset                                             Healthy   52m
kube-system   bm-system-default-deployment                                            Healthy   52m
kube-system   bm-system-default-node                                                  Healthy   52m
kube-system   bm-system-default-pod                                                   Healthy   52m
kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
kube-system   bm-system-default-resource                                              Healthy   52m
kube-system   bm-system-default-service                                               Healthy   52m
kube-system   bm-system-default-statefulset                                           Healthy   57m
kube-system   bm-system-kubernetes                                                    Healthy   57m
kube-system   bm-system-network                                                       Healthy   32m
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 作业的相关信息，请执行以下操作：

  1. 获取已为指定集群运行的 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             25d

    SCHEDULE 列中的值表示按计划语法运行的每个健康检查作业的计划。例如，bm-system-kubernetes 作业会在每天 (* * *) 的每个小时 (*/1) 的第 17 分钟 (17) 运行。定期健康检查的时间间隔不可修改，但了解它们应该在什么时候运行对于问题排查很有用。

  2. 检索特定 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 查看定期健康检查的日志：

  1. 获取 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

  2. 检索 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。

  1. 在 Google Cloud 控制台中，前往日志记录菜单中的 Logs Explorer 页面。

    转到日志浏览器

  2. 在查询字段中，输入以下基本查询：

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

  3. 查询结果窗口会显示节点机器健康检查的日志。

以下是定期健康检查的查询列表：

  • 默认

    resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.default-*"

  • 节点机器

    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    56d

    healthchecks.baremetal.cluster.gke.io 的 Pass 字段表示上次健康检查是通过 (true) 还是失败 (false)。

如需详细了解如何检查定期健康检查的状态，请参阅 HealthCheck 自定义资源和健康检查日志。

停用定期健康检查

默认情况下，所有集群都会启用定期健康检查。您可以通过在集群资源中将 periodicHealthCheck.enable 字段设置为 false 来停用集群的定期健康检查。

如需停用定期健康检查，请执行以下操作：

  1. 修改集群配置文件，并将 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
  ...

  2. 通过运行以下命令来更新集群：

    bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    替换以下内容：

    • CLUSTER_NAME：您要更新的集群的名称。

    • ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。

  3. 如需验证是否已停用定期健康检查，请运行以下命令，确认已删除相应的 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 来重新启用它们。

如需重新启用定期健康检查，请执行以下操作：

  1. 修改集群配置文件，并将 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
  ...

  2. 通过运行以下命令来更新集群：

    bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

    替换以下内容：

    • CLUSTER_NAME：您要更新的集群的名称。

    • ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。

  3. 如需验证是否已启用定期健康检查，请运行以下命令，确认是否存在相应的 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的连接

检查所有集群节点机器是否可以访问 Artifact 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 GDC 和虚拟机之前，VM Runtime on GDC 预检检查会验证一组节点机器前提条件。如果 VM Runtime on GDC 预检检查失败，则系统会阻止创建虚拟机。当 VMRuntime 自定义资源中的 spec.enabled 设置为 true 时，VM Runtime on GDC 预检检查会自动运行。

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

如需了解详情，请参阅 VM Runtime on GDC 预检检查。

运行最新的健康检查

在发现已知问题后，系统会更新健康检查（和预检查）。如需指示 bmctl 从已安装的次要版本的最新补丁映像中运行检查，请使用 --check-image-version latest 选项标志：

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

将 CLUSTER_NAME 替换为您要检查的集群的名称。

这有助于您发现最近发现的任何已知问题，而无需先升级集群。

您还可以在安装或升级集群之前执行最新的预检检查。如需了解详情，请参阅运行最新的预检检查。

配置漂移检测

当插件健康检查运行时，除其他检查项外，还会检查 Google Distributed Cloud 管理的资源是否发生意外变化。 具体而言，该检查会评估这些资源的清单，以确定外部实体是否进行了更改。这些检查有助于提前预警可能对集群运行状况造成不利影响的意外更改。 它们还提供有价值的问题排查信息。

检查哪些清单

除了少数例外情况，插件健康检查会检查集群的所有 Google Distributed Cloud 管理的资源。这些资源由 Google Distributed Cloud 软件安装和管理。此类资源有数百种，并且大多数清单都经过配置漂移检查。清单适用于各种资源，包括但不限于以下资源：

  • ClusterRoles
  • ClusterRoleBindings
  • CustomResourceDefinitions
  • DaemonSets
  • 部署
  • HorizontalPodAutoscalers
  • 签发者
  • MetricsServers
  • MutatingWebhookConfigurations
  • 命名空间
  • 网络
  • NetworkLoggings
  • PodDisruptionBudgets
  • 提供商
  • 角色
  • RoleBindings
  • 服务
  • StorageClasses
  • ValidatingWebhookConfigurations

不检查哪些清单

根据设计，我们会排除一些清单以供审核。出于隐私和安全考虑，我们会忽略特定类型的资源，例如证书、Secret 和 ServiceAccount。插件检查还会忽略一些资源和资源字段，因为我们预计这些资源和字段会发生更改，并且不希望这些更改触发配置漂移错误。例如，检查会忽略 Deployment 中的 replicas 字段，因为自动扩缩器可能会修改此值。

如何从审核中排除其他清单或清单的部分内容

一般来说，我们建议您不要更改 Google Distributed Cloud 管理的资源，也不要忽略对这些资源所做的更改。不过，我们也知道，有时需要修改资源才能满足特殊情况的要求或解决问题。为此，我们为舰队中的每个集群均提供了一个 ignore-config-drift ConfigMap。您可以使用这些 ConfigMap 来指定要从评估中排除的资源和特定资源字段。

Google Distributed Cloud 会为每个集群创建一个 ignore-config-drift ConfigMap。这些 ConfigMap 位于管理（管理员或混合）集群中相应集群命名空间下。例如，如果您有一个管理两个用户集群（user-one 和 user-two）的管理员集群 (admin-one)，则可以在 admin-one 集群的 cluster-user-one 命名空间中找到 user-one 集群的 ignore-config-drift ConfigMap。

如需将资源或资源字段从审核中排除，请执行以下操作：

  1. 向 ignore-config-drift ConfigMap 添加 data.ignore-resources 字段。

    此字段采用 JSON 字符串数组，每个字符串指定资源和（可选）资源中的特定字段。

  2. 在字符串数组中，以 JSON 对象的形式指定资源和（可选）要忽略的特定字段：

    资源和字段的 JSON 对象具有以下结构：

    {
  "Version": "RESOURCE_VERSION",
  "Kind": "RESOURCE_KIND",
  "Namespace": "RESOURCE_NAMESPACE",
  "Name": "RESOURCE_NAME",
  "Fields": [
    "FIELD_1_NAME",
    "FIELD_2_NAME",
    ...
    "FIELD_N_NAME"
  ]
}

    替换以下内容：

    • RESOURCE_VERSION：（可选）资源对应的 apiVersion 值。

    • RESOURCE_KIND：（可选）资源对应的 kind 值。

    • RESOURCE_NAMESPACE：（可选）资源对应的 metadata.namespace 值。

    • RESOURCE_NAME：（可选）资源对应的 metadata.name 值。

    • FIELD_NAME：（可选）指定要忽略的资源字段数组。如果您未指定任何字段，则插件检查会忽略对资源的所有更改。

    JSON 对象中的每个字段都是可选的，因此允许各种排列组合。您可以排除整个资源类别，也可以非常精确地排除特定资源中的特定字段。

    例如，如果您希望插件检查忽略对管理员集群上 ais Deployment 的 command 部分所做的任何更改，则 JSON 可能如下所示：

    {
  "Version": "apps/v1",
  "Kind": "Deployment",
  "Namespace": "anthos-identity-service",
  "Name": "ais",
  "Fields": [
    "command"
  ]
}

    您需要将此 JSON 对象作为数组中的字符串值添加到 config-drift-ignore ConfigMap 中的 ignore-resources，如以下示例所示：

    apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: "2024-09-24T00:39:45Z"
  name: config-drift-ignore
  namespace: cluster-example-admin
  ownerReferences:
  - apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    name: example-admin
  ...
data:
  ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]'
  ...

    借助此 ConfigMap 设置示例，您可以添加、移除或修改 ais Deployment 中的 command 字段，而不会触发任何配置漂移错误。 不过，如果修改 Deployment 中 command 部分以外的字段，插件检查仍会检测到这些修改，并将其报告为配置漂移。

    如果您想排除所有 Deployment，ignore-resources 值可能如下所示：

    ...
data:
  ignore-resources: '[{"Kind":"Deployment"}]'
...

    由于 ignore-resources 接受 JSON 字符串数组，因此您可以指定多个排除模式。如果您正在排查问题或对集群进行实验，并且不想触发配置漂移错误，那么这种灵活性（即可以从漂移检测中排除非常具体的资源和资源字段，也可以排除更广泛的资源类别）会很有用。

后续步骤

详情请参阅以下内容：

如果您需要其他帮助，请与 Cloud Customer Care 联系。 您还可以参阅获取支持，详细了解支持资源，包括以下内容：

  • 提交支持请求的要求。
  • 可帮助您排查问题的工具，例如环境配置、日志和指标。
  • 受支持的组件。