Kubespray v2.27.0 版本中外部云提供商手动部署方案解析

背景与需求场景

在 Kubernetes 集群部署工具 Kubespray 的最新 v2.27.0 版本中，当用户配置 cloud_provider: external 时，系统会默认尝试自动部署外部云控制器管理器（CCM）。这一变更源于该版本对云提供商集成逻辑的改进，特别是在合并相关代码后，自动化部署行为成为默认选项。

然而在实际生产环境中，部分用户已经建立了成熟的外部云控制器管理体系。以 OpenStack 平台为例，这些用户可能已经通过自定义流程部署了 openstack-ccm，但仍需要保留 cloud_provider: external 的配置来确保 kubelet 等组件获得正确的云提供商标识。当前的强制自动部署机制反而会与现有体系产生冲突。

技术实现现状

当前版本中，用户需要通过非常规手段规避自动部署：

1. 同时设置 cloud_provider: external 和 external_cloud_provider: openstack
2. 手动删除部署模板文件 /kubespray/roles/kubernetes-apps/external_cloud_controller/openstack/*

这种解决方案存在明显缺陷：

• 破坏部署过程的可重复性
• 增加维护复杂度
• 可能导致版本升级时的配置冲突

改进方案设计

社区提出的解决方案是引入新的配置参数 manual 模式。当用户指定以下组合时：

cloud_provider: external
external_cloud_provider: manual

部署流程将：

1. 保留所有云提供商相关配置（如 kubelet 的 --cloud-provider=external 参数）
2. 跳过所有外部云控制器的自动化部署步骤
3. 保持集群配置的完整性

技术实现细节

该方案需要在 Kubespray 的以下层面进行修改：

1. 配置解析层：扩展 external_cloud_provider 的取值逻辑，新增 manual 枚举值
2. 任务控制层：在外部云控制器部署任务前添加条件判断
3. 模板生成层：确保跳过相关 Helm chart 或静态 YAML 的生成

用户价值

该改进将为用户带来以下收益：

1. 配置灵活性：支持混合使用 Kubespray 的云集成功能与自定义部署方案
2. 部署一致性：避免通过文件删除等临时方案造成的环境差异
3. 升级友好性：保持配置声明式的特性，确保版本升级时的可预测性

最佳实践建议

对于已经实现自定义云控制器管理的用户，建议采用以下迁移路径：

1. 在现有配置中添加 external_cloud_provider: manual 参数
2. 移除原有的文件删除等临时解决方案
3. 验证 kubelet 等组件的云提供商配置是否正常生效
4. 通过集群自动化测试验证功能完整性

该方案预计将在后续版本中作为标准功能提供，为用户提供更灵活的云集成管理选项。