- Ingress → 透過
Ingress Controller（NGINX / Traefik）來實作 - 基於主機名（Host-based）的負載平衡：
- 基於 URL 路徑（Path-based）的負載平衡：
- 基於 Cookie 的負載平衡：
- 基於請求標頭（Header-based）的負載平衡：
Ingress Controller 可以根據 HTTP 請求的主機名來將流量路由到不同的 Service。例如，您可以配置 Ingress Controller 將來自
example.com 的請求轉發到 Service A，而將來自 example.org 的請求轉發到 Service B。Ingress Controller 可以根據 HTTP 請求的 URL 路徑來將流量路由到不同的 Service。例如，您可以配置 Ingress Controller 將以
/api 開頭的請求轉發到 Service A，而將以 /web 開頭的請求轉發到 Service B。Ingress Controller 可以根據 HTTP 請求的 Cookie 信息來將流量路由到不同的 Service。例如，您可以配置 Ingress Controller 將具有特定 Cookie 的請求轉發到 Service A，而將其他請求轉發到 Service B。
Ingress Controller 可以根據 HTTP 請求的標頭信息來將流量路由到不同的 Service。例如，您可以配置 Ingress Controller 將具有特定 User-Agent 的請求轉發到 Service A，而將其他請求轉發到 Service B。
- Service → 透過
Kube-proxy來實作 - 隨機（Random）：kube-proxy 可以在後端的 Pod 中隨機選擇一個，將請求轉發過去。這種方法簡單，但可能導致流量分布不均。
- Round-robin：kube-proxy 可以使用 round-robin 算法來選擇後端 Pod。這種方法會在每個請求到來時依次選擇下一個 Pod，從而確保流量在後端 Pod 之間均衡分配。
- 基於權重的負載平衡：根據實際需求，kube-proxy 也可以使用其他負載平衡算法，例如基於權重的負載平衡。在這種情況下，每個 Pod 的流量分配比例可以根據預先設定的權重來決定。
- 使用 Session Affinity：
- 使用 ExternalTrafficPolicy：
- 自定義負載平衡策略：
- 使用 Service Mesh：
Kubernetes Service 支持 Session Affinity，通常用於實現客戶端與特定 Pod 之間的持久連接。您可以通過設置
service.spec.sessionAffinity 為 ClientIP 來實現基於客戶端 IP 的 Session Affinity。這樣，來自同一客戶端 IP 的請求將始終被轉發到相同的 Pod。此外，您還可以通過 service.spec.sessionAffinityConfig 自定義 Session Affinity 的超時時間。如果您使用的是 LoadBalancer 或 NodePort 類型的 Service，可以通過設置
service.spec.externalTrafficPolicy 來調整負載平衡策略。設置為 Local 時，只有運行目標 Pod 的節點會接收到該流量，這有助於減少跨節點的流量並提高性能。設置為 Cluster 時（默認值），流量將在所有節點上負載平衡，但可能會導致多餘的跨節點流量。Kubernetes 本身並未提供直接設置負載平衡策略的選項，但您可以通過使用第三方 Ingress 控制器（如 NGINX、HAProxy 或 Traefik）來實現更高級的負載平衡策略。例如，基於權重的負載平衡、基於請求標頭的負載平衡等。您需要根據所選擇的 Ingress 控制器的文檔來配置相應的負載平衡策略。
您可以使用 Service Mesh（如 Istio、Linkerd 或 Kuma）來進一步自定義和管理負載平衡策略。Service Mesh 在應用層提供了更高級的流量管理功能，包括智能負載平衡、金絲雀部署、熔斷器等。您需要根據所選擇的 Service Mesh 的文檔來配置相應的負載平衡策略。