预检检查是一种预防性措施，有助于在启动主要集群操作（例如创建或升级集群）之前排查问题。如果这些检查在操作之前自动运行，除非预检检查所有通过，否则系统不会对您的集群进行任何更改。您还可以按需运行预检检查。
本文档介绍了每项检查在何种情况下会自动运行、如何以及何时手动运行，以及如何解读结果。
在适用于裸金属的 GDCV 中，您可以针对不同的情况运行预检检查：
当您使用
bmctl创建或升级集群和节点池资源时，适用于 Bare Metal 的 GDCV 会运行预检检查。如果检查失败，则不会进行任何更改。您也可以绕过这些检查，或者明确运行这些检查。当管理员或混合集群在用户集群上创建或更新 Kubernetes 资源时，适用于 Bare Metal 的 GDCV 还会运行内部预检检查。这些检查会在更改应用到受影响的用户集群之前运行。如果检查失败，则不会进行任何更改。
PreflightCheck 项自定义资源
运行预检检查时，裸金属的 GDCV 会创建一个 PreflightCheck 自定义资源。PreflightCheck 自定义资源是永久性的，提供预检检查活动和结果的记录。
如需检索 PreflightCheck 自定义资源，请执行以下操作：
获取已针对指定集群运行的预检检查列表：
kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
响应按命名空间列出资源。您可以在所有命名空间中运行
kubectl get preflightchecks，以获取完整列表。对于每项资源，响应都会显示资源的存在时间以及预检检查是否通过。以下示例响应显示了cluster-test-admin001命名空间的PreflightCheck资源。NAMESPACE NAME PASS AGE cluster-test-admin001 test-admin001 true 52d cluster-test-admin001 test-admin001jkm4q true 52d cluster-test-admin001 test-admin001k79t7 true 6d20h cluster-test-admin001 upgrade-cluster-20231106-222746 true 6d20h检索特定
PreflightCheck自定义资源的详细信息：kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE替换以下内容：
ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。CLUSTER_NAMESPACE：集群的命名空间。
以下示例命令响应显示了在集群创建过程中运行的成功预检检查的
PreflightCheck资源：Name: create-cluster-20230922-175006 Namespace: cluster-test-user001 Labels: <none> Annotations: <none> API Version: baremetal.cluster.gke.io/v1 Kind: PreflightCheck Metadata: Creation Timestamp: 2023-09-22T17:50:11Z Generation: 1 Resource Version: 6502800 UID: 917daf64-963d-44b4-a1f9-c54972a39191 Spec: Check Image Version: latest Config YAML: --- apiVersion: v1 kind: Namespace metadata: name: cluster-test-user --- apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: test-user001 namespace: cluster-test-user001 spec: type: user profile: default anthosBareMetalVersion: 1.16.0 gkeConnect: projectID: clusters-project controlPlane: nodePoolSpec: nodes: - address: 192.0.2.53 ... --- apiVersion: baremetal.cluster.gke.io/v1 kind: NodePool metadata: name: node-pool-1 namespace: cluster-test-user001 spec: clusterName: test-user001 nodes: - address: 192.0.2.54 ... Status: Checks: 192.0.2.53: Job UID: d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c Message: Pass: true 192.0.2.53-gcp: Job UID: b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8 Message: Pass: true 192.0.2.54: Job UID: b67cf195-3951-46ad-b91c-0d79025cfc0a Message: Pass: true 192.0.2.54-gcp: Job UID: aed509e2-4bf7-44c4-bfa0-8147ef8ea74e Message: Pass: true Gcp: Job UID: ac479ac4-e1c4-4681-9f2b-5773069bf6ae Message: Pass: true Node - Network: Job UID: 8a57c4ee-ad17-4560-8809-b117c871ad5d Message: Pass: true Pod - Cidr: 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 ... Completion Time: 2023-09-22T17:51:22Z Conditions: Last Transition Time: 2023-10-02T23:59:06Z Observed Generation: 1 Reason: Reconciling Status: True Type: Reconciling Node Pool Specs: node-pool-1: Cluster Name: test-user001 Nodes: Address: 192.0.2.54 ... Pass: true Start Time: 2023-09-22T17:50:32Z Events: <none>在前面的
PreflightCheck自定义资源中，Status部分包含以下信息：Checks部分列出了已运行的各项预检检查，以及这些检查是否通过。在此示例中，运行了以下检查：192.0.2.53和192.0.2.54：针对 IP 地址为192.0.2.53和192.0.2.54的机器的节点检查（操作系统配置、资源和软件设置）。192.0.2.53-gpc和192.0.2.54-gcp：对于 IP 地址为192.0.2.53和192.0.2.54的机器，Google Cloud 连接检查（Container Registry 和 Google API 访问权限）。Gcp：针对集群的 Google Cloud 连接检查。Node - Network：集群网络检查（连接、etcd操作、VIP 访问和端口绑定）。Pod - Cidr：检查 Pod IP 地址是否存在集群重叠的地址。
Cluster Spec部分显示集群配置。Pass字段显示true，表示已总体通过预检检查。
预检检查日志
因 bmctl 命令（例如 bmctl check
preflight）的结果而运行预检检查时，适用于裸金属的 GDCV 会创建日志文件。生成的代码及其位置如下：
预检检查日志采用以下命名模式
preflight-TIMESTAMP在一个目录中生成。此预检目录是在
bmctl工作区内集群的log目录中创建的。默认情况下，log目录路径为bmctl-workspace/CLUSTER_NAME/log。预检日志包含以下文件：
节点机器检查的日志文件，每个集群节点对应一个。这些日志文件使用节点的 IP 地址命名。例如，文件名可能是
192.0.2.53。用于 Google Cloud 访问权限检查的日志文件，每个集群节点对应一个。系统会使用节点的 IP 地址对这些日志文件命名。例如，文件名可能是
192.0.2.53-gcp。用于集群 Google Cloud 访问权限检查的日志文件，名为
gcp。节点网络检查的日志文件，名为
node-network。
如果预检检查失败，这些日志文件可帮助您找出问题并排查问题。
集群创建的预检检查
当您创建集群时，Bare Metal 的 GDCV 会在进行任何更改之前自动运行预检检查。
检查的内容
针对安装的预检检查：
节点机器检查：
集群机器使用的是受支持的操作系统 (OS)。
操作系统版本受支持。
操作系统使用的是受支持的内核版本。
在 Ubuntu 中，停用了非复杂防火墙 (UFW)。
对于 Ubuntu，软件包管理器
apt可操作，并且所需的软件包可用。对于 Red Hat Enterprise Linux，软件包管理器
dnf可操作，并且必需的软件包可供使用。对于 Red Hat Enterprise Linux，未安装 Podman。
节点机器满足最低 CPU 要求。
节点机器满足最低内存要求。
节点机器满足最低磁盘存储空间要求。
时间同步是在节点机器上配置。
kubelet处于活跃状态，且正在节点机器上运行。containerd处于活跃状态，且正在节点机器上运行。节点中存在用于将数据包路由到默认网关的默认路由。
域名系统 (DNS) 运行正常。如果集群配置为在代理后面运行，则会跳过此检查。
Pod CIDR 与节点机器 IP 地址不重叠。
如果集群配置为使用注册表镜像，则可访问注册表镜像。
Google Cloud 会检查每个节点和集群：
Container Registry
gcr.io，已检查可达性。如果集群配置为使用注册表镜像，则会跳过此检查。可访问 Google API。
节点网络检查（因负载均衡配置而异）：
Kubernetes API 服务器的 VIP 可以访问。
负载平衡器 VIP 可以访问。
节点可以在所需端口上进行通信。
已预配
etcd事件实例，并且满足端口要求。
所有检查均通过后，裸金属的 GDCV 会创建集群。如需详细了解创建集群的要求，请参阅安装前提条件概览。
针对创建集群运行按需预检检查
您也可以在创建集群之前独立运行预检检查。这样做的好处在于，大型集群操作（例如集群创建）非常耗时。在开始主要集群操作之前单独识别和解决问题可能有助于您进行调度。
自行管理的集群
以下命令会验证指定的集群配置文件，但不会尝试创建集群本身：
bmctl check config --cluster CLUSTER_NAME将
CLUSTER_NAME替换为与您正在检查的配置文件关联的集群的名称。此命令可检查机器和网络是否已准备好创建集群：
bmctl check preflight --cluster CLUSTER_NAME将
CLUSTER_NAME替换为您要检查的集群的名称。
用户集群
以下命令验证指定的集群配置文件，但不会尝试创建集群本身：
bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：您要检查的用户集群的名称。ADMIN_KUBECONFIG：关联的管理员集群 kubeconfig 文件的路径。
以下命令用于检查机器和网络是否已准备好创建集群：
bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
bmctl 支持使用 --kubeconfig 作为 --admin-kubeconfig 标志的别名。
针对集群升级的预检检查
当您升级集群时，Bare Metal 的 GDCV 会在进行任何更改之前自动运行预检检查。
检查的内容
集群升级的预检检查检查以下各项：
节点机器检查：
集群机器使用的是受支持的操作系统 (OS)。
操作系统版本受支持。
操作系统使用的是受支持的内核版本。
在 Ubuntu 中，停用了非复杂防火墙 (UFW)。
节点机器满足最低 CPU 要求。
节点机器有 20% 以上的可用 CPU 资源。
节点机器满足最低内存要求。
节点机器满足最低磁盘存储空间要求。
时间同步是在节点机器上配置。
节点中存在用于将数据包路由到默认网关的默认路由。
域名系统 (DNS) 运行正常。如果集群配置为在代理后面运行，则会跳过此检查。
如果集群配置为使用注册表镜像，则可访问注册表镜像。
* 没有任何控制平面节点或负载均衡器节点处于维护模式。
Google Cloud 会检查每个节点和集群：
Container Registry
gcr.io，已检查可达性。如果集群配置为使用注册表镜像，则会跳过此检查。可访问 Google API。
机器检查：
kubelet处于活跃状态，且正在节点机器上运行。containerd处于活跃状态，且正在节点机器上运行。容器网络接口 (CNI) 运行状况端点状态为良好。
Pod CIDR 与节点机器 IP 地址不重叠。
节点网络检查（因负载均衡配置而异）：
Kubernetes API 服务器的 VIP 可以访问。
负载平衡器 VIP 可以访问。
节点可以在所需端口上进行通信。
已预配
etcd事件实例，并且满足端口要求。
所有检查均通过后，裸金属的 GDCV 会升级集群。如需详细了解如何升级集群，请参阅裸金属集群升级的 GDCV 最佳做法以及集群升级的生命周期和阶段。
针对集群升级运行按需预检检查
借助 bmctl check preflight 命令，您可以在升级集群之前运行预检检查。在开始升级之前，您可以运行以下预检检查命令来检查集群是否已准备好进行升级：
更新集群配置文件中的集群版本 (
anthosBareMetalVersion)。使用以下命令检查集群是否已准备好进行升级，并运行预检检查：
bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：要升级的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
使用此命令创建预检检查以测试集群升级时，系统会在管理员集群中创建
PreflightCheck自定义资源。
对现有集群进行内部预检检查
将 Kubernetes 资源应用于现有集群时，适用于 Bare Metal 的 GDCV 会自动执行内部预检检查。如果任何检查失败，除非您明确绕过检查，否则裸金属的 GDCV 不会更改任何相关节点。
应用 Kubernetes 资源时绕过预检检查
如需在将资源应用于现有集群时忽略内部预检检查，您需要在集群配置文件中将 BypassPreflightCheck 字段设置为 true。
下面是集群配置文件的一部分，其中显示 bypassPreflightCheck 字段设置为 true：
apiVersion: v1
kind: Namespace
metadata:
name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user1
namespace: cluster-user1
spec:
type: user
bypassPreflightCheck: true
# Anthos cluster version.
anthosBareMetalVersion: 1.28.400-gke.77
...
运行最新的预检检查和健康检查
使用 bmctl 运行预检或健康检查时，您可以在命令中添加 --check-image-version latest 标志，以从针对裸金属补丁程序版本的最新 GDCV 执行检查。这有助于您找出已知问题，而无需先创建或升级集群。
如需使用最新的检查列表来确定您的机器和网络是否已准备好创建集群，请执行以下操作：
bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest将
CLUSTER_NAME替换为您要检查的集群的名称。
您还可以对活跃集群执行最新的健康检查，以确定集群是否健康状况良好。
如需对活跃集群执行最新的健康检查，请执行以下操作：
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest将
CLUSTER_NAME替换为您要检查的集群的名称。
忽略自动预检检查的结果
如果您在创建或升级集群之前按需运行预检检查，则可以绕过自动预检检查。如需绕过自动预检检查，请在运行 bmctl create cluster 或 bmctl upgrade cluster 时使用可选的 --force 标志。