node 节点选择器
我们在创建 pod 资源的时候，pod 会根据 schduler 进行调度，那么默认会调度到随机的一个工
作节点，如果我们想要 pod 调度到指定节点或者调度到一些具有相同特点的 node 节点，怎么办呢?
可以使用
pod 中的 nodeName 或者 nodeSelector 字段指定要调度到的 node 节点
1、nodeName:
指定
pod 节点运行在哪个具体 node
cat pod-node.yaml
apiVersion: v1 #pod属于k8s核心组v1
kind: Pod #创建的是一个pod资源
metadata: #元数据
name: demo-pod1 #pod名字
namespace: default #pod所属的名称空间
labels: #标签
app: myapp #pod具有的标签
env: dev #pod具有的标签
spec:
nodeName: god64
containers: #定义一个容器，容器是独享列表
- name: tomcat-pod-java #容器名字
ports:
- containerPort: 8080 #容器内部的port
的 image: tomcat:8.5-jre8-alpine #容器使用的景象
imagePullPolicy: IfNotPresent #容器拉取的策略
- name: busybox
image: busybox:latest
command: #command是一个列表，定义的时候下面的参数加横线
- "/bin/sh"
- "-c"
- "sleep 3600"
#kubectl apply -f pod-node.yaml
#kubectl get pods -o wide 查看调度到哪里了
#优雅删除
kubectl delete -f pod-node.yaml
#强制删除
kubectl delete -f pod-node.yaml --force --grace-period=0
2、nodeSelector:
指定
pod 调度到具有哪些标签的 node 节点上
#给 node 节点打标签，打个具有 disk=ceph 的标签
kubectl label nodes god62 disk=ceph
kubectl get nodes god62 --show-labels
#定义 pod 的时候指定要调度到具有 disk=ceph 标签的 node 上
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: demo-pod-1
namespace: default
labels:
app: myapp
env: dev
spec:
nodeSelector: ##定义 pod 的时候指定要调度到具有 disk=ceph 标签的 node 上
disk: ceph
containers:
- name: tomcat-pod-java
ports:
- containerPort: 8080
image: tomcat:8.5-jre8-alpine
imagePullPolicy: IfNotPresent
#更新，查看调度到哪里了
kubectl apply -f pod-1.yaml
kubectl get pods -o wide
# 查看kubectl describe pods demo-pod 详细信息
3.污点和容忍度
node 节点亲和性调度:nodeAffinity
kubectl explain pods.spec.affinity
FIELDS:
nodeAffinity <Object>
Describes node affinity scheduling rules for the pod.
podAffinity <Object>
Describes pod affinity scheduling rules (e.g. co-locate this pod in the
same node, zone, etc. as some other pod(s)).
podAntiAffinity <Object>
Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod
in the same node, zone, etc. as some other pod(s)).
#在查询kubectl explain pods.spec.affinity.nodeAffinity
preferredDuringSchedulingIgnoredDuringExecution <[]Object>
prefered 表示有节点尽量满足这个位置定义的亲和性，这不是一个必须的条件，软亲和性
requiredDuringSchedulingIgnoredDuringExecution <Object>
require 表示必须有节点满足这个位置定义的亲和性，这是个硬性条件，硬亲和性
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.no deSelectorTerms
FIELDS:
matchExpressions <[]Object> matchFields <[]Object>
matchExpressions:匹配表达式的 matchFields: 匹配字段的
nodeSelectorTerms <[]Object> -required- #required必须字段
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.no deSelectorTerms.matchFields
VERSION: v1
RESOURCE: matchExpressions <[]Object>
DESCRIPTION:
FIELDS:
key <string> -required- operator <string> -required- values <[]string>
key:检查 label
operator:做等值选则还是不等值选则
values:给定值
使用 requiredDuringSchedulingIgnoredDuringExecution 硬亲和性 #把 myapp-v1.tar.gz 上传到 62 和 64 上，手动解压:
docker load -i myapp-v1.tar.gz
vim pod-nodeaffinity-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-node-affinity-demo
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values:
- foo
- bar
spec:我们检查当前节点中有任意一个节点拥有 zone 标签的值是 foo 或者 bar，就可以把 pod 调度到 这个 node 节点的 foo 或者 bar 标签上的节点上
containers:
- name: myapp
image: ikubernetes/myapp:v1
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values:
- foo
- bar
kubectl apply -f pod-nodeaffinity-demo.yaml
kubectl get pods -o wide | grep pod-node
status 的状态是 pending，上面说明没有完成调度，因为没有一个拥有 zone 的标签的值是 foo 或者 bar，而且使用的是硬亲和性，必须满足条件才能完成调度
kubectl label nodes god64 zone=foo
给这个 god64 节点打上标签 zone=foo，在查看
使用 preferredDuringSchedulingIgnoredDuringExecution 软亲和性
vi pod-nodeaffinity-demo-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-node-affinity-demo-2
namespace: default
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: zone1
operator: In
values:
- foo1
- bar1
weight: 60
Pod 节点亲和性
pod 自身的亲和性调度有两种表示形式
podaffinity:pod 和 pod 更倾向腻在一起，把相近的 pod 结合到相近的位置，如同一区域，同 一机架，这样的话 pod 和 pod 之间更好通信，比方说有两个机房，这两个机房部署的集群有 1000 台主机，那么我们希望把 nginx 和 tomcat 都部署同一个地方的 node 节点上，可以提高 通信效率;
podunaffinity:pod 和 pod 更倾向不腻在一起，如果部署两套程序，那么这两套程序更倾向于 反亲和性，这样相互之间不会有影响。
第一个 pod 随机选则一个节点，做为评判后续的 pod 能否到达这个 pod 所在的节点上的运行方 式，这就称为 pod 亲和性;我们怎么判定哪些节点是相同位置的，哪些节点是不同位置的;我们 在定义 pod 亲和性时需要有一个前提，哪些 pod 在同一个位置，哪些 pod 不在同一个位置，这 个位置是怎么定义的，标准是什么?以节点名称为标准，这个节点名称相同的表示是同一个位置， 节点名称不相同的表示不是一个位置。
kubectl explain pods.spec.affinity.podAffinity
podAffinity 亲和性
podAntiAffinity 反亲和性
requiredDuringSchedulingIgnoredDuringExecution: 硬亲和性 preferredDuringSchedulingIgnoredDuringExecution:软亲和性
topologyKey: 位置拓扑的键，这个是必须字段 怎么判断是不是同一个位置: rack=rack1
row=row1
使用 rack 的键是同一个位置
使用 row 的键是同一个位置
labelSelector:
我们要判断 pod 跟别的 pod 亲和，跟哪个 pod 亲和，需要靠 labelSelector，通过 labelSelector 选则一组能作为亲和对象的 pod 资源
namespace:
labelSelector 需要选则一组资源，那么这组资源是在哪个名称空间中呢，通过 namespace 指 定，如果不指定 namespaces，那么就是当前创建 pod 的名称空间
定义两个 pod，第一个 pod 做为基准，第二个 pod 跟着它走 cat pod-required-affinity-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-first
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
name: pod-second
labels:
app: backend
tier: db
spec:
containers:
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 3600"]
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["myapp"]}
topologyKey: kubernetes.io/hostname
# - {key: app, operator: In, values: ["myapp"]}. key里面的app引用的是之前pod的labels的app
operator 的ln代表等值关系，values: ["myapp]对应app的 myapp ，靠第一个pod的标签对应亲和性，第二个标签会找标签app： myapp的标签
#更新看亲和性
kubectl apply -f pod-required-affinity-demo.yaml
kubectl get pods -o wide
看到pod-second跟pod-first在同一个节点
上面说明第一个 pod 调度到哪，第二个 pod 也调度到哪，这就是 pod 节点亲和性
kubectl delete -f pod-required-affinity-demo.yaml
pod 节点反亲和性
定义两个
pod，第一个 pod 做为基准，第二个 pod 跟它调度节点相反
cat pod-required-anti-affinity-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-first labels:
app: myapp
tier: frontend spec:
---
containers:
- name: myapp
image: ikubernetes/myapp:v1
apiVersion: v1 kind: Pod metadata:
name: pod-second labels:
app: backend
tier: db spec:
containers:
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 3600"] affinity:
podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["myapp"]} topologyKey: kubernetes.io/hostname
kubectl apply -f pod-required-anti-affinity-demo.yaml
kubectl get pods -o wide 显示两个 pod 不在一个 node 节点上，这 就是 pod 节点反亲和性
pod-first running god64
pod-second running god62
kubectl delete -f pod-required-anti-affinity-demo.yaml
换一个 topologykey
kubectl label nodes god62 zone=foo
kubectl label nodes god64 zone=foo
cat pod-required-anti-affinity-demo-1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-first
labels:
app: myapp
tier: frontend
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
name: pod-second
labels:
app: backend
tier: db
spec:
containers:
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["sh","-c","sleep 3600"]
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- {key: app, operator: In, values: ["myapp"]}
topologyKey: zone
kubectl apply -f pod-required-anti-affinity-demo.yaml
kubectl get pods -o wide 显示如下:
pod-first running god64
pod-second pending
第二个节点现是 pending，因为两个节点是同一个位置，现在没有不是同一个位置的了，而且我 们要求反亲和性，所以就会处于 pending 状态，如果在反亲和性这个位置把 required 改成 preferred，那么也会运行。
podaffinity:pod 节点亲和性，pod 倾向于哪个 pod
nodeaffinity:node 节点亲和性，pod 倾向于哪个 node
tolerationSeconds参数含义：
假如说你原来node1节点没有污点，上面会有很多pod在运行，现在你把node1节点打个污点，排斥等级是NoExecute，这样你node1上的pod就会被驱逐走，那多长时间被撵走，取决于tolerationSeconds，这个参数知识在定义排斥等级是NoExecute的时候才会用到
