K8s生产环境配置要注意什么？这5个坑别踩

先别急着甩锅给K8s。很多时候，问题不是出在技术本身，而是我们在生产环境配置上，踩了那些“默认”配置的坑。这些坑，在开发测试环境可能毫无感觉，一旦流量和规模上来，就会集中爆发，把运维同学拖进无尽的救火深渊。今天，我就结合自己和身边朋友的“血泪”教训，盘点5个生产环境配置中最容易踩的坑，希望能帮你提前避雷。

坑一：etcd的存储配额是个“沉默杀手”

默认配置：--quota-backend-bytes=2GB

踩坑场景：你的集群运行了几个月，一切正常。突然某天，所有创建、更新操作全部失败，etcd进入只读模式。告警显示：etcdserver: mvcc: database space exceeded（数据库空间超限）。

原因分析：etcd会保存所有K8s对象（Pod、Service、ConfigMap等）的每一次变更历史。默认2GB的存储空间，在Pod频繁更新、ConfigMap众多的生产环境中，很快就会被写满。

避坑方案：

1. 提前扩容：根据集群规模预估，将配额提升到8GB或更高。
2. 启用自动压缩：定期清理历史版本，这是防止存储无限膨胀的关键。

# 在kubeadm配置中调整
etcd:
  local:
    extraArgs:
      quota-backend-bytes: "8589934592"# 8GB
      auto-compaction-retention: "8h"   # 每8小时压缩一次
      auto-compaction-mode: "periodic"

血泪教训：我朋友的公司曾因此导致线上发布中断2小时，回滚都困难。

切记：etcd不是“设置完就不用管”的组件，它的存储健康是集群的生命线。

坑二：kube-apiserver的并发限制“卡脖子”

默认配置：--max-requests-inflight=400， --max-mutating-requests-inflight=200

踩坑场景：业务高峰期，CI/CD流水线大量触发部署，同时运维人员在执行批量查询。突然，kubectl命令超时，Dashboard页面转圈，甚至出现Too Many Requests的错误。

原因分析：apiserver是所有请求的单一入口。默认的并发限制是为中小规模设计的。当大量客户端（kubectl、控制器、调度器、监控Agent）同时发起请求时，请求队列会被打满，新请求被拒绝或超时。

避坑方案：

• 根据节点和Pod规模上调限制：对于百节点集群，建议读并发(max-requests-inflight)调整到600，写并发(max-mutating-requests-inflight)调整到300。
• 启用优先级和公平性队列：确保--enable-priority-and-fairness=true，防止高优先级的系统请求（如控制器同步）被用户请求淹没。
• 为大列表查询设置合理超时：调整--min-request-timeout，避免一个复杂查询长期占用连接。

坑三：kube-proxy死守iptables，网络性能“断崖式”下跌

默认模式：mode: iptables

踩坑场景：随着微服务拆分，集群内Service数量从几十个增长到几百上千个。这时，Pod之间的网络调用延迟显著增加，甚至出现间歇性连接超时。

原因分析：iptables模式在处理大量Service时，规则数量呈O(N²)增长。每个节点上的iptables规则集会变得极其庞大和复杂，每次数据包转发都需要遍历超长的规则链，CPU消耗和延迟急剧上升。

避坑方案：

• 切换到IPVS模式：IPVS基于内核的哈希表，性能几乎不受Service数量影响，是生产环境大规模集群的标配。

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs  # 关键切换
ipvs:
  scheduler: rr

切换时机：最好在集群初始化时就规划使用IPVS。如果后期切换，需要做好网络中断的预案和测试。

坑四：系统资源“无底洞”，与业务容器“抢饭吃”

默认情况：未给kube-apiserver、kube-controller-manager、kube-scheduler等控制平面组件设置明确的资源请求（requests）和限制（limits）。

踩坑场景：节点上突然部署了一个CPU密集型的业务Pod。很快，该节点状态变为NotReady，因为kubelet进程被“饿死”，无法及时上报心跳。

原因分析：Linux内核的CPU调度是公平的。如果没有为系统组件预留资源，当业务容器全力占用CPU时，系统组件可能分不到足够的时间片，导致其功能异常，进而引发节点失联、调度失败等连锁反应。

避坑方案：

• 必须为控制平面组件设置资源保障：通过DaemonSet或Static Pod的配置，明确指定requests和limits。

# 以kube-apiserver为例
spec:
  containers:
  - name: kube-apiserver
    resources:
      requests:
        cpu: "2"
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "8Gi"

核心思想：把控制平面当作最重要的“系统业务”来对待，保障其资源就是保障整个集群的稳定。

坑五：内核参数“老古董”，撑不起现代云原生负载

默认状态：使用操作系统默认的内核参数。

踩坑场景：集群承载高并发Web服务，在压力测试时，即使Pod和节点资源充足，也会出现大量连接失败、Cannot assign requested address等错误。

原因分析：默认的net.core.somaxconn（TCP连接队列）、fs.file-max（最大文件打开数）、net.ipv4.ip_local_port_range（本地端口范围）等参数可能太小，无法支撑成千上万的Pod间网络连接和频繁的文件操作。

避坑方案：

• 系统性优化节点内核参数：这应是节点镜像或初始化脚本的一部分。

# /etc/sysctl.d/99-k8s-optimize.conf
net.core.somaxconn =32768
fs.file-max =2097152
net.ipv4.ip_local_port_range =102465535
vm.swappiness =0

• 区分工作节点和控制节点：控制节点可能需要对net.netfilter.nf_conntrack_max等参数进行更大调整以应对API流量。

总结：从“能用”到“稳定”的配置思维

这五个坑，本质上都源于同一个问题：用默认的、为通用场景设计的配置，去应对生产环境特有的、高压力、大规模、长周期运行的严苛需求。避坑的关键，不在于记住这几个参数，而在于建立一种 “生产环境配置思维” ：

1. 预见性：根据业务增长预测，提前规划资源（存储、网络、计算）的容量和配置。
2. 系统性：理解K8s各个组件间的依赖，知道改动一处会对其他部分产生什么影响。
3. 可观测性：任何配置变更，都必须有对应的监控指标（如etcd存储使用率、API延迟、节点就绪率）来验证效果和发现异常。
4. 可管理性：配置即代码，所有生产环境的变更都应通过版本化的配置文件（如kubeadm-config.yaml）进行，并具备快速回滚能力。

“无他，惟手熟尔”！有需要的用起来！

如果你觉得这篇文章有用，欢迎点赞、转发、收藏、留言、推荐❤！