部署完所有组件看到kubectl get pods全量 Running 的那一刻心里确实松了半口气。但紧接着问题就来了这套 OpenStack 是不是真的能用我说的是生产意义上的能用——不是 Horizon 能登录、能建一台测试虚拟机而是 API 网关被砍掉一个副本之后业务无感是存储池水位逼近阈值时系统还能优雅响应是租户 A 误删路由不会波及租户 B 的网络。本系列前几篇把环境规划、Kubernetes 基础集群、存储后端、消息队列、各核心服务编排全部跑通这一篇要解决的就是从部署完成到敢于上线之间的那段路。如果你正卡在所有 Pod 都正常但不敢投产的状态这篇内容值得看完。1. 部署完成不等于可以上线第八篇的验收主线1.1 组件全部 Running 之后我心里依然没底前几篇我们把 OpenStack 的核心服务都放进了 Kubernetes每个服务的 Deployment 都设置了多副本Pod 调度、健康检查、配置注入也都按生产标准来做。从容器编排角度讲这套系统的确跑起来了。但做过生产的人都知道Running这个状态能说明的问题非常有限它只代表进程活着不代表 API 能正确响应业务语义更不代表整个链路在故障场景下能自愈。我见过不少团队K8s 集群里的 OpenStack 看着一切正常结果一到业务高峰期就出各种怪问题——某个服务偶发超时、虚拟机创建卡在 SCHEDULING 状态、云硬盘挂载失败。这些问题的共同特点是单看 Pod 状态全是健康的但整个调用链路的某个环节已经处于亚健康状态。所以第八篇我决定不讲新组件的部署专注做一件事生产验收。把所有关键链路逐层拨测一遍用故障注入的方式验证系统的自愈能力把隐藏的风险在上线前挖出来。1.2 验收清单不是随便列的是从故障影响面倒推出来的这次验收清单的来源不是网上随便找的 check-list而是我们根据哪些故障会让业务受损倒推出来的。核心思路很简单先列出生产环境最不能出问题的十个场景再反推出需要验证哪些环节。我梳理后的验收方向分成四个面验收面关注点典型故障场景控制面API 可用性、认证链路、消息队列健康度API 网关单副本故障、Keystone 签发 token 超时、RabbitMQ 队列堆积数据面虚拟机全生命周期、存储与网络联动创建虚拟机卡死、卷挂载失败、安全组规则失效运维面监控告警、容量水位、日志可追溯告警风暴、存储池写满、关键指标采集缺失租户面多租户隔离、配额保护、备份恢复跨租户网络泄漏、配额失控、数据恢复不完整这四类问题一旦发生影响面分别是控制面故障导致整个云平台不可用数据面故障导致用户业务受损运维面故障导致故障发现太晚租户面故障导致租户间互相干扰或数据丢失。每个面都要有对应的验证手段和通过标准不能含糊。1.3 验收前先确认架构处于已知状态动任何测试之前先花半天时间把当前架构状态确认清楚。这一步不能省因为在未知状态下做验收任何结论都不可信。我们需要确认的内容包括所有 Deployment 和 StatefulSet 的副本数是否符合预期、持久化存储的容量使用率、镜像仓库里的 OpenStack 镜像版本是否一致、数据库和消息队列是否有主从或镜像配置。我习惯先把这些信息导成一份快照存档写清楚今天是基于什么状态做的验收。这样后续出现问题能判断是验收改变引起的还是原本就存在的历史隐患。比如我们这次验收前就发现消息队列的连接数在持续缓慢上涨单独看每次涨得不多但拉长到一周就能看到明确趋势。这类隐患不先处理掉后面的拨测结果都会被干扰。2. 控制面逐层拨测从 Pod 存活到业务语义2.1 三层拨测模型存活、就绪、语义kubectl get pods全部 Running只代表 Liveness 探针通过。但 OpenStack 这种高度依赖服务间调用的系统真正的风险在业务语义层。我把控制面的拨测分成三层第一层是存活检查看进程是否活着第二层是就绪检查看服务是否愿意接收流量第三层是语义检查看服务是否真的能完成业务请求。三层里最容易出问题的是第三层。举一个具体的例子Keystone 服务完全健康Pod 也是 Ready 状态但如果你用 curl 实际请求一次 token 签发可能会发现响应时间从正常的 200ms 涨到了 5 秒——因为数据库连接池被打满。这个过程进程没死、接口能通、但业务已经在崩溃边缘。第三层拨测就是要抓住这种带病运行的状态。拨测命令我放在下面这套脚本到现在还在用。注意几个关键点token 签发返回的是完整 JSON需要检查 HTTP 状态码和 token 字符串长度两个维度-w参数会把耗时打出来方便后面做基线对比# Keystone 语义拨测签发 token 并验证响应 TOKEN_RESP$(curl -s -w \n%{http_code} %{time_total} \ -X POST http://keystone-api:5000/v3/auth/tokens \ -H Content-Type: application/json \ -d { auth: { identity: { methods: [password], password: { user: { name: healthcheck, domain: {name: Default}, password: healthcheck-pass } } } } }) HTTP_CODE$(echo $TOKEN_RESP | tail -n1 | awk {print $1}) RESP_BODY$(echo $TOKEN_RESP | head -n -1) TOKEN_LEN$(echo $RESP_BODY | python3 -c import sys,json; print(len(json.load(sys.stdin).get(X-Subject-Token,))) 2/dev/null) echo HTTP$HTTP_CODE token_length$TOKEN_LEN建议每个 API 服务都建立一套类似的拨测脚本放定时任务里每五分钟跑一次。OpenStack 的每个服务暴露的 API 风格不完全一样但拨测思路是通用的构造最小业务请求、校验返回值、记录耗时、失败时告警。这套语义拨测才是生产可用的真实底线。2.2 故障注入实测砍掉 API 副本之后的真实反应拨测确认了系统在正常状态下是健康的下一步就是故障注入。我选择的第一个场景是砍掉一个 API 网关副本验证负载均衡和客户端重试机制是否真的生效。具体操作是直接删除 Keystone 的一个 Pod然后立刻用拨测脚本发起连续请求观察成功率。第一次做这个测试时发现了一个典型的坑HTTP 层请求没问题因为 Kubernetes Service 会把新连接转发到剩余的健康副本但 OpenStack 的某些 Python 客户端会复用连接池连接池里的旧连接指向已经被删除的 Pod如果客户端本身没有重试机制请求就会直接失败。这个问题在命令行工具上尤为明显。比如你在一个长会话环境里持续使用openstack命令底层连接池可能一直持有旧连接。稳妥的做法是在监控脚本和自动化工具里显式打开重试参数。对我们的自动化运维脚本统一做了这样的处理import openstack conn openstack.connect( cloudproduction, # 显式开启重试避免连接池复用导致的偶发失败 retriable_status_codes[502, 503, 504], retriable_exceptions(ConnectionError, TimeoutError), retry_wait2, )故障注入的意义不只是验证能不能恢复更是验证恢复期间业务是否无感。如果一次故障注入导致几个 502 报错那说明高可用配置还有缺口不能上线。2.3 消息队列是第一个容易翻车的地方OpenStack 几乎所有核心服务都依赖消息队列做异步通信Nova 的调度、Neutron 的端口操作、Cinder 的卷管理全靠 RabbitMQ 传递消息。控制面拨测里我把消息队列单独拎出来重点排查因为它的故障形态非常隐蔽服务看起来活着但消息堆积会让所有异步操作越来越慢最终把整个系统拖死。检查消息队列时我优先关注这几个指标检查项健康阈值异常时的影响队列消息数长期接近 0异步操作阻塞虚拟机创建卡住未确认消息数小于队列深度的 10%消费者卡死消息积压连接数稳定无持续增长连接泄漏导致服务假死节点间镜像同步状态无 backlog主节点故障时消息丢失我们这次验收时就发现 Nova 的某个 worker 队列偶尔出现小幅堆积排查后发现是因为某个计算节点的 agent 心跳超时设置太短导致消费者频繁重连。调整心跳参数之后队列恢复稳定。这类问题在部署阶段完全看不出来只有验收阶段用真实业务流量去压才会暴露所以消息队列的拨测必须纳入常态化巡检。3. 数据面端到端演练让一台云主机完整走一遍旅程3.1 从镜像到块设备Glance 与 Cinder 的联动检查控制面没有问题了接下来就看数据面。我选的第一个演练场景是最普通的创建一台云主机但这个看似简单的操作背后实际上是 Glance、Cinder、Nova、Neutron 四个服务的完整联动。当我发起创建云主机的请求后Nova-conductor 先从 Glance 拉取镜像元数据然后调用 Cinder 创建块设备接着把块设备挂载到计算节点最后 Neutron 负责虚拟机的网络接入。这个链条上任何一个环节慢了整个创建流程就会卡住。为了能看清问题出在哪一环我在演练时给每个服务都打印了调用链日志。实测中发现一个常见问题Cinder 创建卷之后Nova 通过 iSCSI 或 RBD 协议挂载设备时只要存储后端和计算节点之间的认证配置稍有偏差挂载就会超时。这个报错在界面上通常表现为虚拟机组装阶段失败日志却指向存储权限不足。我们的经验是先确认 Cinder 卷的状态和计算节点上实际的块设备映射再往上排查认证配置。给一个检查思路# 在计算节点上查看挂载是否真的发生了 # 先找到虚拟机的块设备映射 virsh domblklist vm-instance-id # 检查 RBD 映射是否成功Ceph 后端场景 rbd showmapped # 确认 Nova 计算服务日志里有没有挂载超时记录 grep -i timeout\|mount\|rbd /var/log/container/nova-compute.log | tail -n 20这次实测中我们用一台 2 核 4G 的小规格虚拟机做冷启动测试从发起请求到虚拟机状态变为 ACTIVE耗时 28 秒其中存储链路的耗时占了一半以上。把每次操作的耗时分段记录清楚后续优化才有数据支撑。3.2 网络路径验证不只是能 ping 通网络层面最容易犯的错误是能 ping 通就以为没问题。生产环境里的网络验证需要覆盖更完整的路径虚拟机的 DHCP 获取地址是否稳定、metadata 服务能否被虚拟机访问、安全组规则是否真正生效、浮动 IP 的 NAT 转发是否正常、跨节点通信的 MTU 是否一致。我整理了一份网络验证用例表每次验收都按这个清单执行验证项操作方法通过标准DHCP 获取重启虚拟机网络观察 IP 获取耗时15 秒内获取到正确网段地址Metadata 访问在虚拟机内访问 169.254.169.254返回正确的实例 ID安全组规则配置拒绝规则后测试连通性规则立即生效连接被拒绝浮动 IP从外部 ping 浮动 IP延迟正常无丢包大包传输设置 MTU 9000 后 ping 大包无分片无丢包注意安全组规则验证一定要做拒绝生效的测试而不是只验证允许生效。我们见过一种配置错误安全组默认规则放行了所有流量而显式的拒绝规则没有正确加载结果从界面上看规则配置没问题实际流量却不受管控。最稳妥的验证方式是先配一个显式的 deny 规则确认虚拟机与外界的通信立刻被切断再把规则删掉恢复通信。这个一断一通的过程才是安全组真正生效的证据。还有 MTU 问题。在 overlay 网络场景下如果计算节点和物理网络之间的 MTU 配置不一致大包传输会静默失败表现为小包通、大包断。这类问题排查起来非常费劲因为它只在特定大小的报文下才触发。预防手段是按网络层次逐层核对 MTU 配置从虚拟机虚拟网卡到宿主机网桥再到物理交换机每一层的 MTU 都要对齐。3.3 热迁移和故障恢复做一次才知道有多少隐藏依赖热迁移是生产环境里最容易被忽略的高可用能力。不做迁移演练的话你永远不会知道这套系统在计算节点宕机时能不能把虚拟机搬到另一台机器上。热迁移实测中最典型的问题是 CPU 型号差异导致迁移失败。如果集群里的计算节点 CPU 型号不完全一致虚拟机的 CPU 模式配置不当时迁移会在目标节点上因为 CPU 特性不兼容而失败。另一个问题是共享存储的配置热迁移要求虚拟机磁盘放在共享存储后端本地盘虚拟机是迁移不了的。这个约束在部署阶段就要想清楚。我们这次演练专门挑了一个计算节点做了一次计划内维护把该节点上所有虚拟机热迁移到其他节点。实际过程比预想中曲折有一台虚拟机在迁移过程中出现了长达 30 秒的网络中断原因是迁移期间内存脏页速率太高预拷贝阶段始终无法收敛。针对这个问题最直接的调整是限制虚拟机的内存写入速率或者改走 Post-copy 模式。但 Post-copy 对网络依赖更强一旦迁移链路抖动虚拟机反而会更快出问题。我们最终的选择是给那类高负载虚拟机预留了专用计算节点平时不做跨节点迁移。生产环境不是每个场景都要热迁移而是要清楚哪些虚拟机可以迁移、哪些需要特殊对待。4. 监控告警分层让故障在用户知道之前自动开口4.1 指标分四层K8s 基础设施、中间件、OpenStack 服务、业务语义监控是生产运维里不能省的一环。OpenStack on Kubernetes 这套架构的监控指标天然分成几个层次每一层关注的问题都不同。如果只盯着 Kubernetes 的资源指标OpenStack 服务内部的状态你根本看不到如果只盯着 OpenStack 的服务状态底层基础设施的资源竞争又容易被忽略。我习惯把监控指标分成四层监控层级关键指标数据来源K8s 基础设施Pod 重启次数、节点 CPU/内存、容器 OOMkube-state-metrics、node-exporter中间件RabbitMQ 队列深度、MariaDB 连接数、Ceph 容量水位各中间件 exporterOpenStack 服务API 响应延迟、错误率、各服务的 worker 队列OpenStack exporter 日志采集业务语义虚拟机创建成功率、卷挂载成功率、token 签发耗时自定义拨测脚本结果前两层是通用的后面两层才是 OpenStack 这套架构特有的。比如 RabbitMQ 的队列深度直接反映异步链路是否健康Ceph 的容量水位决定了块存储是否还能写入token 签发耗时则直接反映认证链路是否存在性能瓶颈。没有这些业务层面的监控你看到的就是系统一切正常直到用户报障才发现问题。4.2 告警规则设计的三条原则刚开始做告警的时候最容易犯的错误是把所有指标都配成告警结果导致告警风暴真正重要的问题反而被淹没。经过几次半夜被无意义告警叫醒之后我把告警规则的设计收敛成三条原则。第一条告警必须能定位到具体组件。比如RabbitMQ 队列深度超过 1000比消息队列异常有价值得多前者能直接告诉你系统哪里堵了。第二条优先告警可用性而不是资源水位。节点 CPU 到了 80% 不一定需要告警但 API 错误率超过 5% 必须立刻告警。资源水位可以用趋势预测来处理而不是用水位阈值来打扰值班人。第三条告警要留出逃生时间。比如存储池容量告警不能等到了 90% 才发那基本已经来不及操作了合理的做法是 70% 提醒、85% 严重告警这样才有时间扩容。给一个我们线上正在用的 Prometheus 告警规则示例。注意下面这个规则的核心价值在于用for: 5m做了持续时间过滤——只有持续五分钟的错误率升高才会触发告警短暂抖动不会骚扰值班人- alert: KeystoneTokenSigningHighErrorRate expr: | sum(rate(keystone_http_error_responses_total{code~5..}[5m])) / sum(rate(keystone_http_requests_total[5m])) 0.05 for: 5m labels: severity: critical component: keystone annotations: summary: Keystone token 签发错误率超过 5% description: 当前错误率 {{ $value | humanizePercentage }}持续超过 5 分钟请立即检查 Keystone API 和数据库连接池状态。4.3 别让告警风暴淹掉真正的问题再强调一次告警疲劳的问题。生产环境里告警不在多而在准。我们第一版监控配置上线后第一周就收到了两百多条告警其中大部分是重复规则叠加造成的。比如同一个 RabbitMQ 队列堆积问题同时触发了队列深度告警消费者延迟告警API 超时告警三条每条都往值班群里发一遍。解决告警疲劳靠三个手段告警分级、告警聚合、静默策略。分级是把告警按严重程度分成 P0/P1/P2P0 必须立即处理比如 API 完全不可用P1 需要工作时间处理比如存储容量高位P2 只是信息提示比如某个非核心服务响应稍慢。聚合是把同一个根因引发的多条告警合并成一条回填到同一个事件里。静默策略则是针对已知问题、计划维护窗口、非业务时段的例行波动提前屏蔽掉不会产生新信息的告警。这套机制跑下来值班告警从每周两百多条降到了平均不到十条而且每一条都值得处理。5. 租户配额与备份恢复上线前的最后一道控制面闭环5.1 配额不只是限制资源更是保护伞多租户场景下配额设计直接决定平台稳定性。没有配额约束的云平台等于把整个集群的容量风险暴露给任何一个租户。一个租户误操作创建了一百台大规格虚拟机可能直接把存储池打满其他租户全部受影响。配额设计的核心不是算总量而是留缓冲。比如集群总存储是 50TB就不能把 50TB 全部分配给租户。Ceph 的快照、克隆、回收站都会占用额外空间存储池一旦到 90% 以上性能会明显下降到 95% 以上基本就处于只读边缘。所以实际可分配配额最好控制在总容量的 70% 左右剩下的空间留给系统开销和故障缓冲。配额设计的另一个原则是分租户设定不搞一刀切。比如测试环境的租户和正式生产环境的租户配额必须分开管理。我们给生产租户的初始配额示例资源类型生产租户 A测试租户 B实例数上限4010vCPU 总数8016内存总量160GB32GB云硬盘容量4TB500GB浮动 IP 数5010这里需要注意 Nova 和 Cinder 的配额是分开管理的而且 Neutron 的配额安全组规则数、端口数很容易被忽略。安全组规则数量超限之后新的规则配置会静默失败用户侧看到的表现是规则加不进去排查起来很费劲。所以配额清单一定要覆盖计算、存储、网络三个层面缺一个都是隐患。5.2 跨租户隔离的细节检查配额管住了资源消耗隔离才真正守住租户边界。OpenStack 的多租户隔离依赖 Neutron 的租户网络、安全组和 RBAC 权限。但配置了不等于隔离生效必须逐项验证。我的检查顺序是先从网络层面验证两个租户的虚拟机在二层和三层的隔离再从 API 层面验证租户 A 的 token 不能访问租户 B 的资源。网络隔离的验证方法是分别在两个租户下创建虚拟机然后互相 ping期望结果是隔离网络的 ping 不通。API 层面的验证则简单得多使用租户 A 的 token 尝试查询租户 B 的端口列表期望结果是 403。还有个容易忽略的细节是共享服务网络的隔离。我们有些公共镜像、外部网络是跨租户共享的这类资源要设置好访问权限。曾经因为镜像的共享属性配置错误导致某个租户能直接复制其他租户的私有镜像快照这是个数据泄露级别的隐患。检查时要特别注意镜像、卷快照、备份存储这些数据类资源的 RBAC 配置而不仅是网络类的隔离。5.3 备份恢复演练备份本身不是目的能恢复才是备份是生产环境中平时没用、用时救命的最后一道防线。但很多团队的备份方案停留在数据被定期拷贝这个层面从来没有验证过恢复流程。等到真正需要恢复数据时才发现备份不可用这个教训代价极高。OpenStack 这套架构的备份对象至少要覆盖四个层面数据库Keystone、Nova、Neutron 等控制数据、Ceph 存储池块设备数据、Kubernetes 的 etcd 快照、以及 OpenStack 配置文件。前两类是数据面后两类是控制面。控制面数据丢失可能导致整个平台无法认证、无法管理数据面丢失直接影响用户业务。我们的备份频率和策略备份对象工具频率保留策略MariaDB 控制库mysqldump binlog每日全量 实时增量30 天etcd 快照etcd snapshot save每日7 天配置文件Git 加密存储每次变更永久Ceph 数据Ceph 自身快照/克隆按租户需求按服务等级备份做完之后恢复演练必须按故障场景来测而不是按备份成功来测。比如模拟控制库数据被误删这时你不仅要想办法用备份恢复数据还要验证恢复后各个 OpenStack 服务是否会自动重连、token 是否需要重新签发、正在运行的虚拟机是否会受影响。这些细节不通过演练是绝对掌握不了的。6. 上线前我们踩过的三个实战坑6.1 坑一RabbitMQ 连接数打满导致的假死验收期间有一台 Nova 计算节点表现很奇怪虚拟机创建成功但是状态一直不同步计算节点的日志偶尔报消息队列超时。一开始以为是网络抖动排查了很久才发现是消息队列的连接数被打满了。根因是 Nova 计算节点和 RabbitMQ 之间的连接没有正确回收。服务的 connection pool 参数配置不当导致每个心跳周期都会新建连接旧的连接又没有按预期关闭最后把 RabbitMQ 的连接上限耗尽。这个问题的隐蔽性在于整个系统的服务看起来都是活的但任何依赖消息队列的动作都会随机失败。处理方案是两件事同时做一是检查 RabbitMQ 的心跳超时和连接池参数确保连接会被正常复用和回收二是给消息队列连接数加了监控告警连接数一旦接近上限立即通知运维。我发现很多生产环境的问题不是没有被发现而是发现得太晚等意识到的时候已经过了最佳处理窗口。连接数这种指标平时不容易注意到但一旦出问题就是全局性的。6.2 坑二Ceph 快满时删除卷的操作顺序存储容量一直是 OpenStack 运维里的老大难。这次验收时我们把 Ceph 的容量水位拉到了临界值附近想测试系统在存储快满时的行为。结果发现一个诡异的逻辑问题存储池空间不足时Cinder 的删除卷操作也可能卡住。原因是 Ceph 在存储池达到一定水位后会进入只读保护状态而 Cinder 删除卷时需要先向 Ceph 发送一些元数据操作。如果 Ceph 因为水位保护拒绝了写入请求Cinder 的删除流程就无法走下去表现为删除卷一直显示 deleting。这形成一个死循环你越想清理空间系统越不让你清理。解决方案非常直接先扩容或清理存储池把水位降下来再执行删除操作。但更关键的是要把这个问题作为容量管理的一个原则固化下来——永远不要真的用到 100%建议 Ceph 集群的水位告警线设置在 80% 以下并且扩容流程要提前演练不能等到告警了才开始准备硬件。存储这东西预留的每一分空间都是在给未来的自己留时间。6.3 坑三PDB 与优雅停止的错位Kubernetes 节点做维护时Pod 会被驱逐。OpenStack 的 API 服务本身是无状态的驱逐再重建没问题。但 Nova 的计算服务不同它负责管理计算节点上的虚拟机生命周期如果被强制终止正在执行的操作比如创建虚拟机的最后一个状态更新可能中断。我们的经历是给 Nova-compute 设置了过强的 PodDisruptionBudget导致节点维护时 Pod 无法被驱逐维护计划被阻塞把 PDB 调弱之后Nova-compute 又被频繁强制杀掉虚拟机状态偶发不一致。这个矛盾背后的核心是OpenStack 服务的优雅退出机制和 Kubernetes 的驱逐策略要匹配不能只看 PDB 数值。最终方案是给 Nova-compute 这类服务配置了单独的处理逻辑在节点维护前先手工将计算节点上的虚拟机迁走同时配合preStop钩子让容器在销毁前完成状态上报。这套机制跑了几轮维护演练才稳定下来。经验就是生产环境的优雅停止不是 Kubernetes 默认行为能保证的必须结合具体服务的退出逻辑单独设计。打到这一篇整个 OpenStack on Kubernetes 的生产部署系列已经接近尾声。回想整个过程最大的体会是生产部署的真正难点从来不是把组件装起来而是让整个系统在被故障冲击时依然能正常服务用户。验证这套能力没有捷径只能靠一次次的拨测、故障注入、恢复演练把每一个可能出问题的点在系统上线前都暴露一遍。我建议大家在做生产验收时不要只盯着成功场景也要专门设计失败场景去测——只有知道系统的底线在哪里上线之后才睡得着觉。