张云雷宝宝1. 为什么要在Kubernetes上部署OpenStack？
在云计算领域，OpenStack和Kubernetes都是重量级选手。OpenStack作为IaaS层的代表，提供了虚拟机、存储和网络等基础设施服务；而Kubernetes则是容器编排的事实标准。将这两者结合，看似有些"关公战秦琼"，实则蕴含着深刻的技术演进逻辑。
传统OpenStack部署方式面临几个痛点：组件间依赖复杂、升级困难、资源利用率不高。而Kubernetes提供的声明式API、自动扩缩容、滚动升级等特性，恰好能解决这些问题。通过Kubernetes部署OpenStack（简称OpenStack on K8s或OOK），可以实现：
- 统一编排：用k8s管理OpenStack生命周期，减少运维复杂度
- 资源弹性：利用k8s的调度能力提高资源利用率
- 标准化交付：通过Operator模式实现OpenStack的"一键部署"
- 混合云管理：在k8s上同时运行容器和虚拟机工作负载
提示：生产环境部署需要考虑网络性能、存储可靠性和高可用性等关键因素，这与测试环境有本质区别。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 生产环境部署架构设计
2.1 基础架构选型
生产环境部署首先需要确定基础架构。根据实践经验，推荐以下配置：
| 组件 | 推荐方案 | 备注 |
|---|---|---|
| Kubernetes发行版 | OpenShift 4.x 或 RKE2 | 企业级k8s发行版提供更好的稳定性 |
| 网络插件 | Calico 或 Multus | 多网络接口支持是必须的 |
| 存储后端 | Ceph RBD 或 NetApp Trident | 需要支持RWX(ReadWriteMany) |
| 负载均衡 | MetalLB 或 F5 BIG-IP集成 | 生产环境必须考虑LB高可用 |
| 监控方案 | Prometheus-Operator + Grafana | 需要定制OpenStack专属监控面板 |
2.2 OpenStack组件容器化策略
OpenStack包含30+组件，不是所有组件都适合容器化。我们的策略是：
- 核心服务优先：先容器化Nova、Neutron、Cinder、Glance、Keystone这五大核心
- 有状态服务特殊处理：数据库(RabbitMQ, MySQL)建议使用Operator管理
- 计算节点保留裸机：Nova计算节点建议保持裸机部署以获得最佳性能
- 网络服务混合部署：OVS和LinuxBridge相关组件需要hostNetwork访问
yaml复制# 典型nova-api的Deployment配置片段
apiVersion: apps/v1
kind: Deployment
metadata:
name: nova-api
spec:
replicas: 3
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
spec:
containers:
- name: nova-api
image: quay.io/openstack/nova-api:zed
ports:
- containerPort: 8774
volumeMounts:
- mountPath: /etc/nova
name: nova-config
volumes:
- name: nova-config
configMap:
name: nova-config
3. 关键挑战与解决方案
3.1 网络性能优化
在测试环境中表现良好的网络方案，在生产流量下可能完全失效。我们遇到过几个典型问题：
问题1：Neutron DHCP响应延迟
- 现象：虚拟机启动时获取IP超时
- 根因：DHCP服务在容器中受cgroup限制
- 解决方案：
- 为neutron-dhcp-agent配置更高的CPU配额
- 使用NodeSelector将DHCP Pod调度到专用节点
- 考虑改用Infoblox等专业DHCP服务
问题2：东西向流量瓶颈
- 现象：VM间通信带宽不足
- 根因：VXLAN封装在用户态处理
- 解决方案：
- 启用OVS-DPDK加速
- 或者改用SR-IOV方案（需要硬件支持）
3.2 存储可靠性保障
生产环境对存储的要求极为苛刻。我们总结出以下经验：
-
Cinder卷服务：
- 后端存储必须支持多路径访问
- 每个存储节点部署csi-attacher至少3副本
- 定期检查存储配额，避免空间耗尽
-
Glance镜像服务：
- 镜像存储建议使用Ceph RGW+S3接口
- 启用镜像缓存机制（配置项：disk_cache_enabled=True）
- 大镜像上传使用分片传输（chunked transfer）
-
数据库持久化：
- 使用LocalPV或高端存储保障数据库性能
- 配置合理的备份策略（至少每日全备+binlog）
- 监控长事务和锁等待
4. 生产就绪检查清单
在正式上线前，建议完成以下验证：
4.1 功能验证
- [ ] 创建/删除VM（包括带卷的场景）
- [ ] 网络连通性测试（南北向+东西向）
- [ ] 卷挂载/卸载及数据持久化
- [ ] 镜像上传/下载
- [ ] 浮动IP分配与绑定
- [ ] 安全组规则生效测试
4.2 性能基准测试
- VM启动时间（从发起请求到SSH可连接）
- 网络吞吐量（iperf3测试）
- 存储IOPS（fio测试）
- API响应延迟（关键API的P99值）
4.3 故障模拟
- 随机杀掉1个控制面Pod，观察自愈
- 断开1个存储节点，验证卷可用性
- 模拟网络分区，测试脑裂处理
- 人为制造API过载，验证限流生效
5. 运维监控体系建设
生产环境必须建立完善的监控体系。我们建议分层监控：
5.1 基础设施层
- 节点资源使用率（CPU/Mem/Disk）
- 网络设备状态（交换机、路由器）
- 存储集群健康度（Ceph OSD状态等）
5.2 Kubernetes层
- 节点Ready状态
- Pod重启次数
- API Server延迟
- etcd写入性能
5.3 OpenStack层
python复制# 示例：使用Prometheus查询Nova关键指标
# VM操作失败率
sum(rate(openstack_nova_server_total{outcome="failed"}[5m]))
by (action) / sum(rate(openstack_nova_server_total[5m])) by (action)
# API响应时间
histogram_quantile(0.99,
sum(rate(openstack_nova_api_response_time_seconds_bucket[5m]))
by (le, path))
5.4 业务层
- 租户配额使用率
- 典型工作负载性能基线
- 安全事件监控
6. 升级与扩展策略
6.1 版本升级路径
OpenStack on K8s的升级涉及两个维度：
- Kubernetes版本升级
- OpenStack版本升级
建议采用"先k8s后OpenStack"的顺序，并遵循：
- 在测试环境验证完整的升级流程
- 逐个组件滚动升级
- 准备回滚方案（特别是数据库schema变更）
6.2 水平扩展模式
当集群需要扩容时，考虑以下策略：
-
控制平面扩展：
- 增加API服务副本数
- 分片部署MySQL（如按租户分片）
- 引入消息队列镜像
-
计算节点扩展：
- 使用Machine API动态添加计算节点
- 配置多样化的主机聚合（host aggregates）
- 考虑混合部署（裸机+虚拟机）
-
存储扩展：
- Ceph集群添加OSD
- 分布式文件系统增加存储节点
- 对象存储添加网关节点
在实际扩容操作中，我们发现一个有趣的现象：当控制节点超过7个时，etcd性能可能成为瓶颈。这时需要考虑引入分片策略，或者将部分组件（如日志、监控）卸载到独立集群。
最后分享一个血泪教训：永远不要在周五下午进行生产变更。我们在一次例行升级中，因为一个简单的配置错误导致整个控制平面不可用，团队不得不通宵回滚。现在我们的规则是：所有生产变更必须在周二或周三上午执行，确保有足够的时间窗口处理意外情况。