Label

Label是附着到object上（例如Pod）的键值对。可以在创建object的时候指定，也可以在object创建后随时指定。Labels的值对系统本身并没有什么含义，只是对用户才有意义。

"labels": {
  "key1" : "value1",
  "key2" : "value2"
}

Label selector

Label selector有两种类型：

equality-based ：可以使用=、==、!=操作符，可以使用逗号分隔多个表达式
set-based ：可以使用in、notin、!操作符，另外还可以没有操作符，直接写出某个label的key，表示过滤有某个key的object而不管该key的value是何值，!表示没有该label的object

$ kubectl get pods -l environment=production,tier=frontend
$ kubectl get pods -l 'environment in (production),tier in (frontend)'
$ kubectl get pods -l 'environment in (production, qa)'
$ kubectl get pods -l 'environment,environment notin (frontend)'

在API object中设置label selector

在service、replicationcontroller等object中有对pod的label selector，使用方法只能使用等于操作，例如：

selector:
    component: redis

在Job、Deployment、ReplicaSet和DaemonSet这些object中，支持set-based的过滤，例如：

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

nodeSelector

为node添加一个label

kubectl label nodes <node-name> <label-key>=<label-value>

kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd

kubectl get nodes --show-labels

这是一种强规则，没有妥协，必须遵守。
特点：简单，容易配置
缺点：强规则，没有妥协，若不存在符合条件的node，则无法部署。

nodeSelector 将会在后续的版本中废除，还是建议大家使用使用亲和性策略。

kubectl label nodes kube-node node=kube-node
kubectl get node -a -l "node=kube-node"

sepc.nodeSelector中指定：

image.png

亲和与反亲和 Affinity and anti-affinity

nodeSelector的调度方式略显简单，通过亲和和反亲和配置，能够为调度提供更灵活的策略，主要有以下几点增强：

• 匹配有更多的逻辑组合，不只是字符的完全相等
• 调度分成软策略（soft）和硬策略（hard），在软策略的情况下，如果没有满足调度条件的节点，pod 会忽略这条规则，继续完成调度过程

软策略和硬策略的区分是有用处的，硬策略适用于 pod 必须运行在某种节点，否则会出现问题的情况，比如集群中节点的架构不同，而运行的服务必须依赖某种架构提供的功能；软策略不同，它适用于满不满足条件都能工作，但是满足条件更好的情况，比如服务最好运行在某个区域，减少网络传输等。这种区分是用户的具体需求决定的，并没有绝对的技术依赖。

节点亲和性 Node affinity

类似于nodeSelector，允许我们指定一些Pod在Node间调度的约束
支持两种形式：

• requiredDuringSchedulingIgnoredDuringExecution 必须满足，如果不满足则不进行调度
• preferredDuringSchedulingIgnoredDuringExecution 倾向满足，不满足的情况下会调度的不符合条件的Node上

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

• requiredDuringSchedulingRequiredDuringExecution 必须满足，
• requiredDuringSchedulingRequiredDuringExecution 倾向满足，

...RequiredDuringExecution，如果运行的 pod 所在节点不再满足条件，kubernetes 会把 pod 从节点中删除，重新选择符合要求的节点。这个属性暂时还不支持

AFFINITY SELECTOR	REQUIREMENTS MET	REQUIREMENTS NOT MET	REQUIREMENTS LOST
requiredDuringSchedulingIgnoredDuringExecution	Runs	Fails	Keeps Running
preferredDuringSchedulingIgnoredDuringExecution	Runs	Runs	Keeps Running
(un-implemented) requiredDuringSchedulingRequiredDuringExecution	Runs	Fails	Fails

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: gcr.io/google_containers/pause:2.0

这个 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 中 nodeSelectorTerms 有多个选项，如果节点满足任何一个条件就可以；如果 matchExpressions 有多个选项，则只有同时满足这些逻辑选项的节点才能运行 pod。

pod亲和性和反亲和性 pod affinity and anti-affinity

podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题（拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的cluster、zone等。），podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
作用域： pod 于pod之间

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: gcr.io/google_containers/pause:2.0

污点（Taints）与容忍（tolerations）

NodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

Taints(污点)是Node的一个属性，设置了Taints(污点)后，因为有了污点，所以Kubernetes是不会将Pod调度到这个Node上的，于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。

