Kubernetes中两层架构Web应用应在哪些层级配置HPA？

绝大多数常规场景下仅需为前端WordPress层配置HPA即可，不要直接为后端MySQL层配置通用原生HPA，两层的扩缩容逻辑完全不同，不能一概而论。

前端WordPress层（必须配置HPA） #

• WordPress本身是无状态Web服务，直接承接用户侧访问流量，流量波动会第一时间反映在前端Pod的CPU/内存占用、请求QPS、请求响应延迟等指标上，完全适配HPA的水平扩缩逻辑：流量峰值时自动扩容Pod副本分摊压力，流量低谷时自动缩容副本节约资源。
• 你通过Helm Chart部署WordPress时，不需要单独手写HPA资源，直接在Chart的values配置中开启内置的HPA开关，配置好触发阈值（通常设置CPU使用率60%-70%、内存使用率70%作为扩容触发线）、最小/最大副本数即可生效。

后端MySQL层（禁止直接配置通用原生HPA） #

• MySQL是强一致性的有状态数据库服务，原生通用HPA的逻辑是直接新增Pod副本，不会自动配置主从复制关系、数据同步链路、读写请求路由，盲目给MySQL挂通用HPA不仅无法分担负载，还可能出现多副本同时写入持久化存储导致的数据损坏、服务不可用问题。
• 你使用Operator部署MySQL的场景下，数据库层的扩缩容必须依赖对应MySQL Operator的原生能力：如果你的MySQL集群已经部署为读写分离架构，Operator本身会提供配套的数据库专属扩缩容策略，在检测到读负载过高时自动新增只读节点、配置数据同步和读流量路由，这是经过数据库运维逻辑封装的扩缩能力，和无状态服务的通用HPA不是一回事；如果你的MySQL是单实例部署形态，本身不具备水平扩容能力，要扛数据库压力应该优先做慢查询优化、引入缓存层、架构升级为读写分离集群，而非直接扩Pod副本。

所有数据库、中间件类有状态服务的水平扩缩，都不能直接套用无状态Web服务的HPA配置逻辑，必须遵循对应组件的集群运维规则，否则极易引发数据一致性故障。

内容的提问来源于stack exchange，提问作者Mohamed