1. 项目概述
当OpenStack遇上Kubernetes,这场云原生与传统云架构的碰撞正在重塑企业级基础设施的部署方式。作为一名在云计算领域摸爬滚打多年的老兵,我最近刚完成了一个将OpenStack完整部署在K8s集群的生产级项目,过程中踩过的坑、趟过的雷,都值得用血泪经验来分享。
传统OpenStack部署往往面临组件臃肿、升级困难的问题,而K8s提供的声明式配置、自动修复和弹性扩展能力,恰好能弥补这些短板。但将如此复杂的IaaS平台容器化并非易事——从控制平面的容器化拆分,到计算节点与Kubelet的协同,再到存储网络等核心服务的编排,每个环节都需要精细调校。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构设计与技术选型
2.1 整体架构解析
我们采用的方案是将OpenStack服务拆分为多个Helm Chart进行管理:
- 控制平面服务(Keystone、Nova API等)作为无状态负载部署
- RabbitMQ、MariaDB等中间件通过Operator管理
- Nova Compute以DaemonSet形式运行在计算节点
- Ceph集群通过Rook Operator对接
这种架构下,每个OpenStack服务都变成了K8s集群中的一等公民,可以享受:
- 滚动升级时零停机(通过Readiness探针保障)
- 故障时自动重启(Liveness探针+Pod重启策略)
- 按需弹性伸缩(HPA根据API请求量自动扩缩容)
2.2 关键组件选型对比
| 组件 | 传统部署方案 | K8s部署方案 | 优势对比 |
|---|---|---|---|
| 数据库 | 独立MariaDB主从 | K8s StatefulSet + Galera | 自动故障转移,备份更便捷 |
| 消息队列 | 独立RabbitMQ集群 | RabbitMQ Cluster Operator | 声明式配置,集群自愈 |
| 网络服务 | 手动配置Neutron agent | Multus CNI + VPP Agent | 支持多网卡,性能提升30% |
| 存储服务 | 直接部署Ceph MON/OSD | Rook Operator | 一键部署,自动磁盘发现 |
经验提示:生产环境务必为有状态服务(如数据库)配置Pod反亲和性,避免所有实例被调度到同一物理节点。
3. 详细部署流程
3.1 基础环境准备
首先需要准备符合以下规格的K8s集群:
- 控制节点:至少3台,8核16GB内存(需启用Taints防误调度)
- 计算节点:根据虚拟机密度配置,建议16核64GB起
- 存储节点:单独部署Ceph集群时建议5节点起步
关键配置项:
yaml复制# kubelet必须配置的额外参数
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cpuManagerPolicy: static
reservedSystemCPUs: "0,1" # 为系统进程预留CPU
kubeReserved:
cpu: "500m"
memory: "1Gi"
3.2 OpenStack Helm Chart部署
使用官方openstack-helm项目进行部署:
bash复制git clone https://opendev.org/openstack/openstack-helm.git
cd openstack-helm
# 生成各组件values覆盖文件
./tools/gate/scripts/02-helm-prepare-overrides.sh
# 关键配置示例(nova.conf片段):
nova:
conf:
DEFAULT:
compute_driver: libvirt.LibvirtDriver
libvirt:
virt_type: kvm
cpu_mode: host-passthrough
部署顺序必须严格遵守依赖关系:
- 基础设施层(MariaDB, RabbitMQ, Memcached)
- 认证服务(Keystone)
- 核心服务(Glance, Nova, Neutron)
- 辅助服务(Cinder, Heat, Horizon)
3.3 计算节点特殊处理
计算节点需要额外配置:
- 加载KVM内核模块:
bash复制modprobe kvm_intel nested=1
echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm.conf
- 配置Libvirt与QEMU:
xml复制<!-- /etc/libvirt/qemu.conf 关键配置 -->
memory_backing_dir = "/dev/hugepages"
hugetlbfs_mount = "/dev/hugepages"
- Kubelet必须启用特权模式:
bash复制--allow-privileged=true \
--feature-gates=DevicePlugins=true \
--device-plugins=/var/lib/kubelet/device-plugins
4. 网络方案深度优化
4.1 多网络平面设计
生产环境建议采用四平面网络:
- API网络(K8s Service暴露OpenStack API)
- 租户网络(VXLAN/GENEVE overlay)
- 存储网络(Ceph集群专用)
- 管理网络(组件间通信)
通过Multus CNI实现多网卡支持:
yaml复制apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
name: storage-net
spec:
config: '{
"type": "sriov",
"vlan": 100,
"ipam": {
"type": "host-local",
"subnet": "192.168.100.0/24"
}
}'
4.2 性能调优实测数据
经过优化后,不同网络方案的性能对比:
| 方案 | 吞吐量 (Gbps) | 延迟 (μs) | CPU占用率 |
|---|---|---|---|
| OVS+内核协议栈 | 8.2 | 120 | 35% |
| VPP+用户态协议栈 | 14.7 | 65 | 22% |
| SR-IOV直通 | 24.9 | 9 | 8% |
关键发现:中小规模部署用VPP方案性价比最高,超大规模建议采用SR-IOV
5. 存储集成方案
5.1 Ceph与OpenStack对接
通过Rook Operator部署Ceph集群后,需要配置:
yaml复制# cinder-volume的values.yaml
backends:
- name: ceph
backend_host: ceph-cluster
volume_driver: cinder.volume.drivers.rbd.RBDDriver
rbd_secret_uuid: {{ .Values.secrets.ceph.admin }}
rbd_pool: volumes
5.2 持久化存储注意事项
- Ceph OSD建议采用Bluestore+NVMe组合
- 为不同服务创建独立存储池:
- volumes:云硬盘数据
- vms:虚拟机系统盘
- images:Glance镜像存储
- 监控指标必须采集:
- OSD延迟(<10ms为佳)
- 恢复队列长度(>10需要告警)
6. 生产环境关键问题排查
6.1 典型故障场景
问题现象:虚拟机启动失败,报错"Failed to allocate network"
排查步骤:
- 检查Neutron DHCP agent日志
- 确认NetworkAttachmentDefinition配置
- 验证Multus CNI插件版本兼容性
- 检查底层网络插件(Calico/Flannel)路由表
解决方案:
bash复制# 常见修复命令
kubectl -n openstack delete pod -l app=neutron-dhcp-agent
neutron-netns-cleanup --force
6.2 性能问题诊断
当出现API响应缓慢时,按此流程排查:
- 通过K8s Dashboard查看各组件资源使用
- 检查RabbitMQ队列积压情况
- 分析Keystone令牌签发延迟
- 追踪Nova-Compute与Libvirt通信耗时
7. 运维监控体系搭建
7.1 监控指标采集
必备监控项包括:
- OpenStack服务API响应时间(Prometheus Blackbox)
- 各组件容器资源占用(cAdvisor)
- 虚拟机启动成功率(自定义Exporter)
- Ceph集群健康状态(Rook内置监控)
示例告警规则:
yaml复制- alert: HighAPILatency
expr: rate(openstack_api_request_duration_seconds_sum[1m]) > 1
for: 5m
labels:
severity: critical
annotations:
summary: "OpenStack API latency exceeds threshold"
7.2 日志收集方案
采用Loki+Promtail+Grafana组合:
yaml复制# promtail配置示例
scrape_configs:
- job_name: openstack
static_configs:
- targets:
- localhost
labels:
job: openstack
__path__: /var/log/containers/*openstack*.log
8. 升级与扩展策略
8.1 滚动升级实践
通过Helm实现无缝升级:
bash复制helm upgrade --install nova ./nova \
--namespace openstack \
--values ./nova/values-production.yaml \
--set images.tags.nova_api=2023.1.1
关键注意事项:
- 先升级数据库Schema(通过Job执行)
- 按依赖顺序逐个组件升级
- 每个组件升级后运行冒烟测试
8.2 横向扩展方案
当需要扩容API服务时:
bash复制# Nova API扩容示例
kubectl -n openstack scale deployment nova-api --replicas=5
计算节点扩容流程:
- 新节点加入K8s集群
- 打标允许调度nova-compute
- 自动注册到OpenStack
bash复制kubectl label nodes node-01 openstack-compute=enabled
