一、引言

       談到 kube-proxy，就不得不提到 k8s 中的 Service，下面就對二者的關係作簡單介紹：

• kube-proxy 其實就是管理 Service 的訪問入口，包括叢集內 Pod 到 Service 的訪問和叢集外訪問 Service；
• kube-proxy 管理 Service 的 Endpoints，該 Service 對外暴露一個 Virtual IP，也稱為 Cluster IP, 叢集內通過訪問這個  Cluster IP:Port 就能訪問到叢集內對應的 Serivce 下的 Pod；
• Service 是通過 Selector 選擇的一組 Pods 的服務抽象，其實就是一個微服務，提供了服務的 LB 和反向代理的能力，而 kube-proxy 的主要作用就是負責 Service 的實現；
• Service 一個重要作用就是，一個服務後端的 Pods 可能會隨著生存滅亡而發生 IP 的改變，Service 的出現，給服務提供了一個固定的 IP，而無視後端 Endpoint 的變化，而這種關聯的維護主要依賴 kube-proxy 實現；

二、kube-proxy 內部原理

       kube-proxy 當前實現了三種代理模式：userspace、iptables 以及 ipvs。

2.1  userspace 模式

       在這種模式下，kube-proxy 持續監聽 Service 以及 Endpoints 物件的變化；

       對每個 Service，它都為其在本地節點開放一個埠，作為其服務代理埠；

       發往該埠的請求會採用一定的策略轉發給與該服務對應的後端 Pod 實體。

       kube-proxy 同時會在本地節點設定 iptables 規則，配置一個 Virtual IP，

       把發往 Virtual IP 的請求重定向到與該 Virtual IP 對應的服務代理埠上。

       其工作流程大體如下：

       分析：該模式請求在到達 iptables 進行處理時就會進入核心，而 kube-proxy 監聽則是在使用者態，

                  請求就形成了從使用者態到核心態再返回到使用者態的傳遞過程，一定程度降低了服務效能。

2.2  iptables 模式

       與 userspace 相同，kube-proxy 持續監聽 Service 以及 Endpoints 物件的變化；

       但它並不在本地節點開啟反向代理服務，而是把反向代理全部交給 iptables 來實現；

       即 iptables 直接將對 VIP 的請求轉發給後端 Pod，通過 iptables 設定轉發策略。

       其工作流程大體如下：

       分析：該模式相比 userspace 模式，克服了請求在使用者態-核心態反覆傳遞的問題，效能上有所提升，

                  但使用 iptables NAT 來完成轉發，存在不可忽視的效能損耗，而且在大規模場景下，

                  iptables 規則的條目會十分巨大，效能上還要再打折扣。

2.3  ipvs 模式

       與 iptables、userspace 模式一樣，kube-proxy 依然監聽 Service 以及 Endpoints 物件的變化；

       不過它並不建立反向代理，也不建立大量的 iptables 規則；

       而是通過 netlink 建立 ipvs 規則，並使用 k8s Service 與 Endpoints 資訊，

       對所在節點的 ipvs 規則進行定期同步；

       netlink 與 iptables 底層都是基於 netfilter 鉤子，

       但是 netlink 由於採用了 hash table 而且直接工作在核心態，在效能上比 iptables 更優。

      分析：ipvs 是目前 kube-proxy 所支援的最新代理模式，

                相比使用 iptables，使用 ipvs 具有更高的效能。