因此 Taints(污点)通常与Tolerations(容忍)配合使用。

1、设置污点：

kubectl taint node [node] key=value[effect]   
  示例：kubectl taint node 10.3.1.16 test=16:NoSchedule 

其中[effect] 可取值： [ NoSchedule | PreferNoSchedule | NoExecute ]

• NoSchedule：POD 不会被调度到标记为 taints 节点。
• PreferNoSchedule：NoSchedule 的软策略版本。
• NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出。

2、去除污点：

比如设置污点：
     kubectl taint node 10.3.1.16 test=16:NoSchedule
     kubectl taint node 10.3.1.16 test=16:NoExecute
 去除指定key及其effect：
     kubectl taint nodes node_name key:[effect]-    #(这里的key不用指定value)
                
 去除指定key所有的effect: 
     kubectl taint nodes node_name key-

 示例：
     kubectl taint node 10.3.1.16 test:NoSchedule-
     kubectl taint node 10.3.1.16 test:NoExecute-
     kubectl taint node 10.3.1.16 test-

3、Pod 容忍污点示例：

对于tolerations属性的写法：

其中的key、value、effect 与Node的Taint设置需保持一致， 还有以下几点说明：

1、如果operator的值是Exists，则value属性可省略。

2、如果operator的值是Equal，则表示其key与value之间的关系是equal(等于)。

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

另外，还有两个特殊值：

1、空的key 如果再配合Exists 就能匹配所有的key与value ，也是是能容忍所有node的所有Taints。

2、空的effect 匹配所有的effect。

一个node上可以有多个污点：
比如 test=16:NoScheduler test2=16:NoSchedule
而在Pod容忍时只容忍了其中一个：

tolerations:
  - key: "test"
    operator: "Equal" 
    value: "16"
    effect: "NoSchedule"

这样的结果是此Pod无法被调度到key为test的node( 10.3.1.16)上去，因为此Node上设置了两个污点，
而这个Pod只匹配到了一个污点，也就是只容忍了一个污点，所以可以再加一个容忍：

tolerations:
  - key: "test"
    operator: "Exists" 
    effect: "NoSchedule"
  - key: "test2"
    operator: "Equal"
    value: "16"
    effect: "NoSchedule"

如果在设置node的Taints(污点)之前，就已经运行了一些Pod，那么这些Pod是否还能继续在此Node上运行？ 这就要看设置Taints污点时的effect(效果)了。

如果effect的值是NoSchedule或PreferNoSchedule，那么已运行的Pod仍然可以运行，只是新Pod(如果没有容忍)不会再往上调度。

而如果effect的值是NoExecute，那么此Node上正在运行的Pod，只要没有容忍的，立刻被驱逐。虽然是立刻被驱逐，但是K8S为了彰显人性化，又给具有NoExecute效果的污点， 在容忍属性中有一个可选的tolerationSeconds字段，用来设置这些Pod还可以在这个Node之上运行多久，给它们一点宽限的时间，到时间才驱逐。
如果是以Pod来启动的，那么Pod被驱逐后， 将不会再被运行，就等于把它删除了。
如果是deployment/rc，那么删除的pod会再其它节点运行。
如果是DaemonSet在此Node上启动的Pod，那么也不会再被运行，直到Node上的NoExecute污被去除或者Pod容忍。

#设置Pod的宽限时间
spec:
  tolerations: #设置容忍性
  - key: "test"
    operator: "Equal" #如果操作符为Exists，那么value属性可省略
    value: "16"
    effect: "NoExecute"
    tolerationSeconds: 180 
    #如果运行此Pod的Node，被设置了具有NoExecute效果的Taint(污点)，这个Pod将在存活180s后才被驱逐。
    #如果没有设置tolerationSeconds字段，将永久运行。

通过对Taints和Tolerations的了解，可以知道，通过它们可以让某些特定应用，独占一个Node：
给特定的Node设置一个Taint，只让某些特定的应用来容忍这些污点，容忍后就有可能会被调度到此特定Node，
但是也不一定会调度给此特定Node，设置容忍并不阻止调度器调度给其它Node，那么如何让特定应用的Node
只能被调度到此特定的Node呢，这就要结合NodeAffinity节点亲和性，给Node打个标签，然后在Pod属性里
设置NodeAffinity到Node。如此就能达到要求了。