Kubernetes控制节点的部署

标签和nodeSelector

标签(Label)是附加到 Kubernetes 对象上的键值对，如果用 json 表示附加到 metadata 的 label：

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

yaml：

metadata:
  labels:
    key1: "value1"
    key2: "value2"

标签主要是用于表示对用户有意义的对象的属性标识。

可以给节点设定一些 Label，例如在 kube-system 命名空间中，运行着 Kubernetes 的核心组件，我们可以查看此命名空间中所有组件的 Label。

kubectl get nodes --namespace=kube-system --show-labels

beta.kubernetes.io/arch=amd64,
beta.kubernetes.io/os=linux,
kubernetes.io/arch=amd64,
... ...

我们也可以手动给一个 Node 添加标签。

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

例如我们给节点设置一个 disksize，表示节点的硬盘是否够大。

kubectl label nginx disksize=big

然后我们在编写 yaml 文件时，希望这个 pod 在容量大的 Node 上运行，可以这样写：

  nodeSelector:
    disksize=big

顺便聊一下官方的一个例子，设置 Node 的 Label，表示硬盘是 ssd。

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

在 yaml 文件的节点选择器中，添加选择。

spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

Label 可以在多个地方使用，例如在 Node 上添加 Label，标识此 Node；而在 NodeSelector 里使用，可以选择合适的 Node 运行 Pod；在 metadata 中使用，可以对元数据加以描述。

在 metadata 中添加的 Label，可以在命令查询时做筛选。

查询 pod 的 Label：

kubectl get pods --show-labels

查找符合条件的 pod（参考 LABELS 字段，可以根据里面的标签选择）：

kubectl get pods -l app=nginx

标签选择

在前面，我们学习了 nodeSelector ，可以帮助我们选择合适的 Node 运行 Pod，实际上 Kubernets 的标签选择是丰富多样的，例如：

  nodeSelector:
    disktype: ssd
    disksize: big

则表示节点选择器是等值选择，表达式是 disktype=ssd && disksize=big。

标签选择有等值和集合两种，其中等值选择有 =、==、!= 三种，= 和 == 无区别。在多个需求(多个label)的情况下，相对于使用 && 运算符，但是选择器不存在 ||这种逻辑或运算符。

yaml 只支持 {key}:{value} 这种形式，而我们使用命令形式时，则可使用以上三种运算符。

kubectl get nodes -l disktype=ssd,disksize!=big
# 多个条件使用 逗号","" 隔开，而不是 "&&"。

对于集合选择方式，支持三种操作符：in、notin 和 exists。不过别理解成是从集合中选择，下面举个例子。

假如有三个 Node，其 disksize 有 big、medium、small，我们要部署一个 pod，在 big、medium 中都可以运行，则：

... -l disksize in (big,medium)

... -l disksize notin (small)
# 不在 small 中运行

而 exists 则跟 != 类似，但是 exists 表示只要存在这个 label 即可，而不论其设置了是什么值。

-l disksize
# 等同 -l disksize in (big,medium,small)

我们也可以使用 '' 把选择表达式包起来。

kubectl get pods -l 'app=nginx'

前面已经提到了 yaml 的 nodeSelector 和 命令式的选择，这里我们介绍 yaml 的 selector。

前面我们提到在 Deployment 的 metadata 中加上 Label，即 pod 加上 Label，我们也在 kubectl get pods 中使用 Label 选择过滤 pod。同样，当我们创建 Service 或者使用 ReplicationController 时，也可以使用标签选择合适的 pod。

假如我们已经部署了 nginx，那么查询 kubectl get pods --show-labels 时，其 pod 的 LABELS 会有 app=nginx，那么我们可以这样选择：

  selector:
    app: nginx

完整版本：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 6666
status:
  loadBalancer:
    ingress:
      - ip: 192.0.2.127

selector 还支持以下选择方式 matchLabels、matchExpressions：

matchLabels 是由 {key,value} 对组成的映射。 matchLabels 映射中的单个 {key,value } 等同于 matchExpressions 的元素， 其 key 字段为 "key"，operator 为 "In"，而 values 数组仅包含 "value"。

