前言
kubernetes中部署的pod默認根據資源使用情況自動調度到某個節點。可在實際項目的使用場景中都會有更細粒度的調度需求，比如：某些pod調度到指定主機、某幾個相關的服務的pod最好調度到一個節點上、Master節點不允許某些pod調度等。使用kubernetes中的節點調度、節點親和性、pod親和性、汙點與容忍可以靈活的完成pod調度，從而滿足項目中較為複雜的調度需求。下面用一些項目中的使用場景聊聊pod調度使用法則。
pod調度主要包含以下內容
- nodeSelector
- nodeAffinity
- podAffinity
- Taints & tolerations(汙點與容忍)
指定節點調度
kubectl get nodes #獲取當前Kubernetes集群全部節點
NAME STATUS ROLES AGE VERSION
dev-10 Ready <none> 45d v1.8.6
dev-7 Ready master 45d v1.8.6
dev-8 Ready <none> 45d v1.8.6
dev-9 Ready <none> 45d v1.8.6
/<none>/<none>/<none>
nodeName
通過主機名指定pod調度到指定節點
spec:
nodeName: dev-8 #設置要調度節點的名稱
containers:
- image: nginx
imagePullPolicy: Always
name: my-nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
nodeSelector
kubernetes中常用label來管理集群的資源，nodeSelector可通過標籤實現pod調度到指定節點上。
舉列：使用nodeSelector將pod調度到dev-9節點上
step1：給dev-9打標籤
kubectl label nodes dev-9 test=nginx #設置標籤
kubectl get nodes --show-labels |grep test=nginx #查詢標籤是否設置成功
setp2：nodeSelector設置對應標籤
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: my-nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
nodeSelector: #設置標籤
test: nginx
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
#查詢pod已經成功調度到dev-9節點
kcc get pods -o wide -n ns-team-1-env-1|grep my-nginx
my-nginx-556dcc8c5c-27f7k 1/1 Running 0 2m 10.244.2.238 dev-9
nodeAffinity
node 節點 Affinity ，從字面上很容易理解nodeAffinity就是節點親和性，Anti-Affinity也就是反親和性。節點親和性就是控制pod是否調度到指定節點，相對nodeSelector來說更為靈活，可以實現一些簡單的邏輯組合。
nodeAffinity策略
preferredDuringSchedulingIgnoredDuringExecution #軟策略，儘量滿足
requiredDuringSchedulingIgnoredDuringExecution #硬策略，必須滿足
根據具體一些常用場景感受下
場景1：必須部署到有 test=nginx 標籤的節點
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: test
operator: In
values:
- nginx
場景2：最好部署到有test=nginx 標籤的節點
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: test
operator: In
values:
- nginx
場景3：不能部署在dev-7,dev-8節點；最好部署到有test=nginx標籤的節點
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- dev-7
- dev-8
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: test
operator: In
values:
- nginx
#通過以上場景可以看出使用節點親和性可靈活的控制pod調度到節點，實現一些有邏輯組合的調度
Kubernetes中的operator提供了下面幾種過濾條件:
- In：label 的值在某個列表中
- NotIn：label 的值不在某個列表中
- Gt：label 的值大於某個值
- Lt：label 的值小於某個值
- Exists：某個 label 存在
- DoesNotExist：某個 label 不存
podAffinity
nodeSelector和nodeAffinity 都是控制pod調度到節點的操作，在實際項目部署場景中，希望根據服務與服務之間的關係進行調度，也就是根據pod之間的關係進行調度，Kubernetes的podAffinity就可以實現這樣的場景，podAffinity的調度策略和nodeAffinity類似也有：
requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
場景：希望my-nginx服務my-busybox服務 最好部署在同一個節點上
# my-nginx基本信息
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: my-nginx #標籤 app = my-nginx
name: my-nginx
namespace: ns-team-1-env-1
...
...
# my-busybox基本信息
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: my-busybox #標籤 app = my-busybox
name: my-busybox
namespace: ns-team-1-env-1
...
...
# 在my-busybox設置pod親和性
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-busybox
labels:
app: my-busybox
spec:
containers:
- name: my-busybox
image: nginx
affinity:
podAffinity: #my-busybox 添加pod親和性，與打了標籤app = my-nginx的pod靠近
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- my-nginx
topologyKey: kubernetes.io/hostname
# 以上例子表示，有一個pod在運行，並且這個pod有標籤是app=my-nginx，my-busybox這個pod就會與其調度到同一個節點上，可預見因為上面我們的my-nginx已經調度到dev-9，因此my-nginx和my-busybox都會在dev-9節點上查詢到
Taints & tolerations
Taints：汙點，tolerations：容忍。在實際項目實踐中有時候不希望某些服務調度到指定節點上，比如master節點只運行Kubernetes 組件，應用服務不希望調度到master上。這種場景只需要在master節點設置一個汙點。
#設置汙點
kubectl taint nodes dev-7 system=service:NoSchedule
設置了汙點就不能調度了麼？No 如果設置了汙點還是希望某些pod能夠調度上去，可以給pod針對汙點加容忍。
#添加容忍
tolerations:
- key: "system"
operator: "Equal"
value: "service"
effect: "NoSchedule"
#添加了容忍system=service , 這樣就可以調度到節點設置了汙點：system=service:NoSchedule的主機上，其他沒有添加容忍的服務就不會調度到打了汙點的節點上。
effect 有三種設置
- NoSchedule：pod不能調度到標記了taints的節點
- PreferNoSchedule：pod最好不要調度到標記了taints的節點
- NoExecute：設置了汙點，馬上踢出該節點中沒有設置對應汙點的Tolerate設置的pod
參考文檔
- https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
- https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
原文鏈接：
https://mp.weixin.qq.com/s/-45O_avprSyTcRioJpJ9wg
關於睿雲智合
深圳睿雲智合科技有限公司成立於2012年，總部位於深圳，並分別在成都、深圳設立了研發中心，北京、上海設立了分支機構，核心骨幹人員全部為來自金融、科技行業知名企業資深業務專家、技術專家。早期專注於為中國金融保險等大型企業提供創新技術、電子商務、CRM等領域專業諮詢服務
自2016年始，在率先將容器技術引進到中國保險行業客戶後，公司組建了專業的容器技術產品研發和實施服務團隊，旨在幫助中國金融行業客戶將容器創新技術應用於企業信息技術支持業務發展的基礎能力改善與提升，成為中國金融保險行業容器技術服務領導品牌
此外，憑藉多年來在呼叫中心領域的業務經驗與技術積累，睿雲智合率先在業界推出基於開源軟交換平臺FreeSwitch的微服務架構多媒體數字化業務平臺，將語音、視頻、webchat、微信、微博等多種客戶接觸渠道集成，實現客戶統一接入、精準識別、智能路由的CRM策略，並以容器化治理來支持平臺的全應用生命週期管理，顯著提升了數字化業務處理的靈活、高效、彈性、穩定等特性，為幫助傳統企業向“以客戶為中心”的數字化業務轉型提供完美的一站式整體解決方案。
閱讀更多 睿雲智合Wise2C 的文章
