拓?fù)涓兄酚桑═oplogy Aware Routing）調(diào)整路由行為，以優(yōu)先保持流量在其發(fā)起區(qū)域內(nèi)。 這種方式在某些情況下有助于降低成本或提高網(wǎng)絡(luò)性能。拓?fù)涓兄酚墒?Kubernetes 中用于確定 Pod 之間最優(yōu)路徑的機(jī)制。通過使用節(jié)點(diǎn)和區(qū)域信息，將流量保留在同一個區(qū)域中，可以實(shí)現(xiàn)更好的網(wǎng)絡(luò)性能和更低的成本。這對那些需要處理大量網(wǎng)絡(luò)流量的場景尤為重要。

拓?fù)涓兄酚蛇€可以提供更好的容錯能力。如果一個區(qū)域的節(jié)點(diǎn)宕機(jī)，可以輕松地將流量切換到另一個區(qū)域中的節(jié)點(diǎn)上，從而確保服務(wù)的連續(xù)性和穩(wěn)定性。

一、動機(jī)

Kubernetes 集群越來越多地部署在多區(qū)域環(huán)境中。 拓?fù)涓兄酚?提供了一種機(jī)制幫助流量保留在其發(fā)起所在的區(qū)域內(nèi)。 計(jì)算 服務(wù)（Service） 的端點(diǎn)時， EndpointSlice 控制器考慮每個端點(diǎn)的物理拓?fù)洌ǖ貐^(qū)和區(qū)域），并填充提示字段以將其分配到區(qū)域。 諸如 kube-proxy 等集群組件可以使用這些提示，影響流量的路由方式（優(yōu)先考慮物理拓?fù)渖细亩它c(diǎn)）。

二、啟用拓?fù)涓兄酚?/h2>

在 Kubernetes 1.27 之前，此行為是通過 service.kubernetes.io/topology-aware-hints 注解來控制的。

可以通過將 service.kubernetes.io/topology-mode 注解設(shè)置為 Auto 來啟用 Service 的拓?fù)涓兄酚伞?當(dāng)每個區(qū)域中有足夠的端點(diǎn)可用時，系統(tǒng)將為 EndpointSlices 填充拓?fù)涮崾?，把每個端點(diǎn)分配給特定區(qū)域， 從而使流量被路由到更接近其來源的位置。

三、效果最佳時間

此特性在以下場景中的工作效果最佳：

1、 入站流量均勻分布

如果大部分流量源自同一個區(qū)域，則該流量可能會使分配到該區(qū)域的端點(diǎn)子集過載。 當(dāng)預(yù)計(jì)入站流量源自同一區(qū)域時，不建議使用此特性。

2、 服務(wù)在每個區(qū)域具有至少 3 個端點(diǎn)

在一個三區(qū)域的集群中，這意味著有至少 9 個端點(diǎn)。如果每個區(qū)域的端點(diǎn)少于 3 個， 則 EndpointSlice 控制器很大概率（約 50％）無法平均分配端點(diǎn)，而是回退到默認(rèn)的集群范圍的路由方法。

四、工作原理

“自動”啟發(fā)式算法會嘗試按比例分配一定數(shù)量的端點(diǎn)到每個區(qū)域。 請注意，這種啟發(fā)方式對具有大量端點(diǎn)的 Service 效果最佳。

1、EndpointSlice控制器

當(dāng)啟用此啟發(fā)方式時，EndpointSlice 控制器負(fù)責(zé)在各個 EndpointSlice 上設(shè)置提示信息。 控制器按比例給每個區(qū)域分配一定比例數(shù)量的端點(diǎn)。 這個比例基于在該區(qū)域中運(yùn)行的節(jié)點(diǎn)的可分配 CPU 核心數(shù)。例如，如果一個區(qū)域有 2 個 CPU 核心，而另一個區(qū)域只有 1 個 CPU 核心， 那么控制器將給那個有 2 CPU 的區(qū)域分配兩倍數(shù)量的端點(diǎn)。

以下示例展示了提供提示信息后 EndpointSlice 的樣子：

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: example-hints
labels:
kubernetes.io/service-name: example-svc
addressType: IPv4
ports:
- name: http
protocol: TCP
port: 80
endpoints:
- addresses:
- "10.1.2.3"
conditions:
ready: true
hostname: pod-1
zone: zone-a
hints:
forZones:
- name: "zone-a"

2、kube-proxy

kube-proxy 組件依據(jù) EndpointSlice 控制器設(shè)置的提示，過濾由它負(fù)責(zé)路由的端點(diǎn)。 在大多數(shù)場合，這意味著 kube-proxy 可以把流量路由到同一個區(qū)域的端點(diǎn)。 有時，控制器在另一不同的區(qū)域中分配端點(diǎn)，以確保在多個區(qū)域之間更平均地分配端點(diǎn)。 這會導(dǎo)致部分流量被路由到其他區(qū)域。

五、保護(hù)措施

