從k8s的1.8版本開始，kube-proxy引入了ipvs模式，ipvs模式與iptables同樣基於netfilter，但是ipvs採用的hash表，iptables採用一條條的規則列表。iptables又是為了防火牆設計的，集群數量越多iptables規則就越多，而iptables規則是從上到下匹配，所以效率就越是低下。因此當service數量達到一定規模時，hash查表的速度優勢就會顯現出來，從而提高service的服務效能
每個節點的kube-proxy負責監聽api server中service和endpoint的變化情況。將變化資訊寫入本地userspace、iptables、ipvs來實現service負載均衡，使用nat將vip流量轉至endpoint中。由於userspace模式因為可靠性和效能（頻繁切換核心/使用者空間）早已經淘汰，所有的客戶端請求svc，先經過iptables，然後再經過kube-proxy到pod，所以效能很差。
ipvs和iptables都是基於netfilter的，兩者差別如下：
一、iptables模式
在這種模式下，kube-proxy監視api server中service和endpoint的變化情況。對於每個service，它都生成相應的iptables規則，這些規則捕獲到service的clusterip和port的流量，並將這些流量隨機重定向到service後端pod。對於每個endpoint物件，它生成選擇後端pod的iptables規則。
如果選擇的第乙個pod沒有響應，kube-proxy將檢測到到第乙個pod的連線失敗，並將自動重試另乙個後端pod。
拓撲圖：
缺點：iptables 因為它純粹是為防火牆而設計的，並且基於核心規則列表，集群數量越多效能越差。
乙個例子是，在5000節點集群中使用 nodeport 服務，如果我們有2000個服務並且每個服務有10個 pod，這將在每個工作節點上至少產生20000個 iptable 記錄，這可能使核心非常繁忙。
二、ipvs模式（nat模式）
在這種模式下，kube-proxy監聽api server中service和endpoint的變化情況，呼叫netlink介面建立相應的ipvs規則，並定期將ipvs規則與kubernetes服 services和endpoints同步。保證ipvs狀態。當訪問services時，ipvs將流量定向到後端pod之一。
ipvs**模式基於netfilter hook函式，該函式類似於iptables模式，但使用hash表作為底層資料結構，在核心空間中工作。這意味著ipvs模式下的kube-proxy使用更低的重定向流量。其同步規則的效率和網路吞吐量也更高。
拓撲圖：
說明：ipvs依賴iptables進行包過濾、snat、masquared(偽裝)。 使用 ipset 來儲存需要 drop 或 masquared 的流量的源或目標位址，以確保 iptables 規則的數量是恆定的，這樣我們就不需要關心我們有多少服務了
如果沒有載入並啟用ipvs模組，或者沒有配置ipvs相關配置，則會被降級成iptables模式。
K8s部署prometheus監控K8s細節
prometheus 一些配置檔案可以再github上找到。部署 root kube prometheus manifests 目錄下所有檔案 部署 root kube prometheus manifests setup 目錄下所有檔案 要注意的是自己要建立乙個工作空間 如果報錯執行下面語句 部署...
k8s 多租戶 k8s 基礎介紹
備註 1 每乙個pod裡執行著乙個特殊的容器 pause容器，其他容器都是業務容器，這些業務容器共享pause容器的網路棧和volume 邏輯卷 掛載卷。因此他們之間的通訊和資料交換更為高效。2 k8s設計了pod物件，將每個服務程序包裝到相應的pod中，使其成為pod中執行的乙個容器 contai...
k8s排程 原理 K8s排程原理和Pod生命週期
1 k8s排程原理 pod只存在某乙個物理節點上，可以執行多個container 2 pod的生命週期 暫停pod，可以暫停deployment kubectl get depolyment kubectl scale replicas 0 deployment 刪除pod。刪除之後，狀態變成suc...