centos中k8s性能如何调优 - 问答

CentOS 上 Kubernetes 性能调优实战指南

一系统级内核与网络调优

建议在 /etc/sysctl.d/99-k8s-performance.conf 中统一配置并 sysctl -p 生效，重启后持久化：
- 网络与连接
  - net.ipv4.ip_forward = 1
  - net.core.rmem_max = 134217728
  - net.core.wmem_max = 134217728
  - net.core.somaxconn = 32768
  - net.ipv4.tcp_max_syn_backlog = 4096
  - net.ipv4.tcp_tw_reuse = 1
  - net.ipv4.ip_local_port_range = 1024 65535
- 虚拟内存与文件系统
  - vm.swappiness = 10
  - vm.max_map_count = 524288
  - fs.inotify.max_user_instances = 8192
  - fs.inotify.max_user_watches = 524288
  - fs.aio-max-nr = 1048576
- 容器与进程
  - kernel.pid_max = 4194304
安全与策略
- 生产环境不建议直接关闭 SELinux，应通过策略放行容器网络与挂载需求；临时调试可用 setenforce 0。
- 建议关闭 Swap（生产环境强烈建议）：swapoff -a 并在 /etc/fstab 注释 swap 行，避免内存颠簸与 kubelet 异常。

二节点资源预留与驱逐策略

启用 kubelet 的 Node Allocatable，为系统守护进程与 k8s 组件预留资源，避免与业务 Pod 争抢导致 OOM 或节点失联。
核心参数与公式
- 参数：–enforce-node-allocatable=pods[,kube-reserved][,system-reserved]；–kube-reserved；–system-reserved；–eviction-hard
- 公式：allocatable = NodeCapacity − kube-reserved − system-reserved − eviction-threshold
示例（按节点资源与负载调整数值）
- kubelet 配置片段：
  - –enforce-node-allocatable=pods,kube-reserved,system-reserved
  - –kube-reserved=cpu=1,memory=1Gi,ephemeral-storage=10Gi
  - –system-reserved=cpu=1,memory=2Gi,ephemeral-storage=10Gi
  - –eviction-hard=memory.available<500Mi,nodefs.available<10%
验证
- kubectl describe node 查看 Allocatable
- 检查 cgroup 限制：cat /sys/fs/cgroup/memory/kubepods/memory.limit_in_bytes
- 如为 system.slice/kubelet.service 也做了 cgroup 限制，可分别查看对应 memory.limit_in_bytes。

三 Kubernetes 组件与工作负载调优

kubelet
- 合理设置 maxPods（或 podsPerCore），避免单节点承载过多 Pod 导致网络/存储/内核资源竞争。
- cgroup driver 与容器运行时保持一致（常见为 systemd 或 cgroupfs）。
kube-proxy
- 高并发场景优先使用 ipvs 模式，减少 iptables 规则膨胀带来的性能退化。
- 结合连接规模调整 conntrack 相关参数（如 --conntrack-max、–conntrack-ttl）。
etcd
- 提升稳定性与吞吐：增加副本数（建议 3/5/7），合理设置 --heartbeat-interval 与 --election-timeout 适配网络延迟。
API Server
- 提升并发处理能力：增大 --max-requests-inflight 与 --max-mutating-requests-inflight。
网络插件与策略
- 选择高性能数据面（如 Calico/Cilium），结合网络策略减少无效流量；按实际 MTU 调整（常见 1450/1500）。
存储
- 优先 SSD/NVMe 与高性能存储（如 Ceph、云盘），为关键负载配置 StorageClass 与（如支持）存储 QoS。

四 Pod 与命名空间的资源配置

容器级 requests/limits
- requests 用于调度与保底，limits 为运行时上限；CPU 超限会被限流，内存超限触发 OOMKilled。
- 示例：
  - resources.requests.cpu: “250m”；resources.requests.memory: “64Mi”
  - resources.limits.cpu: “500m”；resources.limits.memory: “128Mi”
QoS 与 OOM 优先级
- Guaranteed（requests=limits）最不易被 OOM；BestEffort 最易被 OOM；Burstable 居中，按 request 大小影响得分。
命名空间级治理
- ResourceQuota：限制命名空间内 Pod 数量与 CPU/内存 requests/limits 总量、PVC 数量等。
- LimitRange：为未显式声明的容器注入默认 requests/limits，并设定最小/最大值边界。

五监控验证与上线流程

监控与观测
- 部署 Metrics Server 与 Prometheus/Grafana，观测节点与 Pod 的 CPU/内存/网络/磁盘、调度与 API 延迟、etcd 性能等关键指标。
基线测试与压测
- 使用 k6/Locust/JMeter 对核心业务做基线压测，结合指标回放与 A/B 变更验证调优收益。
上线与回滚
- 采用滚动升级与 HPA（基于 CPU/自定义指标）配合灰度发布；任何内核/组件参数变更先在测试环境验证并保留回滚方案。

0 赞

0 踩