一 k8s的网络通信

1.1 k8s通信整体架构

• k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等
• CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist
• 插件使用的解决方案如下
  • 虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
  • 多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
  • 硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。
• 容器间通信：
  • 同一个pod内的多个容器间的通信，通过lo即可实现pod之间的通信
  • 同一节点的pod之间通过cni网桥转发数据包。
  • 不同节点的pod之间的通信需要网络插件支持，例如flannel与calico
• pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换
• pod和外网通信：iptables的MASQUERADE
• Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）

1.2 Flannel网络插件

• 定位 “简单易用的 Overlay 网络”，核心目标是解决跨主机 Pod 通信的基础问题，不追求复杂功能。
• 网络模型：基于 Overlay（覆盖网络）技术，默认使用vxlan协议（将 Pod 流量封装在主机网络的 UDP 包中转发），也支持host-gw（主机网关，无封装，需同网段）等后端。
• 本质是 “二层 / 三层混合转发”，通过 etcd 维护 Pod 子网与主机 IP 的映射关系，实现跨节点 Pod 通信。

1.2.1 flannel跨主机通信原理

• 当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。
• VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。
• 内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。
• Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。
• flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。
• linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。
• 此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。

[root@master ~]# ip r
default via 172.25.254.2 dev eth0 proto static metric 100
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.25.254.0/24 dev eth0 proto kernel scope link src 172.25.254.100 metric 100

1.2.2 flannel支持的后端模式

网络模式	功能
vxlan	报文封装，默认模式
Directrouting	直接路由，跨网段使用vxlan，同网段使用host-gw模式
host-gw	主机网关，性能好，但只能在二层网络中，不支持跨网络 如果有成千上万的Pod，容易产生广播风暴，不推荐
UDP	性能差，不推荐

[root@k8s-master ~]# kubectl -n kube-flannel edit cm kube-flannel-cfg
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "EnableNFTables": false,
      "Backend": {
        "Type": "host-gw"			#更改内容
      }
    }
#重启pod
[root@k8s-master ~]# kubectl -n kube-flannel delete pod --all
pod "kube-flannel-ds-bk8wp" deleted
pod "kube-flannel-ds-mmftf" deleted
pod "kube-flannel-ds-tmfdn" deleted

[root@k8s-master ~]# ip r
default via 172.25.254.2 dev eth0 proto static metric 100
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 172.25.254.10 dev eth0
10.244.2.0/24 via 172.25.254.20 dev eth0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.25.254.0/24 dev eth0 proto kernel scope link src 172.25.254.100 metric 101.

1.2.3 flannel的部署

在部署k8s集群篇时开始就是使用flannel插件

#master节点
#下载flannel的yaml部署文件
]# wget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

#下载镜像：
[root@k8s-master ~]# docker pull docker.io/flannel/flannel:v0.25.5
[root@k8s-master ~]# docekr	pull docker.io/flannel/flannel-cni-plugin:v1.5.1-flannel1

#上传镜像到harbor仓库
]# docker tag flannel/flannel:v0.25.5  reg.fy.org/flannel/flannel:v0.25.5	#打标签
]# docker push reg.fy.org/flannel/flannel:v0.25.5		#推送

]# docker tag flannel/flannel-cni-plugin:v1.5.1-flannel reg.fy.org/flannel/flannel-cni-plugin:v1.5.1-flannel1
]# docker push reg.fy.org/flannel/flannel-cni-plugin:v1.5.1-flannel1

#编辑kube-flannel.yml 修改镜像下载位置
]# vim kube-flannel.yml
#由于初始化时已经指定拉取镜像的位置所以只需要指定镜像仓库的项目
146:        image: flannel/flannel:v0.25.5
173:        image: flannel/flannel-cni-plugin:v1.5.1-flannel1
184:        image: flannel/flannel:v0.25.5

#开始部署 Flannel 网络插件
]# kubectl apply -f kube-flannel.yml

1.3 Calico网络插件

官网：

https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises

• 定位 “高性能、可扩展的三层网络”，强调原生路由和网络策略能力。
• 网络模型：基于纯三层路由，通过 BGP（边界网关协议）协议在节点间交换路由信息，Pod 流量直接通过主机路由转发，无需封装（默认模式）。
• 也支持 Overlay 模式（如 IPIP 封装），但更推荐纯三层模式以发挥性能优势。

1.3.1 calico跨主机原理

• Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
• BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里

1.3.2 部署calico

1.删除flannel插件

# kubectl delete  -f kube-flannel.yml

