容器云原生技术架构落地指南：从概念到部署避坑

简介这是一份面向企业IT架构师、运维与研发人员的容器云原生技术架构方案PPT系统讲解云原生在数字化转型中的定位与核心能力。内容先定义云原生架构的典型特征——容器化封装、动态管理、微服务化和持续交付再拆解容器技术“飞天”、微服务改造、DevOps流水线的协同方式同时引入某股份制银行AI异构计算案例展示容器平台在GPU驱动匹配、预编译算法、镜像签名与安全扫描等真实生产环节的应用。资源为单个pptx演示文稿大小6.96MB目录涵盖云原生PaaS、业务敏态转型与多云管理三大模块适合技术培训、方案汇报或内部架构评审。目前已有158人学习。通过该材料读者可快速建立云原生架构的完整认知理解其在节省资源、缩短交付周期、提升业务敏捷性方面的商业价值并为多云、容灾及安全合规体系的建设提供可参考的设计思路。1. 当「容器云原生技术架构.pptx」摆上评审桌真正要回答的两个问题一份命名为「容器云原生技术架构.pptx」的材料出现在立项评审会上时很多人下意识以为这又是一次「把虚拟机换成容器」的演示。但这份材料的真正分量在于回答两个问题容器负责解决什么、云原生负责解决什么。容器解决的是运行单元的分发与隔离云原生解决的是整套架构能否被声明式地描述、自动地调度、在故障面前自愈。大量团队把应用塞进镜像就宣布改造完成结果半年后翻车退回虚拟机原因往往是把「容器化部署」当成了终点。这篇笔记按一线落地顺序拆先立概念与分层再定关键选型落到可运行的部署路径与避坑清单。适合正在写这份评审材料、或准备立项推进容器化的同事做对照。2. 先拆清概念再谈架构容器、云原生与编排器2.1 容器与云原生一个管「打包」一个管「运营」容器本身解决的是运行单元的分发问题。namespace 做资源视图隔离cgroup 做资源使用限制镜像把应用、依赖库和配置固化在一起在任意一台内核兼容的宿主机上都能以一致方式启动。它带来的直接好处是环境一致性——测试环境跑得起来的东西生产环境不会因为少一个系统包而当场崩溃。但容器不等于云原生。云原生是一整套软件工程约束镜像不可变、配置外置、实例可被随意创建销毁、故障由平台自动修复而不是靠运维手工登录接管。很多团队混淆这两者把业务塞进容器就认为「云原生改造已完成」。这种误判在评审阶段不暴露上了生产才开始付利息容器的资源隔离是内核级隔离不是安全级隔离单点内核问题会同时波及其他容器没有编排器兜底容器挂了不会自己恢复存储和网络方案没规划有状态应用迁移时直接卡住。所以看一份容器云原生技术架构第一个判断标准是看它把「容器化」写得多重。如果通篇只谈镜像和启动没有编排、调度、自愈的篇幅这份架构本质上还是虚拟机思维换皮。2.2 把架构拆成三层资源层、编排层、业务负载层我一般建议把整个技术架构拆成三层评审材料按这个顺序画不要只画一张大分层图就完事。第一层是资源层物理机或虚拟机、操作系统、容器运行时。这一层决定资源密度、隔离粒度和故障域。第二层是编排层以 Kubernetes 为核心承担调度、服务发现、滚动更新、故障自愈。第三层是业务负载层Deployment、StatefulSet、DaemonSet 这些工作负载对象以及 Service、Ingress 组成的暴露链路。支撑组件——镜像仓库、可观测性、密钥管理——不属于业务层它们是云原生底座的一部分要单独画出来。这三层的验收标准完全不同。资源层看容量规划和高可用编排层看 API 可用性与组件健康业务负载层看应用是否具备「可被杀掉而不丢数据」的能力。用一张表可以把传统虚拟机部署与容器化部署的差异写清楚评审时直接贴在 PPT 里维度传统虚拟机部署容器化部署启动速度分钟级秒级单机密度几十台虚拟机上百个容器环境一致性依赖配置管理工具补齐镜像固化、开箱即用故障恢复虚拟机 HA 或人工介入编排器自愈、滚动重启隔离边界强隔离虚拟化层内核级软隔离这张表背后还有一个容易被忽略的点隔离粒度变了安全责任边界也变了。虚拟机崩溃互不牵连容器之间共享宿主机内核一个提权漏洞可能横向影响同节点所有 Pod。所以容器云原生架构里的安全设计必须在资源层和应用层各做一道防护。2.3 编排器为什么默认是 Kubernetes选型理由与适用边界编排层选 Kubernetes 在当前环境下几乎不需要辩论但评审时还得能说清楚理由。它最好的三样东西声明式 API、控制器自愈模式、可插拔生态。声明式 API 的意思是用户只描述期望状态——我要 3 个副本、镜像版本 1.0.0——平台负责把实际状态拉回期望状态。这让变更可以审计、可以回滚而不是靠运维记住「上次手工改了什么」。控制器模式把自愈做成了平台能力节点挂了Pod 会被重新调度副本数不够ReplicaSet 会自动补配置变了滚动更新按策略推进。生态方面网络、存储、安全、可观测性都实现了标准接口接入成本被压到最低。但 Kubernetes 有明确的适用边界。一个只有两三台机器、应用全是无状态批处理的小团队直接上 K8s 会发现自己被 kube-apiserver、etcd、证书轮换这些基础设施的运维成本缠住收益完全体现不出来。评审时如果说不清「为什么不用其他编排方案」说明这层还没有想透。常见做法是团队规模与节点数量足够、业务需要持续发布与弹性伸缩、故障自愈能直接带来 SLA 提升才把 Kubernetes 写进架构。2.4 云原生就绪度自检用五个问题判断团队能不能上这套架构这一节是把前面的概念落到评审现场最实用的一步。我看过太多材料把目标写得很大但没回答「现有应用到底能不能在这套架构上跑」。不用复杂工具五个问题就能做完就绪度评估应用日志是否走标准输出而不是写死到本地某个路径云原生下日志由平台统一采集写死路径等于让日志成为黑匣子。配置是否外置到环境变量或 ConfigMap而不是编译进镜像配置不分离一个环境一套镜像滚动发布就没法做。实例是否可以被随意销毁重建有状态数据是否已迁到外部存储或由 StatefulSet 接管存储是否独立于 Pod 生命周期Pod 重建后数据还在不在决定了有没有资格用云原生弹性能力。故障自愈的 RTO 目标有没有量化比如「节点宕机后业务在 5 分钟内恢复」必须要写明确数字。如果五个问题里有两个以上答不上来架构评审不应通过。不是技术不行而是业务负载层还没有达到云原生要求的最低门槛。这个自检清单可以直接搬进 PPT 的应用迁移方案页比写十页「微服务改造愿景」都管用。3. 落地前四个关键选型运行时、网络、存储与安全基线编排器在上一章定为 Kubernetes这一章只谈支撑它的四块配套。这四样东西决定了集群跑起来之后的稳定性上限也决定了评审阶段需要写进 PPT 哪些参数。很多项目卡在部署中期翻工原因几乎都是选型没在评审时定死到了实施现场才边做边改。3.1 容器运行时选型containerd 是默认项Docker 退到开发端容器运行时是资源层最基础的组件。当前用 kubeadm 初始化集群默认运行时已经是 containerdDocker 的角色退回到开发和本地调试端。选 containerd 的核心原因是 Kubernetes 通过 CRI 接口直接与运行时通信containerd 原生实现这个接口控制面组件少一层转换故障点更少。Docker 在历史版本里依赖 dockershim 作为中间层这套桥接组件已经被上游移除继续在节点上装 Docker 再让 Kubelet 连过去属于给自己制造兼容性负担。评审时要把两个参数写清楚。第一个是 cgroup 驱动Kubelet 和 containerd 必须保持一致当前主流环境都设成 systemd。如果初始化后 Kubelet 报 failed to load cgroups先检查这里不要急着怀疑网络或证书。第二个是镜像加速与私有仓库地址要提前分发给所有节点而不是部署完再逐台补。查当前节点运行时很简单一个命令就能看到kubectl get nodes -o wide输出里的 CONTAINER-RUNTIME 列会显示containerd://字样确认集群实际跑的运行时与架构设计一致。这一列在评审后的复检阶段也是重要的审计证据避免实施时有人悄悄退回 Docker。3.2 网络方案先拍板Flannel、Calico、Cilium 的对比与参数网络模型是评审阶段必须最先拍板的选型因为它直接决定集群的 IP 规划改起来代价最大。Kubernetes 本身不做 Pod 间网络依赖 CNI 插件。三个常见方案各有明显边界。Flannel 走 overlay VXLAN部署简单、轻量、不依赖底层网络设备适合纯内网、不需要网络策略的私有环境。Calico 走 BGP 或 IPIP支持 NetworkPolicy性能和规模上限高是生产环境最常见的选择。Cilium 基于 eBPF数据路径短、可观测性强、安全策略能力强但对内核版本和内核模块有要求老内核上跑不起来。维度FlannelCalicoCilium数据路径VXLAN overlayBGP / IPIPeBPFNetworkPolicy不支持支持支持且能力更强适用规模几百节点以内数千节点大规模高性能场景内核依赖弱弱需要较新内核这三个方案在 PPT 里要写死三个参数。第一个是 Pod CIDR 网段必须和公司现有网段错开后面避坑章会重点讲第二个是 MTU取决于底层网络的承载能力比如跑了 VXLAN 的物理网络MTU 不调大会出现包被丢弃的诡异问题第三个是 overlay 模式Calico 下就是 IPIP 还是 VXLAN 的选择。IPIP 封装开销小但要求底层网络允许 IPIP 协议VXLAN 走 UDP 更容易穿透现有网络。我一般默认 Calico明确要求低延迟且内核足够新再考虑 CiliumFlannel 只在小规模内部环境用。3.3 存储模型有状态应用绕不开的 CSI 选型容器本身无状态但业务总有 MySQL、Redis、对象存储网关这类需要持久化数据的东西。存储选型通过 CSI 接口接进 Kubernetes评审时要把存储方案与 StorageClass 对应起来。纯本地盘方案性能最好但节点故障数据就跟着丢失只适合做缓存或中间态数据。NFS 部署简单、支持多节点读写但单点风险与 IOPS 瓶颈明显适合日志和文件类负载。Ceph 或者云厂商云盘是生产环境首选自带数据冗余配合 StatefulSet 能把有状态应用的可用性真正托住。评审材料里要给每个有状态应用写清 storageClassName而不是留一句「按需申请」。常见翻车方式是没规划 StorageClass 就允许 PVC 自动创建结果默认挂在本地目录上数据没有任何冗余节点一坏全丢。还要写明回收策略Retain 还是 Delete。Delete 策略省事但误删 PVC 会连数据一起清掉对数据库类应用必须用 Retain 并把备份任务纳入巡检。存储与备份是两件事架构里只有存储没有备份等于给数据判了缓刑。3.4 镜像安全和容器安全评审时就要定下的三道闸门镜像安全和容器安全在整个架构里经常被压缩成一页但后续生产事故里安全欠账占比很高。我习惯把它设计成三道闸门。第一道闸在镜像入库前CI 里接入镜像漏洞扫描高危漏洞阻断构建不让问题镜像流进仓库。第二道闸在拉取与准入环节内网必须走私有镜像仓库禁用 latest 标签防止版本漂移用签名机制保证镜像来源可信在 Kubernetes 侧通过准入策略只允许从可信仓库拉镜像。第三道闸在运行期容器默认权限过大是普遍问题需要收紧安全上下文。一个最小可用的 securityContext 配置长这样securityContext: runAsNonRoot: true runAsUser: 10001 readOnlyRootFilesystem: true capabilities: drop: [ALL] allowPrivilegeEscalation: false这段配置做四件事禁止以 root 运行、指定非 root 用户、根文件系统只读、丢弃所有 Linux 能力并禁止提权。它对绝大多数业务应用无害但能把容器逃逸的入口收窄一大半。运行期的异常行为检测可以交给 Falco配合系统调用白名单能捕捉到反弹 Shell 和异常文件读写。三道闸门全部落地比写十页安全愿景都实在。镜像安全和容器安全不是运维的独角戏应用开发也要按这个基线改造镜像所以评审阶段定下来后面才不会扯皮。4. 从评审稿到可运行集群容器化部署的最小落地路径4.1 部署前的环境准备主机名、内核参数与 containerd 配置评审通过后第一步不是敲 kubeadm 命令而是把所有节点的环境差异抹平。常见做法是准备一个前置脚本在三件事上对齐主机名唯一且不含下划线Kubernetes 对主机名有硬性要求时间同步开启证书校验和事件排序都依赖时间内核模块和系统参数一次性加载好。很多部署翻车都发生在环境准备不彻底上等到 kubeadm init 报错再回头看很难判断是哪个前置项没做。cat EOF | sudo tee /etc/modules-load.d/containerd.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter cat EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system这段脚本加载两个内核模块并打开两个转发开关。overlay 是镜像分层存储依赖的文件系统类型br_netfilter 让桥接流量也经过 iptables 过滤这是 Pod 与 Service 通信能正常工作的前提。启动容器之前先确认内核模块已加载能省掉后面大量网络排障时间。containerd 的配置也要在部署前落下默认配置生成后把 SystemdCgroup 设为 true再按实际环境配置镜像加速源。这一步不做好后面拉镜像会各种超时和证书报错。4.2 kubeadm 初始化控制面三个 CIDR 参数一次写对环境就绪后在控制平面节点执行初始化。这是整个部署里参数最密集、出错代价最高的一步三个 CIDR 网段必须一次规划对sudo kubeadm init \ --pod-network-cidr172.16.0.0/16 \ --service-cidr10.96.0.0/16 \ --control-plane-endpointp-lb.example.local \ --apiserver-advertise-address10.0.0.11这些参数的含义和取舍pod-network-cidr 给集群内所有 Pod 分配 IP。它必须是一个没有被公司现有网络占用的独立网段而且不能和 service-cidr、node 网段重叠。service-cidr 给 Service 虚拟 IP 使用。两个网段错开是底线重叠后 DNS 解析和路由会乱到无法定位。control-plane-endpoint 在高可用架构中填负载均衡的域名或 VIP单机环境可以直接填本机地址。apiserver-advertise-address 让 kube-apiserver 监听在指定的内网 IP 上多网卡机器尤其要显式指定否则可能监听在错误的网卡导致 Worker 节点连不上。初始化完成后Kubernetes 的控制面组件——etcd、kube-apiserver、scheduler、controller-manager——会以静态 Pod 的方式由 Kubelet 拉起。说白了云原生底座本身就是一组由容器组成的系统集群启动容器这个词在这里不单指业务应用也指这些系统组件。然后配置 kubectl 的访问凭证mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config复制 admin.conf 到用户目录并修正属主kubectl 才能以管理员身份访问集群。这一步漏了后面所有 kubectl 命令都会提示 connection refused。工作节点加入集群的命令会由 kubeadm init 在末尾输出带着 token 和证书哈希直接在工作节点执行即可。token 的有效期只有 24 小时评审环境如果隔天继续操作过期后要用kubeadm token create重新生成这是新手最容易踩的延迟坑。4.3 让网络插件接管 Pod 通信Calico 的安装与验证控制面起来后集群处于「已初始化但不可用」状态因为节点还是 NotReadyPod 之间没法通信。此时安装网络插件以 Calico 为例。从 Calico 官方发布页获取与目标集群版本匹配的 manifests 文件然后应用kubectl apply -f calico.yaml重点在应用前要修改 calico.yaml 里的 CALICO_IPV4POOL_CIDR 变量让它与 kubeadm init 时传的 pod-network-cidr 完全一致。这个值不一致Calico 会给 Pod 分配另一个网段的地址节点上的路由表与编排器的期望直接打架。IPIP 和 VXLAN 的选择在 Calico 的安装参数里配拿不准就先保持默认 IPIP集群跑通后再按性能测试结果调整。装完网络插件后查询组件状态kubectl get pods -n kube-system -o wide观察 calico-node 是否进入 Running。长期处于 CrashLoopBackOff 时先看日志用kubectl logs -n kube-system -l k8s-appcalico-node。常见原因是 Pod CIDR 与节点网段冲突或底层网络放通了不该放通的协议端口。注意calico-node 状态是 Running 不代表 Pod 网络一定通必须建一个测试 Pod 做跨节点访问验证这一步要在架构验收时留下记录。4.4 验证集群节点就绪、核心组件启动与排错入口网络插件就绪后执行完整的健康检查kubectl get nodes kubectl get pods -n kube-system kubectl run nginx-test --imagenginx第一条命令输出应显示所有节点为 Ready。第二条确认 kube-system 里核心组件全部 Running如果某个组件反复重启优先看对应 Pod 的日志与事件而不是立刻猜证书问题。第三条创建一个测试 Pod验证最基础的拉镜像与调度链路。Node 长期 NotReady 时到对应节点执行journalctl -u kubelet -fKubelet 会把拒绝调度的原因直接打出来。一个体检旧习惯是执行kubectl get cs看控制面健康这个命令在后续版本里已经下线返回的信息不可靠。判断控制面是否健康直接看静态 Pod 的 running 状态和 apiserver 的/healthz探针不要依赖这个废弃命令。整个部署路径走到这里一份从评审稿到可运行集群的最小闭环就完成了后面所有业务迁移都在这套底座上展开。5. 容器云原生落地避坑手册从网段冲突到 etcd 备份5.1 网段冲突集群内部互访时通时不通现象集群内 Pod 互访正常但访问公司内部某个系统比如数据库或监控平台时通时不通从不同节点发起结果还不一样。这种情况最容易让人怀疑是代码问题或负载均衡问题实际查下去发现是网络路由在捣乱。原因Pod CIDR 与公司现有网段重叠。底层交换机不知道 Pod 网段应该往哪转发把流量丢到了默认路由的错误方向。还有一种情况是 Pod 网段本身没冲突但跨机房通信时中间设备没有发布这条路由。解决在评审阶段先做 IP 段登记表把 Pod CIDR、Service CIDR、Node 网段三张表放到一起检查。Calico 走 IPIP 时确认宿主机内核支持走 VXLAN 时确认 UDP 4789 端口在全链路放通。我见过的最典型事故是把 Pod 网段设成了内网常见的 172.16 开头的某段与办公网冲突最后花了两个晚上排路由才定位到。这个坑的最佳解法是前置永远不要在实施现场临时想网段。5.2 资源限制没设全一个高负载应用拖垮整台宿主机现象一个 Java 服务在促销流量下 CPU 使用率飙升同节点的其他 Pod 开始大面积超时随后节点触达 MemoryPressure系统开始驱逐 Pod整个服务雪崩。事后看监控那个出问题的 Pod 根本没有设置资源上下限。原因Deployment 里只写了镜像名没有写 resources 字段或者只写了 requests 没写 limits。requests 告诉调度器需要预留多少资源limits 才是真正限制使用量的闸门。内存没有 limit容器的实际占用可以无限增长直到把宿主机内存吃完。解决所有工作负载统一补齐 requests 与 limits内存密集应用尤其要设 limit。对容量没把握时先加 requests再逐步收紧 limits。一份标准的资源配置长这样resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2 memory: 2Gicpu 的 500m 表示请求半个核心limits 里的 2 表示最多可使用两个核心memory 512Mi 是预留2Gi 是硬上限。注意容器触达内存 limit 后会被 OOMKill而不是像 CPU 那样被限流所以 memory 的 limit 必须大于应用正常常驻内存留足余量。容器资源隔离不是只靠内核的 cgroup 默认值而是要靠运维在编排层把这些值定义清楚这是云原生底座里最容易拖欠的一项也是集群稳定性最直接的影响因素。5.3 私有镜像仓库拉取失败x509 证书与 containerd 配置不一致现象工作节点启动容器时拉镜像一直失败报x509: certificate signed by unknown authority或者报http: server gave HTTP response to HTTPS client。同一个仓库地址在开发机上用 Docker 拉没问题到了集群节点上就拉不动。原因containerd 的 registry 配置与 Docker 完全两套Docker 的 daemon.json 不会自动同步给 containerd。自建仓库用的是 HTTP 协议而 containerd 默认按 HTTPS 请求所以直接拒了。解决在 /etc/containerd/config.toml 里显式配置该仓库的信任选项。内网 HTTP 仓库可以这样配[plugins.io.containerd.grpc.v1.cri.registry] [plugins.io.containerd.grpc.v1.cri.registry.configs] [plugins.io.containerd.grpc.v1.cri.registry.configs.reg.internal.example] insecure_skip_verify true然后重启 containerdsystemctl restart containerd。不同版本下配置结构略有差异以节点上containerd config dump的输出为准但思路一致。注意这个选项只应加给可控的内网仓库生产环境面向公网或跨部门共享的仓库必须走正规证书。配好仓库后还要把镜像 tag 固定下来禁止 latest 漂移否则后面排查问题时镜像版本对不上连复现都做不到这是镜像安全里最基础的一条纪律。5.4 Service 转发性能退化iptables 在大规模集群里的软肋现象集群节点规模到几十台后Service 访问偶发超时kube-proxy 所在节点 CPU 偏高更新 Service 规则时偶现连接中断几秒。规模小时完全正常规模一上来就暴露。原因kube-proxy 默认走 iptables 模式。iptables 是链式遍历Service 和 Endpoint 越多规则链越长每条转发都要线性匹配规则更新时还可能整链重建造成窗口期断连。解决kube-proxy 切换到 IPVS 模式。IPVS 基于哈希查表规则规模对性能的影响远小于 iptables。kubeadm 环境下可以通过 kube-proxy 的 ConfigMap 把 mode 改为 ipvs然后滚动重启 kube-proxy 生效。启用前确认节点安装了 ipvsadm 和相关内核模块。IPVS 模式还有额外收益支持更丰富的调度算法需要会话保持时可以通过调度参数配置。这个坑在评审阶段几乎没人讲因为小集群根本测不出来但它决定了架构能不能随着业务规模成长。评审材料里把 kube-proxy 的运行模式写清楚比写十行「高性能网络」更有说服力。5.5 只做不备份etcd 单点故障让整个集群失去记忆现象控制节点磁盘故障后kube-apiserver 一直起不来集群里所有资源对象全部丢失节点上的工作负载还在跑但已经无人能管理。即使配了多控制节点如果 etcd 部署在同一批机器上故障范围一样被放大。原因评审时把 etcd 当成普通数据库没有纳入容灾设计或者只做了单机备份备份文件和集群在同一块盘上盘坏了备份跟着没。etcd 保存的是整个集群的期望状态没有它kube-apiserver 就是无头苍蝇。解决自建集群要定期做 etcd 快照核心命令etcdctl --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ snapshot save /backup/etcd-snapshot-$(date %F).db证书路径以实际部署为准如果 etcd 没有开启证书认证可以去掉后两行参数。快照文件要同步到与集群生命周期解耦的独立存储比如对象存储或另一套备份系统。恢复时用etcdctl snapshot restore并把恢复出来的数据目录指给新集群。这条是我做过容器项目里最后悔没早做的事。后来我把 etcd 备份脚本加进了每周巡检清单并要求恢复演练每季度做一次才算把这块短板补上。云原生底座不是保险箱etcd 备份就是它的后悔药不能省。6. 架构交付前验证两件事容量压测与故障演练6.1 容量压测看 P95 延迟别看平均值架构评审通过、集群跑起来并不代表规划的参数真的成立。交付前要做容量压测验证两件事应用在预期流量下能不能扛住HPA 能不能按时生效。压测时不要盯平均延迟平均值会把长尾问题盖住要看 P95 甚至 P99同时观察容器有没有出现 CPU throttling。throttling 严重时应用整体负载不高但响应变慢这就是 limit 设置过紧的信号。HPA 的配置要提前落下kubectl autoscale deployment demo --cpu-percent80 --min3 --max10这条命令让 demo 在 CPU 使用率超过 80% 时自动扩容到最多 10 个副本。HPA 依赖 metrics-server 提供指标数据压测前先确认 metrics-server 已部署否则命令不会生效。压测时重点观察扩容的触发速度——从指标超限到新副本 Ready 用了多久这个时间直接决定弹性能不能兜住突发流量。6.2 故障演练一条命令验证自愈能力容量压测通过后还要做故障演练。最简单也最有效的一招就是在一个工作节点上直接停掉 Kubeletsystemctl stop kubelet然后在控制面观察驱逐过程kubectl get pods -o wide kubectl get events --sort-by.lastTimestamp观察目标只有一个从节点 NotReady 到 Pod 被重新调度到其他节点中间用了多长时间是否在评审时约定的 RTO 内。如果业务 Pod 没有配置 requests 和 readinessProbe被驱逐的时间会明显变长如果某个 Pod 是 StatefulSet 且 PVC 绑定在本地卷这个演练当场就会翻车——数据不在Pod 起不来。故障演练要放在交付前不是上线后。我早年评审架构材料时画了很漂亮的图却没有把演练写进交付清单。后来一次宿主机维护业务中断时间比预期长了四倍定位后才发现很多 Pod 只是从 NotReady 恢复并没有被快速驱逐到健康节点。那次之后我养成了一个习惯任何容器云原生技术架构要签字必须配一份压测报告和一份故障演练记录缺一不可。希望这些经验帮到你让你的底座经得起真实故障考验。本文还有配套的精品资源点击获取