集成测试用例列表

自动生成的minikube所有集成测试列表及其功能说明。

仅下载测试

确保 `minikube start` 命令中的 `--download-only` 参数能够缓存相应的镜像和压缩包。

仅下载Kic测试

确保 `--download-only` 参数也缓存 Docker 驱动镜像。

二进制镜像测试

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

离线测试

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

插件测试

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

验证 Ingress 插件

通过部署一个默认的 Nginx Pod 来测试 Ingress 插件。

验证 Registry Creds 插件

通过尝试加载其配置来测试 Registry Creds 插件。

验证 Registry 插件

测试 Registry 插件。

验证 Metrics Server 插件

通过确保 `kubectl top pods` 返回合理结果来测试 Metrics Server 插件。

验证 OLM 插件

测试 OLM 插件。

验证 CSI 驱动和快照

通过创建持久卷、对其进行快照并恢复来测试 CSI HostPath 驱动。

验证 GCP Auth 命名空间

验证新创建的命名空间包含 `gcp-auth` Secret。

验证 GCP Auth 插件

使用虚假或真实凭据测试 GCP Auth 插件,并确保文件正确挂载到 Pod 中。

验证 Headlamp 插件

验证 Inspektor Gadget 插件

通过确保 Pod 已启动且插件已禁用,来测试 Inspektor Gadget 插件。

验证 Cloud Spanner 插件

通过确保部署和 Pod 已启动且插件已禁用,来测试 Cloud Spanner 插件。

验证 Volcano 插件

测试 Volcano 插件,确保 Volcano 已安装到集群中。

验证 Local Path 插件

测试 `storage-provisioner-rancher` 插件的功能。

验证在不存在的集群上启用插件

测试在不存在的集群上启用插件。

验证在不存在的集群上禁用插件

测试在不存在的集群上禁用插件。

验证 Nvidia 设备插件

通过确保 Pod 启动且插件禁用,来测试 Nvidia 设备插件。

验证 AMD GPU 设备插件

通过确保 Pod 启动且插件禁用,来测试 AMD GPU 设备插件。

验证 Yakd 插件

证书选项测试

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

证书过期测试

确保 minikube 在其配置文件证书过期后能够启动。它通过配置 minikube 证书在 3 分钟后过期,然后等待 3 分钟,再重新启动来实现。它还确保 minikube 向用户打印证书过期警告。

Docker标志测试

确保 `--docker-env` 和 `--docker-opt` 参数受到遵守。

强制Systemd标志测试

测试 `--force-systemd` 标志,正如预期。

验证 Docker Systemd

确保 `--force-systemd` 标志与 Docker 容器运行时一起正常工作。

验证 Containerd Systemd

确保 `--force-systemd` 标志与 Containerd 容器运行时一起正常工作。

验证 Crio Systemd

确保 `--force-systemd` 标志与 CRI-O 容器运行时一起正常工作。

强制Systemd环境变量测试

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

Docker环境Containerd测试

确保当运行时为 Containerd 时,`minikube docker-env` 命令正常工作。

KVM驱动安装或更新测试

确保我们的 `docker-machine-driver-kvm2` 二进制文件能够正确安装。

HyperKit驱动安装或更新测试

确保我们的 `docker-machine-driver-hyperkit` 二进制文件能够正确安装。

Hyperkit驱动跳过升级测试

确保我们的 `docker-machine-driver-hyperkit` 二进制文件能够正确安装。

错误信息输出测试

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

功能测试

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

最新Kubernetes功能测试

使用 `NewestKubernetesVersion` 运行功能测试。

验证节点标签

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

步骤

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

验证镜像命令

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

