0. Deployment 有哪些不足

Deployment 能够创建任意多个的 Pod 实例，并且维护这些 Pod 的正常运行，保证应用始终处于可用状态。Deployment 并不关心 Pod 在哪些节点上运行，只要 Pod 的数量足够，应用程序应该会正常工作。

但是有些业务是和运行环境相关的，它们并非完全独立于系统运行，而是与主机存在绑定关系，必须依附于节点才能产生价值：

网络应用如 kube-proxy，节点不运行这个 Pod 就无法加入 Kubernetes 网络
监控应用如 Prometheus，节点需要运行这个 Pod 报告节点运行状态
日志应用如 Fluentd，节点需要运行这个 Pod 来收集日志
安全应用，每个节点都要有一个 Pod 来执行安全审计、入侵检查、漏洞扫描等工作

这些业务如果用 Deployment 来部署就不太合适了，因为 Deployment 所管理的 Pod 数量是固定的，而且可能会在集群里“漂移”，但，实际的需求却是要在集群里的每个节点上都运行 Pod，也就是说 Pod 的数量与节点数量保持同步。

所以，Kubernetes 就定义了新的 API 对象 DaemonSet，它在形式上和 Deployment 类似，都是管理控制 Pod，但管理调度策略却不同。

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

1. 使用 YAML 描述 DaemonSet 对象

使用命令 kubectl api-resources 可以知道它的简称是 ds。Kubernetes 不提供自动创建 DaemonSet YAML 样板的功能，我们只能去 DaemonSet 的文档页面获取一个 DaemonSet 的 YAML 模板。我们把它拷贝下来，再去掉多余的部分，就可以做成自己的一份样板文件：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: redis-ds
  labels:
    app: redis-ds

spec:
  selector:
    matchLabels:
      name: redis-ds

  template:
    metadata:
      labels:
        name: redis-ds
    spec:
      containers:
      - image: redis:5-alpine
        name: redis
        ports:
        - containerPort: 6379

这个 DaemonSet 对象的名字是 redis-ds，镜像是 redis:5-alpine。

在 spec 部分，DaemonSet 也有 selector 字段，匹配 template 里 Pod 的 labels 标签，这和 Deployment 对象几乎一模一样。

DaemonSet 在 spec 里没有 replicas 字段，意味着它不会在集群里创建多个 Pod 副本，而是要在每个节点上只创建出一个 Pod 实例。也就是说，DaemonSet 仅仅是在 Pod 的部署调度策略上和 Deployment 不同，其他的都是相同的，某种程度上我们也可以把 DaemonSet 看做是 Deployment 的一个特例。

所以我们只需要用 kubectl create 先创建出一个 Deployment 对象，然后把 kind 改成 DaemonSet，再删除 spec.replicas 就行了。

2. 在 Kubernetes 里使用 DaemonSet

现在，让我们执行命令 kubectl apply，把 YAML 发送给 Kubernetes，让它创建 DaemonSet 对象，再用 kubectl get 查看对象的状态：

$ kubectl apply -f redis-ds.yaml 
daemonset.apps/redis-ds created
l$ kubectl get ds
NAME       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
redis-ds   1         1         0       1            0           <none>          12s
$ kubectl get ds
NAME       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
redis-ds   1         1         1       1            1           <none>          15s
$ kubectl get pod -o wide 
NAME                       READY   STATUS    RESTARTS   AGE   IP           NODE      NOMINATED NODE   READINESS GATES
redis-ds-ktmrm             1/1     Running   0          22s   10.10.1.26   worker1   <none>           <none>

虽然我们没有指定 DaemonSet 里 Pod 要运行的数量，但它自己就会去查找集群里的节点，在节点里创建 Pod。因为我们的实验环境里有一个 Master 一个 Worker，而 Master 默认是不跑应用的，所以 DaemonSet 就只生成了一个 Pod，运行在了“worker”节点上。

按照 DaemonSet 的本意，应该在每个节点上都运行一个 Pod 实例才对，但 Master 节点却被排除在外了，这就不符合我们当初的设想了。

为了应对 Pod 在某些节点的“调度”和“驱逐”问题，它定义了两个新的概念：污点（taint） 和 容忍度（toleration）。

3. Taint 和 Toleration

“污点”是 Kubernetes 节点的一个属性，它的作用也是给节点“贴标签”，但为了不和已有的 labels 字段混淆，就改成了 taint。

