我们正在从独立的docker容器架构转向K3 s架构。当前的架构使用Nginx容器来公开多个uwsgi和WebSocket服务（对于django），这些服务在不同的容器中运行。我在互联网上阅读了关于应该使用什么方法的冲突意见。
选项包括：
- LoadBalancer类型的Nginx服务（可以重用现有架构中的大多数配置）
- Nginx-ingress（必须将现有体系结构中的所有配置转换为入口注解和ConfigMap）
- Nginx-ingress +类型为ClusterIP的nginx服务（现有架构中的大多数配置都可以重用，进入ingress的流量将被简单地路由到nginx服务）
2条答案
按热度按时间sh7euo9m1#
在非常类似的情况下，我们使用了选项3。
从网络的Angular 来看，这可能是次优的，但它给了我们一个更平滑的过渡路径。它也给了我们时间来看看入口之后可以处理什么。
对各种nginx配置的支持会随Ingress实现的不同而不同，并且是特定于这个Ingress实现的（一个通用的Ingress只处理基于主机或路径的HTTP路由）。所以我不会建议选择2，除非你已经确定你的Ingress可以处理它（并且你不想切换到另一个Ingress）。
关于选项1（LoadBalancer，或者甚至NodePort），它可能也会工作，但是当使用http（s）时，Ingress是一个更好的选择。
jq6vz3qz2#
我对这3个选项的看法是：
1.你可以保持现有的配置，但是你需要从你的网络中分配一个IP给你想要公开的每个服务。在裸机中，你需要使用一个额外的服务，比如Metallb。
1.这也是一种选择，但如果您想回滚之前的配置，这就不灵活了，就像您要调整解决方案以适应Kubernetes架构一样。
1.我认为这是最好的选择，你维护你的nginx+wsgi来与你的Django应用程序对话，并使用Nginx入口来集中你的服务的暴露，应用SSL，域名等。