如何通过Kubernetes在CentOS上实现高效资源管理，以提升业务性能？

Kubernetes 在 CentOS 上的资源管理是一场技术与人文的交响。它不只是让机器跑得更快，更是让团队的协作更顺畅，让业务的每一次迭代都充满温度。下面我把亲身实际操作中领悟到的点滴经验，用轻松却不失严谨的文字，献给正在追求高效与可持续发展的你。

一、 系统底层的“养生”准备

在任何一颗大树根系稳固之前，都需要先把土壤翻耕、 事实上... 除草。对 CentOS 这一步尤为关键：

• 关闭 Swapswapoff -a 并在 /etc/fstab 注释掉 swap 行，防止 kubelet 因内存压榨而报错。
• 内核参数调优创建 /etc/sysctl.d/k8s.conf 写入 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 vm.swappiness = 0 施行 sysctl -p /etc/sysctl.d/k8s.conf让网络流量和内存管理更顺畅。
• 防火墙与 SELinux将 firewalld 暂时关闭或配置相应端口；将 SELinux 设置为 permissive避免不必要的权限阻拦。
• 时间同步使用 chrony 保持所有节点时间一致，防止证书和日志出现奇怪的时间戳。

二、 容器运行时与网络插件的选择——让“根系”更健壮

换个赛道。 Kubernetes 的核心是容器运行时而网络插件则是枝叶之间的信息通道。以下两张表格帮助你快速对比常用选型：

容器运行时对比表

特性	Docker Engine 20.xx	containerd 1.7+	CRI‑O 1.28+
原生 CRI 支持	No	Yes	Yes
镜像大小
社区活跃度	Mature but 趋向停更	Straightforward & fast updates	K8s 原生推荐， 更新及时
平安加固能力	Audit 支持一般	BPF + seccomp 完整支持	BPF + seccomp 完整支持 + OCI 签名集成
适用场景推荐 如果你追求兼容性且已有 Docker 镜像仓库，可暂时保留 Docker；若想削减系统负担、提升平安性，则首选 containerd 或 CRI‑O。

CNI 插件功能速览

CNI 插件	L3 路由能力	BGP 支持	L4/L7 策略
Cilium	Yes	Yes	丰富
Calico	Yes	Yes	NetworkPolicy 基础 + eBPF 可选
Flannel	No	No	仅 NetworkPolicy 基础版
Weave Net	Yes	No	NetworkPolicy 简单实现

*表格中“~”表示约数，仅供参考。

三、 资源请求 & 限制——精准配给，让每个容器都有饭吃也不会抢饭碗 ​

Kubernetes 用两个概念来管控 CPU 与内存：Requests和 Limits”。想象一下 如果我们把业务比作农田，那么 Requests 就是每块地块最基本的灌溉水量，而 Limits 则是该地块能够承受的最大灌溉量。合理设定， 两者相辅相成：

• #CPU 请求示例：   resources:     requests:       cpu: "500m"     limits:       cpu: "1000m"
• #内存请求示例：   resources:     requests:       memory: "512Mi"     limits:  &nb sp;memory: "1Gi"
• #技巧一：先跑基准测试，再根据实际 CPU 利用率调低 Requests，避免节点空闲率过高。
• #技巧二：对 IO 密集型服务， 加上 memory.limit 的 “软限制”，让 OOM Killer 不会轻易踢掉关键进程。
• #技巧三：使用 ResourceQuota 为命名空间划定总额， 让不同团队像种植不同作物一样，有序共享肥料。