matchExpressions 是 Pod 选择算符需求的列表。 有效的运算符包括 In、NotIn、Exists 和 DoesNotExist。 在 In 和 NotIn 的情况下，设置的值必须是非空的。 来自 matchLabels 和 matchExpressions 的所有要求都按逻辑与的关系组合到一起 -- 它们必须都满足才能匹配。

示例如下：

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

这里就不在详细说这些选择规则了，前面提到的已经够用了，读者可以查阅官方文档学习更多复杂的操作：https://kubernetes.io/zh/docs/concepts/overview/working-with-objects/labels/

亲和性和反亲和性

前面我们学习了 nodeSelector ，使用 nodeSelector 选择合适的 Label，可以表达我们约束的类型。

亲和性则类似于 nodeSelector，可以根据节点上的标签约束 pod 可以调度到哪些节点。

pod 亲和性有两种别为：

• requiredDuringSchedulingIgnoredDuringExecution

  硬需求，将 pod 调度到一个节点必须满足的规则。

• preferredDuringSchedulingIgnoredDuringExecution。

  尝试执行但是不能保证偏好。

这是官方的一个例子：

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: k8s.gcr.io/pause:2.0

亲和性的约束相对于：

... ... -l kubernetes.io/e2e-az-name in (e2e-az1,e2e-az2)

affinity 设置亲密关系，nodeAffinity 设置节点亲密关系，最后才到 亲和性，它们表示必须满足和尽量满足。

如果我们设置了多个 nodeSelectorTerms ：

requiredDuringSchedulingIgnoredDuringExecution:
  nodeSelectorTerms:
  ...
  nodeSelectorTerms:

则只需要满足其中一种即可调度 pod 到 node 上。

如果你同时指定了 nodeSelector 和 nodeAffinity，两者必须都要满足， 才能将 Pod 调度到候选节点上。

节点亲和性语法支持下面的操作符： In，NotIn，Exists，DoesNotExist，Gt，Lt。

Pod 亲和性与反亲和性的合法操作符有 In，NotIn，Exists，DoesNotExist。

通过 -Affinity 可以设置亲和性，例如节点亲和性 nodeAffinity，而且设置反亲和性使用 -AntiAffinity，例如 nodeAntiAffinity。

反亲和性跟亲和性一样，都有 requiredDuringSchedulingIgnoredDuringExecution 硬限制和 preferredDuringSchedulingIgnoredDuringExecution 软限制，只是反亲和性是相反的表示，如果符合条件则不能调度。

关于亲和性和反亲和性的说明就到这里，着两者的配置比较多和复杂，读者可以参考官方文档，这里不在赘述。

污点和容忍度

前面提到亲和性和反亲和性，我们加以通过 pod 选择合适的 node，或者 service 选择合适的 pod，这些拥有 Label 的对象都是被选择的。

这里，我们介绍污点和容忍度，它们可以排斥 “被选择” 的命运。

节点污点(taint) 可以排斥一类特定的 pod，而 容忍度(Tolerations)则表示能够容忍这个对象的污点。

当节点添加一个污点后，除非 pod 声明能够容忍这个污点，否则 pod 不会被调度到这个 节点上。

系统会 尽量 避免将 Pod 调度到存在其不能容忍污点的节点上， 但这不是强制的。Kubernetes 处理多个污点和容忍度的过程就像一个过滤器：从一个节点的所有污点开始遍历， 过滤掉那些 Pod 中存在与之相匹配的容忍度的污点。

但是如果你只有一个 worker，那么设置了污点，那 pod 也只能选择在这个节点上运行。

添加污点格式：

kubectl taint node [node] key=value:[effect]

更新污点或覆盖：

kubectl taint node [node] key=value:[effect] --overwrite=true

使用 kubectl taint 给节点增加一个污点。

kubectl taint nodes node1 key1=value1:NoSchedule

移除污点：

kubectl taint nodes node1 key1=value1:NoSchedule-

其中，污点需要设置 label ，并设置这个 label 的效果为 NoSchedule。

污点的效果称为 effect ，节点的污点可以设置为以下三种效果：