步骤

  • 确保通过 `minikube image build` 可以正常构建镜像。
  • 确保通过 `minikube image load --daemon` 可以从 Docker daemon 加载镜像。
  • 尝试加载已加载的镜像,并确保 `minikube image load --daemon` 正常工作。
  • 确保通过 `minikube image load --daemon` 新的更新标签正常工作。
  • 确保通过 `minikube image load --daemon` 镜像保存正常工作。
  • 确保通过 `minikube image rm` 镜像移除正常工作。
  • 确保通过 `minikube image load` 从文件加载镜像正常工作。
  • 确保通过 `minikube image load` 保存镜像到 Docker daemon 正常工作。

跳过

  • 由于不支持镜像加载,跳过 `none` 驱动。
  • 由于此测试用例需要运行中的 Docker daemon,跳过 GitHub Actions 和 macOS。

验证 Docker 环境

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

步骤

  • 运行 `eval $(minikube docker-env)` 以配置当前环境使用 minikube 的 Docker daemon。
  • 运行 `minikube status` 以获取 minikube 状态。
  • 确保 minikube 组件的状态为 `Running`。
  • 确保 `docker-env` 的状态为 `in-use`。
  • 运行 `eval $(minikube -p profile docker-env)` 并检查是否指向 minikube 内部的 Docker。
  • 通过检查 `gcr.io/k8s-minikube/storage-provisioner` 是否在 `docker images` 的输出中,确保 `docker images` 命令命中 minikube 的 Docker daemon。

跳过

  • 由于不支持 `docker-env`,跳过 `none` 驱动。
  • 跳过非 Docker 容器运行时。

验证 Podman 环境

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

步骤

  • 运行 `eval $(minikube podman-env)` 以配置当前环境使用 minikube 的 Podman daemon,并运行 `minikube status` 以获取 minikube 状态。
  • 确保 minikube 组件的状态为 `Running`。
  • 确保 `podman-env` 的状态为 `in-use`。
  • 再次运行 `eval $(minikube docker-env)` 并使用 `docker images` 列出使用 minikube Docker daemon 的 Docker 镜像。
  • 通过检查 `gcr.io/k8s-minikube/storage-provisioner` 是否在 `docker images` 的输出中,确保 `docker images` 命令命中 minikube 的 Podman daemon。

跳过

  • 由于不支持 `podman-env`,跳过 `none` 驱动。
  • 跳过非 Docker 容器运行时。
  • 跳过非 Linux 平台。

验证带代理启动

确保 `minikube start` 尊重 `HTTP_PROXY` 环境变量。

步骤

  • 启动本地 HTTP 代理。
  • 将环境变量 `HTTP_PROXY` 设置为本地 HTTP 代理,然后启动 minikube。

验证带自定义证书启动

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

验证启动后的审计

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

步骤

  • 读取审计日志文件,并确保它包含当前的 minikube 配置文件名。

验证软启动

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

步骤

  • `validateStartWithProxy` 测试应该已经启动 minikube,确保配置的节点端口是 `8441`。
  • 再次运行 `minikube start` 作为软启动。
  • 确保配置的节点端口没有改变。

验证 KubeContext

断言 kubectl 已正确配置(容易发生竞争条件!)。

步骤

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

验证 Kubectl Get Pods

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

步骤

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

验证 Minikube Kubectl

验证 `minikube kubectl` 命令返回内容。

步骤

  • 运行 `minikube kubectl -- get pods` 以获取当前 minikube 配置文件中的 Pod。
  • 确保该命令不会引发任何错误。

验证 Minikube Kubectl 直接调用

验证调用 minikube 的 kubectl。

步骤

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

验证 Extra Config

验证带有 `--extra-config` 的 minikube 正常工作。

步骤

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

验证组件健康状况

断言所有 Kubernetes 组件都是健康的。注意:它期望所有组件都处于 `Ready` 状态,因此建议仅在包含 `--wait=all` 启动标志的测试之后运行它。

步骤

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

验证 Status 命令

确保 `minikube status` 输出正确。

步骤

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

验证 Dashboard 命令

断言 dashboard 命令有效。

步骤

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

验证 Dry Run

断言干运行模式快速以正确的代码退出。

步骤

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

验证国际语言

