Kube-Proxy 可以說是 Kubernetes 叢集中的網路流量指揮家。它的主要工作是管理 Service 的網路規則，確保流量能夠正確地從 Service 轉發到對應的 Pod。但它到底是怎麼運作的呢？讓我們一起來看看。

首先，Kube-Proxy 會在每個節點上運行，監聽 Kubernetes API Server 的變化。當有新的 Service 被創建或現有的 Service 被修改時，Kube-Proxy 就會更新該節點上的網路規則。

Kube-Proxy 主要有三種運行模式：

• Userspace模式：
  這是最早的模式，Kube-Proxy會在用戶空間監聽一個端口，收到Service請求後，再轉發給後端Pod。由於需要在用戶空間和內核空間來回轉換，效率較低，現在已很少使用。
• iptables模式：
  曾經的默認模式。Kube-Proxy監聽API Server，並在本地生成iptables規則，通過Linux內核直接轉發流量，無需在用戶空間做數據拷貝，大幅提高效率。
• IPVS模式：
  為了解決iptables規則過多導致的性能問題，Kubernetes 1.11引入了IPVS模式。IPVS使用哈希表管理網路流量，尤其在大規模集群中提供更佳的性能和擴展性。

為什麼需要Kube-Proxy？

你可能會問，為什麼需要Kube-Proxy？直接讓Pod互相通信不行嗎？

這是個好問題！實際上，Kube-Proxy的存在主要是為了實現Service這個抽象。Service為一組Pod提供穩定的網路端點，即使Pod的IP變化，Service的IP保持不變。Kube-Proxy負責維護Service到Pod的映射關係。

假設你有個前端應用需要訪問後端資料庫。你可以創建一個名為“db”的Service，前端只需要訪問“db”這個固定名稱，而不用關心後端Pod的具體IP。當數據庫Pod發生變化時，Kube-Proxy會自動更新轉發規則，保證“db”始終指向可用的Pod。

Kube-Proxy的局限性

Kube-Proxy雖然強大，但也有其局限性。比如，它只能做簡單的負載均衡，不支持高級路由功能。對於更複雜的需求，你可能需要考慮使用Ingress Controller或Service Mesh。

今天就先介紹到這裡，各位明天見~