k8s下的网络通信与调度

周湘zx2024-09-23 16:30

目录

一、k8s网络通信

1、k8s通信整体架构

2、flannel网络插件

（1）flannel跨主机通信原理

（2）flannel支持的后端模式

3、calico网络插件

（1）简介

（2）网络架构

（3）部署calico

二、k8s调度（Scheduling）

1、调度在kubernetes中的作用

2、调度原理

3、调度器种类

4、常用调度方法

（1）nodename

（2）Nodeselector

5、affinity（亲和性）

（1）亲和与反亲和

（2）nodeAffinity节点亲和

（3）podaffinity（pod的亲和）

（4）Podantiaffinity（pod反亲和）

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

示例

tolerations（污点容忍）

[情形一 设置容忍所有污点](#情形一 设置容忍所有污点)

[情节二 容忍effect为Noschedule的污点](#情节二 容忍effect为Noschedule的污点)

[情节三 容忍指定kv的NoSchedule污点](#情节三 容忍指定kv的NoSchedule污点)

一、k8s网络通信

1、k8s通信整体架构

  • k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等

  • CNI插件存放位置：cat /etc/cni/net.d/10-flannel.conflist

  • 插件使用的解决方案如下

    • 虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。

    • 多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。

    • 硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

  • 容器间通信：

    • 同一个pod内的多个容器间的通信，通过lo即可实现pod之间的通信

    • 同一节点的pod之间通过cni网桥转发数据包。

    • 不同节点的pod之间的通信需要网络插件支持

  • pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换

  • pod和外网通信：iptables的MASQUERADE

  • Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）

2、flannel网络插件

插件 功能
VXLAN 即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过"隧道"机制，构建出覆盖网络（Overlay Network）
VTEP VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因
Cni0 网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）
Flannel.1 TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端
Flanneld flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息

（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@k8s-master ~]# ip route
    default via 172.25.254.2 dev eth0 proto static metric 100
    172.25.254.0/24 dev eth0 proto kernel scope link src 172.25.254.200 metric 100

    #桥接转发数据库
    [root@k8s-master ~]# bridge fdb
    01:00:5e:00:00:01 dev eth0 self permanent
    01:00:5e:00:00:fb dev eth0 self permanent
    33:33:00:00:00:01 dev eth0 self permanent
    33:33:00:00:00:fb dev eth0 self permanent
    33:33:ff:8b:58:76 dev eth0 self permanent
    33:33:00:00:00:01 dev docker0 self permanent
    01:00:5e:00:00:6a dev docker0 self permanent
    33:33:00:00:00:6a dev docker0 self permanent
    01:00:5e:00:00:01 dev docker0 self permanent
    02:42:9c:dc:8c:61 dev docker0 vlan 1 master docker0 permanent
    02:42:9c:dc:8c:61 dev docker0 master docker0 permanent
    06:f2:9c:9f:ae:ff dev flannel.1 dst 172.25.254.20 self permanent
    9e:f7:ac:55:c9:4d dev flannel.1 dst 172.25.254.10 self permanent
    01:00:5e:00:00:6a dev cni0 self permanent
    01:00:5e:00:00:01 dev cni0 self permanent
    33:33:00:00:00:6a dev cni0 self permanent
    33:33:00:00:00:01 dev cni0 self permanent
    4a:2e:ca:b5:48:a8 dev cni0 vlan 1 master cni0 permanent
    4a:2e:ca:b5:48:a8 dev cni0 master cni0 permanent
    33:33:00:00:00:01 dev vethad69e73d self permanent
    01:00:5e:00:00:01 dev vethad69e73d self permanent
    33:33:ff:4f:a9:02 dev vethad69e73d self permanent
    33:33:00:00:00:fb dev vethad69e73d self permanent
    33:33:00:00:00:01 dev veth91ca1a5b self permanent
    01:00:5e:00:00:01 dev veth91ca1a5b self permanent
    33:33:ff:d7:f8:4e dev veth91ca1a5b self permanent
    33:33:00:00:00:fb dev veth91ca1a5b self permanent
    33:33:00:00:00:01 dev kube-ipvs0 self permanent

    #arp列表
    [root@k8s-master ~]# arp -n
    Address HWtype HWaddress Flags Mask Iface
    172.25.254.10 ether 00:0c:29:40:7b:63 C eth0
    172.25.254.1 ether 00:50:56:c0:00:08 C eth0
    172.25.254.100 ether 00:0c:29:13:fd:c6 C eth0
    172.25.254.20 ether 00:0c:29:16:26:1b C eth0
    172.25.254.2 ether 00:50:56:e7:b1:57 C eth0

（2）flannel支持的后端模式

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

更改flannel的默认模式

[root@k8s-master ~]# kubectl -n kube-flannel edit cm kube-flannel-cfg

#重启pod
[root@k8s-master ~]# kubectl -n kube-flannel delete pod --all

3、calico网络插件

官网：

Install Calico networking and network policy for on-premises deployments | Calico Documentation

（1）简介

  • 纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。

  • Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

（2）网络架构

  • Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。

  • BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里

（3）部署calico

删除flannel插件
[root@k8s-master ~]# kubectl delete  -f kube-flannel.yml
删除所有节点上flannel配置文件,避免冲突
[root@k8s-master & node1-2 ~]# rm -rf /etc/cni/net.d/10-flannel.conflist
下载部署文件
[root@k8s-master calico]# curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.1/manifests/calico-typha.yaml -o calico.yaml
下载镜像上传至仓库
[root@k8s-master ~]# mkdir calico
[root@k8s-master ~]# cd calico/
[root@k8s-master calico]# ls
calico-3.28.1.tar  calico.yaml
[root@k8s-master calico]# docker load -i calico-3.28.1.tar 
6b2e64a0b556: Loading layer   3.69MB/3.69MB
38ba74eb8103: Loading layer  205.4MB/205.4MB
5f70bf18a086: Loading layer  1.024kB/1.024kB
Loaded image: calico/cni:v3.28.1
3831744e3436: Loading layer  366.9MB/366.9MB
Loaded image: calico/node:v3.28.1
4f27db678727: Loading layer  75.59MB/75.59MB
Loaded image: calico/kube-controllers:v3.28.1
993f578a98d3: Loading layer  67.61MB/67.61MB
Loaded image: calico/typha:v3.28.1

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

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

更改yml设置，修改镜像位置等信息

[root@k8s-master calico]# vim calico.yaml
[root@k8s-master calico]# kubectl apply -f calico.yaml
[root@k8s-master calico]# kubectl -n kube-system get pods
测试
[root@k8s-master calico]# kubectl run web --image reg.zx.org/library/myapp:v1
pod/web created
[root@k8s-master calico]# kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS      AGE   IP               NODE               NOMINATED NODE   READINESS GATES
testpod   1/1     Running   1 (72m ago)   77m   10.244.2.117     k8s-node2.zx.org   <none>           <none>
web       1/1     Running   0             9s    10.244.101.129   k8s-node1.zx.org   <none>           <none>

[root@k8s-master calico]# curl 10.244.101.129
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

二、k8s调度（Scheduling）

1、调度在kubernetes中的作用

  • 调度是指将未调度的Pod自动分配到集群中的节点的过程

  • 调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod

  • 调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行

2、调度原理

  • 创建Pod

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

  • 调度器监视Pod

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

  • 选择节点

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

  • 绑定Pod到节点

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

  • 节点启动Pod

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

3、调度器种类

  • 默认调度器（Default Scheduler）：

    • 是Kubernetes中的默认调度器，负责对新创建的Pod进行调度，并将Pod调度到合适的节点上。

  • 自定义调度器（Custom Scheduler）：

    • 是一种自定义的调度器实现，可以根据实际需求来定义调度策略和规则，以实现更灵活和多样化的调度功能。

  • 扩展调度器（Extended Scheduler）：

    • 是一种支持调度器扩展器的调度器实现，可以通过调度器扩展器来添加自定义的调度规则和策略，以实现更灵活和多样化的调度功能。

  • kube-scheduler是kubernetes中的默认调度器，在kubernetes运行后会自动在控制节点运行

4、常用调度方法

（1）nodename

  • nodeName 是节点选择约束的最简单方法，但一般不推荐

  • 如果 nodeName 在 PodSpec 中指定了，则它优先于其他的节点选择方法

  • 使用 nodeName 来选择节点的一些限制

    • 如果指定的节点不存在。

    • 如果指定的节点没有资源来容纳 pod，则pod 调度失败。

    • 云环境中的节点名称并非总是可预测或稳定的

      [root@k8s-master Scheduler]# kubectl run testpod --image reg.zx.org/library/myapp:v1 --dry-run=client -o yaml > pod1.yml
      [root@k8s-master Scheduler]# vim pod1.yml
      [root@k8s-master Scheduler]# kubectl apply -f pod1.yml
      pod/testpod created
      [root@k8s-master Scheduler]# kubectl get pods -o wide
      NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
      testpod 1/1 Running 0 9s 10.244.207.67 k8s-node2.zx.org <none> <none>
      [root@k8s-master Scheduler]# cat pod1.yml
      apiVersion: v1
      kind: Pod
      metadata:
      labels:
      run: testpod
      name: testpod
      spec:
      containers:

[root@k8s-master Scheduler]# 
[root@k8s-master Scheduler]# vim pod1.yml 
[root@k8s-master Scheduler]# cat pod1.yml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  nodeName: k8s-node1.zx.org
  containers:
  - image: reg.zx.org/library/myapp:v1
    name: testpod
[root@k8s-master Scheduler]# kubectl apply -f pod1.yml 
pod/testpod created
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE   IP               NODE               NOMINATED NODE   READINESS GATES
testpod   1/1     Running   0          14s   10.244.101.131   k8s-node1.zx.org   <none>           <none>

（2）Nodeselector

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

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

    kubectl label nodes k8s-node1 lab=zx

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

    [root@k8s-master Scheduler]# cp pod1.yml pod2.yml
    [root@k8s-master Scheduler]# vim pod2.yml
    [root@k8s-master Scheduler]# kubectl get nodes --show-labels

    [root@k8s-master Scheduler]# kubectl label nodes k8s-node1.zx.org lab=zx #设定节点标签
    [root@k8s-master Scheduler]# kubectl get nodes --show-labels
    NAME STATUS ROLES AGE VERSION LABELS
    k8s-node1.zx.org Ready <none> 3d6h v1.30.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node1.zx.org,kubernetes.io/os=linux,lab=zx

    [root@k8s-master Scheduler]# kubectl label nodes k8s-node1.zx.org name- # 删除标签

    [root@k8s-master Scheduler]# vim pod2.yml
    [root@k8s-master Scheduler]# kubectl apply -f pod2.yml
    pod/testpod created
    [root@k8s-master Scheduler]# kubectl get pods -o wide
    NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
    testpod 1/1 Running 0 7s 10.244.101.132 k8s-node1.zx.org <none> <none>
    [root@k8s-master Scheduler]# cat pod2.yml
    apiVersion: v1
    kind: Pod
    metadata:
    labels:
    run: testpod
    name: testpod
    spec:
    nodeSelector:
    lab: zx
    containers:
    - image: reg.zx.org/library/myapp:v1
    name: testpod

5、affinity（亲和性）

官方文档 ：

将 Pod 指派给节点 | Kubernetes

（1）亲和与反亲和

  • nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。

  • 使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。

（2）nodeAffinity节点亲和

  • 那个节点服务指定条件就在那个节点运行

  • requiredDuringSchedulingIgnoredDuringExecution 必须满足，但不会影响已经调度

  • preferredDuringSchedulingIgnoredDuringExecution 倾向满足，在无法满足情况下也会调度pod

    • IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。

  • nodeaffinity还支持多种规则匹配条件的配置如

匹配规则 功能
ln label 的值在列表内
Notln label 的值不在列表内
Gt label 的值大于设置的值，不支持Pod亲和性
Lt label 的值小于设置的值，不支持pod亲和性
Exists 设置的label 存在
DoesNotExist 设置的 label 不存在 
[root@k8s-master Scheduler]# cp pod1.yml pod3.yml
[root@k8s-master Scheduler]# vim pod3.yml 
[root@k8s-master Scheduler]# kubectl apply -f pod3.yml 
[root@k8s-master Scheduler]# cat pod3.yml 
apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:
  - name: nginx
    image: reg.zx.org/library/nginx:latest
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: disk
               operator: In
               values:
                 - ssd

（3）podaffinity（pod的亲和）

  • 那个节点有符合条件的POD就在那个节点运行

  • podAffinity 主要解决POD可以和哪些POD部署在同一个节点中的问题

  • podAntiAffinity主要解决POD不能和哪些POD部署在同一个节点中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。

  • Pod 间亲和与反亲和在与更高级别的集合（例如 ReplicaSets，StatefulSets，Deployments 等）一起使用时，

  • Pod 间亲和与反亲和需要大量的处理，这可能会显著减慢大规模集群中的调度。

    [root@k8s-master Scheduler]# vim pod4.yml
    [root@k8s-master Scheduler]# kubectl apply -f pod4.yml
    deployment.apps/nginx-deployment created
    [root@k8s-master Scheduler]# kubectl get pods -o wide
    NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
    nginx-deployment-6fd5d564df-r57cc 1/1 Running 0 8s 10.244.207.69 k8s-node2.zx.org <none> <none>
    nginx-deployment-6fd5d564df-r8bb7 1/1 Running 0 8s 10.244.207.68 k8s-node2.zx.org <none> <none>
    nginx-deployment-6fd5d564df-tcwpc 1/1 Running 0 8s 10.244.207.70 k8s-node2.zx.org <none> <none>
    [root@k8s-master Scheduler]# cat pod4.yml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: nginx-deployment
    labels:
    app: nginx
    spec:
    replicas: 3
    selector:
    matchLabels:
    app: nginx
    template:
    metadata:
    labels:
    app: nginx
    spec:
    containers:
    - name: nginx
    image: reg.zx.org/library/nginx:latest
    affinity:
    podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
    matchExpressions:
    - key: app
    operator: In
    values:
    - nginx
    topologyKey: "kubernetes.io/hostname"

（4）Podantiaffinity（pod反亲和）

[root@k8s-master Scheduler]# cp pod4.yml pod5.yml
[root@k8s-master Scheduler]# vim pod5.yml 
[root@k8s-master Scheduler]# kubectl apply -f pod5.yml 
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE               NOMINATED NODE   READINESS GATES
nginx-deployment-69897b9dc9-7kvnb   0/1     Pending   0          13s   <none>           <none>             <none>           <none>
nginx-deployment-69897b9dc9-dnkcl   1/1     Running   0          13s   10.244.101.135   k8s-node1.zx.org   <none>           <none>
nginx-deployment-69897b9dc9-ngqnw   1/1     Running   0          13s   10.244.207.71    k8s-node2.zx.org   <none>           <none>

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 设置，会直接被逐出

示例

[root@k8s-master Scheduler]# vim pod6.yml
[root@k8s-master Scheduler]# kubectl apply -f pod6.yml 
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP               NODE               NOMINATED NODE   READINESS GATES
web-55b779fb6-6lw55   1/1     Running   0          6s    10.244.101.136   k8s-node1.zx.org   <none>           <none>
web-55b779fb6-8lpfw   1/1     Running   0          6s    10.244.207.72    k8s-node2.zx.org   <none>           <none>
[root@k8s-master Scheduler]# kubectl taint node k8s-node1.zx.org name=zx:NoSchedule
node/k8s-node1.zx.org tainted
[root@k8s-master Scheduler]# kubectl describe nodes k8s-node1.zx.org | grep Tain
Taints:             name=zx:NoSchedule
[root@k8s-master Scheduler]# kubectl delete -f pod6.yml 
deployment.apps "web" deleted
[root@k8s-master Scheduler]# kubectl apply -f pod6.yml 
deployment.apps/web created
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP              NODE               NOMINATED NODE   READINESS GATES
web-55b779fb6-chsth   1/1     Running   0          15s   10.244.207.73   k8s-node2.zx.org   <none>           <none>
web-55b779fb6-v8lt8   1/1     Running   0          15s   10.244.207.74   k8s-node2.zx.org   <none>           <none>
[root@k8s-master Scheduler]# cat pod6.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: reg.zx.org/library/nginx:latest
        name: nginx

#设定污点为NoExecute
[root@k8s-master Scheduler]# kubectl taint node k8s-node1.zx.org name=zx:NoExecute
node/k8s-node1.zx.org tainted
[root@k8s-master Scheduler]# kubectl describe nodes k8s-node1 | grep Tain
Taints:             name=zx:NoExecute
[root@k8s-master Scheduler]# kubectl delete -f pod6.yml 
deployment.apps "web" deleted
[root@k8s-master Scheduler]# kubectl apply -f pod6.yml 
deployment.apps/web created
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP              NODE               NOMINATED NODE   READINESS GATES
web-55b779fb6-6xspv   1/1     Running   0          7s    10.244.207.77   k8s-node2.zx.org   <none>           <none>
web-55b779fb6-kx2qs   1/1     Running   0          7s    10.244.207.78   k8s-node2.zx.org   <none>           <none>

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

tolerations（污点容忍）

  • tolerations中定义的key、value、effect，要与node上设置的taint保持一直：

    • 如果 operator 是 Equal ，则key与value之间的关系必须相等。

    • 如果 operator 是 Exists ，value可以省略

    • 如果不指定operator属性，则默认值为Equal。

  • 还有两个特殊值：

    • 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。

    • 当不指定effect ，则匹配所有的effect

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

情形一 设置容忍所有污点
[root@k8s-master Scheduler]# vim pod7.yml 
[root@k8s-master Scheduler]# kubectl apply -f pod7.yml 
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE                NOMINATED NODE   READINESS GATES
web-6577586697-6cxz8   1/1     Running   0          12s   10.244.207.84    k8s-node2.zx.org    <none>           <none>
web-6577586697-8277s   1/1     Running   0          12s   10.244.207.85    k8s-node2.zx.org    <none>           <none>
web-6577586697-9pd9w   1/1     Running   0          12s   10.244.116.201   k8s-master.zx.org   <none>           <none>
web-6577586697-kjstm   1/1     Running   0          12s   10.244.116.202   k8s-master.zx.org   <none>           <none>
web-6577586697-xh95h   1/1     Running   0          12s   10.244.101.143   k8s-node1.zx.org    <none>           <none>
web-6577586697-z82s7   1/1     Running   0          12s   10.244.101.142   k8s-node1.zx.org    <none>           <none>
[root@k8s-master Scheduler]# cat pod7.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: reg.zx.org/library/nginx:latest
        name: nginx
      tolerations:
      - operator: Exists
情形二 容忍effect为Noschedule的污点
#容忍effect为Noschedule的污点
[root@k8s-master Scheduler]# vim pod7.yml 
[root@k8s-master Scheduler]# kubectl delete -f pod7.yml 
deployment.apps "web" deleted
[root@k8s-master Scheduler]# kubectl apply -f pod7.yml 
deployment.apps/web created
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP               NODE                NOMINATED NODE   READINESS GATES
web-6cd9968f87-8ghgv   1/1     Running   0          17s   10.244.207.87    k8s-node2.zx.org    <none>           <none>
web-6cd9968f87-drtx7   1/1     Running   0          17s   10.244.207.86    k8s-node2.zx.org    <none>           <none>
web-6cd9968f87-fhgks   1/1     Running   0          17s   10.244.116.205   k8s-master.zx.org   <none>           <none>
web-6cd9968f87-fj2b8   1/1     Running   0          17s   10.244.116.204   k8s-master.zx.org   <none>           <none>
web-6cd9968f87-jt8tf   1/1     Running   0          17s   10.244.207.88    k8s-node2.zx.org    <none>           <none>
web-6cd9968f87-vx6lz   1/1     Running   0          17s   10.244.116.203   k8s-master.zx.org   <none>           <none>
[root@k8s-master Scheduler]# cat pod7.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: reg.zx.org/library/nginx:latest
        name: nginx
      tolerations:
      - operator: Exists
        effect: NoSchedule
情形三 容忍指定kv的NoSchedule污点
#容忍指定kv的NoSchedule污点
[root@k8s-master Scheduler]# kubectl get pods -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP              NODE               NOMINATED NODE   READINESS GATES
web-55c8bd688d-99w74   1/1     Running   0          17s   10.244.207.91   k8s-node2.zx.org   <none>           <none>
web-55c8bd688d-9ml5g   1/1     Running   0          17s   10.244.207.93   k8s-node2.zx.org   <none>           <none>
web-55c8bd688d-cq2d8   1/1     Running   0          17s   10.244.207.92   k8s-node2.zx.org   <none>           <none>
web-55c8bd688d-lh6m5   1/1     Running   0          17s   10.244.207.94   k8s-node2.zx.org   <none>           <none>
web-55c8bd688d-r2bdk   1/1     Running   0          17s   10.244.207.89   k8s-node2.zx.org   <none>           <none>
web-55c8bd688d-wbv9d   1/1     Running   0          17s   10.244.207.90   k8s-node2.zx.org   <none>           <none>
[root@k8s-master Scheduler]# cat pod7.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: reg.zx.org/library/nginx:latest
        name: nginx
      tolerations:
      - key: nodetype
        value: bad
        effect: NoSchedule
相关推荐
皮小白17 分钟前
linux国产机器-麒麟V10系统VNCserver的安装及使用
linux·运维·服务器
长安不及十里37 分钟前
操作日志设计（一） Binlog 方案（Canal+Mq）
分布式·后端·学习·云原生
龙行天538 分钟前
限时特惠，香港服务器，低至53元/年
运维·服务器
w_outlier1 小时前
UDP_TCP
linux·c++·网络协议·udp·tcp
豆是浪个1 小时前
Linux(Centos 7.6)命令详解：ls
linux·运维·服务器
Mr.kanglong1 小时前
【Linux】传输层协议UDP
linux·运维·udp
鱼忆梦1 小时前
Debian安装配置MariaDB
运维·debian·mariadb
cui_win1 小时前
Linux性能优化-系列文章-汇总
linux·网络·安全·性能优化
新知图书1 小时前
Linux C/C++编程-获得套接字地址、主机名称和主机信息
linux·运维·服务器
猫猫的小茶馆1 小时前
【数据结构】栈与队列（FIFO）
linux·c语言·数据结构·算法·链表
热门推荐
01半导体应用系统一些小知识收集(strip&wafer mapping,EAP&scada)02新手学习VR全景需要知道的几个问题03HCIA-datacom数通题库和录播视频资料04Coze扣子平台完整体验和实践（附国内和国际版对比）05【漏洞复现】CVE-2015-3337 Arbitrary File Reading06玄机平台应急响应—webshell查杀07Installing CMake (安装 CMake)08docker安装启动问题解决排查09优化手机性能，解决卡顿问题：关闭这3个微信开关，释放内存空间10Matlab|参与辅助服务的用户侧储能优化配置及经济分析