2.删除所有k8s节点上flannel配置文件，避免冲突

# rm -rf /etc/cni/net.d/10-flannel.conflist
[root@master network]# ssh -l root 172.25.254.10 rm -rf /etc/cni/net.d/10-flannel.conflist
[root@master network]# ssh -l root 172.25.254.20 rm -rf /etc/cni/net.d/10-flannel.conflist

3.下载部署镜像，并上传到仓库

#从公网仓库获取calico镜像
[root@master network]# docker pull docker.io/calico/cni:v3.28.1
[root@master network]# docker pull docker.io/calico/node:v3.28.1
[root@master network]# docker pull docker.io/calico/kube-controllers:v3.28.1
[root@master network]# docker pull docker.io/calico/typha:v3.28.1

#从本地导入
[root@master network]# docker load -i calico-3.28.1.tar

[root@master network]# docker tag calico/cni:v3.28.1 reg.fy.org/calico/cni:v3.28.1
[root@master network]# docker tag calico/node:v3.28.1 reg.fy.org/calico/node:v3.28.1
[root@master network]# docker tag calico/kube-controllers:v3.28.1 reg.fy.org/ calico/kube-controllers:v3.28.1
[root@master network]# docker tag calico/typha:v3.28.1 reg.fy.org/typha:v3.28.1

[root@master network]# docker push reg.fy.org/calico/cni:v3.28.1
[root@master network]# docker push reg.fy.org/calico/node:v3.28.1
[root@master network]# docker push reg.fy.org/alico/kube-controllers:v3.28.1 reg.fy.org/ calico/kube-controllers:v3.28.1
[root@master network]# docker push reg.fy.org/typha:v3.28.1

4.更改yml文件

#获取yaml文件
[root@master network]# curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico-typha.yaml -o calico.yaml

[root@master network]#  vim calico.yaml
4835           image: calico/cni:v3.28.1
4835           image: calico/cni:v3.28.1
4906           image: calico/node:v3.28.1
4932           image: calico/node:v3.28.1
5160           image: calico/kube-controllers:v3.28.1
5249         - image: calico/typha:v3.28.1

4970             - name: CALICO_IPV4POOL_IPIP			#禁用IPIP隧道模式，不通过封装，直接使用主机网络进行pod间通信
4971               value: "Never"						

4999             - name: CALICO_IPV4POOL_CIDR			#指定集群分配的pod网段
5000               value: "10.244.0.0/16"
5001             - name: CALICO_AUTODETECTION_METHOD	#指定Calic自动检测节点IP地址的方式
5002               value: "interface=eth0"

5.查看并测试

[root@master network]# kubectl apply -f calico.yaml
[root@master network]# kubectl -n kube-system get pods
NAME                                       READY   STATUS    RESTARTS       AGE
calico-kube-controllers-6849cb478c-fdnf2   1/1     Running   0              9m1s
calico-node-4hrzv                          1/1     Running   0              9m1s
calico-node-qtb7s                          1/1     Running   0              9m1s
calico-node-rqf6h                          1/1     Running   0              9m1s
calico-typha-fff9df85f-7hhs6               1/1     Running   0              9m1s
coredns-7bbdf5df5d-c482k                   1/1     Running   17 (10m ago)   8d
coredns-7bbdf5df5d-gvdwk                   1/1     Running   17 (10m ago)   8d
etcd-master                                1/1     Running   17 (10m ago)   8d
kube-apiserver-master                      1/1     Running   17 (10m ago)   8d
kube-controller-manager-master             1/1     Running   17 (10m ago)   8d
kube-proxy-j7kfc                           1/1     Running   12 (10m ago)   5d17h
kube-proxy-ld4rp                           1/1     Running   13 (10m ago)   5d17h
kube-proxy-nfctx                           1/1     Running   12 (10m ago)   5d17h
kube-scheduler-master                      1/1     Running   17 (10m ago)   8d

#测试
[root@master network]# kubectl run web --image nginx
[root@master network]# kubectl get pods -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
web    1/1     Running   0          16m   10.244.166.128   node1   <none>           <none>

[root@master network]# curl 10.244.166.128
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

1.4 Flannel与Calico核心功能对比

