Kubernetes教程性能优化实战指南

Kubernetes性能上不去？别急，老司机带您实战优化！

说实话，咱们把应用搬到Kubernetes上，图的不就是个弹性、稳定和高性能嘛。但您是不是也遇到过这种情况？明明资源给足了，服务跑起来却总觉得“不得劲”，响应时快时慢，资源利用率看着也不高，排查起来像大海捞针。别担心，这太常见了！今天，咱们不聊那些空洞的理论，就结合我这些年摸爬滚打的经验，特别是和阿里云、MongoDB、Express这些技术栈打交道的心得，来一场实实在在的K8s性能优化实战。

第一站：给您的K8s集群做个“全身检查”

优化不能瞎搞，得先知道瓶颈在哪儿。这就好比医生看病，得先做检查。

资源请求与限制：别让“饿死”和“撑死”拖后腿

坦白讲，很多性能问题的根源，从YAML文件里就埋下了。咱们是不是经常为了省事，把CPU请求设成`100m`，内存请求设成`128Mi`，或者干脆不设限制？

这隐患可大了！ 举个例子，一个Node.js的Express应用，如果内存请求设得太低，它可能刚启动没多久，就被K8s因为内存不足（OOM）给杀掉了，然后不断重启，服务压根不稳。反过来，如果请求设得过高，比如一个简单的服务占了2个CPU核心，其他Pod就调度不进来，资源白白浪费。

我们的实战做法是：

基于监控数据设定： 先用工具（比如阿里云ARMS或Prometheus）监控应用在真实压力下的资源使用情况，观察其峰值和常态。拿一个MongoDB的Pod来说，我们通过监控发现它平常内存占用在1.5GiB左右，高峰到1.8GiB。那么，我们的内存请求就可以设为`1.6Gi`，限制设为`2Gi`。这样既保证了稳定性，又避免了过度分配。
使用Vertical Pod Autoscaler (VPA)： 在阿里云ACK环境中，我们可以利用VPA这个利器。它能自动分析Pod的历史资源使用，并给出调整请求和限制的建议，甚至能自动帮我们更新，特别适合那些流量变化有规律的应用。

第二站：让应用在容器里“跑得更舒服”

集群调好了，咱们得看看应用本身。尤其是像Node.js（Express）和MongoDB这类有“脾气”的服务，得顺着它们的特性来。

Node.js (Express) 应用优化：不止是代码

您可能觉得Express应用的性能优化主要在代码逻辑和数据库查询。没错，但放在K8s里，还有些容器层面的“小窍门”。

利用Node.js集群模式： 一个Node.js进程只能用一个CPU核心。在K8s里，我们完全可以把CPU请求设为`2`或更多，然后在Dockerfile的启动命令里，用`cluster`模块或者像`pm2`这样的工具，启动多个进程实例，充分利用多核资源。这样一来，一个Pod就能处理更多并发请求。
调整垃圾回收（GC）： 对于内存敏感的应用，我们可以通过容器环境变量为Node.js设置更积极的GC参数，比如`--max-old-space-size`，明确告诉它可以使用多少内存，减少GC停顿对请求响应时间的影响。

MongoDB有状态服务的部署心法

在K8s里跑MongoDB，性能的坑最多。直接用一个Deployment加普通卷？数据持久化和高性能很难兼得。

我们的推荐方案是：

使用StatefulSet + 高性能云盘： 在阿里云上，我们一定会用StatefulSet来部署MongoDB副本集。存储呢？千万别用默认的！我们会根据性能要求选择ESSD PL云盘，它的IOPS和吞吐量远超普通云盘。有一次，我们把一个客户MongoDB的存储从普通云盘换成ESSD PL1，仅磁盘读写延迟就降低了70%，查询耗时直接降了三分之一。
内核参数调优： 通过Init Container或者特权模式，为运行MongoDB的Pod调整Linux内核参数，比如`vm.dirty_ratio`、`net.core.somaxconn`等，这对提升数据库的写入性能和网络连接能力立竿见影。这部分阿里云的官方教程里也有详细说明，照着做准没错。

第三站：网络与调度，看不见的战场

前面都是“单兵作战”的优化，现在来看看“集团军”配合的问题。

减少网络跳数，让通信更“直接”

K8s网络模型很强大，但多跳一次，延迟就增加一点。比如，您的Express应用Pod和MongoDB的Pod如果被调度到不同的可用区（AZ），那网络延迟可能从零点几毫秒飙升到几毫秒。

怎么办？

使用节点亲和性/反亲和性： 我们可以通过配置，让需要频繁通信的Pod（比如Web应用和它的缓存Redis）尽量调度到同一个节点，或者同一个可用区。这在阿里云上，可以通过打标签和`podAffinity`轻松实现。
考虑Service Mesh（如Istio）但需谨慎： Service Mesh带来了强大的可观测性和流量管理能力，但它本身也会增加网络开销。对于极度追求性能的内部服务间调用，我们有时会建议绕过Service Mesh的Sidecar，直接使用Pod IP进行通信。这需要权衡管理和性能。

巧用探针，让调度器更“聪明”

您有没有遇到过，Pod状态是`Running`了，但应用还没真正准备好接受请求，导致流量打进来就报错？

这就是`readinessProbe`（就绪探针）和`livenessProbe`（存活探针）没配置好的典型症状。给Express应用配置一个合理的HTTP就绪探针（比如检查`/health`端点），确保应用完全启动后再接入流量；给MongoDB配置一个TCP存活探针，确保数据库服务真的在监听端口。这能极大提升服务的整体可用性和稳定性，避免“病态”Pod拖累整个系统。