如何将nginx与Kubernetes（GKE）和Google HTTPS负载均衡器配合使用

Question

我们利用Ingress创建HTTPS负载均衡器，直接转发到我们的（通常是nodejs）服务。但是，最近我们希望在Google负载均衡器无法提供的nodejs前面更多地控制流量。

• 标准化的自定义错误页面
• 标准重写规则（例如将http重定向到https）
• 将pod readyinessProbes从负载均衡器运行状况检查中解耦（因此，当没有健康的pod时，我们仍然可以提供自定义错误页面。）

我们在堆栈的其他部分使用nginx，所以这似乎是一个不错的选择，我已经看到了几个nginx用于Kubernetes前端服务的例子，通常是两种配置中的一种。

• 每个pod中的nginx容器直接将流量转发到localhost上的应用程序。
• 单独的nginx部署＆amp;服务，独立扩展并将流量转发到适当的Kubernetes服务。

每种方法的优缺点是什么？如何确定哪种方法最适合我们的用例？

Answer 1

继Vincent H之后，我建议将Google HTTPS Load Balancer流水线化为nginx入口控制器。

正如您所提到的，这可以独立扩展;有它自己的健康检查;并且您可以标准化您的错误页面。

我们通过拥有一个kubernetes.io/ingress.class: "gce"入口对象来实现这一目标，该对象具有我们的nginx入口控制器的默认后端。我们所有其他入口对象都使用kubernetes.io/ingress.class: "nginx"进行注释。

我们正在使用此处记录的控制器：https://github.com/kubernetes/ingress/tree/master/controllers/nginx。使用custom /etc/nginx/template/nginx.tmpl可以完全控制入口。

  

为了完全透明，我们尚未在nginx控制器中设置自定义错误页面，但documentation显示为直接。

Answer 2

列出的要求之一是您要将pod readyinessProbe解耦，以便您可以提供自定义错误页面。如果你要为每个pod添加一个nginx容器，这是不可能的。然后，当pod中的一个容器无法粘附到活动/准备就绪探针时，将重新启动pod。就个人而言，我也更喜欢尽可能地分离，以便你可以扩展独立的pod，如果需要的话，分配自定义的机器类型，并且通过仅启动你真正需要的nginx实例（主要是内存）来节省一些资源。