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。如此就能达到要求了。

k8s schedule