Kubernetes中MySQL Router部署方案选型（Sidecar/独立Deployment）及扩缩容疑问

一、Sidecar方式部署是否可行？ #

完全可以，但得权衡清楚利弊再决定：

• 好处：
  • 应用Pod直接本地访问Router，没有集群Service转发的额外延迟，性能最优
  • 不用操心跨命名空间的Service访问权限问题，每个应用Pod自带的Router只服务自己，配置简单
  • 单个Router故障只会影响对应的应用Pod，不会波及整个集群的应用
• 缺点：
  • 资源浪费严重：应用Pod有多少个，Router实例就有多少个，额外占用CPU、内存，尤其是应用频繁扩容时，资源开销会很可观
  • 维护麻烦：要升级Router版本或调整配置，得把所有应用的Deployment都重新部署一遍，没法统一操作
  • 日志、监控分散：每个Router的日志都跟着应用Pod走，排查问题时要在一堆应用日志里找Router的记录，很费劲

二、独立Deployment部署是不是更好的选择？ #

这才是生产环境更推荐的方案，优势很明显：

• 资源利用率高：Router实例可以按需扩容，不用和应用Pod一一绑定，比如10个应用Pod配2个Router实例就够，大大节省集群资源
• 维护成本低：Router的版本更新、配置调整只需要操作自己的Deployment，不会影响正在运行的应用
• 监控运维更方便：所有Router的日志、监控指标都集中在一起，容易做统一的告警和排查

当然也有小缺点：应用访问Router要走K8s Service的转发，延迟比Sidecar略高，但在绝大多数业务场景下，这点延迟完全可以忽略；另外如果应用在不同命名空间，得确保每个命名空间都能访问Router的Service，不过这在K8s里配置起来也不难。

三、独立部署时，应用扩容了Router怎么扛住请求增长？ #

有几种实用的应对方式：

• 用HPA自动扩缩容：给Router的Deployment配置水平Pod自动扩缩容规则，比如基于CPU使用率（超过70%扩容，低于30%缩容），或者自定义的QPS指标，让K8s自动根据请求负载调整Router实例数
• 按比例同步扩容：如果你的应用扩容节奏比较固定，比如每次扩5个应用Pod，就同步加1个Router实例，可以把这个逻辑写到CI/CD脚本里，自动执行
• 优化负载均衡策略：把Router的Service配置成最少连接数的负载均衡模式，让请求更均匀地分配到各个Router实例上，避免单个实例被压爆
• 调整连接池参数：一方面在应用侧设置合理的数据库连接池大小，避免短时间内创建大量连接；另一方面调整Router自身的连接池配置，提升并发处理能力

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