健康检查

健康检查是一种测试和监控现有集群运行情况的方法。健康检查会定期独立运行。您还可以使用 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-operator

    • controller-manager

    • cluster-api-provider

    • ais

    • capi-kubeadm-bootstrap-system

    • cert-manager

    • kube-dns

插件

插件检查会在预检检查和定期健康检查中自动运行,并且可以按需运行。如果缺少列出的任何插件,此健康检查不会返回错误。仅当插件存在且在命令执行时发生错误,检查才会返回错误。

这些检查对应于集群命名空间的管理员集群中运行的名为 bm-system-add-ons* 资源的 Bare Metal HealthCheck 自定义资源。如需详细了解健康检查资源,请参阅 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 Bare Metal HealthCheck 自定义资源 Status.Pass 值会设置为 falseFailures 部分中的 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 健康检查 严重级别

类型:机器类型

名称: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-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 作业的相关信息,请执行以下操作:

  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,并可在 Logs Explorer 中查看。定期健康检查在控制台日志中被归类为 Pod。

  1. 在 Google Cloud 控制台中,转到 Logging 菜单中的日志浏览器页面。

    转到日志浏览器

  2. 查询字段中,输入以下基本查询:

    resource.type="k8s_container"
    resource.labels.pod_name=~"bm-system.*-machine.*"
    
  3. 查询结果窗口会显示节点机器健康检查的日志。

下面列出了针对定期健康检查的查询:

  • 节点机器

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

    healthchecks.baremetal.cluster.gke.ioPass 字段指示上次健康检查是通过 (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 命令来更新集群:

    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 命令来更新集群:

    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。如需详细了解此类日志,请参阅健康检查日志

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 预检检查上的虚拟机运行时

后续步骤