功能点	Flannel	Calico
网络策略（Network Policy）	不支持（无任何网络隔离能力）	完全支持（L3/L4 层策略，如基于 IP、端口、Pod 标签的访问控制）
转发效率	较低（vxlan 模式有封装 / 解封装开销）	高（纯三层路由无额外开销，接近原生网络性能）
跨网段部署	依赖 vxlan 封装，无需额外配置	纯三层模式需底层网络支持 BGP 路由传递（或配置 IPIP 封装跨网段）
扩展性	中小规模集群（节点数较少时表现稳定）	大规模集群（BGP 协议天然支持路由聚合，适合千级节点）
附加功能	无（仅满足基础通信）	支持网络监控（如 Calico Monitor）、加密（IPsec）、BGP 路由精细控制等

二 k8s调度（Scheduling）

2.1 调度在Kubernetes中的作用

• 调度是指将未调度的Pod自动分配到集群中的节点的过程
• 调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod
• 调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行

2.2 调度原理：

• 创建Pod

  • 用户通过Kubernetes API创建Pod对象，并在其中指定Pod的资源需求、容器镜像等信息。

• 调度器监视Pod

  • Kubernetes调度器监视集群中的未调度Pod对象，并为其选择最佳的节点。

• 选择节点

  • 调度器通过算法选择最佳的节点，并将Pod绑定到该节点上。调度器选择节点的依据包括节点的资源使用情况、Pod的资源需求、亲和性和反亲和性等。

• 绑定Pod到节点

  • 调度器将Pod和节点之间的绑定信息保存在etcd数据库中，以便节点可以获取Pod的调度信息。

• 节点启动Pod

  • 节点定期检查etcd数据库中的Pod调度信息，并启动相应的Pod。如果节点故障或资源不足，调度器会重新调度Pod，并将其绑定到其他节点上运行。

2.3 调度器种类

• 默认调度器（Default Scheduler）：
  • 是Kubernetes中的默认调度器，负责对新创建的Pod进行调度，并将Pod调度到合适的节点上。
• 自定义调度器（Custom Scheduler）：
  • 是一种自定义的调度器实现，可以根据实际需求来定义调度策略和规则，以实现更灵活和多样化的调度功能。
• 扩展调度器（Extended Scheduler）：
  • 是一种支持调度器扩展器的调度器实现，可以通过调度器扩展器来添加自定义的调度规则和策略，以实现更灵活和多样化的调度功能。
• kube-scheduler是kubernetes中的默认调度器，在kubernetes运行后会自动在控制节点运行

2.4 常用的调度方法

2.4.1 nodename

• nodeName 是节点选择约束的最简单方法，但一般不推荐
• 如果 nodeName 在 PodSpec 中指定了，则它优先于其他的节点选择方法
• 使用 nodeName 来选择节点的一些限制
  • 如果指定的节点不存在。
  • 如果指定的节点没有资源来容纳 pod，则pod 调度失败。
  • 云环境中的节点名称并非总是可预测或稳定的

实例：

[root@master schedule]# kubectl run testpod --image=myapp:v1 --dry-run=client -o yaml > test.yml
[root@master schedule]# cat test.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  nodeName: node1
  containers:
  - image: myapp:v1
    name: testpod

[root@master schedule]# kubectl apply  -f test.yml
pod/testpod created
[root@master schedule]# kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
testpod   1/1     Running   0          6s    10.244.166.130   node1   <none>           <none>

[!NOTE]

#找不到节点pod会出现pending，优先级最高，其他调度方式无效

2.4. 2 Nodeselector(通过标签控制节点)

• nodeSelector 是节点选择约束的最简单推荐形式

• 给选择的节点添加标签：

  kubectl label nodes k8s-node1 lab=test
  

• 可以给多个节点设定相同标签

示例：

#查看节点标签
[root@master schedule]# kubectl get nodes --show-labels
NAME     STATUS   ROLES           AGE   VERSION   LABELS
master   Ready    control-plane   8d    v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers=
node1    Ready    <none>          8d    v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2    Ready    <none>          8d    v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

#给节点添加标签
[root@master schedule]# kubectl label nodes node1 disktype=ssd
[root@master schedule]# kubectl get nodes node1 --show-labels
NAME    STATUS   ROLES    AGE   VERSION   LABELS
node1   Ready    <none>   8d    v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux

[root@master schedule]# cat test.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  nodeSelector:
    disktype: ssd		#指定node1上的标签就会被调度到node1
  containers:
  - image: myapp:v1
    name: testpod

[root@master schedule]# kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
testpod   1/1     Running   0          70s   10.244.166.132   node1   <none>           <none>

#更改标签
[root@master schedule]# kubectl label nodes node1 distype=fjw --overwrite
node/node1 labeled
#去除标签
[root@master schedule]# kubectl label nodes node1 distype-
node/node1 unlabeled

