如何將nginx與Kubernetes（GKE）和Google HTTPS負載均衡器配合使用

Question

我們利用Ingress創建HTTPS負載均衡器，直接轉發到我們的（通常是nodejs）服務。 但是，最近我們希望在Google負載均衡器不提供的nodejs前面更多地控制流量。

• 標准化的自定義錯誤頁面
• 標准重寫規則（例如，將http重定向到https）
• 從負載均衡器運行狀況檢查中分離pod readyinessProbes（因此，當沒有健康的pod時，我們仍然可以提供自定義錯誤頁面）。

我們在堆棧的其他部分使用nginx，所以這似乎是一個不錯的選擇，我已經看到了幾個nginx用於Kubernetes前端服務的例子，通常是兩種配置中的一種。

• 每個pod中的nginx容器將流量直接轉發到localhost上的應用程序。
• 一個單獨的nginx部署和服務，獨立擴展並將流量轉發到適當的Kubernetes服務。

每種方法的優缺點是什么？如何確定哪種方法最適合我們的用例？

Answer 1

繼Vincent H之后，我建議將Google HTTPS Load Balancer流水線化為nginx入口控制器。

正如您所提到的，這可以獨立擴展; 有它自己的健康檢查; 並且您可以標准化您的錯誤頁面。

我們通過使用單個kubernetes.io/ingress.class: "gce"入口對象來實現這一目標，該對象具有我們的nginx入口控制器的默認后端。 我們所有其他入口對象都使用kubernetes.io/ingress.class: "nginx"注釋kubernetes.io/ingress.class: "nginx" 。

我們使用此處記錄的控制器： https ： //github.com/kubernetes/ingress/tree/master/controllers/nginx 。 使用自定義/etc/nginx/template/nginx.tmpl可以完全控制入口。

為了完全透明，我們還沒有（還）在nginx控制器中設置自定義錯誤頁面，但是文檔顯得很直接。

Answer 2

列出的要求之一是您要分離pod readyinessProbes，以便您可以提供自定義錯誤頁面。 如果要向每個pod添加nginx容器，則無法進行此操作。 然后，當pod中的一個容器無法粘附到活動/准備就緒探針時，將重新啟動pod。 我個人也更喜歡盡可能地分離，這樣你就可以擴展獨立的pod，如果需要的話可以分配自定義的機器類型，並且它只通過啟動你真正需要的nginx實例（主要是內存）來節省一些資源。