和“污点”相对的，就是 Pod 的“容忍度”，顾名思义，就是 Pod 能否“容忍”污点。

Kubernetes 在创建集群的时候会自动给节点 Node 加上一些“污点”，方便 Pod 的调度和部署。你可以用 kubectl describe node 来查看 Master 和 Worker 的状态：

$ kubectl describe node k8s-master
Name:               k8s-master
Roles:              control-plane
···
Taints:             node-role.kubernetes.io/control-plane:NoSchedule
···

$ kubectl describe node worker1
Name:               worker1
Roles:              <none>
···
Taints:             <none>
···

可以看到，Master 节点默认有一个 taint，名字是 node-role.kubernetes.io/master，它的效果是 NoSchedule，也就是说这个污点会拒绝 Pod 调度到本节点上运行，而 Worker 节点的 taint 字段则是空的。这正是 Master 和 Worker 在 Pod 调度策略上的区别所在，通常来说 Pod 都不能容忍任何“污点”，所以加上了 taint 属性的 Master 节点也就会无缘 Pod 了。

两种方法让 DaemonSet 在 Master 节点（或者任意其他节点）上运行：

去掉 Master 节点上的 taint，DaemonSet 自然就不需要再区分 Master/Worker
```
$ kubectl taint node master node-role.kubernetes.io/master:NoSchedule-
```
这种方法修改的是 Node 的状态，影响面会比较大，可能会导致很多 Pod 都跑到这个节点上运行，所以我们可以保留 Node 的“污点”，为需要的 Pod 添加“容忍度”，只让某些 Pod 运行在个别节点上，实现“精细化”调度
为 Pod 添加字段 tolerations，让它能够“容忍”某些“污点”，就可以在任意的节点上运行了

tolerations 是一个数组，里面可以列出多个被“容忍”的“污点”，需要写清楚“污点”的名字、效果。比较特别是要用 operator 字段指定如何匹配“污点”，一般我们都使用 Exists，也就是说存在这个名字和效果的“污点”。
如果我们想让 DaemonSet 里的 Pod 能够在 Master 节点上运行，就要写出这样的一个 tolerations，容忍节点的 node-role.kubernetes.io/master:NoSchedule 这个污点：
```
tolerations:
- key: node-role.kubernetes.io/control-plane
  effect: NoSchedule
  operator: Exists
```
重新部署加上了“容忍度”的 DaemonSet：
```
$ kubectl apply -f ds.yml

$ kubectl get ds -o wide 
NAME       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS   IMAGES           SELECTOR
redis-ds   2         2         2       2            2           <none>          53m   redis        redis:5-alpine   name=redis-ds
```

需要特别说明的是：“容忍度”并不是 DaemonSet 独有的概念，而是从属于 Pod，所以理解了“污点”和“容忍度”之后，你可以在 Job/CronJob、Deployment 里为它们管理的 Pod 也加上 tolerations，从而能够更灵活地调度应用。

污点和容忍度的文档在这里：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ ，有哪些污点、污点有哪些效果可以在这里找到。

4. 静态 Pod

DaemonSet 是在 Kubernetes 里运行节点专属 Pod 最常用的方式，但它不是唯一的方式，Kubernetes 还支持另外一种叫“静态 Pod”的应用部署手段。

“静态 Pod”非常特殊，它不受 Kubernetes 系统的管控，不与 apiserver、scheduler 发生关系，所以是“静态”的。但既然它是 Pod，也必然会“跑”在容器运行时上，也会有 YAML 文件来描述它，而唯一能够管理它的 Kubernetes 组件也就只有在每个节点上运行的 kubelet 了。

“静态 Pod”的 YAML 文件默认都存放在节点的 /etc/kubernetes/manifests 目录下，它是 Kubernetes 的专用目录。

Kubernetes 的 4 个核心组件 apiserver、etcd、scheduler、controller-manager 原来都以静态 Pod 的形式存在的，这也是它们能够先于 Kubernetes 集群启动的原因。

附：DaemonSet YAML

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: redis-ds
  labels:
    app: redis-ds

spec:
  selector:
    matchLabels:
      name: redis-ds

  template:
    metadata:
      labels:
        name: redis-ds
    spec:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
        operator: Exists

      containers:
      - image: redis:5-alpine
        name: redis
        ports:
        - containerPort: 6379