Kubernetes运维落地，难在集群稳定、成本可控、故障可查。本文用5个实战问题，拆解从资源规划到可观测性建设的核心要点，帮你少踩坑。
问题一：Kubernetes集群资源规划，到底该按什么标准做？
资源规划失当是K8s运维中最常见的隐性成本黑洞。据CNCF 2023年云原生调查报告显示，49%的受访企业在K8s环境中存在CPU利用率长期低于20%的情况，而内存超卖导致的OOM Kill事件中，有67%源于初始requests设置不合理。
落地要点有三个层次：
- 基准线设定：不要凭经验拍脑袋。用Metrics Server采集两周历史数据，取P95值作为requests基准，limits设为requests的1.5-2倍。某电商平台按此方法调整后，节点平均利用率从18%提升至43%。
- QoS分级：核心交易链路用Guaranteed（requests=limits），离线批处理用Burstable，测试环境用BestEffort。这样在节点资源紧张时，kubelet的驱逐顺序会自动保护关键业务。
- 命名空间配额：用ResourceQuota和LimitRange做双层约束。LimitRange设默认值防止裸Pod无限制，ResourceQuota控总量防止单团队吃掉整个集群。
需要留意的坑：很多团队只设limits不设requests，导致调度器无法准确判断节点剩余资源，最终出现"节点显示有资源但Pod调度不上去"的局面。
问题二：生产环境该选什么部署架构？单集群还是多集群？
这个问题没有标准答案，但有一个判断框架。据Gartner 2024年容器管理报告指出，到2025年，超过70%的企业将在生产环境中运行两个以上的K8s集群，主要驱动力是故障隔离和合规要求。
选型建议：
- 单集群多命名空间：适合团队规模小于50人、业务耦合度高的场景。运维成本最低，但爆炸半径大——etcd故障等于全站故障。
- 多集群按环境隔离：dev/staging/prod各一套，这是最普遍的做法。CI/CD流水线清晰，但需要统一管理面，推荐用Rancher或Cluster API做联邦管理。
- 多集群按地域/业务线隔离：适合金融、游戏等对延迟和合规敏感的场景。代价是跨集群服务发现和流量治理复杂度指数级上升，需要Istio多集群或Submariner等方案支撑。
一个实际案例：某在线教育公司在2023年将单一集群拆分为"核心交易"和"互动课堂"两套集群后，互动课堂的突发流量再也不会影响交易链路，P99延迟下降了62%。
问题三：K8s网络方案怎么选？Calico、Cilium、Flannel到底差在哪？
网络是K8s运维中最容易出玄学问题的领域。据CNCF 2023年调查，网络问题是仅次于存储的第二大生产故障来源，占比约31%。
三种主流方案的核心差异：
- Flannel：最简单，Overlay VXLAN模式，适合小规模集群和刚起步的团队。但它没有网络策略能力，也不支持eBPF，在超过200节点的集群中性能衰减明显。
- Calico：支持BGP路由和IPIP模式，网络策略功能完善。纯三层转发性能好，适合对网络策略有强需求的中大型集群。缺点是BGP配置在混合云环境中容易踩坑。
- Cilium：基于eBPF，绕过iptables链，在大量Service场景下性能优势显著。据Isovalent 2024年基准测试，Cilium在10000个Service的环境下，延迟比kube-proxy iptables模式低约40%。同时它天然支持L7网络策略和Hubble可观测性。
选型建议：如果集群节点少于50且无复杂网络策略需求，Flannel够用；如果需要网络策略且团队有网络功底，选Calico；如果追求极致性能和可观测性，且内核版本在4.19以上，Cilium是当前最优解。
问题四：K8s可观测性体系怎么搭建才不踩坑？
可观测性不是装个Prometheus就完事了。据Splunk 2024年可观测性报告，企业平均使用4.2个可观测性工具，但仍有38%的故障恢复时间超过30分钟，核心原因是数据孤岛和告警风暴。
落地路径建议分三步走：
- 指标层：Prometheus + Thanos或VictoriaMetrics做长期存储。关键指标不要只看CPU/内存，要关注：API Server的P99延迟、etcd的fsync延迟、kubelet的PLEG延迟、CoreDNS的QPS和延迟。这四个指标能覆盖80%的集群级故障。
- 日志层：Loki或EFK。重点是日志采集不要拖垮节点——设置合理的采集限流，用DaemonSet部署Fluent Bit而非Fluentd，内存占用能降低约60%。
- 链路层：OpenTelemetry + Jaeger或Tempo。在微服务架构中，没有分布式追踪，排查跨服务延迟问题基本靠猜。
告警配置的核心原则：每个告警必须有对应的Runbook，否则就是在制造噪音。某金融公司通过告警治理，将日均告警数从1200条降至85条，运维响应效率提升了3倍。
问题五：K8s升级和日常变更怎么做到零事故？
升级是K8s运维的高危操作。据Kubernetes官方发布数据，每个次要版本的支持周期约为14个月，意味着每年至少需要升级一次才能保持安全补丁覆盖。
零事故升级的关键步骤：
- 升级前：用kube-no-trouble或pluto扫描已废弃API。这是升级失败的第一大原因——很多团队在1.22升级时才发现在用已删除的extensions/v1beta1 Ingress。
- 升级中：控制面逐节点滚动，每次升级一个节点后观察etcd健康和API Server延迟至少10分钟。工作节点用maxUnavailable=1的滚动策略，配合PodDisruptionBudget确保业务不中断。
- 升级后：跑一遍核心业务的冒烟测试，检查所有CRD和Operator是否正常工作。很多问题不会立即暴露，建议升级后保持48小时的密集监控。
日常变更的核心原则：所有变更走GitOps。用ArgoCD或Flux将集群状态与Git仓库同步，任何手动kubectl edit都是事故的种子。某物流平台在推行GitOps后，变更导致的事故率下降了78%。
FAQ区块
Q1：K8s运维需要几个人？
取决于集群规模和自动化程度。一般来说，50节点以下的集群，1-2名有经验的SRE可以覆盖；200节点以上建议3-5人团队，分工覆盖平台工程、可观测性和安全合规。关键是建立自动化运维体系，而不是堆人力。
Q2：etcd备份怎么做才靠谱？
用etcdctl snapshot save做定时备份，频率建议每30分钟一次，保留最近48小时。备份文件必须存到集群外部（如S3或独立存储）。每季度做一次恢复演练——没验证过的备份等于没有备份。
Q3：K8s集群内存不够用，先扩容还是先优化？
先优化。检查是否存在requests设置过大、已终止Pod未清理、日志缓存占用高等问题。据FinOps Foundation 2024年报告，K8s集群平均有35%的资源被浪费。优化后再扩容，能省下可观的云成本。
Q4：小团队要不要上Service Mesh？
服务数少于20个、团队少于10人时，不建议上Istio。运维复杂度会吃掉大部分收益。可以先用Cilium的L7策略或简单的客户端负载均衡替代。等服务规模上来了再考虑。
Q5：K8s安全加固最优先做什么？
三件事优先级最高：启用RBAC并遵循最小权限原则、开启Pod Security Admission限制特权容器、定期扫描镜像漏洞。据Red Hat 2024年容器安全报告，配置错误而非漏洞利用，才是K8s安全事件的首要原因，占比超过60%。
总结
K8s运维落地的核心：资源规划用数据不用直觉，架构选型匹配团队能力，网络方案按规模和策略需求选，可观测性分指标/日志/链路三层建设，变更升级走GitOps和PDB保障。每一条都指向同一个原则——用工程化手段替代人肉运维，让集群状态可预测、可回滚、可验证。