• NoSchedule：不能容忍此污点的 Pod 不会被调度到节点上；不会影响已存在的 pod。
• PreferNoSchedule：Kubernetes 会避免将不能容忍此污点的 Pod 安排到节点上。
• NoExecute：如果 Pod 已在节点上运行，则会将该 Pod 从节点中逐出；如果尚未在节点上运行，则不会将其安排到节点上。

但是某些系统创建的 Pod 可以容忍所有 NoExecute 和 NoSchedule 污点，因此不会被逐出，例如 master 节点是不能被部署 pod 的，但是 kube-system 命名空间却有很多系统 pod。当然通过修改污点，可以让 户 pod 部署到 master 节点中。

查询节点的污点：

kubectl describe nodes | grep Taints

Taints:             node-role.kubernetes.io/master:NoSchedule
Taints:             key1=value1:NoSchedule

系统默认污点

我们去除 master 的污点：

kubectl taint node instance-1 node-role.kubernetes.io/master:NoSchedule-

然后部署 nginx pod。

kubectl create deployment nginxtaint --image=nginx:latest --replicas=3

查看 pod：

kubectl get pods -o wide

结果笔者查到三个副本都在 master 节点上。

为了保证集群安全，我们需要恢复 master 的污点。

kubectl taint node instance-1 node-role.kubernetes.io/master:NoSchedule

当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括：

• node.kubernetes.io/not-ready：节点未准备好。这相当于节点状态 Ready 的值为 "False"。
• node.kubernetes.io/unreachable：节点控制器访问不到节点. 这相当于节点状态 Ready 的值为 "Unknown"。
• node.kubernetes.io/out-of-disk：节点磁盘耗尽。
• node.kubernetes.io/memory-pressure：节点存在内存压力。
• node.kubernetes.io/disk-pressure：节点存在磁盘压力。
• node.kubernetes.io/network-unavailable：节点网络不可用。
• node.kubernetes.io/unschedulable: 节点不可调度。
• node.cloudprovider.kubernetes.io/uninitialized：如果 kubelet 启动时指定了一个 "外部" 云平台驱动， 它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager 的一个控制器初始化这个节点后，kubelet 将删除这个污点。

容忍度

一个 node 可以设置污点，排斥 pod，但是 pod 也可以设置 容忍度，容忍 node 的污点。

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

也可以设置 value。

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

operator 的默认值是 Equal。

一个容忍度和一个污点相“匹配”是指它们有一样的键名和效果，并且：

• 如果 operator 是 Exists

  此时容忍度不能指定 value，如果存在 key 为 key1 的 label，且污点效果为 NoSchedule，则容忍。

• 如果 operator 是 Equal ，则它们的 value 应该相等

如果 effect 留空，则表示只要是 label 为 key1 的节点，都可以容忍。

如果：

tolerations:
  operator: "Exists"

则表示此 pod 能够容忍任意的污点，无论 node 怎么设置 key、value 、effect ，此 pod 都不会介意。

如果要在 master 上也能部署 pod，则可以修改 pod 的容忍度：

    spec:
      tolerations:
      # this toleration is to have the daemonset runnable on master nodes
      # remove it if your masters can't run pods
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

DaemonSet

在 Kubernetes 中，有三个 -Set ，分别是 ReplicaSet、DaemonSet、StatefulSets。而 负载类型有 Deployments、ReplicaSet、DaemonSet、StatefulSets等(或者说有这几个控制器)。

前面已经介绍过 Deployments ，而 kind: ReplicaSet 一般是没必要的，可以在 kind: Deployment 加上 replicas: 。

而 kind: DaemonSet 需要使用一个 yaml 来描述，但是整体跟 Deployment 一样。

DaemonSet 可以确保一个节点只运行一个 Pod 副本，假如有个 nginx 的 pod，当新的 Node 加入集群时，会自动在这个 Node 上部署一个 pod；当节点从集群中移开时，这个 Node 上的 Pod 会被回收；如果 DaemontSet 配置被删除，则也会删除所有由它创建的 Pod。

DaemonSet 的一些典型用法：

• 在每个节点上运行集群守护进程
• 在每个节点上运行日志收集守护进程
• 在每个节点上运行监控守护进程

在 yaml 中，要配置 Daemont，可以使用 tolerations，配置示例：

kind: DaemontSet
... ...

其它地方跟 Deployment 一致。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。