共计 5181 个字符，预计需要花费 13 分钟才能阅读完成。
做自动化的共事明天竟然问我 k8s 中为什么我部署的 pod 会跑到你们开发的节点上来？我能够去管制它吗？🧐🧐
兄弟，天然是能够管制的，接下来我具体给你说一下对于 k8s 中节点污点，pod 对污点的容忍度，以及 亲缘性和非亲缘性✔✔
👀需要场景
首先咱们要明确咱们的需要和场景
- 如果冀望本人的 pod 须要部署到指定的 Node 上，那么能够在 pod 的 yaml 中加上 nodeSelector 节点标签选择器，或者在 pod 中加上节点亲缘性的配置
<!—->
- 如果咱们冀望某一个节点不让别的 pod 的部署上来，只冀望一些特定的 pod 部署到这个 Node 上，那么咱们就能够应用节点的污点，和 pod 对污点的容忍度来进行实现
接下来咱们就开始吧，看看什么是 nodeSelector，以及上述提到的各种名词，本次文章内容，须要有一点点 k8s 根底的同学看起来会更加敌对，至多你得晓得 Deployment 资源和 pod 资源的 yaml 清单
✔nodeSelector 节点标签选择器
nodeSelector 节点标签选择器， 用过 K8S 的咱们都晓得，如果想让 pod 指定部署到某一些节点上，那么咱们能够通过这个字段来进行标识。
例如咱们的 Pod 资源中 nodeSelector 字段标识的是 func=dev，那么 pod 就会部署到 func=dev 的任意节点上，这是强制指定的😥
apiVersion: v1
kind: Pod
metadata:
name: test-node-selector
sepc:
nodeSelector:
fun: "dev"
...通过这里就能够看到节点标签选择器，它的应用局限性还是非常明显 的，它只能用于你指定 pod 肯定要部署到某一个指定标签节点上的时候，那如果这个时候没有这种标签的节点时，你这个 pod 就会部署不胜利。
✔k8s 中节点污点和 pod 对污点的容忍度
咱们个别会应用节点污点和 pod 对污点的容忍度来阻止 pod 被调度到特定的节点上
如果你冀望某一个 pod 肯定不能部署到某一个节点上的时候，你就能够应用节点污点和 pod 对污点的容忍度
例如当初上了一个新的节点，然而还没有调试残缺，你不冀望你部署的 pod 会部署到这个新的节点上，那么这个时候，你就能够给这个节点加上污点。
那你测试这个新节点的时，你就能够在你将要部署的 pod 资源下面，加上 pod 对该污点的容忍度
先来看一下 k8s master 上默认的一个污点
能够看到咱们环境外面的 minikube，它的污点是空
因为它只有一个节点，它既是 master 又是 worker，所以它部署的 pod 依然能够在这个节点上进行失常部署
如果咱们是在 K8S 集群中查看 master 节点的详情时，咱们能够看到这样的污点
Taints: node-role.kubernetes.io/master:NoSchedule其中污点的
key 是 node-role.kubernetes.io/master
value 是 空的
effect 是 NoSchedule
表白的意思是这个污点会阻止 pod 调度到这个节点下面
一个 pod 只有容忍了节点上的污点，那么他才能够被调度到这个节点上
个别状况下，用于零碎的 pod 会容忍 master 上的这个污点也，就是说这样的 pod 就能够部署到 master 上
对于污点 Taints，咱们须要留神这 三类：
前两类 (NoSchedule, PreferNoSchedule) 污点都只作用于调度期间，后一类的污点(NoExecute)，它会影响正在节点上运行的 pod
NoSchedule
示意如果 pod 无奈容忍这个污点那么 pod 将不能调度到蕴含该污点的节点上
PreferNoSchedule
示意尽量阻止 pod 被调度到这个节点上，当然如果没有其余节点能够调度，那么 pod 依然还是能够调度到以后有这种污点的节点上的
NoExecute
如果在一个节点上退出了这种类型的污点，那么在以后节点上曾经运行的 pod，若不能容忍这个污点，则这些 pod 就会被干掉
如何操作
👀咱们能够通过编辑的形式去批改节点的污点或者通过命令的形式给节点加上污点
- 通过 edit node 的形式批改
kubectl edit node [nodeName]找到 Taints 的地位，加上咱们的 key，value，effect
批改结束后，应用命令查看污点是否增加胜利
kubectl describe node [nodeName]- 通过命令的形式批改
kubectl taint node [nodeName] key=value:effect
例如：kubectl taint node vm-20-15-centos node-type=newNode:NoSchedule表白的意思是，给节点 vm-20-15-centos 加上一个污点：
Key 为 node-type
Value 为 newNode
Effect 为 NoSchedule
此时，只有容忍这个新节点上污点（node-type=newNode:NoSchedule）的 pod 才能够部署上来，其余没有容忍度的 pod 就无奈部署上来
👀咱们能够这样在 pod 外面增加对污点的容忍度
间接在 pod 资源中，或者在 deployment 资源中的 spec.template.spec 下增加 tolerations 的配置
tolerations:
- effect: NoSchedule
key: node-type
operator: Equal
value: newNode当初，咱们的刚批改的这个 pod 有了对这个污点的容忍度（node-type=newNode:NoSchedule），因而能够在上述节点上进行部署
🧐简略了解
如果你可能容忍得了坏的生存，那么你也值得好的生存，好坏你都能够去感触去抉择
如果你无奈容忍坏的生存，那么你无奈靠近这片区域的
✔节点亲缘性
节点的亲缘性和节点标签选择器有点相似，但节点亲缘性可能表白的意思更多。
应用节点亲缘性，它能够让咱们部署的 pod，更加偏向于调度到某一些节点上 ，在 K8S 中会尽量的将这个 pod 依照咱们冀望的节点进行部署， 如果没方法实现的话，那也会把这些节点部署到其余节点上。
对于节点的亲源性，咱们聊一聊如下 三个重要的标签。
failure-domain.beta.kubernetes.io/region
示意节点所在地区
failure-domain.beta.kubernetes.io/zone
示意节点所在的可用性区域
kubernetes.io/hostname
示意节点的主机名
🧐如何操作
第 1 步
天然是先将节点打上咱们冀望的标签，例如节点的标签是 func=dev，当然咱们也能够不必自定义标签，能够应用零碎的默认标签，例如 kubernetes.io/hostname 主机名
kubectl label nodes [nodeName] key=value
例如
kubectl label nodes vm-20-15-centos func=dev第 2 步
咱们须要去批改 pod 资源 中对于节点亲和性的地位，例如能够这样。
nodeSelectorTerms 标签下满足任意一个 matchExpressions 即可
matchExpressions 标签下须要全副满足
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: func
operator: Euqal
values:
- dev
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- dev这个时候，咱们部署的 pod，就会去找有 func=dev 标签的节点进行部署，如果没有的话，那么就无奈部署
这里咱们能够看到 nodeAffinity 上面有一长串单词 requiredDuringSchedulingIgnoredDuringExecution，此处具体解释一下。咱们能够离开来看这一长串单词。
requiredDuringScheduling
此处的 required 示意的是必须蕴含，示意 pod 若要调度到该节点上，那么必须要指出该节点蕴含的标签。
IgnoredDuringExecution
依据单词名字咱们能够看出。在调度过程中会疏忽正在运行的 pod，也就是说对正在执行的 pod 不影响。
同样的情理，咱们能够将上述的 required 换成 preferred，对 K8S 来说就是尽可能的优先将 pod 调度到咱们指定的节点上，如果没有这样的节点，那么它也是会将 pod 调度到其余节点上的。
能够这样写，尽量满足要求
spec:
affinity:
nodeAffinity:
prefferredDuringSchedulingIgnoredDuringExecution:
- weight 100
preference:
matchExpressions:
- key: func
operator: Euqal
values:
- dev看到此处你曾经学会了，如何让 pod 部署到指定的节点上，同时你也能够让某一些节点回绝 pod 部署上来。
✔Pod 的亲缘性
这个时候咱们会有另外的一些需要，咱们心愿将一些交互比拟多的不同类型的 pod 部署到一个节点上，这样的话他们的网络通信性能会更好。
例如 租户零碎就会常常调用用户管理系统的接口。那么这两类 pod 就能够放到同一个节点进行部署 。这个时候咱们就能够 应用 pod 的亲缘性来很好地解决。
对于 pod 亲缘性和节点的亲缘性来说，在写法上将 nodeAffinity 换成了 podAffinity
🧐如何操作
例如，此处的 租户零碎 pod 标签为 app=tenant，那么 用户治理写 pod 亲和性的时候，就只须要去找这个标签的 pod 所在的节点进行部署即可
批改 pod / deployment 资源
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
masrchLabels:
app: tenant
...其中 topologyKey 指定 kubernetes.io/hostname，含意是：要求 pod 将被调度到 蕴含 app=tenant 标签的 pod 所在的雷同节点下面
✔Pod 的非亲缘性
咱们的需要总是无穷无尽的，当初咱们为了服务更加的强壮，冀望同一个利用，可能在 K8S 上每一个节点都部署一个，而不是这一个利用全都部署在一个节点上。
这样是为了避免某一个节点呈现故障之后，其余节点上依然有这个利用提供服务。
那咱们能够如法炮制，既然有 pod 的亲缘性，那天然也有 pod 的非亲缘性
Pod 的非亲缘性，咱们个别用来去离开调度 pod，让同一类型 pod 别离部署到不同的 节点上
👀如何操作
批改 pod / deployment 资源
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
masrchLabels:
app: tenant
...此处咱们能够看到，应用的 podAntiAffinity 示意 pod 的反亲缘性， 此处不要弄错了
此处写的标签是 app=tenant，示意的意思是，如果有一个 pod 标签为 app=tenant 在 节点 1 上，那么如果再部署这种类型的 pod 的时候，就不会再部署到节点 1 上的，就会去部署到其余节点上
🔥总结
至此，通过下面的常识，咱们解决了这样几个场景问题
- 利用节点的亲缘性 将 pod 指定部署到某些节点上，如果这样的节点不存在，那么也能够将他们的部署到别的节点上。
<!—->
- 利用 pod 亲缘性 将交互比拟频繁的一些服务利用尽可能部署到同一个节点上。
<!—->
- 利用 pod 的非亲缘性 将 pod 离开调度到不同的节点上，更好的保障高可用
本次就是这样，如果有帮忙到你，欢送点赞，评论，留言哦
感激浏览，欢送交换，点个赞，关注一波 再走吧
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 阿兵云原生，欢送点赞关注珍藏，下次见~
文中提到的技术点，感兴趣的能够查看这些文章：
- 【k8s 系列】如何拜访 pod 元数据
<!—->
- 【k8s 系列】如何降级利用？
<!—->
- 【k8s 系列】Deployment 降级利用
<!—->
- 【k8s 系列】Deployment 降级利用 2
<!—->
- 【k8s 系列】pod 知识点 上
<!—->
- 【k8s 系列】pod 知识点 下
<!—->
- 【k8s 系列】Label 2