考虑的替代方案

这种设置会更简洁，因为它不需要虚拟机进行设置。

当运行真实的 Docker 时，Docker Compose 将支持 CPU 限制，但 Podman 不支持。

Docker Compose 不支持模板，因此自定义具有不同 CPU 限制的不同设置很困难，而 Helm for minikube 提供了这种模板功能。对于 Grafana 堆栈，有一个很好的可自定义的 Helm 模板，而 Docker Compose 没有这种方式。

它将具有与 Minishift 相同的功能，并且已经安装了 operator 支持。它可以自动设置（如果开发人员注册了 Red Hat 帐户并获得了 pull secret）。

OpenShift 风格的监控可以通过标准的监控功能/operators 进行安装，也可能通过额外的扩展进行安装。另一方面，Helm charts 似乎比 OpenShift operator 更可配置。

Keycloak Java operator 团队正在使用 minikube 进行测试，并且可以使用 shell 脚本在几分钟内安装 operator hub 功能。这也将允许在此设置中在 Minishift 上运行 Keycloak operator。

OpenShift Local 将始终使用 VM，并且在 CPU 和 RAM 使用方面会更重。对于社区贡献者来说，安装 OpenShift 是一个更大的步骤。从长远来看，维护 OpenShift 和 minikube 的设置可能会带来更高的维护成本。从头开始安装 OpenShift Local 比安装 Minishift 花费的时间要长得多，因为 OpenShift 附带了更多 Operators，它们需要下载并启动其容器，并且会等待依赖项。

minikube 有一种机制可以在本地以轻量级方式构建容器，并将其提供给正在运行的 minikube 实例。OpenShift 的替代方案是 binary builds。