从Docker迁移至K3s：三种Nginx流量暴露方案选型咨询

我们正从独立Docker容器架构往K3s迁移，当前用Nginx容器暴露多个uWSGI和Django WebSocket服务，现在有三个可选方案，各有优劣，下面逐个拆解：

方案1：LoadBalancer类型的Nginx Service #

• 优势：能复用绝大多数现有Nginx配置，几乎不用改原有配置文件——直接把Nginx容器做成Deployment，再挂个LoadBalancer Service对外暴露就行，迁移速度极快。
• 劣势：没用到K8s原生的Ingress路由能力，后续要加新域名、改路径规则的话，得手动改Nginx配置再重启容器，运维起来特别麻烦；另外LoadBalancer Service依赖云厂商的负载均衡器或者本地的MetalLB这类组件，纯私有环境得额外部署；没法用Ingress生态里的统一流量管理、自动续证书这些便利功能。

方案2：Nginx-Ingress #

• 优势：完全贴合K8s原生玩法，所有路由规则、SSL配置、WebSocket支持都靠Ingress注解和ConfigMap来管，配置和应用解耦，适合长期在K3s环境运维；能直接集成Cert-Manager自动搞定HTTPS证书，多域名、路径匹配、重定向这些高级路由功能都支持；不用自己维护独立Nginx容器，Ingress Controller要么是K3s自带的，要么是官方维护的，稳定性有保障。
• 劣势：得把现有Nginx配置全转换成Ingress规则和注解，比如uWSGI的转发配置、WebSocket需要的头信息设置，都得对应到Ingress的配置里，迁移初期工作量不小；要是对Ingress配置语法不熟，很容易踩坑，尤其是WebSocket这种需要特殊配置的场景。

方案3：Nginx-Ingress + ClusterIP类型的Nginx Service #

• 优势：兼顾了现有配置复用和K8s生态能力——把原有Nginx容器部署成ClusterIP Service，流量先经过Nginx-Ingress统一入口，再转发到内部的Nginx Service，既不用大改原有Nginx配置，又能靠Ingress做统一的域名管理、SSL终止、流量分发；后续还能慢慢把部分路由规则迁到Ingress里，实现平滑过渡。
• 劣势：多了一层Nginx转发，理论上会有一点点性能损耗，但大部分业务场景完全可以忽略；得维护两套Nginx相关配置（Ingress的入口配置和内部Nginx的后端配置），初期运维复杂度稍高；要是以后完全转到Ingress规则，这个中间层就有点多余了。

选型建议 #

• 要是想最快完成迁移，而且短期内没什么复杂路由扩展需求，选方案1；
• 要是打算长期在K3s环境深耕，想标准化运维、用好K8s生态工具，选方案2；
• 要是想平衡迁移成本和长期灵活性，做平滑过渡，选方案3。

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