Kubernetes 中的服務到服務通信

Question

我已經在 EKS 上部署了我的 Kubernetes 集群。 我有一個通過負載均衡器公開的 ingress-nginx，用於將流量路由到不同的服務。 在 ingress-nginx 中，第一個請求轉到 auth 服務進行身份驗證，如果它是有效請求，那么我允許它繼續前進。 假設請求在服務 1 中，現在從那里，它想與服務 2 通信。因此，如果我想以某種方式將我對 go 的請求直接發送到入口，而不是通過負載均衡器，然后從入口到服務 2。

1. 有可能這樣做嗎？
2. 當我繞過負載均衡器時，它是否有助於提高性能？
3. 由於請求沒有通過負載均衡器，所以負載均衡不會發生，這是一個嚴重的問題嗎？

Answer 1

1/ 是否可能：簡短的回答，不。

在某些極端情況下，需要有人首先創建另一個 Ingress object 來暴露 Service2。 然后，您可以欺騙 Ingress 將您路由到某些可能無法訪問的服務（如果 DNS 不存在，則某些 VIP 尚未公開，...）

繞過 ELB 的外部客戶端沒有真正的問題，只要它們不能加入您節點上的所有端口，只有那些由您的入口 controller 綁定的端口。

2/繞過負載均衡器：在性能方面不會有太大變化。

但是，如果我們談論的是 TCP 負載均衡器，那么將其移除將有助於跟蹤真實的客戶端 IP。 弄清楚如何為 HTTP 負載均衡器更改它可能會更好——盡管並不總是那么容易。

3/ 移除 LoadBalancer：如果您有多個節點托管您的增量 controller 的副本，那么您仍然可以進行某種基於 DNS 的負載平衡。 雖然可以肯定的是，這與擁有真正的 LB 不同。

在 AWS 中，您可以找到一個中間立場，設置基於健康檢查的 Route53 記錄：為每個托管入口 controller 的節點設置一個，創建另一個重新組合所有健康入口節點，然后更改現有入口 FQDN 記錄，以便它們都指向您的新 route53 名稱。 您將能夠對 EC2 實例 IP 進行 TCP/HTTP 檢查，這通常已經足夠了。 但同樣：DNS 負載平衡可能會受到過時的瀏覽器緩存、一些 ISP 不刷新區域的影響，...... LB 是真實的。