断言使用的语言可以通过环境变量更改。

步骤

  • 设置环境变量 `LC_ALL=fr` 以启用 minikube 翻译为法语。
  • 以 250MB 内存启动 minikube(过少):`minikube start --dry-run --memory 250MB`。
  • 确保干运行输出消息是法语。

验证 Cache 命令

测试缓存命令的功能(缓存添加、删除、列表)。

步骤

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

验证 Config 命令

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

步骤

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

验证 Logs 命令

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

步骤

  • 运行 `minikube logs` 并确保日志包含 `apiserver`、`Audit` 和 `Last Start` 等关键字。

验证 Logs File 命令

断言“logs –file”命令功能。

步骤

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

验证 Profile 命令

断言“profile”命令功能。

步骤

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

验证 Service 命令

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

验证 Service 命令部署应用

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

验证 Service 命令列表

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

验证 Service 命令 JSON

运行 `minikube service list -o JSON` 并确保服务以 JSON 输出形式正确列出。

验证 Service 命令 HTTPS

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

验证 Service 命令格式

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

验证 Service 命令 URL

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

验证 Service 命令连接

步骤

  • 创建一个新的 `registry.k8s.io/echoserver` 部署。
  • 使用常规的 `--url` 运行 `minikube service` 以确保打印服务的 HTTP 端点 URL。
  • 确保我们可以使用 HTTP GET 请求访问端点 URL。

验证 Addons 命令

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

步骤

  • 运行 `minikube addons list` 以表格形式列出插件。
  • 确保 `dashboard`、`ingress` 和 `ingress-dns` 被列为可用插件。
  • 运行 `minikube addons list -o JSON` 以 JSON 格式列出插件。

验证 SSH 命令

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

步骤

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

验证 Cp 命令

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

步骤

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

跳过

  • 由于不支持 `cp`,跳过 `none` 驱动。

验证 MySQL

验证最小化 MySQL 部署。

步骤

  • 运行 `kubectl replace --force -f testdata/mysql/yaml`。
  • 等待 `mysql` Pod 运行。
  • 在 MySQL Pod 内部运行 `mysql -e show databases;` 以验证 MySQL 正在运行。
  • 如果失败,则使用指数退避重试,因为 `mysqld` 首次启动时未配置用户。在重新调度的情况下扫描名称。

跳过

  • 由于 MySQL 不支持 ARM64 架构,跳过。

验证文件同步

检查测试文件是否存在。

步骤

  • 测试文件已在 `setupFileSync` 上一步中同步到 minikube。
  • 检查测试文件是否存在。
  • 确保文件已正确同步。

跳过

  • 由于不支持 SSH,跳过 `none` 驱动。

验证证书同步

检查确保自定义证书已复制到 minikube 访客机并正确安装。

步骤

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

验证非活动运行时已禁用

断言对于给定的运行时,其他运行时是禁用的,例如对于 `containerd` 运行时,`docker` 和 `crio` 不应运行。

步骤

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

验证 Update Context 命令

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

步骤

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

验证 Version 命令

断言 `minikube version` 命令对 `--short` 和 `--components` 都正常工作。

步骤

  • 运行 `minikube version --short` 并确保返回的版本是有效的语义版本(semver)。
  • 运行 `minikube version --components` 并确保返回组件版本。

验证 License 命令

断言 `minikube license` 命令会下载并解压许可证。注意:此测试将在发布 PR 上失败,因为新版本的许可证文件届时不会上传。

验证无效服务

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

验证 Mount 命令

验证 minikube 挂载命令在其支持的平台上正常工作,我们正在测试:

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

验证持久卷声明

确保 PVC 正常工作。

验证 Tunnel 命令

确保 minikube tunnel 命令按预期工作。

验证隧道启动

启动 `minikube tunnel`。

验证无第二个隧道

确保只有一个隧道可以同时运行。

验证服务稳定性

启动 Nginx Pod、Nginx Service,并等待 Nginx 获得 LoadBalancer Ingress IP。