Kubernetes 控制平面和每個節(jié)點(diǎn)上的 kube-proxy 在使用拓?fù)涓兄崾拘畔⑶埃瑫?yīng)用一些保護(hù)措施規(guī)則。 如果規(guī)則無法順利通過，kube-proxy 將無視區(qū)域限制，從集群中的任意位置選擇端點(diǎn)。

1、端點(diǎn)數(shù)量不足： 如果一個集群中，端點(diǎn)數(shù)量少于區(qū)域數(shù)量，控制器不創(chuàng)建任何提示。

2、不可能實(shí)現(xiàn)均衡分配： 在一些場合中，不可能實(shí)現(xiàn)端點(diǎn)在區(qū)域中的平衡分配。 例如，假設(shè) zone-a 比 zone-b 大兩倍，但只有 2 個端點(diǎn)， 那分配到 zone-a 的端點(diǎn)可能收到比 zone-b 多兩倍的流量。 如果控制器不能確保此“期望的過載”值低于每一個區(qū)域可接受的閾值，控制器將不添加提示信息。 重要的是，這不是基于實(shí)時反饋。所以對于特定的端點(diǎn)仍有可能超載。

3、一個或多個 Node 信息不足： 如果任一節(jié)點(diǎn)沒有設(shè)置標(biāo)簽 topology.kubernetes.io/zone， 或沒有上報(bào)可分配的 CPU 數(shù)據(jù)，控制平面將不會設(shè)置任何拓?fù)涓兄崾荆?進(jìn)而 kube-proxy 也就不能根據(jù)區(qū)域來過濾端點(diǎn)。

4、至少一個端點(diǎn)沒有設(shè)置區(qū)域提示： 當(dāng)這種情況發(fā)生時， kube-proxy 會假設(shè)從拓?fù)涓兄崾镜酵負(fù)涓兄酚桑ɑ蚍捶较颍┑倪w移仍在進(jìn)行中， 在這種場合下過濾 Service 的端點(diǎn)是有風(fēng)險(xiǎn)的，所以 kube-proxy 回退到使用所有端點(diǎn)。

5、提示中不存在某區(qū)域： 如果 kube-proxy 無法找到提示中指向它當(dāng)前所在的區(qū)域的端點(diǎn)， 它將回退到使用來自所有區(qū)域的端點(diǎn)。當(dāng)向現(xiàn)有集群新增新的區(qū)域時，這種情況發(fā)生概率很高。

六、限制

1、當(dāng) Service 的 internalTrafficPolicy 值設(shè)置為 Local 時， 系統(tǒng)將不使用拓?fù)涓兄崾拘畔?。可以在同一集群中的不?Service 上使用這兩個特性， 但不能在同一個 Service 上這么做。

2、這種方法不適用于大部分流量來自于一部分區(qū)域的 Service。 相反，這項(xiàng)技術(shù)的假設(shè)是入站流量與各區(qū)域中節(jié)點(diǎn)的服務(wù)能力成比例關(guān)系。

3、EndpointSlice 控制器在計(jì)算各區(qū)域的比例時，會忽略未就緒的節(jié)點(diǎn)。 在大部分節(jié)點(diǎn)未就緒的場景下，這樣做會帶來非預(yù)期的結(jié)果。

4、EndpointSlice 控制器忽略設(shè)置了 node-role.kubernetes.io/control-plane 或 node-role.kubernetes.io/master 標(biāo)簽的節(jié)點(diǎn)。如果工作負(fù)載也在這些節(jié)點(diǎn)上運(yùn)行，也可能會產(chǎn)生問題。

5、EndpointSlice 控制器在分派或計(jì)算各區(qū)域的比例時，并不會考慮 容忍度。 如果 Service 背后的各 Pod 被限制只能運(yùn)行在集群節(jié)點(diǎn)的一個子集上，計(jì)算比例時不會考慮這點(diǎn)。

6、這項(xiàng)技術(shù)和自動擴(kuò)縮容機(jī)制之間可能存在沖突。例如，如果大量流量來源于同一個區(qū)域， 那只有分配到該區(qū)域的端點(diǎn)才可用來處理流量。這會導(dǎo)致 Pod 自動水平擴(kuò)縮容 要么不能處理這種場景，要么會在別的區(qū)域添加 Pod。

七、自定義啟發(fā)方式

Kubernetes 提供了多種部署方式，但沒有一種啟發(fā)式方法可以適用于所有場景來按區(qū)域分配端點(diǎn)。因此，Kubernetes 引入了自定義啟發(fā)式方法的能力，以滿足不同使用場景的需求。該特性的關(guān)鍵目標(biāo)是允許用戶在無法滿足其需求的情況下開發(fā)自定義的啟發(fā)式方法。

在 Kubernetes 1.27 版本中，已經(jīng)實(shí)現(xiàn)了啟用自定義啟發(fā)式方法的第一步。這是一個相對受限的實(shí)現(xiàn)，可能尚未涵蓋一些重要的、可進(jìn)一步探索的場景。然而，這為用戶提供了一個開始定制化路由行為的平臺，并為未來的改進(jìn)和探索鋪平了道路。