[!NOTE]

当pod运行后node节点发生变化，不会影响已经运行的node；

当pod寻找不到对应的label的节点就会设为pending，可把node标签添加或改为对应的label

2.5 affinity（亲和性）

官方文档 ：

https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node

2.5.1 亲和与反亲和

• nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。
• 使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。

2.5.2 nodeAffinity节点亲和

• 那个节点服务指定条件就在那个节点运行
• requiredDuringSchedulingIgnoredDuringExecution 必须满足，但不会影响已经调度
• preferredDuringSchedulingIgnoredDuringExecution 倾向满足，在无法满足情况下也会调度pod
  • IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。
• nodeaffinity还支持多种规则匹配条件的配置如

匹配规则	功能
ln	label 的值在列表内
Notln	label 的值不在列表内
Gt	label 的值大于设置的值，不支持Pod亲和性
Lt	label 的值小于设置的值，不支持pod亲和性
Exists	设置的label 存在
DoesNotExist	设置的 label 不存在

nodeAffinity示例

[root@master schedule]# kubectl get nodes node1 --show-labels
NAME    STATUS   ROLES    AGE   VERSION   LABELS
node1   Ready    <none>   8d    v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
[root@master schedule]# kubectl get nodes node2 --show-labels
NAME    STATUS   ROLES    AGE   VERSION   LABELS
node2   Ready    <none>   8d    v1.30.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=fc,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

[root@master schedule]# cat test.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
              - fc
  containers:
  - image: myapp:v1
    name: testpod

NAME      READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
testpod   1/1     Running   0          8s    10.244.104.4   node2   <none>           <none>

2.5.3 podAffinity(pod的亲和)

• 那个节点有符合条件的POD就在那个节点运行
• podAffinity 主要解决POD可以和哪些POD部署在同一个节点中的问题
• podAntiAffinity主要解决POD不能和哪些POD部署在同一个节点中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
• Pod 间亲和与反亲和在与更高级别的集合（例如 ReplicaSets，StatefulSets，Deployments 等）一起使用时，
• Pod 间亲和与反亲和需要大量的处理，这可能会显著减慢大规模集群中的调度。

1.PodAffinity亲和性

[root@master schedule]# kubectl get  pods --show-labels
NAME      READY   STATUS    RESTARTS   AGE     LABELS
testpod   1/1     Running   0          9m22s   run=testpod

[root@master schedule]# cat 1-test.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  affinity:
    podAffinity:			#亲和
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: run							#与testpod的标签一致亲和testpod
            operator: In
            values:
              - testpod
        topologyKey: "kubernetes.io/hostname"
  containers:
  - image: nginx
    name: nginx1
    
[root@master schedule]# kubectl apply -f 1-test.yml
NAME      READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
nginx     1/1     Running   0          2m14s   10.244.166.138   node1   <none>           <none>
testpod   1/1     Running   0          2m33s   10.244.166.137   node1   <none>           <none>

#可以把testpod运行在node2上，然后重启nginx也会运行在node2亲和testpod

2.Podantiaffinity(pod反亲和)

[root@master schedule]# cat 1-test.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  affinity:
    podAntiAffinity:			#反亲和
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: run
            operator: In
            values:
              - testpod
        topologyKey: "kubernetes.io/hostname"
  containers:
  - image: nginx
    name: nginx1
   
 
[root@master schedule]# kubectl delete -f 1-test.yml
[root@master schedule]# kubectl apply -f 1-test.yml

Every 1.0s: kubectl get pods -o wide                                                         master: Tue Aug 19 13:00:55 2025
NAME      READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
nginx     1/1     Running   0          85s     10.244.104.6     node2   <none>           <none>
testpod   1/1     Running   0          6m37s   10.244.166.137   node1   <none>           <none>

2.6 Taints（污点模式，禁止调度）

• Taints(污点)是Node的一个属性，设置了Taints后，默认Kubernetes是不会将Pod调度到这个Node上
• Kubernetes如果为Pod设置Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去
• 可以使用命令 kubectl taint 给节点增加一个 taint：

$ kubectl taint nodes <nodename> key=string:effect   #命令执行方法
$ kubectl taint nodes node1 key=value:NoSchedule    #创建
$ kubectl describe nodes server1 | grep Taints        #查询
$ kubectl taint nodes node1 key-                  #删除

其中[effect] 可取值：

effect值	解释
NoSchedule	POD 不会被调度到标记为 taints 节点
PreferNoSchedule	NoSchedule 的软策略版本，尽量不调度到此节点
NoExecute	如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出

