k8s：将pod部署到指定的node运行（pod&node选择部署策略）

查看所有节点labels：

添加labels：

修改yaml配置文件：

添加nodeSelector配置，样式为[label.key]: [label.value]

修改后重启服务

参考文章： https://blog.csdn.net/lzy_zhi_yuan/article/details/106913428

nodeSelector配置相对简单，k8s提供了另外一个pod调度配置： nodeAffinity（节点亲和） ，相对于nodeSelector的简单匹配他拥有更多更加个性化的配置。

这段配置表示：该pod可以被调度到标签key为 "deploy.type" ，值为 "yztssjdxt-test" 或 "yztssjdxt" 的节点。

通过使用的语句不同，调度分成软策略(soft)和硬策略(hard) ，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。而硬策略下，pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。

DuringScheduling和IgnoredDuringExecution组合生成目前主要的nodeaffinity策略

软硬策略可以组合使用 ，如下面这段配置中pod必须被调度到标签为 "deploy.type=yztssjdxt-test" 的节点。另外，在满足该条件的节点中，优先使用具有 "server=oms" 标签的节点。

nodeAffinity中nodeSelector字段下，节点满足任何一个条件即可；但更下一级matchExpressions，节点必须同时满足所有条件才能运行pod 。

如下面这段配置需要deploy.type=yztssjdxt-test、server=oms同时满足

而这段配置只需要deploy.type=yztssjdxt-test、deploy.type1=yztssjdxt满足一个即可

operator字段 ：pod与node的匹配逻辑，可选的 *** 作符有：（我只测过in、notin）

如下方这段配置，pod将不会调度到deploy.type=yztssjdxt-test的node上

一，准备新设备，新建一台虚机，尽量和其他阶段保持一致（ubantu20要知道固定ip）

二，按照搭建手册准备节点的前置条件

ubantu20.10 搭建部署k8s v1.20.0集群步骤

sudo apt install -y nfs-common cifs-utils

三，添加新节点到集群

1，生成token

kubeadm token list #token如果没有就是过期了 要重新生成

kubeadm token create

2，获取ca 

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

3，添加集群，需要加入的节点上执行

kubeadm join 192.168.0.153:6443 --token ajbh7x.sqm1fgfkqt9etn5l --discovery-token-ca-cert-hash sha256:fbabd74517e39c7103a484483315f50b055b06dc48922b71d2371312849a20d7

删除节点

1，卸载节点（drain 翻译排出，此时卸载节点，但是没有删除）

kubectl drain <node name>--delete-local-data --force --ignore-daemonsets

2，删除节点

kubectl delete node <node name>

3，清空init配置，需要删除的节点上执行

kubeadm reset

Node Affinity

Affinity 翻译成中文是“亲和性”，它对应的是 Anti-Affinity，我们翻译成“互斥”。这两个词比较形象，可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥，不同的是除了简单的正负极之外，pod 和 node 的吸引和互斥是可以灵活配置的。

Affinity的优点：

匹配有更多的逻辑组合，不只是字符串的完全相等

调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。

目前主要的node affinity：

requiredDuringSchedulingIgnoredDuringExecution

表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。

requiredDuringSchedulingRequiredDuringExecution

表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。

preferredDuringSchedulingIgnoredDuringExecution

表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。

preferredDuringSchedulingRequiredDuringExecution

表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。其中RequiredDuringExecution表示如果后面节点标签发生了变化，满足了条件，则重新调度到满足条件的节点。

pod绑定节点最简单的方法是使用 nodeSelector，但它比较简单粗暴，使用起来不能灵活调度，这个在后续版本中也会慢慢过实，所以我们一般用 nodeAffinity来实现这些需求。

如果我不希望pod调度到打了 tester=chenqiang 这个标签的 node，那么需要使用 NotIn 这个介词，否则使用 In 。

假设不希望调度，则添加如下的 nodeAffinity:

这条规则表示，pod可以被调度到标签key为“kubernetes.io/e2e-az-name”，值为“e2e-az1”或“e2e-az2”的节点。另外，在满足该条件的节点中，优先使用具有“another-node-label-key”标签，且至为“another-node-label-value”的节点。

这个 pod 同时定义了 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 两种 nodeAffinity。第一个要求 pod 运行在特定 AZ 的节点上，第二个希望节点最好有对应的 another-node-label-key:another-node-label-value 标签。

这里的匹配逻辑是label在某个列表中，可选的 *** 作符有：

In: label的值在某个列表中

NotIn：label的值不在某个列表中

Exists：某个label存在

DoesNotExist：某个label不存在

Gt：label的值大于某个值（字符串比较）

Lt：label的值小于某个值（字符串比较）

如果nodeAffinity中nodeSelector有多个选项，节点满足任何一个条件即可；如果matchExpressions有多个选项，则节点必须同时满足这些选项才能运行pod 。

需要说明的是，node并没有anti-affinity这种东西，因为NotIn和DoesNotExist能提供类似的功能。

---