本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
使用 EndpointSlice 擴展 Kubernetes 網路
EndpointSlices 是一個令人興奮的新 API，它為 Endpoints API 提供了一個可擴展且可延伸的替代方案。EndpointSlices 追蹤支援 Service 的 Pod 的 IP 位址、連接埠、就緒狀態和拓撲資訊。
在 Kubernetes 1.19 中，此功能預設為啟用，kube-proxy 從 EndpointSlices 而非 Endpoints 讀取。雖然這大部分將是一個不可見的變更，但它應該會在大型叢集中帶來顯著的擴充性改進。它還為未來 Kubernetes 版本中的重要新功能（如拓撲感知路由）奠定了基礎。
Endpoints API 的擴充性限制
使用 Endpoints API，一個 Service 只有一個 Endpoints 資源。這表示它需要能夠儲存支援對應 Service 的每個 Pod 的 IP 位址和連接埠（網路端點）。這導致了龐大的 API 資源。更糟糕的是，kube-proxy 在每個節點上執行，並監看 Endpoints 資源的任何更新。如果 Endpoints 資源中即使只有一個網路端點發生變更，也必須將整個物件傳送給每個 kube-proxy 執行個體。
Endpoints API 的另一個限制是它限制了可以為 Service 追蹤的網路端點數量。儲存在 etcd 中的物件的預設大小限制為 1.5MB。在某些情況下，這可能會將 Endpoints 資源限制為 5,000 個 Pod IP。對於大多數使用者來說，這不是問題，但對於使用接近此大小的 Service 的使用者來說，這會成為一個嚴重的問題。
為了展示這些問題在規模擴大時變得有多麼嚴重，一個簡單的範例會很有幫助。想像一個具有 5,000 個 Pod 的 Service，它最終可能會產生一個 1.5MB 的 Endpoints 資源。如果該清單中即使只有一個網路端點發生變更，也需要將完整的 Endpoints 資源分發到叢集中的每個節點。這在具有 3,000 個節點的大型叢集中會成為一個相當大的問題。每次更新都將涉及在叢集中傳送 4.5GB 的資料 (1.5MB Endpoints * 3,000 個節點)。這幾乎足以填滿一張 DVD，而且每次 Endpoints 變更都會發生這種情況。想像一下，一個滾動更新導致所有 5,000 個 Pod 被替換 - 這將傳輸超過 22TB（或 5,000 張 DVD）的資料。
使用 EndpointSlice API 分割端點
EndpointSlice API 的設計目的是透過類似於分片的策略來解決此問題。我們沒有使用單個 Endpoints 資源追蹤 Service 的所有 Pod IP，而是將它們分割成多個較小的 EndpointSlice。
考慮一個 Service 由 15 個 Pod 支援的範例。我們最終會得到一個追蹤所有這些 Pod 的單個 Endpoints 資源。如果 EndpointSlices 配置為每個儲存 5 個端點，我們最終會得到 3 個不同的 EndpointSlice： 
預設情況下，EndpointSlices 每個最多儲存 100 個端點，儘管可以使用 kube-controller-manager 上的 --max-endpoints-per-slice 標誌來配置此數量。
EndpointSlices 提供 10 倍的擴充性改進
此 API 顯著提高了網路擴充性。現在，當新增或移除 Pod 時，只需要更新 1 個小型 EndpointSlice。當數百或數千個 Pod 支援單個 Service 時，這種差異變得非常明顯。
可能更重要的是，既然 Service 的所有 Pod IP 不需要儲存在單個資源中，我們就不必擔心儲存在 etcd 中的物件的大小限制。EndpointSlices 已被用於將 Service 擴展到超過 100,000 個網路端點。
所有這些都與 kube-proxy 中進行的一些重大效能改進結合在一起。大規模使用 EndpointSlices 時，端點更新傳輸的資料將顯著減少，並且 kube-proxy 應該可以更快地更新 iptables 或 ipvs 規則。除此之外，Service 現在可以擴展到至少比以前的限制高出 10 倍。
EndpointSlices 啟用新功能
EndpointSlices 作為 Kubernetes v1.16 中的 alpha 功能引入，旨在為未來 Kubernetes 版本中的一些令人興奮的新功能提供基礎。這可能包括雙堆疊 Service、拓撲感知路由和端點子集。
雙堆疊 Service 是一個令人興奮的新功能，它與 EndpointSlices 同步開發。它們將為 Service 使用 IPv4 和 IPv6 位址，並依賴 EndpointSlices 上的 addressType 欄位來依 IP 系列追蹤這些位址。
拓撲感知路由將更新 kube-proxy 以優先在相同區域或區域內路由請求。這利用了儲存在 EndpointSlice 中每個端點的拓撲欄位。作為進一步的改進，我們正在探索端點子集的潛力。這將允許 kube-proxy 僅監看 EndpointSlices 的子集。例如，這可以與拓撲感知路由結合使用，以便 kube-proxy 只需要監看包含相同區域內端點的 EndpointSlices。這將提供另一個非常顯著的擴充性改進。
這對 Endpoints API 意味著什麼？
雖然 EndpointSlice API 正在為 Endpoints API 提供更新、更具擴充性的替代方案，但 Endpoints API 將繼續被視為一般可用且穩定的。Endpoints API 計畫的最重大變更將涉及開始截斷否則會遇到擴充性問題的 Endpoints。
Endpoints API 不會消失，但許多新功能將依賴 EndpointSlice API。為了利用 EndpointSlices 提供的全新擴充性和功能，目前使用 Endpoints 的應用程式未來可能會想要考慮支援 EndpointSlices。