预检检查是一种预防措施，有助于在启动主要集群操作（例如创建或升级集群）之前发现问题。如果在操作之前自动运行这些检查，除非预检检查全部通过，否则不会对集群进行任何更改。您还可以按需运行预检检查。
本文档介绍了每项检查、在哪些情况下会自动运行、如何以及何时手动运行，以及如何解释结果。
在 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：Google Cloud 连接性检查（Container Registry 和 Google API 访问），IP 地址为192.0.2.53和192.0.2.54的机器。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，系统会停用 Uncomplicated Firewall (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，系统会停用 Uncomplicated Firewall (UFW)。
节点机器满足最低 CPU 要求。
节点机器有 20% 以上的可用 CPU 资源。
节点机器满足最低内存要求。
节点机器满足最低磁盘存储空间要求。
时间同步在节点机器上配置。
节点中存在用于将数据包路由到默认网关的默认路由。
域名系统 (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。
以下是集群配置文件的一部分，该文件显示了设置为 true 的 bypassPreflightCheck 字段：
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.29.100-gke.251
...
运行最新的预检检查和健康检查
使用 bmctl 运行预检或健康检查时，您可以在命令中添加 --check-image-version latest 标志，以通过最新的 Google Distributed Cloud 补丁版本执行检查。这有助于您确定已知问题，而无需先创建或升级集群。
如需使用最新的检查列表来确定您的机器和网络是否已准备好创建集群，请执行以下操作：
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 标志。