集成测试用例列表

TestDownloadOnly

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

TestDownloadOnlyKic

确保 –download-only 也缓存 Docker 驱动程序镜像。

TestBinaryMirror

测试 –binary-mirror 标志的功能

TestOffline

确保在用户缓存必要的镜像后，minikube 可以在没有互联网的情况下工作。此测试必须在 TestDownloadOnly 之后运行。

TestAddons

并行测试不需要特殊环境的插件

validateIngressAddon

通过部署默认的 nginx pod 来测试 ingress 插件

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 命令有效

TestKVMDriverInstallOrUpdate

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

TestHyperKitDriverInstallOrUpdate

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

TestHyperkitDriverSkipUpgrade

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

TestErrorSpam

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

TestFunctional

是在并行情况下可以安全地共享配置文件的功能测试

validateNodeLabels

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

步骤

• 使用 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 和 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 的输出中是否包含 gcr.io/k8s-minikube/storage-provisioner 来确保 docker images 命中 minikube 的 Docker 守护程序

跳过

• 由于不支持 docker-env，因此在 none 驱动程序上跳过
• 在非 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 的输出中是否包含 gcr.io/k8s-minikube/storage-provisioner 来确保 docker images 访问的是 minikube 的 Podman 守护进程。

跳过

• 在 none 驱动程序上跳过，因为不支持 podman-env。
• 在非 Docker 容器运行时上跳过
• 在非 Linux 平台上跳过。

validateStartWithProxy

确保 minikube start 遵守 HTTP_PROXY 环境变量。

步骤

• 启动一个本地 HTTP 代理。
• 启动 minikube，并将环境变量 HTTP_PROXY 设置为本地 HTTP 代理。

validateStartWithCustomCerts

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

validateAuditAfterStart

确保审计日志在 minikube 启动后包含正确的日志记录。

步骤

• 读取审计日志文件，并确保它包含当前的 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

验证直接调用 minikube 的 kubectl。

步骤

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

validateExtraConfig

验证 minikube 使用 –extra-config 按预期工作。

步骤

• 此前的测试已经创建了一个配置文件。
• 使用不同的 --extra-config 命令行选项软启动 minikube。
• 加载配置文件的配置。
• 确保指定的 --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 输出。
• 确保 JSON 输出中设置了 host、kublete、apiserver 和 kubeconfig 状态。

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

创建一个新的 registry.k8s.io/echoserver 部署。

validateServiceCmdList

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

validateServiceCmdJSON

运行 minikube service list -o JSON，确保服务以 JSON 格式正确列出

validateServiceCmdHTTPS

运行带 --https --url 的 minikube service，确保打印服务的 HTTPS 端点 URL

validateServiceCmdFormat

运行带 --url --format={{.IP}} 的 minikube service，确保打印服务的 IP 地址

validateServiceCmdURL

运行带常规 --url 的 minikube service，确保打印服务的 HTTP 端点 URL

validateServiceCmdConnect

步骤

• 创建一个新的 registry.k8s.io/echoserver 部署。
• 运行带常规 --url 的 minikube service，确保打印服务的 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 首次启动时未配置用户。扫描名称以防重新调度。

跳过

• 由于 MySQL 不支持 ARM64 架构，因此跳过

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 正常工作

validateTunnelCmd

确保 minikube tunnel 命令按预期工作

validateTunnelStart

启动 minikube tunnel

validateNoSecondTunnel

确保只能同时运行 1 个隧道

validateServiceStable

启动 nginx pod、nginx 服务，并等待 nginx 拥有负载均衡器的入口 IP

validateAccessDirect

验证是否可以使用主机上的负载均衡器 IP 访问测试服务

validateDNSDig

通过 dig 命令 DNS 查找验证 DNS 转发是否有效。注意：DNS 转发是实验性的：https://minikube.kubernetes.ac.cn/docs/handbook/accessing/#dns-resolution-experimental

validateDNSDscacheutil

通过 dscacheutil 命令 DNS 查找验证 DNS 转发是否有效。注意：DNS 转发是实验性的：https://minikube.kubernetes.ac.cn/docs/handbook/accessing/#dns-resolution-experimental

validateAccessDNS

验证是否可以通过主机上的 DNS 转发访问测试服务。注意：DNS 转发是实验性的：https://minikube.kubernetes.ac.cn/docs/handbook/accessing/#dns-resolution-experimental

validateTunnelDelete

停止 minikube tunnel

TestGuestEnvironment

验证 minikube ISO/基础映像内部安装的文件和软件包

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' 子命令依赖于主控制平面节点，并且存储配置程序仅在主控制平面节点上运行。

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 构建的测试用例

TestJSONOutput

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

validateDistinctCurrentSteps

确保每个步骤都有不同的步骤编号

validateIncreasingCurrentSteps

验证成功启动 minikube 时，“当前步骤”应递增

TestErrorJSONOutput

确保 JSON 输出可以正确打印错误

TestKicCustomNetwork

验证 docker 驱动程序可以使用自定义网络

TestKicExistingNetwork

验证 docker 驱动程序并在现有网络上运行

TestKicCustomSubnet

验证 docker/podman 驱动程序可以使用自定义子网

TestKicStaticIP

使用静态 IP 标志启动 minikube

TestingKicBaseImage

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

TestMinikubeProfile

TestMountStart

测试在启动时使用 mount 命令

validateStartWithMount

启动启用挂载的集群

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 正确配置了发夹模式（https://en.wikipedia.org/wiki/Hairpinning）。尝试使用从“netcat”服务 DNS 解析获得的外部 IP 地址访问部署/netcat pod。如果 hairpinMode 关闭，则应失败。

TestNoKubernetes

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

validateStartNoK8sWithVersion

在没有 Kubernetes 且具有 Kubernetes 版本的情况下启动 minikube 集群时，应出现错误。

步骤

• 在没有 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

验证配置文件列表在 --no-kubernetes 下工作

validateStartNoArgs

验证没有参数的 minikube start 工作。

TestChangeNoneUser

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

TestPause

测试 minikube 暂停功能

validateFreshStart

只是启动一个新的 minikube 集群

validateStartNoReconfigure

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

validatePause

运行 minikube pause

validateUnpause

运行 minikube unpause

validateDelete

删除未暂停的集群

validateVerifyDeleted

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

validateStatus

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

TestPreload

验证预加载的 tarball 是否被 minikube 正确拉取

TestScheduledStopWindows

测试 Windows 上的计划停止功能

TestScheduledStopUnix

测试 Unix 上的计划停止功能

TestSkaffold

确保可以使用 minikube 运行 skaffold run

TestStartStop

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

validateFirstStart

运行初始 minikube 启动

validateDeploying

将应用程序部署到 minikube 集群

validateEnableAddonWhileActive

确保在集群处于活动状态时可以启用插件。

validateStop

测试 minikube stop

validateEnableAddonAfterStop

确保可以在已停止的集群上启用插件

validateSecondStart

验证启动已停止的集群是否有效

validateAppExistsAfterStop

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

validateAddonAfterStop

验证在 minikube 停止时启用的插件将被启用并工作。

validateKubernetesImages

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

validatePauseAfterStart

验证 minikube 暂停是否有效

TestInsufficientStorage

确保如果机器上磁盘空间不足，minikube 状态会显示正确的信息

TestRunningBinaryUpgrade

将运行中的旧版集群升级到 HEAD 的 minikube

TestStoppedBinaryUpgrade

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

TestKubernetesUpgrade

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

TestMissingContainerUpgrade

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