1. 为什么要在Kubernetes上部署OpenStack这个问题困扰了我整整三个月。作为某金融云平台的架构师当我第一次提出要把OpenStack迁移到Kubernetes时团队里几位资深工程师直接摔了键盘——你疯了吗OpenStack本来就是IaaS现在要跑在容器编排系统上但当我们完成POC验证后这些反对者都成了最积极的推动者。Kubernetes提供的声明式API、自动化运维能力和弹性扩缩特性恰好解决了传统OpenStack部署中最棘手的几个问题部署效率提升80%传统Fuel部署需要2天K8s Operator只需2小时故障恢复时间从小时级降到分钟级Pod崩溃后K8s自动重建资源利用率提高3倍通过K8s的bin packing算法优化VM调度重要提示生产环境部署必须使用经过验证的OpenStack Helm Charts或Airship项目不要尝试从零开始编写CRD。1.1 架构设计的核心挑战将OpenStack控制平面容器化不是简单的搬上K8s需要解决几个关键问题有状态服务处理数据库MySQL/Galera必须使用StatefulSetRabbitMQ集群需要headless service配合消息队列持久化卷要配置StorageClass网络性能瓶颈Neutron的OVS组件需要hostNetwork模式Calico与Neutron的集成方案选择DPDK加速在容器环境下的实现认证体系整合Keystone与K8s RBAC的权限映射服务账户的跨系统认证流程我们在测试集群中曾因忽略OVS的网卡直通配置导致网络吞吐量暴跌70%。后来通过给kubelet配置--allowed-unsafe-sysctlsnet.*参数才解决。2. 生产级部署方案选型经过对比主流方案我们的技术选型路径如下方案优势缺陷适用场景OpenStack Helm官方维护组件齐全部署复杂调试困难大型生产环境Airship 2.0声明式管理集成MetalLB学习曲线陡峭电信级部署Kolla-Kubernetes容器镜像经过优化文档较少已有Kolla经验团队自研Operator完全定制化开发成本高特殊架构需求最终选择OpenStack Helm方案主要基于金融行业对官方组件的合规要求需要同时支持Train和Wallaby版本已有专业的K8s运维团队2.1 硬件资源配置基准根据我们的压力测试数据建议的最低配置control_plane: nodes: 3 vCPU: 16 Memory: 64GB Storage: - 200GB (系统盘) - 500GB (Ceph OSD) compute_nodes: nodes: 3 vCPU: 32 Memory: 128GB SR-IOV网卡: 2端口10Gbps特别注意必须为每个控制平面节点配置Bonding网卡我们曾因单网卡故障导致整个AZ瘫痪。3. 关键组件部署实战3.1 Ceph存储集群部署这是最易出错的环节分享我们的避坑清单OSD准备# 必须预先创建LVM卷 pvcreate /dev/nvme0n1 vgcreate ceph-vg /dev/nvme0n1 lvcreate -L 500G -n osd1 ceph-vgHelm values配置ceph: config: osd_pool_default_size: 3 osd_crush_update_on_start: false dashboard: enabled: false # 生产环境必须关闭性能调优设置bluestore_block_db_size: 4GB启用osd_op_num_threads_per_shard: 2血泪教训永远不要在Ceph集群未完成peering时强制重启Pod这会导致PG处于inconsistent状态。我们因此丢失过一个测试环境的Glance镜像池。3.2 Neutron网络方案对比测试三种网络方案后的性能数据方案网络延迟(μs)吞吐量(Gbps)适用场景Calico VXLAN1808开发测试环境OVN-Kubernetes15012中等规模生产SR-IOV Passthrough2825高性能计算选择OVN方案时需要特别注意# 必须设置巨帧 ansible -i inventory k8s-node -m shell -a \ ip link set eth0 mtu 90004. 高可用设计要点4.1 多AZ部署策略我们的部署架构Region: RegionOne AZ: - az1 (k8s-node01-03) - az2 (k8s-node04-06) - az3 (k8s-node07-09)关键配置nova: scheduler: default_availability_zone: az1 default_schedule_zone: az1 cells: enable: true4.2 故障转移测试方案建议定期执行以下测试随机删除control plane Pod验证重建断掉一个AZ的网络连接模拟Ceph OSD故障强制重启所有etcd节点我们设计的自动化测试脚本def test_pod_recovery(deployment): original_pods get_pod_count(deployment) delete_random_pod(deployment) assert wait_for( lambda: get_pod_count(deployment) original_pods, timeout300 )5. 监控与日志方案5.1 Prometheus监控指标必须监控的核心指标openstack_api_request_duration_secondsrabbitmq_queue_messages_readyceph_osd_upneutron_agent_state我们的Grafana看板配置示例sum(rate(openstack_api_request_duration_seconds_count[5m])) by (service)5.2 日志收集优化使用Loki收集日志时的关键过滤规则pipeline_stages: - regex: expression: ^(?Ptimestamp\S) (?Plevel\w) (?Pcomponent\S) (?Pmessage.*) - labels: level: component:曾因日志量过大导致ES集群崩溃后来通过以下措施解决为Nova API设置debugFalse使用Fluentd的buffer_chunk_limit限制对Neutron日志单独配置采样率6. 升级与维护实战6.1 原地升级方案从Train升级到Wallaby的步骤先升级Helm chart版本按顺序滚动更新helm upgrade openstack/keystone --version 3.0.0 helm upgrade openstack/glance --version 2.0.0最后执行数据库迁移ALTER TABLE nova.instances ADD COLUMN new_feature TEXT;6.2 日常维护命令常用诊断命令合集# 查看Pod资源使用 kubectl top pod -n openstack # 检查Neutron agent状态 openstack network agent list # 强制GC Ceph存储 kubectl exec -it ceph-osd-0 -- radosgw-admin gc process记住任何维护操作前必须先执行kubectl cordon node我们曾因忘记此步骤导致计算节点同时重启触发VM大规模迁移。