2.6.1 Taints示例

#建立控制器并运行
[root@k8s-master scheduler]# vim example6.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx

[root@k8s-master scheduler]# kubectl apply -f example6.yml
deployment.apps/web created

root@k8s-master scheduler]# kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
web-7c56dcdb9b-9wwdg   1/1     Running   0          25s   10.244.36.68     k8s-node1   <none>           <none>
web-7c56dcdb9b-qsx6w   1/1     Running   0          25s   10.244.169.137   k8s-node2   <none>           <none>

#设定污点为NoSchedule
[root@k8s-master scheduler]# kubectl taint node k8s-node1 name=lee:NoSchedule
node/k8s-node1 tainted
[root@k8s-master scheduler]# kubectl describe nodes k8s-node1 | grep Tain
Taints:             name=lee:NoSchedule

#控制器增加pod
[root@k8s-master scheduler]# kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE     IP               NODE        NOMINATED NODE   READINESS GATES
web-7c56dcdb9b-4l759   1/1     Running   0          6s      10.244.169.140   k8s-node2   <none>           <none>
web-7c56dcdb9b-9wwdg   1/1     Running   0          6m35s   10.244.36.68     k8s-node1   <none>           <none>
web-7c56dcdb9b-bqd75   1/1     Running   0          6s      10.244.169.141   k8s-node2   <none>           <none>
web-7c56dcdb9b-m8kx8   1/1     Running   0          6s      10.244.169.138   k8s-node2   <none>           <none>
web-7c56dcdb9b-qsx6w   1/1     Running   0          6m35s   10.244.169.137   k8s-node2   <none>           <none>
web-7c56dcdb9b-rhft4   1/1     Running   0          6s      10.244.169.139   k8s-node2   <none>           <none>


#设定污点为NoExecute
[root@k8s-master scheduler]# kubectl taint node k8s-node1 name=lee:NoExecute
node/k8s-node1 tainted
[root@k8s-master scheduler]# kubectl describe nodes k8s-node1 | grep Tain
Taints:             name=lee:NoExecute

[root@k8s-master scheduler]# kubectl get pod -o wide
NAME                   READY   STATUS              RESTARTS   AGE     IP               NODE        NOMINATED NODE   READINESS GATES
web-7c56dcdb9b-4l759   1/1     Running             0          108s    10.244.169.140   k8s-node2   <none>           <none>
web-7c56dcdb9b-bqd75   1/1     Running             0          108s    10.244.169.141   k8s-node2   <none>           <none>
web-7c56dcdb9b-m8kx8   1/1     Running             0          108s    10.244.169.138   k8s-node2   <none>           <none>
web-7c56dcdb9b-mhkhl   0/1     ContainerCreating   0          14s     <none>           k8s-node2   <none>           <none>
web-7c56dcdb9b-qsx6w   1/1     Running             0          8m17s   10.244.169.137   k8s-node2   <none>           <none>
web-7c56dcdb9b-rhft4   1/1     Running             0          108s    10.244.169.139   k8s-node2   <none>           <none>


#删除污点
[root@k8s-master scheduler]# kubectl taint node k8s-node1 name-
node/k8s-node1 untainted
[root@k8s-master scheduler]#
[root@k8s-master scheduler]# kubectl describe nodes k8s-node1 | grep Tain
Taints:             <none>

2.6.2tolerations（污点容忍）

• tolerations中定义的key、value、effect，要与node上设置的taint保持一直：
  • 如果 operator 是 Equal ，则key与value之间的关系必须相等。
  • 如果 operator 是 Exists ，value可以省略
  • 如果不指定operator属性，则默认值为Equal。
• 还有两个特殊值：
  • 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。
  • 当不指定effect ，则匹配所有的effect

2.6.3 污点容忍示例

#设定节点污点
[root@k8s-master scheduler]# kubectl taint node k8s-node1 name=lee:NoExecute
node/k8s-node1 tainted
[root@k8s-master scheduler]# kubectl taint node k8s-node2 nodetype=bad:NoSchedule
node/k8s-node2 tainted


[root@k8s-master scheduler]# vim example7.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx
        name: nginx
      
      tolerations:				#容忍所有污点
      - operator: Exists
    
	  tolerations:				#容忍effect为Noschedule的污点
      - operator: Exists
        effect: NoSchedule
	
	  tolerations:				#容忍指定kv的NoSchedule污点
      - key: nodetype
        value: bad
        effect: NoSchedule