验证直接访问

验证测试服务是否可以从主机通过 LoadBalancer IP 访问。

验证 DNS Dig

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

验证 DNS Dscacheutil

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

验证 DNS 访问

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

验证隧道删除

停止 `minikube tunnel`。

访客环境测试

验证 minikube ISO/基础镜像中安装的文件和软件包。

Gvisor插件测试

测试 gVisor 插件的功能。

多控制平面测试

测试所有高可用(多控制平面)集群功能。

验证高可用集群启动

确保高可用(多控制平面)集群可以启动。

验证高可用部署应用

将应用程序部署到高可用(多控制平面)集群,并确保所有节点都可以提供流量。

验证 Pods 从高可用集群 Ping 主机

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

验证高可用添加工作节点

使用 `minikube node add` 命令向现有高可用(多控制平面)集群添加工作节点。

验证高可用节点标签

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

步骤

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

验证高可用状态正常

确保 `minikube profile list` 在高可用(多控制平面)集群下输出正确。

验证高可用复制文件

确保 `minikube cp` 在高可用(多控制平面)集群下正常工作。

验证高可用停止辅助节点

通过使用 `minikube node stop` 命令停止辅助控制平面节点来测试高可用(多控制平面)集群。

验证高可用状态降级

确保 `minikube profile list` 在高可用(多控制平面)集群下输出正确。

验证高可用重启辅助节点

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

验证高可用集群重启保留节点

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

验证高可用删除辅助节点

在辅助控制平面上测试 `minikube node delete` 命令。注意:目前,`minikube status` 子命令依赖于主控制平面节点,并且存储供应器仅在主控制平面节点上运行。

验证高可用停止集群

在高可用(多控制平面)集群上运行 `minikube stop`。

验证高可用重启集群

验证在高可用(多控制平面)集群上软重启是否有效。

验证高可用添加辅助节点

使用 `minikube node add` 命令向现有高可用(多控制平面)集群添加辅助控制平面节点。

镜像构建测试

确保 `minikube image build` 命令正常工作。

验证设置镜像构建

为镜像构建启动集群。

验证普通镜像构建

是 `minikube image build` 的普通测试用例,带 `-t` 参数。

验证指定 Dockerfile 的普通镜像构建

是 `minikube image build` 的普通测试用例,带 `-t` 和 `-f` 参数。

验证带 Build Arg 的镜像构建

是使用 `--build-opt` 构建的测试用例。

验证带 Build Env 的镜像构建

是使用 `--build-env` 构建的测试用例。

验证带 Docker Ignore 的镜像构建

是使用 `.dockerignore` 构建的测试用例。

JSON输出测试

确保 JSON 输出对于 `start`、`pause`、`unpause` 和 `stop` 命令正常工作。

验证不同当前步骤

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

验证递增当前步骤

验证对于成功的 minikube 启动,'当前步骤' 应该递增。

错误JSON输出测试

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

Kic自定义网络测试

验证 Docker 驱动与自定义网络一起工作。

Kic现有网络测试

验证 Docker 驱动并与现有网络一起运行。

Kic自定义子网测试

验证 Docker/Podman 驱动与自定义子网一起工作。

Kic静态IP测试

使用静态 IP 标志启动 minikube。

Kic基础镜像测试

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

Minikube配置文件测试

挂载启动测试

测试在启动时使用 mount 命令。

验证带 Mount 启动

启动一个启用了挂载的集群。

验证 Mount

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

验证 Mount 停止

停止集群。

验证重启

重启集群。

多节点测试

测试所有多节点集群功能。

验证多节点启动

确保一个 2 节点集群可以启动。

验证向多节点添加节点

使用 `minikube node add` 命令向现有集群添加节点。

验证多节点配置文件列表

确保 `minikube profile list` 在多节点集群下输出正确。

验证多节点文件复制

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

验证多节点标签

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

步骤

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

验证停止运行中的节点

