openshift-installer 评测：OpenShift 4.x 集群的官方安装器，用对 --dir 才能干净销毁

它解决什么问题：OpenShift 4.x 的官方安装入口

OpenShift 4.x 的安装不是简单的几条 kubectl 命令。它涉及基础设施编排、证书生成、集群初始化等大量步骤。openshift/installer 正是官方提供的统一入口，它把整个流程封装成一个二进制。你面对的不是一堆分散的脚本，而是一个可重复执行的工具。它的目标用户是需要在 AWS、Azure、裸金属等平台创建生产级 OpenShift 集群的运维人员。如果你只想跑一个单节点的测试环境，这个工具可能过于庞大。但如果你要管理多个云环境下的正式集群，它就是标准答案。

工作机制：从二进制到集群的完整链路

这个项目用 Go 编写，构建后生成一个名为 openshift-install 的二进制。它的核心机制是分阶段执行：先读取用户配置，然后调用 Terraform 创建基础设施，最后部署 OpenShift 控制平面和工作节点。README 明确提到，安装完成后会生成 .openshift_install.log，其中包含连接集群所需的信息，比如 kubeconfig 路径和 Web 控制台地址。这个日志文件是排障的第一手资料。整个流程是声明式的，你提供 install-config.yaml 或交互回答，工具负责把集群状态收敛到目标。

快速上手：构建与首次安装的真实命令

从源码构建需要先安装所有构建依赖，具体清单在 docs/dev/dependencies.md 里。然后运行 hack/build.sh，脚本会在 bin/ 目录下生成 openshift-install。最简单的安装命令是 bin/openshift-install create cluster，它会弹出交互式提示，询问用户特定信息，其他配置使用合理默认值。如果你在 CI 或自动化环境里，可以用 install-config.yaml 跳过交互，具体方法见 docs/user/overview.md 的 multiple-invocations 章节。安装完成后，连接信息会打印在终端，同时写入 .openshift_install.log。销毁集群用 openshift-install destroy cluster，但 README 特别强调，几乎总是需要清理 state 文件，包括 auth/ 和 terraform.tfstate。

--dir 参数：最容易忽略却最关键的细节

README 用了一句很直白的话：最好的做法是始终给 create 和 destroy 传递 --dir 参数。这背后的原因不难理解：installer 会在当前目录生成一堆状态文件，包括 auth/ 目录（存放 kubeconfig 和密码）和 terraform.tfstate。如果你不指定 --dir，这些文件散落在运行命令的目录里，销毁时容易遗漏。更糟的是，如果 create 和 destroy 在不同目录执行，destroy 可能找不到 state，导致云资源无法正确释放。所以，官方建议每次都用 --dir 指向同一个专用目录，比如 ~/cluster-installs/prod。如果要从头重装，先 rm -rf 那个目录。

平台支持矩阵：裸金属到云的全面覆盖

README 列出了支持的平台，包括 AWS、Azure、GCP、IBM Cloud、Nutanix、OpenStack、Power、Power VS、vSphere 和 z/VM。每个平台都有独立的文档子目录，比如 docs/user/aws 和 docs/user/metal。这说明 installer 不是简单的云厂商封装，它针对不同基础设施做了适配。裸金属和 vSphere 这类自建环境，安装逻辑与公有云差异很大，但 installer 统一了入口。不过，这种广度也意味着每个平台的细节需要单独学习，比如 AWS 的 IAM 权限或 vSphere 的存储配置。如果你只用其中一个平台，其他平台的文档可以忽略。

一个真实的失败模式：state 文件残留

最典型的失败场景是：你运行了 create cluster，然后想销毁，但忘了清理 state 文件。README 警告说，销毁后几乎肯定要清理 auth/ 和 terraform.tfstate。如果不清理，这些文件会占用磁盘空间，更重要的是，它们包含敏感信息，比如 kubeadmin 密码。另一个失败模式是重复安装：如果你不 rm -rf 资产目录，再次 create 时 installer 可能读取到旧的 state，导致配置冲突或资源重复创建。所以，官方建议的流程是：销毁集群，删除 state 文件，然后才重新安装。

替代方案：与手动 Terraform 或 kubeadm 的差异

如果你不想用这个 installer，常见的替代是直接用 Terraform 编写自己的 OpenShift 基础设施代码，再用 kubeadm 或其他工具初始化集群。但这两者有一个根本差异：openshift/installer 是官方维护的，它知道 OpenShift 4.x 的特定要求，比如 Ignition 配置、证书轮换、升级路径。手动 Terraform 方案需要你自己追踪这些细节，而 installer 把这些封装在版本化的代码里。另一个替代是使用 OpenShift 的托管服务，比如 Red Hat OpenShift Dedicated，但那是 SaaS 产品，不涉及本地安装。所以，如果你需要自管集群，installer 是最贴近官方支持路径的选择。

维护与升级成本：版本分支与许可

这个项目采用 Apache-2.0 许可，可以自由使用和修改。但要注意，它不是一个独立版本的工具，而是与 OpenShift 发行分支紧密绑定。最近的发布包括 v0.90.16（对应 release-4.16 分支）和 v0.91.0（主分支），这说明你需要根据你的 OpenShift 版本选择合适的 installer 版本。升级成本在于：每次 OpenShift 新版本发布，installer 也会更新，你需要重新构建或下载新二进制。由于它依赖 Terraform 和云平台 API，这些外部依赖的变化也可能影响安装过程。好在官方文档和 release notes 会给出迁移说明，但你必须主动跟踪。

编辑结论

openshift/installer 适合需要快速部署 OpenShift 4.x 集群的运维和平台团队，尤其是使用 AWS、Azure、GCP 或裸金属环境的场景。它由 Red Hat 官方维护，版本与 OpenShift 发行分支同步（如 v0.90.16 对应 release-4.16），可信度较高。但如果你只想要一个轻量的 Kubernetes 发行版，或需要自定义安装流程，它可能过重。首次使用前，务必验证你的云平台凭据和 install-config.yaml 的字段格式，并严格遵循文档：每次 create 和 destroy 都显式传入 --dir，销毁后手动删除 auth/ 和 terraform.tfstate 等文件。否则，残留的 state 会导致资源泄漏或重新安装失败。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes