香港服务器跑Kubernetes怎么配置？从EKS新调度参数看资源利用率

现在租香港服务器的用法在变。过去多是放一个网站、一个数据库或一组API，这两年越来越多企业一次租三五台独立服务器，组成Kubernetes集群跑电商、SaaS、微服务或者AI推理。机器一多，一个别扭的问题也跟着来了：算力明明买够了，集群却总是一半节点喘不过气、另一半在睡觉。

AWS最近的一次更新，正好把这个问题摆回了台面上。8月12日，AWS宣布Amazon EKS支持高级Kubernetes控制平面配置（Advanced Kubernetes Control Plane Configuration），集群管理员第一次可以直接调整Scheduler、Controller Manager和API Server的部分参数——Pod往哪个节点放的打分策略、HPA自动扩缩容的评估周期、事件保留时长，还有NodePort的端口范围，支持Kubernetes 1.31及以上版本的新老集群。这当然是EKS自己的功能，跟你在香港服务器上自建的K8s没有直接关系。但AWS这次选择开放哪几个参数，恰好点出了大多数集群资源利用率上不去的原因，而这几个参数在开源Kubernetes里同样存在，自建集群完全可以对着调。

36GB空闲内存，却起不动一个16GB的Pod

先看资源碎片化这个老毛病。假设租了4台香港服务器，每台16核64GB，账面上整个集群有64核、256GB。跑上几个月，很可能变成这样：四台机器分别剩6GB、10GB、8GB、12GB内存。加起来还有36GB，但这时要起一个申请16GB内存的新Pod，调度器翻遍四个节点，一个能塞下的都没有——资源没少，只是被摊碎在了不同机器上。

这和Kubernetes的默认调度习惯有关。默认的打分策略叫LeastAllocated，谁最空闲就派活给谁，好处是每台机器都留有余量，代价就是负载被均匀摊薄，谁也攒不出一块完整的空闲资源。AWS这次展示的MostAllocated策略正好反过来：新Pod优先往已经用得比较满的节点上堆，把整机的连续容量留出来。对按小时计费的云服务器，这直接等于省钱，腾空的节点可以缩掉；对整台租下的香港独立服务器，租金省不了，但给大内存应用、突发业务和后续扩容留出了连续空间。

有两个官方提醒别漏看。一是改打分策略只影响之后的调度决策，已经在跑的Pod不会自动搬家，想重新集中负载，得主动驱逐或滚动重启。二是堆得越密，代价越集中——一台机器出硬件故障，被波及的Pod就越多，独立服务器换盘换件动辄按小时算，这笔账要提前掂量。AWS自己也说得直白：在乎每个节点都留余量的业务，保持默认就好。自建集群想试，kube-scheduler配置文件里的NodeResourcesFit打分策略就是同一个开关；跑GPU推理的集群还可以给GPU资源设更高的打分权重，让申请显卡的Pod集中到已经部分占用的GPU节点上，别把每张卡都各占一台机器。

分组和requests，比调度策略更先决

调度策略只是最后一步，前面还有两件更基础的事。

一是节点别全混着用。实际部署时，比较稳的做法是按用途分组：Web和API走通用计算节点，MySQL、Redis这类有状态服务单独一组，跑推理的GPU机器自成一池，大内存的Java应用划到高内存节点，Ingress网关视规模独立部署。看起来限制了Kubernetes"随便调度"的自由度，换来的是容量规划能算得清。香港服务器本来就是资源独享，既然已经明确某几台承担数据库或核心业务，就没必要为了"云原生"的纯度，强行让所有负载完全随机漂移。

二是requests和limits要认真填。不少团队选香港服务器配置时反复比较CPU和内存，Pod的资源申报却随手一写，结果是硬件很强，调度器却不知道每个应用到底要多少资源——它只认申报的数字，不认实际用量。比较务实的做法是按监控数据定值并定期修正：一个平时只吃500MB内存的Web服务，不必因为机器有64GB就给它预留4GB；反过来，数据库、Java和部分AI应用有明显的内存峰值，也别为了把"表面利用率"做高而压得太紧。

扩容快慢与跨地域，两个容易想当然的地方

这次EKS更新还把HPA的同步周期开放到10至15秒可调（默认15秒），但只对使用Provisioned Control Plane的集群开放。更值得注意的是AWS文档里那句提醒：周期从15秒缩到10秒，控制平面能按时处理的HPA对象数量大约要少三分之一，超出之后不报警，症状恰恰是扩容变得更慢——和调快的初衷正好相反。换句话说，扩容灵敏度是拿控制面开销换的。电商大促、直播、游戏活动这类分钟级波动的业务，调快确实有价值；数据库、启动缓慢的Java服务如果扩缩得太灵敏，只会看到Pod反复地建了删、删了建。自建集群调HPA参数前，这个取舍同样成立。顺带一提，CI/CD、批处理这类事件量大的集群，把事件保留时长从默认的60分钟适当调短，也能减轻etcd的存储压力。

跨地域是另一个容易想当然的点。节点都在同一个香港机房时，节点间通信容易控制；但把香港、日本、新加坡、美国的服务器全塞进同一个集群，etcd心跳、容器网络、Service发现和跨境流量都会变成麻烦。对绝大多数生产环境，一个地域一个集群、上层用DNS和负载均衡做跨区调度，远比一个横跨几千公里的"大集群"稳当。SellBGP的香港服务器部署在香港数据中心、提供面向中国大陆及亚洲访问的优化网络，常见的用法也是承接大陆、香港及东南亚方向的业务，跨区需求交给架构层去解决。

最后说说什么业务值得上K8s。只有一两个WordPress站或企业官网，没必要为了架构而架构；业务由多个微服务组成、发版频繁、机器不止一两台、开发测试生产要统一管理、或者要跑GPU推理和大批量容器任务，Kubernetes的收益才盖得过它的复杂度。下次觉得"集群不够用"的时候，先打开监控看看各节点的真实利用率，再决定是加第五台机器，还是先把调度策略和requests理一遍——很多时候，后者要便宜得多。

参考信息： AWS于2026年8月12日宣布Amazon EKS支持高级Kubernetes控制平面配置，可调整调度器打分策略（LeastAllocated/MostAllocated及资源权重）、HPA同步周期（10–15秒，仅限Provisioned Control Plane集群）、事件保留时长（10–60分钟）及NodePort端口范围，支持Kubernetes 1.31及以上版本，已在所有提供EKS的AWS区域上线。