Daemonset | Deployment 让应用永不宕机

一、前言|

在kubernetes集群里有两类应用，一类是离线业务，比如job、CronJob等，那么另一种大概就是今天要讲到的在线应用：daemonset,Deployment。

二、区别

• damonset可以理解为是节点守护进程，每个node都必须有并且一直在线。有并且只有1个即可。可以理解为daemonset是deployment的一种特列。
• deployment可以理解为集群每个节点上都可以有若干pod.可以持续扩缩容。
• 两者相同点体现在二者的yml 对象基本一致，daemonSet无replicas字段，默认仅启动一个pod。

三、yml文件

由于二者yml文件格式大致相同，我们可以看一个daemonSet文件

apiVersion: apps/v1
kind: DaemonSet      //类型
metadata:
  name: redis-ds     //应用名字
  labels:
    app: redis-ds    //应用标签 
spec:
  selector:
    matchLabels:
      name: redis-ds

  template:         //默认启动一个pod.  名字为redis-ds
    metadata:
      labels:
        name: redis-ds
    spec:
      containers:
      - image: redis:5-alpine      //底层容器基本信息
        name: redis
        ports:
        - containerPort: 6379

定义好这个文件后，启动这个应用，如下：

应用yml文件

使用命令查看一下daemonset情况，如下，状态都正常：

再看看pod 状况。发现pod启动过来，但是仅在work节点，master节点没有分配。

原因：

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

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

四、解决办法

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

比如我这里 ，如下图

节点属性查看

无法调度，自然pod无法被安排。解决办法有两种，这里介绍一个简单的办法，执行如下命令：

master节点去污
kubectl taint node master node-role.kubernetes.io/master:NoSchedule-

再次查看，pod 分布是否正常，发现正常了。

pod分布正常。

ds状态

测试删掉一个pod,系统马上就生成一个。

这样就保证集群每个节点上都会有这样的一个进程，一个pod,这就是daemonSet的作用。

五、Deployment

这个API对象使用率很高，yml结构基本保持一致，只是多了一个replicas字段，表示副本概念，几个实列的意思。

demo:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx-dep
  name: ngx-dep
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx-dep
  template:
    metadata:
      labels:
        app: ngx-dep
    spec:
      containers:
      - image: nginx:alpine
        name: nginx

其他用法基本保持一致，不详细多讲。

六、总结

常见语法： export out="--dry-run=client -o yaml" kubectl create deploy ngx-dep --image=nginx:alpine $out

kubectl scale --replicas=XXXX deploy ngx-dep

kubectl delete pod XXX

kubectl describe pod XXX

kubectl get api objects