当前位置: 首页 > article >正文

k8s下的网络通信与调度

目录

一、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的污点

情节三  容忍指定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)
VTEPVXLAN Tunnel End Point(虚拟隧道端点),在Flannel中 VNI的默认值是1,这也是为什么宿主机的VTEP设备都叫flannel.1的原因
Cni0网桥设备,每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0,另一端是Cni0网桥中的端口(网卡)
Flannel.1TUN设备(虚拟网卡),用来进行 vxlan 报文的处理(封包和解包)。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端
Flanneldflannel在每个主机中运行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:
  - image: reg.zx.org/library/myapp:v1
    name: testpod

[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还支持多种规则匹配条件的配置如

匹配规则功能
lnlabel 的值在列表内
Notlnlabel 的值不在列表内
Gtlabel 的值大于设置的值,不支持Pod亲和性
Ltlabel 的值小于设置的值,不支持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值解释
NoSchedulePOD 不会被调度到标记为 taints 节点
PreferNoScheduleNoSchedule 的软策略版本,尽量不调度到此节点
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


http://www.kler.cn/news/316127.html

相关文章:

  • 苹果CMS插件:优化蜘蛛访问内容,提升百度收录率
  • 供方软件供应链安全保障要求及开源场景对照自评表(下)
  • 【JVM】类加载
  • 玩转RabbitMQ声明队列交换机、消息转换器
  • 用终端请求接口
  • [数据集][目标检测]手机识别检测数据集VOC+YOLO格式9997张1类别
  • 283. 移动零
  • Linux:权限管理
  • mysql等保数据库命令
  • 【动态规划】两个数组的 dp 问题二
  • 828华为云征文 | 云服务器Flexus X实例:开源项目 LangChain 部署,实例测试
  • 演示:基于WPF的DrawingVisual开发的Chart图表和表格绘制
  • 【编程基础知识】mysql是怎样执行一条sql语句的,涉及到哪些环节步骤是,mysql的整体体系结构是啥样的,有哪些组件
  • 如何使用ssm实现大湾区旅游推荐系统的设计与实现+vue
  • (一)Lambda-Stream流
  • 前端常用的设计模式
  • C++ -缺省参数-详解
  • Exploring Large Language Models for Knowledge Graph Completion
  • 【设计模式】工厂模式、单例模式、观察者模式、发布订阅模式
  • C++_继承详解
  • 构建智能化直播美颜工具:视频美颜SDK的开发指南
  • 灯塔:JavaScript
  • C++:多态(协变,override,final,纯虚函数抽象类,原理)
  • 10 vue3之全局组件,局部组件,递归组件,动态组件
  • 博睿谷IT认证-订阅试学习
  • 利用H5无插件播放RTSP流的实现方案
  • Vue3 路由传参:玩转 params,让页面交互更流畅!
  • 什么是堡垒机?运维为什么需要堡垒机?
  • ES 索引或索引模板
  • 【图像匹配】基于SIFT算法的图像匹配,matlab实现