系列文章:
總目錄索引：九析帶你輕鬆完爆 istio 服務網格系列教程
目錄
1 前言
2 邀約
3 節點調度
3.1 節點打標
3.2 編寫 pod
4 kiali 親和性調度
4.1 舉個例子
4.2 節點親和性調度（NodeAffinity）
4.3 kiali 節點親和性調度
1 前言
如果你對博客有任何疑問，請告訴我。
2 邀約
你可以從 b 站搜索 “九析”，獲取免費的、更生動的視頻資料：
3 節點調度
在開始 kiali 親和性調度之前，先演示一個簡單的例子介紹 pod 選擇調度到指定 node：
3.1 節點打標
使用命令查看當前所有 k8s 節點：
kubectl get nodes
命令截圖如下：
現在給 k8s-w-206 這個節點打上一個標籤，標籤內容爲 name: jiuxi，命令如下：
kubectl label node k8s-w-206 name=jiuxi
3.2 編寫 pod
編寫 pod 資源文件 jiuxi-pod.yaml，文件中使用 nodeSelector 指定該 pod 要調度到 k8s-w-206 節點之上：
apiVersion: v1
kind: Pod
metadata:
labels:
app: busybox
name: busybox
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: [ "/bin/sh", "-c", "sleep 3600" ]
nodeSelector:
name: jiuxi
部署 jiuxi-pod.yaml，發現 pod 果然被調度到了 k8s-w-206 這個 node，截圖如下：
4 kiali 親和性調度
上面舉例 pod 使用 nodeSelector 選擇 node，這就是最簡單的 k8s 調度方式。而 kiali 調度方式複雜一些，使用的是節點親和性調度策略，使用如下命令查看：
kubectl get deployments.apps kiali -n istio-system -o yaml
命令執行結果部分顯示如下：
4.1 舉個例子
舉一個生活的例子，以前去醫院看病，病人（pod）不能挑醫生（node），排隊叫到誰就是誰，冷冰冰完全沒有親和性而言；如今可以網上掛號了，病人也可以挑選中意的醫生，這樣就有了親和性，說明社會進步了。
當然病人在挑選醫生的過程中也會有兩種情況：一種是硬性（required），比如非要某醫生，即使他忙，也願意一直等下去；還有一種是軟性（prefered），比如優先選擇某醫生，但是如果真不行，其他醫生也未嘗不可。
4.2 節點親和性調度（NodeAffinity）
下面的理論可以對照上面的例子。
節點親和性，也就是 NodeAffinity，用來控制 pod 部署或者不能部署在哪臺機器上。
節點親和性調度策略分爲硬策略分爲軟策略和硬策略兩種方式。硬策略是如果沒有滿足條件的節點，就會不斷重試直到條件滿足了爲止；軟策略是如果沒有滿足條件的節點，pod 就會忽略這條規則，繼續完成調度過程。
節點親和性軟硬策略的語法分別介紹如下。
硬策略（關鍵字 require）：
requiredDuringSchedulingIgnoredDuringExecution：
pod 必須部署到滿足條件的節點上，如果節點不滿足條件，就不停重試。IgnoreDuringExecution 表示 pod 部署成功後，如果節點標籤發生了變化，不再滿足 pod 指定的條件，pod 仍會在此節點繼續運行
軟策略（關鍵字 prefer）：
preferredDuringSchedulingIgnoredDuringExecution：
pod 優先部署到滿足條件的節點，如果節點不滿足條件，就忽略這些條件，調度到其他節點。
IgnoredDuringExecution 表示 pod 部署成功後，如果節點標籤發生變化，不再滿足 pod 指定條件，pod 仍會在此節點繼續運行
4.3 kiali 節點親和性調度
kiali 節點親和性調度如下圖所示：
由圖可知，kiali pod 有兩個節點親和性調度策略，一個軟策略，一個硬策略。硬策略要求節點 beta.kubernetes.io/arch 標籤值必須是 amd64, ppc64le，s390x 三個值之一，如果節點不滿足此硬策略，pod 就會一直處於 pending 狀態；當滿足了此硬策略之後，pod 調度還要經過軟策略調度，即：軟策略要求節點 beta.kubernetes.io/arch 標籤值爲 amd64，ppc64le 和 s390x，並且不偏不倚，權重都是 2。