K8S在Linux上的性能优化策略
一、硬件资源优化
- 节点资源扩容：根据工作负载需求增加节点的CPU、内存资源，避免因资源不足导致Pod抢占或调度延迟。
- 存储设备升级：优先使用SSD（尤其是NVMe SSD）作为etcd、Pod持久卷的存储介质，显著提升磁盘IO性能（etcd对磁盘延迟极其敏感）。
- NUMA架构感知：若服务器支持NUMA，配置Kubernetes节点为NUMA感知模式，优化内存访问效率，减少跨NUMA节点的内存访问延迟。
二、内核参数调优
通过调整Linux内核参数，优化网络、文件系统等性能，适配K8S高并发场景：
- 网络栈优化：
- 增大连接跟踪表大小：
net.netfilter.nf_conntrack_max=1048576（应对高并发连接)；
- 开启TIME_WAIT连接复用：
net.ipv4.tcp_tw_reuse=1（减少TIME_WAIT状态的连接占用）；
- 扩大源端口范围：
net.ipv4.ip_local_port_range=1024 65535（提升客户端并发连接能力）；
- 调整TCP缓冲区：
net.ipv4.tcp_rmem=4096 87380 16777216、net.ipv4.tcp_wmem=4096 87380 16777216（优化TCP收发缓冲区大小）。
- 文件系统优化：
- 增大进程可打开文件数：
fs.file-max=2097152（避免Pod因文件描述符耗尽失败）；
- 增大inotify实例和watch数量：
fs.inotify.max_user_instances=8192、fs.inotify.max_user_watches=524288（适配Nginx Ingress等需要监控大量文件的应用）。
- 其他参数：关闭Swap分区（
swapoff -a并注释/etc/fstab中的Swap行），设置vm.swappiness=10（减少内存交换，提升性能）。
三、Kubernetes组件调优
- kubelet调优：
- 增加并发处理能力：
--concurrent-endpoints=1000（提升Endpoint更新效率）；
- 调整Pod数量上限：
--max-pods=110（默认110，可根据节点规格适当增加）；
- 优化心跳机制：缩短
--node-status-update-frequency（如设为10s），加快节点状态同步。
- kube-apiserver调优：
- 增加资源请求/限制：如
--request-cpu=2、--request-memory=4Gi（避免API Server因资源不足成为瓶颈）；
- 控制并发请求数：
--max-requests-inflight=1000、--max-mutating-requests-inflight=500（平衡吞吐量与稳定性）。
- kube-controller-manager与kube-scheduler调优：
- 根据集群规模调整资源：如
--kube-api-qps=100、--kube-api-burst=200（提升与API Server的通信效率）；
- 启用Leader选举：
--leader-elect=true（避免单点故障）。
- kube-proxy调优：
- 优先使用iptables模式（而非ipvs，除非需要高并发场景）：
--proxy-mode=iptables（iptables在小规模集群中延迟更低）；
- 调整连接跟踪参数：
--conntrack-max=1048576、--conntrack-tcp-timeout-established=3600（优化连接跟踪性能）。
四、网络优化
- CNI插件选择：使用高性能CNI插件（如Calico、Cilium），支持更高效的网络转发（如Cilium的eBPF技术可降低网络延迟）。
- MTU设置：根据网络环境调整MTU（如使用Overlay网络时设为1450，避免分片），提升网络吞吐量。
- 网络策略：通过K8S NetworkPolicy限制Pod间不必要的通信，减少网络流量负载。
五、存储优化
- 分布式存储系统：使用Ceph、GlusterFS等分布式存储，提升存储的可扩展性与可靠性（适合大规模集群）。
- 存储类配置：根据应用需求创建不同的StorageClass（如
ssd、hdd），实现存储资源的动态分配（如数据库应用使用ssd类，日志应用使用hdd类）。
- PV/PVC管理：合理设置PV、PVC的大小（避免过度分配），使用动态PV（如通过StorageClass自动创建PV），简化存储管理。
六、应用层优化
- 容器镜像优化：使用轻量级基础镜像（如Alpine Linux），采用多阶段构建减小镜像大小（如从
golang:alpine构建Go应用，最终镜像仅几MB）；避免安装不必要的软件包，减少镜像层数。
- 资源限制与请求：为Pod设置合理的
resources.requests（如cpu: "500m"、memory: "512Mi"）和resources.limits（如cpu: "1"、memory: "1Gi"），避免Pod间资源争用（触发OOM Killer或CPU节流）。
- 水平扩展：使用Horizontal Pod Autoscaler（HPA）根据CPU/内存利用率或自定义指标（如QPS）动态调整Pod数量（如当CPU利用率超过70%时，自动扩容Pod数量）。
- 缓存策略：在应用层引入缓存（如Redis、Memcached），减少对数据库等后端服务的访问压力（如电商应用缓存热门商品信息）。
七、监控与持续调优
- 监控工具：使用Prometheus+Grafana搭建集群监控体系，采集CPU、内存、磁盘IO、网络带宽、Pod状态等指标，实时监控集群性能。
- 日志分析：使用EFK（Elasticsearch+Fluentd+Kibana）或Loki收集和分析应用日志，快速定位性能瓶颈（如慢查询、错误请求）。
- 基准测试：定期使用Kubemark、Locust等工具进行基准测试，模拟高并发场景，评估优化效果（如测试API Server的QPS、Pod启动时间）。