1. 项目概述
在云计算领域混了这么多年,我见过太多企业被OpenStack的部署复杂度折磨得死去活来。传统部署方式需要手动配置大量节点,维护成本高得吓人。直到我们把OpenStack搬到Kubernetes上,才发现原来云平台也能像容器应用一样优雅地编排管理。这次要分享的是我们在金融行业客户生产环境中的真实落地经验,整套方案已经稳定运行18个月,日均处理百万级虚拟机请求。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构设计解析
2.1 核心组件容器化
OpenStack的每个服务现在都被打包成独立的容器镜像:
- Nova-compute需要特殊处理:我们定制了包含qemu和libvirt的增强镜像
- Neutron使用OVN+DPDK方案,容器内集成了OpenvSwitch 2.15
- Cinder对接Ceph集群时,在容器内挂载了rdma驱动
重要提示:Keystone容器必须禁用内存交换(swapoff -a),否则认证延迟会飙升
2.2 Kubernetes层设计
采用混合部署架构:
- 控制平面:3个master节点跑OpenStack API服务
- 计算节点:裸金属服务器专供nova-compute
- 网络节点:绑定NUMA的DPDK机器运行neutron
yaml复制# 关键资源限制示例(nova-api)
resources:
limits:
cpu: "2"
memory: 4Gi
hugepages-1Gi: 1Gi
requests:
cpu: "1"
memory: 2Gi
3. 网络方案实战
3.1 多网络平面隔离
我们设计了四层网络平面:
- API网络:Calico BGP对接客户骨干网
- 存储网络:100G RDMA专用网络
- 租户网络:OVN-Kubernetes实现VPC
- 管理网络:独立VLAN供K8s控制面使用
3.2 DPDK优化技巧
在neutron-server容器中需要设置:
bash复制echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
mount -t hugetlbfs none /dev/hugepages
实测参数:
- 单个vSwitch可处理120Gbps流量
- 包转发延迟<50μs
- 建议预留4个CPU核专供DPDK轮询
4. 存储对接方案
4.1 Ceph集群对接
通过RBD协议对接时要注意:
- 容器内需要安装最新版librbd
- 建议配置RDMA传输模式
- 块设备映射超时设为600秒
ini复制# cinder.conf关键配置
[libvirt]
rbd_user = openstack
rbd_secret_uuid = xxxxxxxx
disk_cachemodes = "network=writeback"
4.2 本地存储优化
对于本地SSD盘:
- 使用LVM thin provisioning
- 配置noop调度器
- 关闭文件系统atime
5. 高可用实现
5.1 服务熔断策略
为每个OpenStack服务配置了:
- PodDisruptionBudget保证最小可用实例数
- HPA基于API请求量自动扩缩
- 就绪探针检查数据库连接
5.2 故障转移实测
模拟测试场景:
- 随机kill节点上的nova-api容器
- 网络分区持续5分钟
- 存储集群短暂不可用
恢复指标:
- API中断<30秒
- 现有VM不受影响
- 新创建VM延迟增加<15%
6. 监控体系搭建
6.1 指标采集方案
采用Prometheus Operator采集:
- OpenStack服务指标(通过prometheus-client)
- 容器基础指标(cAdvisor)
- 物理节点指标(Node Exporter)
关键告警规则示例:
yaml复制- alert: NovaAPILatencyHigh
expr: rate(nova_http_request_duration_seconds_sum[1m]) > 1
for: 5m
labels:
severity: critical
6.2 日志收集架构
Fluent-bit sidecar收集容器日志后:
- 关键错误日志实时告警
- 审计日志保留1年
- 调试日志按需开启
7. 升级维护实践
7.1 滚动升级流程
OpenStack版本升级步骤:
- 先升级Kubernetes控制平面
- 按依赖顺序更新OpenStack服务
- 最后处理计算节点上的nova-compute
必须注意:Cinder升级前要确保所有volume状态正常
7.2 日常运维技巧
几个实用命令:
bash复制# 查看某个服务的所有容器
kubectl get pods -n openstack -l service=nova
# 进入容器调试
kubectl debug -it <pod> --image=busybox
# 强制删除卡住的Pod
kubectl delete pod <name> --grace-period=0 --force
8. 性能调优记录
8.1 API层优化
关键参数调整:
- WSGI workers根据CPU核心数配置
- MySQL连接池大小=最大并发请求数×1.2
- 启用HTTP keepalive
8.2 计算节点优化
在nova-compute容器中:
ini复制[libvirt]
cpu_mode = host-passthrough
disk_cachemodes = "network=writeback"
9. 安全加固措施
9.1 网络策略
使用NetworkPolicy实现:
- 控制平面组件间双向认证
- 计算节点只出不进规则
- API服务白名单访问
9.2 证书管理
通过Cert-manager实现:
- 自动续签内部TLS证书
- 硬件HSM保护根CA
- 证书吊销列表每日更新
10. 踩坑实录
10.1 典型故障排查
案例1:虚拟机启动超时
- 检查项:libvirt日志、qemu进程状态、存储连接
- 最终定位:Ceph集群osd_full导致
案例2:网络性能骤降
- 检查项:DPDK计数器、NUMA绑定、中断均衡
- 解决方案:调整rx-queue大小
10.2 资源限制教训
我们曾遇到:
- Nova调度器OOM:需限制内存并启用swap
- Neutron数据库连接泄露:配置连接池回收
- Glance镜像上传超时:调整nginx client_max_body_size
这套架构目前支撑着客户核心交易系统,最忙时段同时运行着8000+虚拟机。最大的收获是发现Kubernetes的Operator模式特别适合管理OpenStack生命周期,比如通过自定义资源定义(CRD)来控制nova-cell的部署拓扑。下次我会详细分享我们开发的OpenStack Operator设计细节。
