部署pod時，大多數情況下kubernetes的調度程序能將pod調度到集群中合適的節點上。但有些情況下用戶需要對pod調度到哪個節點上施加更多控制，比如將特定pod部署到擁有SSD存儲節點、將同一個服務的多個后端部署在不同的機器上提高安全性、將通信頻繁的服務部署在同一個可用區域降低通信鏈路長度。用戶對pod部署的節點施加控制都與"label selector"有關。
nodeSelector(節點選擇器)
nodeSelector也是標簽選擇器，是最簡單、最直接控制pod部署node的方法，在daemonset用nodeSelector過濾可部署節點，以下是其普通的應用示例。
步驟1：為節點添加標簽
-
kubectl get nodes，返回集群中所有node。
-
kubectl node label
= ，為node選定的node添加標簽。如kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd -
為pod configuration添加節點選擇器：
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
當運行kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml命令創建pod時，節點選擇器選中有上述節點，如果沒有符合條件的node則調度失敗，為pod輸出調度失敗事件並指明失敗原因。pod一直處於pending狀態，直到找到合適的節點。
運行kubectl get pods -o wide查看調度程序為pod選定的節點。
Interlude: built-in node labels（插曲:內置節點標簽）
上例中使用用戶自定義標簽，也可以使用系統自動生成的內置節點標簽。不同kubernetes版本、不同的基礎設備供應商，默認添加的內置節點標簽可能不同，需查詢相關文檔確認，以下是kubernetes1.4的內置節點標簽：
- kubernetes.io/hostname
- failure-domain.beta.kubernetes.io/zone
- failure-domain.beta.kubernetes.io/region
- beta.kubernetes.io/instance-type
- beta.kubernetes.io/os
- beta.kubernetes.io/arch
親和與反親和（Affinity and anti-affinity）
nodeSelector只能基於節點標簽控制pod部署node，並且選擇器只支持“與”邏輯操作。親和與反親和特性目前處於測試階段，相比於節點選擇器，其更靈活，功能更強大，體現在以下三點：
-
不僅僅是“與”，支持更多的邏輯表達式。
-
nodeSelector是硬性要求，親和與反親和支持軟硬兩種要求。
-
除了節點標簽，親和與反親和支持根據節點上已經部署的pod進行節點選擇，這一點很重要。比如不想將兩種計算密集類型的pod部署在同一節點上，后部署pod可選擇過濾。
細分成兩種類型的選擇器："節點親和"與"內部pod親和、反親和"。節點親和與nodeSelector相似，具備上述1、2兩條優點。內部pod親和依賴的是節點上已有pod的標簽而不是節點標簽，兼俱上述三個優點。因為節點親和能完成nodeSelector所工作並且具備額外的優點，因此nodeSelector雖然還能用，但已經不再維護，並且將來可能刪除。
節點親和（測試特性）
節點親和與nodeSelector工作原理相同，都是其於node標簽選擇節點。有兩點不同，第一是節點親和支持軟硬兩種節點選擇requiredDuringSchedulingIgnoredDuringExecution、preferredDuringSchedulingIgnoredDuringExecution。前者是硬性條件必需滿足，后者是軟性條件，屬於偏好部署。第二點是在選擇節點時，節點親和比nodeSelector支持更多更靈活的表達式，示例如下：
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
符合條件的節點必需滿足requiredDuringSchedulingIgnoredDuringExecution的條件，在此基礎上，如果有節點滿足
preferredDuringSchedulingIgnoredDuringExecution的條件，則更傾向部署在后者上。查詢表達式中可以使用的操作符有：
In, NotIn, Exists, DoesNotExist, Gt, Lt等。
在requiredDuringSchedulingIgnoredDuringExecution中的matchExpressions可以包含多條選擇表達式，相互之間是"邏輯與"的關系，必需同時滿足。preferredDuringSchedulingIgnoredDuringExecution中的matchExpressions也可以有多條，因為它是軟性條件，因為並非一定要全匹配，匹配的條目越多越符合條件。另外還可以為偏好中的表達式賦予不同的權重weight，可取的值在0-100之間，最后通過計算權重和決定那個節點更符合條件。
如果同時使用了nodeSelector與nodeAffinity，那么目標節點必需同時滿足這兩個選擇器。
內部pod親和與反親和（測試特性）
內部pod親和與反親和特性由kubernetes1.4版本初次引入，其基於節點上已部署pod的標簽計算親和與反親和，如實現將兩種通信頻繁pod部署在相同節點，將兩種計算密集型pod部署在不同節點等。
提示：實現內部親和與反親和需要數量可觀的計算步驟，會明顯降低pod調度的速度，集群規模越大、節點越多降速越明顯，呈指數級增長，需要在使用此特性時考慮對調度速度的影響。
在配置時，內部pod親和用podAffinity字段表示，內部pod反親和用podAntiAffinity字段表示，其它與節點親和一樣，也有軟硬兩種選擇器，每種選擇器可以多個過濾條件。
內部pod親和示例：
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0
上例中的topologyKey用來縮小節點選擇范圍，其值可以是任何合法的節點標簽，在大規模集群中，為此字段不指定或者指定錯誤值，可能引發巨大的性能、安全問題。因此，對其使用有如下限制：
-
對於親和與硬性反親和，topologyKey字段值不能為空。
-
對於硬性反親和，topoloygKey只能是kubernetes.io/hostname，除非禁止LimitPodHardAntiAffinityTopology允入控制器或者修改其實現。
-
對於軟件反親和，允許topoloygKey為空，表示對節點拓撲沒有限制。
-
以上情況外，topologyKey可以是任何合法標簽。
示例1：用反親和特性實現pod位置協商
假設集群有五個工作節點，部署一個web應用，假設其用redis作內存緩存，共需要三個副本，通過反親和將三個redis副本分別部署在三個不同的節點上，提高可用性，Deployment配置如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine
反親和會阻止同相的redis副本部署在同一節點上。
現在部署三個nginx web前端，要求三個副本不對分別部署在不同的節點上，通過與上列相似的反親和實現。同時需要將三個web前端部署在其上已經部署redis的節點上，降低通信成本，通過親和實現，配置如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
selector:
matchLabels:
app: web-store
replicas: 3
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx:1.12-alpine