集成测试用例列表

TestDownloadOnly

确保 --download-only 参数在 minikube start 时缓存适当的镜像和 tarball。

TestDownloadOnlyKic

确保 --download-only 也缓存 docker 驱动的镜像。

TestBinaryMirror

测试 --binary-mirror 标志的功能

TestOffline

确保 minikube 在用户缓存了必要的镜像后，无需互联网即可工作。此测试必须在 TestDownloadOnly 之后运行。

TestAddons

并行测试无需特殊环境的附加组件

validateIngressAddon

通过部署一个默认的 nginx pod 来测试 ingress 附加组件

validateRegistryCredsAddon

通过尝试加载其配置来测试 registry-creds 附加组件

validateRegistryAddon

测试 registry 附加组件

validateMetricsServerAddon

通过确保“kubectl top pods”返回合理的结果来测试 metrics-server 附加组件

validateOlmAddon

测试 OLM 附加组件

validateCSIDriverAndSnapshots

通过创建持久卷、快照并恢复它来测试 csi hostpath 驱动。

validateGCPAuthNamespaces

验证新创建的命名空间是否包含 gcp-auth 密钥。

validateGCPAuthAddon

使用虚假或真实凭据测试 GCP Auth 附加组件，并确保文件正确挂载到 pod 中

validateHeadlampAddon

validateInspektorGadgetAddon

通过确保 pod 已启动并禁用附加组件来测试 inspektor-gadget 附加组件

validateCloudSpannerAddon

通过确保部署和 pod 启动以及附加组件禁用，来测试 cloud-spanner 附加组件

validateVolcanoAddon

测试 Volcano 附加组件，确保 Volcano 已安装到集群中。

validateLocalPathAddon

测试 storage-provisioner-rancher 附加组件的功能

validateEnablingAddonOnNonExistingCluster

测试在不存在的集群上启用附加组件

validateDisablingAddonOnNonExistingCluster

测试在不存在的集群上禁用附加组件

validateNvidiaDevicePlugin

通过确保 pod 启动以及附加组件禁用，来测试 nvidia-device-plugin 附加组件

validateAmdGpuDevicePlugin

通过确保 pod 启动以及附加组件禁用，来测试 amd-gpu-device-plugin 附加组件

validateYakdAddon

TestCertOptions

确保 minikube 证书遵守 --apiserver-ips 和 --apiserver-names 参数

TestCertExpiration

确保 minikube 在其配置文件证书过期后仍能启动。它通过将 minikube 证书配置为在 3 分钟后过期，然后等待 3 分钟，然后重新启动来做到这一点。它还确保 minikube 向用户打印证书过期警告。

TestDockerFlags

确保 --docker-env 和 --docker-opt 参数得到遵守

TestForceSystemdFlag

按预期测试 --force-systemd 标志。

validateDockerSystemd

确保 --force-systemd 标志在 docker 容器运行时有效

validateContainerdSystemd

确保 --force-systemd 标志在 containerd 容器运行时有效

validateCrioSystemd

确保 --force-systemd 标志在 cri-o 容器运行时有效

TestForceSystemdEnv

确保 MINIKUBE_FORCE_SYSTEMD 环境变量与 --force-systemd 标志一样有效

TestDockerEnvContainerd

确保在运行时是 containerd 时，minikube docker-env 命令有效

TestHyperKitDriverInstallOrUpdate

确保我们的 docker-machine-driver-hyperkit 二进制文件可以正确安装

TestHyperkitDriverSkipUpgrade

确保我们的 docker-machine-driver-hyperkit 二进制文件可以正确安装

TestErrorSpam

断言 minikube 命令输出中没有意外错误显示。

TestParseAllMounts

TestParseSingle

TestFunctional

是功能测试，可以安全地并行共享配置文件

TestFunctionalNewestKubernetes

使用 NewestKubernetesVersion 运行功能测试

validateNodeLabels

检查 minikube 集群是否使用正确的 kubernetes 节点标签创建

