• Pod的调度


    在默认情况下,一个Pod在哪个Node节点上运行,是由Scheduler组件采用相应的算法计算出来的,这个过程是不受人工控制的。但是在实际使用中,这并不满足需求,因为很多情况下,我们想控制某些Pod到达某些节点上,那么应该怎么做?这就要求了解Kubernetes对Pod的调度规则,Kubernetes提供了四大类调度方式。

    • 自动调度:运行在哪个Node节点上完全由Scheduler经过一系列的算法计算得出。
    • 定向调度:NodeName、NodeSelector。
    • 亲和性调度:NodeAffinity、PodAffinity、PodAntiAffinity。
    • 污点(容忍)调度:Taints、Toleration。

    一、定向调度

    定向调度,指的是利用在Pod上声明的nodeName或nodeSelector,以此将Pod调度到期望的Node节点上。注意,这里的调度是强制的,这就意味着即使要调度的目标Node不存在,也会向上面进行调度,只不过Pod运行失败而已。

    1、nodeName

    nodeName用于强制约束将Pod调度到指定的name的Node节点上。这种方式,其实是直接跳过Scheduler的调度逻辑,直接将Pod调度到指定名称的节点。

    首先创建一个pod-nodename.yaml文件,内容如下:

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodename
      namespace: dev
      labels:
        user: Negan
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1  # 容器需要的镜像地址
          imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
          ports:
            - name: nginx-port  # 端口名称,如果执行,必须保证name在Pod中是唯一的
              containerPort: 80 # 容器要监听的端口
              protocol: TCP # 端口协议
      nodeName: node1  # 指定调度到node1上
    

    创建和查看Pod的状态,我们会发现Pod所在的Node节点就是我们指定的node1节点。

    # 创建pod
    kubectl create -f pod_nodename.yaml
    
    # 查看
    kubectl get pod pod-nodename -n dev -o wide
    NAME           READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
    pod-nodename   1/1     Running   0          27s   10.244.1.18   node1   <none>           <none>
    

    当然我们也可以将pod调度到不存在node上,pod肯定也是不能正常运行。

    # 删除pod
    kubectl delete -f pod_nodename.yaml
    
    # 修改pod_nodename.yaml
    # 将nodeName:node1 修改为node3 (node3不存在)
    
    # 创建和查看状态
    kubectl create -f pod_nodename.yaml
    
    kubectl get pods pod-nodename -n dev -o wide
    
    # 我们发现pod的状态时挂起状态
    NAME           READY   STATUS    RESTARTS   AGE   IP       NODE    NOMINATED NODE   READINESS GATES
    pod-nodename   0/1     Pending   0          6s    <none>   node3   <none>           <none>
    

    2、nodeSelector

    nodeSelector用于将Pod调度到添加了指定标签的Node节点上,它是通过Kubernetes的label-selector机制实现的,换言之,在Pod创建之前,会由Scheduler使用MatchNodeSelector调度策略进行label匹配,找出目标node,然后将Pod调度到目标节点,该匹配规则是强制约束。

    首先给node节点添加标签

    kubectl label node node1 env=pro # 给node1添加标签为env=pro
    kubectl label node node2 env=debug # 给node2添加标签为env=debug
    
    # 可以看到我们已经添加上了相应的标签
    kubectl get nodes --show-labels
    NAME     STATUS   ROLES    AGE   VERSION   LABELS
    master   Ready    master   2d    v1.18.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/master=
    node1    Ready    <none>   2d    v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env=pro,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
    node2    Ready    <none>   2d    v1.18.0   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env=debug,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux
    
    

    创建pod_nodeselector.yaml文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodeselector
      namespace: dev
      labels:
        user: Negan
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1  # 容器需要的镜像地址
          imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
          ports:
            - name: nginx-port  # 端口名称,如果执行,必须保证name在Pod中是唯一的
              containerPort: 80 # 容器要监听的端口
              protocol: TCP # 端口协议
      nodeSelector:
        env: debug
    

    查看Pod的状态:

    kubectl get pod pod-nodeselector -n dev -o wide
    
    # 发现成功调度到node2上
    NAME               READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
    pod-nodeselector   1/1     Running   0          21s   10.244.2.20   node2   <none>           <none>
    

    同样,我们如要调度要不存在的标签上,会发生什么情况:

    # 删除pod
    kubectl delete -f pod_nodeselector.yaml
    
    # 修改pod_nodeselector.yaml文件
    # 将debug改为debug1 
    
    # 创建和查看
    kubectl get pod pod-nodeselector -n dev -o wide
    # pod的状态为挂起状态
    NAME               READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
    pod-nodeselector   0/1     Pending   0          24s   <none>   <none>   <none>           <none>
    

    二、亲和性调度

    虽然定向调度的两种方式,使用起来非常方便,但是也有一定的问题,那就是如果没有满足条件的Node,那么Pod将不会被运行,即使在集群中还有可用的Node列表也不行,这就限制了它的使用场景。

    基于上面的问题,Kubernetes还提供了一种亲和性调度(Affinity)。它在nodeSelector的基础之上进行了扩展,可以通过配置的形式,实现优先选择满足条件的Node进行调度,如果没有,也可以调度到不满足条件的节点上,使得调度更加灵活。

    Affinity主要分为三类:

    • nodeAffinity(node亲和性):以Node为目标,解决Pod可以调度到那些Node的问题。
    • podAffinity(pod亲和性):以Pod为目标,解决Pod可以和那些已存在的Pod部署在同一个拓扑域中的问题。
    • podAntiAffinity(pod反亲和性):以Pod为目标,解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。

    亲和性:如果两个应用频繁交互,那么就有必要利用亲和性让两个应用尽可能的靠近,这样可以较少因网络通信而带来的性能损耗。

    反亲和性:当应用采用多副本部署的时候,那么就有必要利用反亲和性让各个应用实例打散分布在各个Node上,这样可以提高服务的高可用性。

    1、nodeAffinity

    查看nodeAffinity的可选配置项:

    requiredDuringSchedulingIgnoredDuringExecution  #Node节点必须满足指定的所有规则才可以,相当于硬限制
        nodeSelectorTerms  #节点选择列表
          matchFields   # 按节点字段列出的节点选择器要求列表  
          matchExpressions   #按节点标签列出的节点选择器要求列表(推荐)
            key    #键
            values #值
            operator #关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
    
    preferredDuringSchedulingIgnoredDuringExecution #优先调度到满足指定的规则的Node,相当于软限制 (倾向)     
        preference   #一个节点选择器项,与相应的权重相关联
          matchFields #按节点字段列出的节点选择器要求列表
          matchExpressions   #按节点标签列出的节点选择器要求列表(推荐)
            key #键
            values #值
            operator #关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt  
        weight # 倾向权重,在范围1-100。
    

    关系符的使用说明:

    - matchExpressions:
    	- key: env # 匹配存在标签的key为env的节点
    	  operator: Exists   
    	- key: env # 匹配标签的key为env,且value是"xxx"或"yyy"的节点
    	  operator: In    
          values: ["xxx","yyy"]
        - key: env # 匹配标签的key为env,且value大于"xxx"的节点
          operator: Gt   
          values: "xxx"
    

    1.1、requiredDuringSchedulingIgnoredDuringExecution硬限制

    创建pod_nodeaffinity_required.yaml文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodeaffinity-required
      namespace: dev
      labels:
        user: Negan
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1  # 容器需要的镜像地址
          imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
          ports:
            - name: nginx-port  # 端口名称,如果执行,必须保证name在Pod中是唯一的
              containerPort: 80 # 容器要监听的端口
              protocol: TCP # 端口协议
      affinity: # 亲和性设置
        nodeAffinity: # node亲和性
          requiredDuringSchedulingIgnoredDuringExecution: # node节点必须满足所有规则
            nodeSelectorTerms: # 节点选择列表
              - matchExpressions:
                  - key: env
                    operator: In
                    values: ["xxx","yyy"] # 需要满足其中一个
    

    查看状态

    kubectl get pods pod-nodeaffinity-required -n dev -o wide
    
    # 我们发现STATUS为Pending,这也不难解释,我们的标签env对应的值没有xxx和yyy
    NAME                        READY   STATUS    RESTARTS   AGE   IP       NODE     NOMINATED NODE   READINESS GATES
    pod-nodeaffinity-required   0/1     Pending   0          24s   <none>   <none>   <none>           <none>
    

    使其正常调度

    # 删除pod
    kuebctl delete -f pod_nodeaffinity_required.yaml 
    
    # 修改yaml文件,将“pro”或“debug”添加到values列表中,这里我添加了"pro"
    
    # 创建
    kubectl create -f pod_nodeaffinity_required.yaml 
    
    # 查看
    kubectl get pods pod-nodeaffinity-required -n dev -o wide
    # 发现Pod成功被调度到node1节点上了
    kubectl get pods pod-nodeaffinity-required -n dev -o wide
    NAME                        READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
    pod-nodeaffinity-required   1/1     Running   0          3s    192.168.166.131   node1   <none>           <none>
    

    1.2、preferredDuringSchedulingIgnoredDuringExecution 软限制

    创建pod_nodeaffinity_preferred.yaml文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-nodeaffinity-preferred
      namespace: dev
    spec:
      containers: # 容器配置
        - name: nginx
          image: nginx:1.17.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: nginx-port
              containerPort: 80
              protocol: TCP
      affinity: # 亲和性配置
        nodeAffinity: # node亲和性配置
          preferredDuringSchedulingIgnoredDuringExecution: # 优先调度到满足指定的规则的Node,相当于软限制 (倾向)
            - preference: # 一个节点选择器项,与相应的权重相关联
                matchExpressions:
                  - key: nodeenv
                    operator: In
                    values:
                      - "xxx"
                      - "yyy"
              weight: 1
    

    查看Pod状态:

    kubectl get pods pod-nodeaffinity-preferred -n dev -o wide
    
    # 发现即使没有满足条件,pod也被正常调度了。
    NAME                         READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
    pod-nodeaffinity-preferred   1/1     Running   0          16s   192.168.104.2   node2   <none>           <none>
    

    注意:

    如果同时定义了nodeSelectornodeAffinity,那么必须两个条件都满足,Pod才能运行在指定的Node上。

    如果nodeAffinity指定了多个nodeSelectorTerms,那么只需要其中一个能够匹配成功即可。

    如果一个nodeSelectorTerms中有多个matchExpressions,则一个节点必须满足所有的才能匹配成功。

    如果一个Pod所在的Node在Pod运行期间其标签发生了改变,不再符合该Pod的nodeAffinity的要求,则系统将忽略此变化。

    2、podAffinity

    podAffinity主要实现以运行的Pod为参照,实现让新创建的Pod和参照的Pod在一个区域的功能。

    查看PodAffinity的可选配置项

    requiredDuringSchedulingIgnoredDuringExecution  # 硬限制
      namespaces # 指定参照pod的namespace
      topologyKey # 指定调度作用域
      labelSelector # 标签选择器
        matchExpressions  # 按节点标签列出的节点选择器要求列表(推荐)
          key    #  键
          values # 值
          operator # 关系符 支持In, NotIn, Exists, DoesNotExist.
        matchLabels    # 指多个matchExpressions映射的内容  
      
    preferredDuringSchedulingIgnoredDuringExecution # 软限制    
      podAffinityTerm  # 选项
        namespaces
        topologyKey
        labelSelector
           matchExpressions 
              key   #  键  
              values # 值  
              operator
           matchLabels 
      weight 倾向权重,在范围1-100
    

    topologyKey用于指定调度的作用域,例如:

    如果指定为kubernetes.io/hostname,那就是以Node节点为区分范围。

    如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分。

    案例

    创建参照的pod,编写pod-podaffinity-target.yaml文件

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-podaffinity-target
      namespace: dev
      labels:
        user: Negan
    spec:
      containers:
        - name: nginx # 容器名称
          image: nginx:1.17.1  # 容器需要的镜像地址
          imagePullPolicy: IfNotPresent  # 设置镜像的拉取策略
          ports:
            - name: nginx-port  # 端口名称,如果执行,必须保证name在Pod中是唯一的
              containerPort: 80 # 容器要监听的端口
              protocol: TCP # 端口协议
      nodeName: node1 # 将pod定向调度到node1节点上
    

    查看目标pod的运行状态:

    kubectl get pods pod-podaffinity-target -n dev -o wide
    NAME                     READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
    pod-podaffinity-target   1/1     Running   0          37s   192.168.166.134   node1   <none>           <none>
    

    发现如我们预期那样,参照pod运行在node节点上。

    2.1、requiredDuringSchedulingIgnoredDuringExecution

    创建目标pod,将其调度到参照pod所在的节点上,编写pod-podaffinity-requred.yaml文件 :

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-podaffinity-requred
      namespace: dev
    spec:
      containers: # 容器配置
        - name: nginx
          image: nginx:1.17.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: nginx-port
              containerPort: 80
              protocol: TCP
      affinity: # 亲和性配置
        podAffinity: # Pod亲和性
          requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
            - labelSelector:
                matchExpressions: # 该Pod必须和拥有标签user=Negan或者user=yyy的Pod在同一个Node上
                  - key: user
                    operator: In
                    values:
                      - "Negan"
                      - "yyy"
              topologyKey: kubernetes.io/hostname
    

    查看目标pod运行状态:

    kubectl get pods pod-podaffinity-requred -n dev -o wide
    NAME                      READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
    pod-podaffinity-requred   1/1     Running   0          25s   192.168.166.135   node1   <none>           <none>
    

    发现目标pod和参考pod运行在同一个Node节点上。

    2.2、preferredDuringSchedulingIgnoredDuringExecution软限制

    编写pod-podaffinity-requred.yaml文件,我们将pod调度到不满足调度条件的node上,看是否能成功 :

    apiVersion: v1
    kind: Pod 
    metadata:
      name: pod-podaffinity-prefer
      namespace: dev 
    spec:
      containers: # 容器配置
        - name: nginx
          image: nginx:1.17.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: nginx-port
              containerPort: 80
              protocol: TCP 
      affinity: # 亲和性配置
        podAffinity: # Pod亲和性
          preferredDuringSchedulingIgnoredDuringExecution: #软限制
            - podAffinityTerm:
                labelSelector:
                  matchExpressions: 
                    - key: user
                      operator: In
                      values:
                        - "xxx"
                        - "yyy"
                topologyKey: kubernetes.io/hostname
              weight: 1
    

    查看pod的状态:

    kubectl get pod -n dev pod-podaffinity-prefer -o wide
    NAME                     READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
    pod-podaffinity-prefer   1/1     Running   0          21s   192.168.104.4   node2   <none>           <none>
    

    发现pod在不满足给定调度条件情况下,任然可以调度,pod被调度到了node2上。

    3、podAntiAffinity

    podAntiAffinity主要实现以运行的Pod为参照,让新创建的Pod和参照的Pod不在一个区域的功能。

    其配置方式和podAffinity一样,此处不做详细解释。

    这里我们继续使用上面的参照pod做演示。

    创建pod-podantiaffinity-requred.yaml文件,内容如下:

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-podantiaffinity-requred
      namespace: dev
    spec:
      containers: # 容器配置
        - name: nginx
          image: nginx:1.17.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: nginx-port
              containerPort: 80
              protocol: TCP
      affinity: # 亲和性配置
        podAntiAffinity: # Pod反亲和性
          requiredDuringScheduAlingIgnoredDuringExecution: # 硬限制
            - labelSelector:
                matchExpressions: # 该Pod必须和拥有标签user=Negan或者user=yyy的Pod在不在同一个Node上
                  - key: user
                    operator: In
                    values:
                      - "Negan"
                      - "yyy"
              topologyKey: kubernetes.io/hostname
    

    查看pod状态:

    kubectl get pods pod-podantiaffinity-requred -n dev -o wide
    NAME                          READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
    pod-podantiaffinity-requred   1/1     Running   0          27s   192.168.104.5   node2   <none>           <none>
    

    发现,目标pod被调度到node2节点上,我们的参照pod被调度在node1上,说明和我们预期的效果一致。

    三、污点和容忍

    1、污点

    前面的调度方式都是站在Pod的角度上,通过在Pod上添加属性,来确定Pod是否要调度到指定的Node上,其实我们也可以站在Node的角度上,通过在Node上添加污点属性,来决定是否运行Pod调度过来。

    Node被设置了污点之后就和Pod之间存在了一种相斥的关系,进而拒绝Pod调度进来,甚至可以将已经存在的Pod驱逐出去。

    污点的格式为:key=value:effect,key和value是污点的标签,effect描述污点的作用,支持如下三个选项:

    ​ 1、PreferNoSchedule:Kubernetes将尽量避免把Pod调度到具有该污点的Node上,除非没有其他节点可以调度。

    ​ 2、NoSchedule:Kubernetes将不会把Pod调度到具有该污点的Node上,但是不会影响当前Node上已经存在的Pod。

    ​ 3、NoExecute:Kubernetes将不会把Pod调度到具有该污点的Node上,同时也会将Node上已经存在的Pod驱逐。

    污点相关语法:

    • 设置污点

      kubectl taint node xxx key=value:effect
      
    • 去除污点

      kubectl taint node xxx key:effect-
      
    • 去除所有污点

      kubectl taint node xxx key-
      
    • 查看指定节点上的污点

      kubectl describe node 节点名称
      

    下面通过案例来进行演示污点。

    为了方便操作,先暂时停掉node2节点。

    在node2上执行下面命令,停掉node2:

    kubeadm reset
    

    在master节点上进行查看节点状态:

    kubectl get node 
    NAME     STATUS     ROLES    AGE    VERSION
    master   Ready      master   147m   v1.18.0
    node1    Ready      <none>   146m   v1.18.0
    node2    NotReady   <none>   146m   v1.18.0
    

    发现node2节点已经停掉了,接着我们为node1添加PreferNoSchedule污点:

    kubectl taint node node1 tag=Negan:PreferNoSchedule
    

    创建一个pod1,并查看pod的状态:

    kubectl get pod pod1 -n dev -o wide
    
    NAME   READY   STATUS    RESTARTS   AGE   IP                NODE    NOMINATED NODE   READINESS GATES
    pod1   1/1     Running   0          16s   192.168.166.136   node1   <none>           <none>
    

    发现pod1正常运行,并且被调度到node1节点上。

    给node1更换NoSchedule污点

    # 去掉node1上原有的污点
    kubectl taint node node1 tag:PreferNoSchedule-
    
    # 添加新污点
    kubectl taint node node1 tag=Negan:NoSchedule
    

    创建pod2,正常情况下,新创建的pod不能被调度到node1上,原有的pod不受影响。

    # 创建pod2
    kubectl run pod2 --image=nginx:1.17.1 -n dev
    
    # 查看状态,与我们预期的结果一致
    kubectl get pod -n dev -o wide
    NAME                          READY   STATUS        RESTARTS   AGE    IP                NODE  
    ...... 省略部分内容
    pod1                          1/1     Running       0          6m5s   192.168.166.136   node1    <none>           <none>
    pod2                          0/1     Pending       0          14s    <none>            <none>   <none>           <none>
    

    给node1更换NoExecute污点:

    # 给node1更换污点NoExecute
    kubectl taint node node1 tag:NoSchedule-
    kubectl taint node node1 tag=Negan:NoExecute
    

    查看namespace=dev下所有pod的状态:

    kubectl get pod -n dev
    NAME                          READY   STATUS        RESTARTS   AGE
    pod-nodeaffinity-preferred    1/1     Terminating   1          128m
    pod-nodeaffinity-required     0/1     Terminating   1          132m
    pod-podaffinity-prefer        1/1     Terminating   0          36m
    pod-podaffinity-requred       0/1     Terminating   0          85m
    pod-podaffinity-target        0/1     Terminating   0          90m
    pod-podantiaffinity-requred   1/1     Terminating   0          26m
    pod1                          0/1     Terminating   0          12m
    pod2                          0/1     Terminating   0          6m13s
    

    发现所有的Pod的状态都变为了Terminating

    说明

    使用kubeadm搭建的集群,默认就会给Master节点添加一个污点标记,所以Pod就不会调度到Master节点上

    2、容忍

    上面介绍了污点的作用,我们可以在Node上添加污点用来拒绝Pod调度上来,但是如果就是想让一个Pod调度到一个有污点的Node上去,这时候应该怎么做?这就需要使用到容忍。

    污点就是拒绝,容忍就是忽略,Node通过污点拒绝Pod调度上去,Pod通过容忍忽略拒绝。

    容忍详细配置:

    kubectl explain pod.spec.tolerations
    ......
    FIELDS:
      key       # 对应着要容忍的污点的键,空意味着匹配所有的键
      value     # 对应着要容忍的污点的值
      operator  # key-value的运算符,支持Equal和Exists(默认)
      effect    # 对应污点的effect,空意味着匹配所有影响
      tolerationSeconds   # 容忍时间, 当effect为NoExecute时生效,表示pod在Node上的停留时间
    

    当operator为Equal的时候,如果Node节点有多个Taint,那么Pod每个Taint都需要容忍才能部署上去。

    当operator为Exists的时候,有如下的三种写法:

    • 容忍指定的污点,污点带有指定的effect:

        tolerations: # 容忍
          - key: "tag" # 要容忍的污点的key
            operator: Exists # 操作符
            effect: NoExecute # 添加容忍的规则,这里必须和标记的污点规则相同
      
    • 容忍指定的污点,不考虑具体的effect:

        tolerations: # 容忍
          - key: "tag" # 要容忍的污点的key
            operator: Exists # 操作符
      
    • 容忍一切污点(慎用):

       tolerations: # 容忍
          - operator: Exists # 操作符
      

    在上面的污点示例中,已经给node1打上了NoExecute的污点,此时任何Pod是调度不上去的,可以通过在Pod中添加容忍,将Pod调度上去。

    创建pod-toleration.yaml文件,内容如下:

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-toleration
      namespace: dev
    spec:
      containers: # 容器配置
        - name: nginx
          image: nginx:1.17.1
          imagePullPolicy: IfNotPresent
          ports:
            - name: nginx-port
              containerPort: 80
              protocol: TCP
      tolerations: # 容忍
        - key: "tag" # 要容忍的污点的key
          operator: Equal # 操作符
          value: "Negan" # 要容忍的污点的value
          effect: NoExecute # 添加容忍的规则,这里必须和标记的污点规则相同
    

    查看pod状态:

    kubectl get pods pod-toleration -n dev
    NAME             READY   STATUS    RESTARTS   AGE
    pod-toleration   1/1     Running   0          47s
    
  • 相关阅读:
    stm32之波特率、USART
    C语言排序
    【要经常更新】C语言一些题目
    jquery瀑布流布局插件,兼容ie6不支持下拉加载,用于制作分类卡
    jquery等待图片加载完成,再使用函数,使用$(window).load(fn)
    ie6中 object doesn’t support this property or method
    jquery插件中参数未填写错误,火狐不会显示和报错,ie会显示
    flash插件使用外部数据的方法
    织梦在广告(myad)中使用css样式
    织梦改变模板目录
  • 原文地址:https://www.cnblogs.com/huiyichanmian/p/15701778.html
Copyright © 2020-2023  润新知