基于AWS与Kubernetes的Web应用架构选型问题咨询

• 该方案完全不属于信息展示类Web应用的最佳实践，仅适合有强租户隔离要求的专有SaaS实例场景，普通多用户信息展示平台用这个方案会带来极高的资源浪费和运维成本。
• 按用户粒度分配Pod会导致资源利用率极低：用户闲置时段对应Pod占用的CPU、内存资源完全无法复用，K8s单集群的Pod承载量有明确上限，用户规模增长到一定量级后集群会首先遇到调度瓶颈，根本跑不动太多用户。
• 全应用打包进单个Pod会完全丧失云原生架构的优势：任何一个组件迭代都需要重新构建全量镜像、重启整个Pod，无法单独扩缩容瓶颈模块，比如后端接口压力大时只能连前端、认证模块一起扩容，资源浪费会进一步加剧。
• 这类场景的标准最佳实践是按组件拆分独立的无状态Deployment：前端、认证、数据访问、后端逻辑各拆分为独立服务，多用户共享服务副本，通过HPA根据CPU、内存或请求QPS动态调整副本数，资源利用率比单用户Pod架构高10倍以上，迭代和运维成本也低得多。

• 该认知是错误的，你仍然需要根据场景使用对应存储服务，核心原因是ECR仅用于存储容器镜像，无法满足应用运行时的各类持久化、共享存储需求：
  • 容器镜像本身是只读的，运行时的可写层是临时存储，Pod销毁或重启后可写层的所有数据会直接丢失，需要持久化存储的用户配置、操作日志、业务数据都不可能存在镜像或容器本地。
  • 前端静态资源（js、css、图片、静态页面）放在S3中配合CDN加速，访问效率远高于从Pod本地读取，更新静态资源也不需要重新构建镜像、重新发布Pod，迭代效率高很多。
  • 如果你需要在K8s中部署有状态服务（比如数据库、消息队列），必须通过PV/PVC绑定EBS做持久化存储，否则服务重启后数据会全部丢失。如果有跨Pod的共享文件访问需求，就需要用到EFS。
• 就算你坚持使用单用户Pod的架构，用户的个性化数据、缓存资源也不可能全部打包到镜像里，还是需要对接外部存储服务。

如果你的AWS和K8s经验不多，完全可以选择更轻量化的成熟架构：前端资源放S3+CloudFront CDN，后端无状态服务托管在EKS，数据库用托管的RDS，缓存用ElastiCache，整套架构的运维复杂度、资源成本都比你当前设想的方案低很多，可用性也更有保障。

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