预检检查是一种预防措施，可帮助您在开始执行主要集群操作（例如创建或升级集群）之前发现问题。在操作之前自动运行这些检查时，除非预检检查全部通过，否则系统不会对集群进行任何更改。您还可以按需运行预检查。
本文档介绍了每项检查、在何种情况下会自动运行、如何以及何时手动运行以及如何解读结果。
在 Google Distributed Cloud 中，您可以针对不同的情况运行预检检查：
当您使用
bmctl创建或升级集群和节点池资源时，Google Distributed Cloud 会运行预检检查。如果检查失败，则不进行任何更改。您也可以绕过这些检查，或者明确运行这些检查。当管理员集群或混合集群在用户集群上创建或更新 Kubernetes 资源时，Google Distributed Cloud 也会运行内部预检检查。这些检查会在实际应用更于受影响用户集群之前运行。 如果检查失败，则不进行任何更改。
PreflightCheck 自定义资源
运行预检检查时，Google Distributed Cloud 会创建 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）导致预检检查运行时，Google Distributed Cloud 会创建日志文件。以下是生成的内容及其位置：
预检检查日志会在以下命名格式
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。
如果预检检查失败，这些日志文件可帮助您确定问题并进行问题排查。
为集群创建进行预检检查
当您创建集群时，Google Distributed Cloud 会在进行任何更改之前自动运行预检检查。
检查了什么？
安装的预检检查会检查以下内容：
节点机器检查：
集群机器使用的是受支持的操作系统 (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事件实例，且满足端口要求。
所有检查都通过后，Google Distributed Cloud 会创建集群。如需详细了解创建集群的要求，请参阅安装前提条件概览。
针对集群创建运行按需预检检查
您还可以在创建集群之前独立运行预检检查。这样做可能很有益，因为主要集群操作（例如集群创建）非常耗时。在开始执行主要集群操作之前，单独识别和解决问题可能会有助于您进行调度。
自行管理的集群
以下命令验证指定的集群配置文件，但不会尝试创建集群本身：
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 标志的别名。
集群升级的预检检查
当您升级集群时，Google Distributed Cloud 会在进行任何更改之前自动运行预检检查。
检查了什么？
集群升级的预检检查会检查以下内容：
节点机器检查：
集群机器使用的是受支持的操作系统 (OS)。
操作系统版本。
操作系统使用的是受支持的内核版本。
对于 Ubuntu，复杂防火墙 (UFW) 已停用。
节点机器满足最低 CPU 要求。
节点机器的可用 CPU 资源超过 20%。
节点机器满足最低内存要求。
节点机器满足最低磁盘存储空间要求。
时间同步是在节点机器上配置的。
节点中存在将数据包路由到默认网关的默认路由。
域名系统 (DNS) 正常运行。如果集群配置为在代理后面运行，则会跳过此检查。
如果集群已配置为使用注册表镜像，则可以访问注册表镜像。
* 没有处于维护模式的控制平面节点或负载均衡器节点。
Google Cloud 会针对每个节点和集群进行检查：
Container Registry、
gcr.io、可达性已检查。如果集群已配置为使用注册表镜像，则会跳过此检查。Google API 可访问。
机器检查：
kubelet处于活跃状态，并在节点机器上运行。containerd处于活跃状态，并在节点机器上运行。容器网络接口 (CNI) 健康端点状态为健康。
Pod CIDR 不会与节点机器 IP 地址重叠。
节点网络检查（因负载均衡配置而异）：
Kubernetes API 服务器的 VIP 地址可供访问。
负载均衡器 VIP 可访问。
节点可以在所需端口上进行通信。
已预配
etcd事件实例，且已满足端口要求。
当所有检查都通过后，Google Distributed Cloud 会升级集群。如需详细了解如何升级集群，请参阅 Google Distributed Cloud 集群升级最佳实践和集群升级的生命周期和阶段。
按需运行集群升级的预检检查
您可以使用 bmctl check preflight 命令在升级集群之前运行预检检查。您可以在开始升级之前运行以下预检检查命令来检查集群是否已准备好进行升级：
更新集群配置文件中的集群版本 (
anthosBareMetalVersion)。使用以下命令检查集群是否已准备好进行升级并运行预检检查：
bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG替换以下内容：
CLUSTER_NAME：要升级的集群的名称。ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
使用此命令创建预检检查以测试集群升级时，系统会在管理员集群中创建
PreflightCheck自定义资源。
对现有集群进行内部预检检查
在将 Kubernetes 资源应用于现有集群时，Google Distributed Cloud 会自动执行内部预检检查。如果任何检查失败，除非您明确绕过检查，否则 Google Distributed Cloud 不会更改任何相关节点。
应用 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.30.100-gke.96
...
运行最新的预检检查
在发现已知问题后，系统会更新预检检查（和健康检查）。如需指示 bmctl 从已安装的次要版本的最新补丁映像中运行检查，请使用 --check-image-version latest 选项标志：
bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest
将 CLUSTER_NAME 替换为您要检查的集群的名称。
这有助于您发现最近发现的任何已知问题，而无需先创建或升级集群。
您还可以对活跃集群执行最新的健康检查，以确定其是否正常运行。如需了解详情，请参阅运行最新的健康检查。
忽略自动预检检查的结果
如果您在创建或升级集群之前按需运行预检检查，则可以跳过自动预检检查。如需绕过自动预检检查，请在运行 bmctl create cluster 或 bmctl upgrade cluster 时使用可选的 --force 标志。