步骤

• 使用 kubectl get nodes 从集群获取节点标签
• 检查节点标签是否与预期的 Minikube 标签匹配：minikube.k8s.io/*

validateImageCommands

对所有 minikube image 命令运行测试，例如 minikube image load、minikube image list 等。

步骤

• 通过 minikube image build 确保镜像构建正常工作
• 通过 minikube image load --daemon 确保从 Docker 守护进程加载镜像正常工作
• 尝试加载已加载的镜像，并确保 minikube image load --daemon 有效
• 通过 minikube image load --daemon 确保新更新的标签有效
• 通过 minikube image load --daemon 确保镜像保存正常工作
• 通过 minikube image rm 确保镜像移除正常工作
• 通过 minikube image load 确保从文件加载镜像正常工作
• 通过 minikube image load 确保将镜像保存到 Docker 守护进程正常工作

跳过

• 跳过 none 驱动，因为不支持镜像加载
• 跳过 GitHub Actions / prow 环境和 macOS，因为此测试用例需要正在运行的 docker 守护进程

validateDockerEnv

评估 docker-env 后检查 minikube 的功能

步骤

• 运行 eval $(minikube docker-env) 将当前环境配置为使用 minikube 的 Docker 守护进程
• 运行 minikube status 获取 minikube 状态
• 确保 minikube 组件的状态为 Running
• 确保 docker-env 的状态为 in-use
• 运行 eval $(minikube -p profile docker-env) 并检查我们是否指向 minikube 中的 docker
• 确保 docker images hits minikube 的 Docker 守护进程，方法是检查 gcr.io/k8s-minikube/storage-provisioner 是否在 docker images 的输出中

跳过

• 跳过 none 驱动，因为不支持 docker-env
• 跳过非 docker 容器运行时

validatePodmanEnv

评估 podman-env 后检查 minikube 的功能

步骤

• 运行 eval $(minikube podman-env) 将当前环境配置为使用 minikube 的 Podman 守护进程，并运行 minikube status 获取 minikube 状态
• 确保 minikube 组件的状态为 Running
• 确保 podman-env 的状态为 in-use
• 再次运行 eval $(minikube docker-env) 和 docker images 来列出使用 minikube 的 Docker 守护进程的 docker 镜像
• 确保 docker images hits minikube 的 Podman 守护进程，方法是检查 gcr.io/k8s-minikube/storage-provisioner 是否在 docker images 的输出中

跳过

• 跳过 none 驱动，因为不支持 podman-env
• 跳过非 docker 容器运行时
• 跳过非 Linux 平台

validateStartWithProxy

确保 minikube start 遵守 HTTP_PROXY 环境变量

步骤

• 启动本地 HTTP 代理
• 使用设置为本地 HTTP 代理的环境变量 HTTP_PROXY 启动 minikube

validateStartWithCustomCerts

确保 minikube start 遵守 HTTPS_PROXY 环境变量，并且与自定义证书一起工作。通过在后台调用 mitmdump 二进制文件来启动代理，然后安装由二进制文件生成的证书。mitmproxy/dump 在 localhost 的 8080 端口创建代理。仅在 amd64 Linux 的 GitHub Actions 上运行，否则将运行 validateStartWithProxy。

validateAuditAfterStart

确保审计日志在 minikube start 后包含正确的日志

步骤

• 读取审计日志文件，并确保其中包含当前 minikube 配置文件的名称

validateSoftStart

验证在 minikube 已启动后，minikube start 不应更改配置。

步骤

• 测试 validateStartWithProxy 应该已经启动了 minikube，确保配置的节点端口是 8441
• 再次运行 minikube start 进行软启动
• 确保配置的节点端口未更改

validateKubeContext

断言 kubectl 配置正确（易受竞争条件影响！)

步骤

• 运行 kubectl config current-context
• 确保当前 minikube 配置文件的名称在命令输出中

validateKubectlGetPods

断言 kubectl get pod -A 返回非空内容

步骤

• 运行 kubectl get po -A 获取当前 minikube 配置文件的所有 pod
• 确保输出不为空并包含 kube-system 组件

validateMinikubeKubectl

验证 minikube kubectl 命令是否返回内容

步骤

• 运行 minikube kubectl -- get pods 获取当前 minikube 配置文件的 pod
• 确保命令不引发任何错误

validateMinikubeKubectlDirectCall

验证调用命名为“kubectl”的 minikube 二进制文件是否充当 kubectl 包装器。这测试了当通过名为“kubectl”的二进制文件调用时，minikube 充当 kubectl 的功能。

步骤

• 通过调用 minikube 的 kubectl 二进制文件直接运行 kubectl get pods
• 确保命令不引发任何错误

validateExtraConfig

验证 --extra-config 的 minikube 是否按预期工作

步骤

• 之前的测试已创建配置文件
• 软启动 minikube，使用不同的 --extra-config 命令行选项
• 加载配置文件
• 确保指定的 --extra-config 已正确返回

validateComponentHealth

断言所有 Kubernetes 组件都健康。注意：它期望所有组件都处于 Ready 状态，因此最好在仅包含“–wait=all”启动标志的那些测试之后运行它。

步骤

• 运行 kubectl get po po -l tier=control-plane -n kube-system -o=json 获取所有 Kubernetes 组件
• 对于每个组件，确保 pod 状态为 Running

validateStatusCmd

确保 minikube status 输出正确

步骤

• 运行 minikube status 并使用自定义格式 host:{{.Host}},kublet:{{.Kubelet}},apiserver:{{.APIServer}},kubeconfig:{{.Kubeconfig}}
• 确保在输出中显示 host、kublete、apiserver 和 kubeconfig 状态
• 再次运行 minikube status 作为 JSON 输出
• 确保 host、kublete、apiserver 和 kubeconfig 状态在 JSON 输出中设置

validateDashboardCmd

断言 dashboard 命令有效

步骤

• 运行 minikube dashboard --url 来启动 minikube dashboard 并返回其 URL
• 向 dashboard URL 发送 GET 请求
• 确保返回 HTTP 状态 OK

validateDryRun

断言 dry-run 模式会快速退出并返回正确的代码

步骤

• 运行 minikube start --dry-run --memory 250MB
• 由于 250MB 内存少于所需的 2GB，minikube 应以退出代码 ExInsufficientMemory 退出
• 运行 minikube start --dry-run
• 确保命令不引发任何错误

validateInternationalLanguage

断言语言可以通过环境变量更改

步骤

• 设置环境变量 LC_ALL=fr 以启用 minikube 到法语的翻译
• 使用 250MB 的内存启动 minikube，这太少了：minikube start --dry-run --memory 250MB
• 确保 dry-run 输出消息为法语

validateCacheCmd

测试 cache 命令的功能（cache add, delete, list）

步骤

• 运行 minikube cache add 并确保我们可以将远程镜像添加到缓存中
• 运行 minikube cache add 并确保我们可以构建本地镜像并将其添加到缓存中
• 运行 minikube cache delete 并确保我们可以从缓存中删除镜像
• 运行 minikube cache list 并确保我们可以列出缓存中的镜像
• 运行 minikube ssh sudo crictl images 并确保我们可以使用 crictl 列出缓存中的镜像
• 从 minikube 节点删除一个镜像并运行 minikube cache reload 以确保镜像被正确恢复

validateConfigCmd

断言基本的“config”命令功能

步骤

• 运行 minikube config set/get/unset 以确保配置已正确修改

validateLogsCmd

断言基本的“logs”命令功能

步骤

• 运行 minikube logs 并确保日志包含一些关键词，如 apiserver、Audit 和 Last Start

validateLogsFileCmd

断言“logs –file”命令功能

步骤

• 运行 minikube logs --file logs.txt 将日志保存到本地文件
• 确保日志已正确写入

validateProfileCmd

断言“profile”命令功能

步骤

• 运行 minikube profile lis 并确保该命令不会因不存在的配置文件 lis 而失败
• 运行 minikube profile list --output json 以确保上一个命令没有创建新配置文件
• 运行 minikube profile list 并确保配置文件已正确列出
• 运行 minikube profile list -o JSON 并确保配置文件已正确列为 JSON 输出

validateServiceCmd

断言基本的“service”命令功能

validateServiceCmdDeployApp

创建一个新的 kickbase/echo_server 部署

validateServiceCmdList

运行 minikube service list 以确保新创建的服务已正确列在输出中

validateServiceCmdJSON

运行 minikube service list -o JSON 并确保服务已正确列为 JSON 输出

validateServiceCmdHTTPS

运行 minikube service 并使用 --https --url 以确保打印服务的 HTTPS 端点 URL

validateServiceCmdFormat

运行 minikube service 并使用 --url --format={{.IP}} 以确保打印服务的 IP 地址

validateServiceCmdURL

运行 minikube service 并使用常规的 --url 以确保打印服务的 HTTP 端点 URL

validateServiceCmdConnect

步骤

• 创建一个新的 kickbase/echo-server 部署
• 运行 minikube service 并使用常规的 --url 以确保打印服务的 HTTP 端点 URL
• 确保我们可以通过 HTTP GET 请求访问端点 URL

validateAddonsCmd

断言基本的“addon”命令功能

步骤

• 运行 minikube addons list 以表格格式列出附加组件
• 确保 dashboard、ingress 和 ingress-dns 被列为可用附加组件
• 运行 minikube addons list -o JSON 以 JSON 格式列出附加组件

validateSSHCmd

断言基本的“ssh”命令功能

步骤

• 运行 minikube ssh echo hello 以确保我们可以 SSH 进入 minikube 容器并运行命令
• 还运行 minikube ssh cat /etc/hostname 以确保命令在 minikube 内部运行

validateCpCmd

断言基本的“cp”命令功能

步骤

• 运行 minikube cp ... 将文件复制到 minikube 节点
• 运行 minikube ssh sudo cat ... 在 minikube 内部打印复制的文件
• 确保文件已正确复制

跳过

• 跳过 none 驱动，因为不支持 cp

validateMySQL

验证一个极简的 MySQL 部署

步骤

• 运行 kubectl replace --force -f testdata/mysql/yaml
• 等待 mysql pod 处于运行状态
• 在 mysql pod 中运行 mysql -e show databases; 来验证 MySQL 是否已启动并正在运行
• 如果失败，则以指数退避重试，因为 mysqld 最初会在没有配置用户的情况下启动。在重新调度的情况下扫描名称。

validateFileSync

检查测试文件的存在

步骤

• 测试文件已在之前的 setupFileSync 步骤中同步到 minikube
• 检查测试文件的存在
• 确保文件已正确同步

跳过

• 跳过 none 驱动，因为不支持 SSH

validateCertSync

检查以确保自定义证书已复制到 minikube 虚拟机并正确安装

步骤

• 检查已安装的证书和引用证书，并确保它们是符号链接

validateNotActiveRuntimeDisabled

断言对于给定的运行时，其他运行时已被禁用。例如，对于 containerd 运行时，docker 和 crio 需要处于非运行状态

步骤

• 对于每个容器运行时，运行 minikube ssh sudo systemctl is-active ... 并确保其他容器运行时未运行

validateUpdateContextCmd

断言基本的“update-context”命令功能

步骤

• 运行 minikube update-context
• 通过检查命令输出，确保上下文已正确更新

validateVersionCmd

断言 minikube version 命令对 --short 和 --components 都有效

步骤

• 运行 minikube version --short 并确保返回的版本是有效的 semver
• 运行 minikube version --components 并确保返回组件版本

validateLicenseCmd

断言 minikube license 命令会下载并解压许可证。注意：此测试将在发布 PR 中失败，因为新版本的许可证文件此时尚未上传。

validateInvalidService

确保 minikube 不会为没有运行 pod 的不可用服务启动隧道

validateMountCmd

验证 minikube mount 命令在支持它的平台上是否正常工作。我们正在测试

• 一个通用的 9p 挂载
• 一个特定端口上的 9p 挂载
• 配置文件特定挂载的清理机制

validatePersistentVolumeClaim

确保 PVC 工作正常。验证至少存在一个 StorageClass。应用一个 PVC 清单 (pvc.yaml) 并验证名为 myclaim 的 PVC 达到 Bound 状态。创建一个挂载了声明 (通过 createPVTestPod) 的测试 pod (sp-pod)。将文件 foo 写入挂载卷中的 /tmp/mount/foo。删除 pod，重新创建它，并验证文件 foo 仍然存在，方法是列出 /tmp/mount，证明数据在 pod 重启后仍然存在。

validateTunnelCmd

确保 minikube tunnel 命令按预期工作

validateTunnelStart

启动 minikube tunnel

validateNoSecondTunnel

确保一次只能运行一个隧道

validateServiceStable

启动 nginx pod，nginx 服务，并等待 nginx 获得 loadbalancer ingress IP

validateAccessDirect

从主机验证测试服务是否可以使用 LoadBalancer IP 访问

validateDNSDig

通过 dig 命令 DNS 查询来验证 DNS 转发是否正常工作。注意：DNS 转发是实验性的：https://minikube.cn/docs/handbook/accessing/#dns-resolution-experimental

validateDNSDscacheutil

通过 dscacheutil 命令 DNS 查询来验证 DNS 转发是否正常工作。注意：DNS 转发是实验性的：https://minikube.cn/docs/handbook/accessing/#dns-resolution-experimental

validateAccessDNS

从主机验证 DNS 转发是否正常工作。注意：DNS 转发是实验性的：https://minikube.cn/docs/handbook/accessing/#dns-resolution-experimental

validateTunnelDelete

停止 minikube tunnel

TestGvisorAddon

测试 gVisor 附加组件的功能

TestMultiControlPlane

测试所有 ha（多控制平面）集群功能

validateHAStartCluster

确保 ha（多控制平面）集群可以启动。

validateHADeployApp

将应用程序部署到 ha（多控制平面）集群，并确保所有节点都可以提供流量。

validateHAPingHostFromPods

使用 validateDeployAppToHACluster 之前部署的应用程序来验证其 pod（位于不同节点上）是否可以解析“host.minikube.internal”。

validateHAAddWorkerNode

使用 minikube node add 命令将工作节点添加到现有 ha（多控制平面）集群。

validateHANodeLabels

检查所有节点标签是否配置正确。

步骤

• 使用 kubectl get nodes 从集群获取节点标签
• 检查所有节点标签是否与预期的 Minikube 标签匹配：minikube.k8s.io/*

validateHAStatusHAppy

确保 minikube profile list 在 ha（多控制平面）集群上输出正确。

validateHACopyFile

确保 minikube cp 在 ha（多控制平面）集群上正常工作。

validateHAStopSecondaryNode

通过使用 minikube node stop 命令停止辅助控制平面节点来测试 ha（多控制平面）集群。

validateHAStatusDegraded

确保 minikube profile list 在 ha（多控制平面）集群上输出正确。

validateHARestartSecondaryNode

测试现有的已停止的辅助节点上的 minikube node start 命令。

validateHARestartClusterKeepsNodes

重新启动 minikube 集群并检查报告的节点列表是否未更改。

validateHADeleteSecondaryNode

测试辅助控制平面的 minikube node delete 命令。注意：当前，“minikube status”子命令依赖于主控制平面节点，并且 storage-provisioner 仅在主控制平面节点上运行。

validateHAStopCluster

在 ha（多控制平面）集群上运行 minikube stop。

validateHARestartCluster

验证 ha（多控制平面）集群上的软重启是否正常工作。

validateHAAddSecondaryNode

使用 minikube node add 命令将辅助控制平面节点添加到现有的 ha（多控制平面）集群。

TestImageBuild

确保 ‘minikube image build’ 命令正常工作

validateSetupImageBuild

启动用于镜像构建的集群

validateNormalImageBuild

是 minikube image build 的正常测试用例，带 -t 参数

validateNormalImageBuildWithSpecifiedDockerfile

是 minikube image build 的正常测试用例，带 -t 和 -f 参数

validateImageBuildWithBuildArg

是使用 –build-opt 进行构建的测试用例

validateImageBuildWithBuildEnv

是使用 –build-env 进行构建的测试用例

validateImageBuildWithDockerIgnore

是使用 .dockerignore 进行构建的测试用例

TestISOImage

验证安装在 minikube ISO/Base 镜像内部的文件和包

TestJSONOutput

确保 start、pause、unpause 和 stop 命令的 JSON 输出正常工作

validateDistinctCurrentSteps

确保每个步骤都有一个唯一的步骤编号

validateIncreasingCurrentSteps

验证对于成功的 minikube start，‘current step’应该递增

TestErrorJSONOutput

确保 JSON 输出能够正确打印错误

TestKicCustomNetwork

验证 docker 驱动程序是否与自定义网络一起工作

TestKicExistingNetwork

验证 docker 驱动程序并使用现有网络运行

TestKicCustomSubnet

验证 docker/podman 驱动程序是否与自定义子网一起工作

TestKicStaticIP

使用静态 IP 标志启动 minikube

TestingKicBaseImage

如果集成测试是针对传递的 –base-image 标志运行的，则返回 true

TestMinikubeProfile

TestMountStart

测试在启动时使用 mount 命令

validateStartWithMount

启动启用了 mount 的集群

validateMount

检查集群是否挂载了文件夹

validateMountStop

停止集群

validateRestart

重启集群

TestMultiNode

测试所有多节点集群功能

validateMultiNodeStart

确保 2 节点集群可以启动

validateAddNodeToMultiNode

使用 minikube node add 命令将节点添加到现有集群

validateProfileListWithMultiNode

确保 minikube profile list 在多节点集群上输出正确

validateCopyFileWithMultiNode

确保 minikube cp 在多节点集群上正常工作。

validateMultiNodeLabels

检查所有节点标签是否配置正确

步骤

• 使用 kubectl get nodes 从集群获取节点标签
• 检查所有节点标签是否与预期的 Minikube 标签匹配：minikube.k8s.io/*

validateStopRunningNode

测试 minikube node stop 命令

validateStartNodeAfterStop

测试在已停止的节点上运行 minikube node start 命令

validateRestartKeepsNodes

重新启动 minikube 集群并检查报告的节点列表是否未更改

validateStopMultiNodeCluster

在多节点集群上运行 minikube stop

validateRestartMultiNodeCluster

验证多节点集群上的软重启是否正常工作

validateDeleteNodeFromMultiNode

测试 minikube node delete 命令

validateNameConflict

测试节点名称验证是否按预期工作

validateDeployAppToMultiNode

将应用程序部署到多节点集群，并确保所有节点都能提供流量

validatePodsPingHost

使用 validateDeployAppToMultiNode 之前部署的应用程序来验证其 pod（位于不同节点上）是否可以解析“host.minikube.internal”。

TestNetworkPlugins

测试所有支持的 CNI 选项。测试的选项：kubenet、bridge、flannel、kindnet、calico、cilium。测试的标志：enable-default-cni（旧版）、false（CNI 关闭）、自动检测

validateFalseCNI

检查当容器运行时为“containerd”或“crio”且 –cni=false 时，minikube 是否返回错误

validateHairpinMode

确保为给定的 CNI 正确配置了 hairpinning（https://en.wikipedia.org/wiki/Hairpinning）。尝试使用从“netcat”服务 DNS 解析获得的外部 IP 地址访问 deployment/netcat pod。如果 hairpinMode 关闭，访问应该失败。

TestNoKubernetes

测试在没有 Kubernetes 的情况下启动 minikube，用于用户只需要使用 minikube 内部容器运行时（docker、containerd、crio）的用例

validateStartNoK8sWithVersion

期望在启动没有 Kubernetes 的 minikube 集群并指定 Kubernetes 版本时出现错误。

步骤

• 启动没有 Kubernetes 的 minikube。

validateStartWithK8S

启动已启动/配置的 Kubernetes 的 minikube 集群。

步骤

• 启动带 Kubernetes 的 minikube。
• 如果 Kubernetes 未运行，则返回错误。

validateStartWithStopK8s

在停止 Kubernetes 的同时启动 minikube 集群。

步骤

• 启动没有 Kubernetes 的 minikube。
• 如果 Kubernetes 未停止，则返回错误。
• 删除 minikube 配置文件。

validateStartNoK8S

启动没有启动/配置 Kubernetes 的 minikube 集群

步骤

• 启动没有 Kubernetes 的 minikube。

validateK8SNotRunning

验证 minikube 内部没有运行 Kubernetes

validateStopNoK8S

验证在 --no-kubernetes 启动后 minikube 已停止

validateProfileListNoK8S

验证 profile list 在 --no-kubernetes 下是否正常工作

validateStartNoArgs

验证不带参数的 minikube start 是否正常工作。

TestChangeNoneUser

测试以确保 CHANGE_MINIKUBE_NONE_USER 环境变量得到遵守，并将 minikube 文件权限从 root 更改为正确的用户。

TestPause

测试 minikube pause 功能

validateFreshStart

只是启动一个新的 minikube 集群

validateStartNoReconfigure

验证启动一个正在运行的集群不会调用重新配置

validatePause

运行 minikube pause

validateUnpause

运行 minikube unpause

validateDelete

删除未暂停的集群

validateVerifyDeleted

确保删除配置文件后没有遗留物，如容器或卷

validateStatus

确保暂停的集群在 minikube status 中显示正确

TestPreload

验证禁用初始预加载，拉取特定镜像，然后重新启动集群可以跨重启保留该镜像。还测试 --preload-source 是否适用于 github 和 gcs

TestScheduledStopWindows

测试 Windows 上的计划停止功能

TestScheduledStopUnix

测试 Unix 上的计划停止功能

TestSkaffold

确保 skaffold run 可以与 minikube 一起运行

TestStartStop

测试使用各种 Kubernetes 版本和配置启动、停止和重启 minikube 集群。总是测试最旧支持的、最新支持的和默认的 Kubernetes 版本。

validateFirstStart

运行初始 minikube start

validateDeploying

将应用程序部署到 minikube 集群

validateEnableAddonWhileActive

确保附加组件可以在集群激活时启用。

validateStop

测试 minikube stop

validateEnableAddonAfterStop

确保附加组件可以在已停止的集群上启用

validateSecondStart

验证启动已停止的集群是否正常工作

validateAppExistsAfterStop

验证用户的应用程序在 minikube 停止后不会消失

validateAddonAfterStop

验证在 minikube 停止时启用的附加组件将保持启用并正常工作。

validateKubernetesImages

验证重启后的集群是否包含所有必需的镜像

validatePauseAfterStart

验证 minikube pause 是否正常工作

TestInsufficientStorage

确保在机器磁盘空间不足时，minikube status 显示正确信息

TestRunningBinaryUpgrade

将旧版集群升级到 HEAD 上的 minikube

TestStoppedBinaryUpgrade

启动一个旧版 minikube，停止它，然后升级到 HEAD 上的 minikube

TestKubernetesUpgrade

将 Kubernetes 从最旧版本升级到最新版本

TestMissingContainerUpgrade

测试底层容器丢失的 Docker 升级