测试 `minikube node stop` 命令。

验证停止后启动节点

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

验证重启保留节点

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

验证停止多节点集群

在多节点集群上运行 `minikube stop`。

验证重启多节点集群

验证在多节点集群上软重启是否有效。

验证从多节点删除节点

测试 `minikube node delete` 命令。

验证名称冲突

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

验证将应用部署到多节点

将应用程序部署到多节点集群,并确保所有节点都可以提供流量。

验证 Pods Ping 主机

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

网络插件测试

测试所有支持的 CNI 选项。测试的选项:kubenet, bridge, flannel, kindnet, calico, cilium。测试的标志:`enable-default-cni` (旧版), `false` (关闭 CNI), 自动检测。

验证 False CNI

检查如果容器运行时是“containerd”或“crio”并且 `--cni=false`,minikube 是否返回错误。

验证 Hairpin 模式

确保对于给定的 CNI,回环(Hairpinning)(https://en.wikipedia.org/wiki/Hairpinning) 配置正确。尝试使用从 'netcat' 服务 DNS 解析获得外部 IP 地址访问 deployment/netcat pod,如果 hairpinMode 关闭,则应失败。

无Kubernetes测试

测试在没有 Kubernetes 的情况下启动 minikube,适用于用户只需要在 minikube 内部使用容器运行时(Docker, Containerd, CRI-O)的用例。

验证带版本无 K8s 启动

预计在没有 Kubernetes 且带 Kubernetes 版本的情况下启动 minikube 集群时会出错。

步骤

  • 在没有 Kubernetes 的情况下启动 minikube。

验证带 K8S 启动

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

步骤

  • 使用 Kubernetes 启动 minikube。
  • 如果 Kubernetes 未运行,则返回错误。

验证带停止 K8s 启动

启动 minikube 集群,同时停止 Kubernetes。

步骤

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

验证无 K8S 启动

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

步骤

  • 在没有 Kubernetes 的情况下启动 minikube。

验证 K8S 未运行

验证 minikube 内部没有 Kubernetes 运行。

验证无 K8S 停止

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

验证无 K8S 配置文件列表

验证配置文件列表与 `--no-kubernetes` 一起工作。

验证无参数启动

验证 `minikube start` 无参数时正常工作。

更改None用户测试

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

暂停测试

测试 minikube 暂停功能。

验证全新启动

仅仅启动一个新的 minikube 集群。

验证启动不重新配置

验证启动一个运行中的集群不会触发重新配置。

验证暂停

运行 `minikube pause`。

验证取消暂停

运行 `minikube unpause`。

验证删除

删除已取消暂停的集群。

验证删除确认

确保删除配置文件后没有剩余的容器或卷等残留物。

验证状态

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

预加载测试

验证 minikube 正确拉取预加载的 tarball。

Windows计划停止测试

测试 Windows 上的计划停止功能。

Unix计划停止测试

测试 Unix 上的计划停止功能。

Skaffold测试

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

启动停止测试

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

验证首次启动

运行初始 `minikube start`。

验证部署

将应用程序部署到 minikube 集群。

验证活跃时启用插件

确保集群活跃时可以启用插件。

验证停止

测试 `minikube stop`。

验证停止后启用插件

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

验证第二次启动

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

验证停止后应用是否存在

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

验证停止后插件

验证在 minikube 停止时已启用的插件在启动后仍然启用并正常工作。

验证 Kubernetes 镜像

验证重新启动的集群包含所有必要的镜像。

验证启动后暂停

验证 minikube 暂停功能是否有效。

存储空间不足测试

确保如果机器磁盘空间不足,`minikube status` 显示正确的信息。

运行中二进制升级测试

将运行中的旧集群升级到最新版本的 minikube。

已停止二进制升级测试

启动一个旧版 minikube,停止它,然后升级到最新版本的 minikube。

Kubernetes升级测试

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

缺失容器升级测试

测试当底层容器缺失时的 Docker 升级。