Kubernetes - 帶有負載均衡器的 Ingress 與 Nginx

AFAIK 入口只是針對 Nginx（或其他）的 LoadBalancer 服務的抽象層

是否有隻有入口才能提供的功能？使用 LoadBalancer + Nginx 有什麼缺點嗎？

AFAIK 入口只是針對 Nginx（或其他）的 LoadBalancer 服務的抽象層

這只是部分正確；如果您願意，您可以直接從節點上使用hostNetworking: true和公開 Ingress 控制器，跳過 SDN 和對負載均衡器的需求（儘管缺點是將節點的埠直接暴露給 Internet）——並且大致相同帶有額外埠愚蠢Service的想法type: NodePort

很多人確實在 LoadBalancer 後面使用 Ingress 控制器來將節點與 Internet 隔離，但這不是必需的

人們還應該知道ALB 入口控制器，它採用另一種方​​式：要求 LBhost:在到達集群之前執行 URI 路由，並且集群中沒有（？）nginx 組件執行

是否有隻有入口才能提供的功能？

只有？不太可能。方便和雲便攜？極其

我不確定這是否是您要問的，但大多數人使用單個 LB 和集群內 Ingress 控制器的原因是只需為一個具有幾乎無限 Ingress 資源的 LB 支付大量成本。如果沒有 Ingress，則需要使用Service，type: LoadBalaner然後等待 kubernetes 為每個 Service 提供一個新的 LB，耗費時間和金錢

使用 LoadBalancer + Nginx 有什麼缺點嗎？

主要圍繞錯誤和成本管理：

• 從 LB 到集群內 httpd 會有一個額外的網路躍點
• 大多數 LB 都有自己的健康檢查方案，並且 LB 可以獨立於入口控制器的健康檢查失敗，從而導致人為中斷

這也適用於路由問題、權限、雲配額，所有這些爵士樂

• 可能有兩種不同的安全機制：LB 和入口控制器，如果它們不對齊，可能會導致中斷
• 如果打開了訪問日誌，它將記錄兩次，一次在 LB，一次在入口
• 需要知道集群內路由正在進行這一事實，否則將不明顯為什麼一切都只使用一個 LB

引用自：https://serverfault.com/questions/1015655