【Kubernetes 008】多种类型控制器区别及实际操作详解（RS，Deployment，DaemonSet，Job，ConJob）

Pod是k8s中的基本结构，前面我们已经创建过一个。但是生产环境中往往不需要我们自己去创建pod，而是通过创建管理pod的控制器而达到自动批量管理pod的目的。这一节我们就一起来看看k8s中有哪些控制器，以及这些控制器的一些基本操作。

我是T型人小付，一位坚持终身学习的互联网从业者。喜欢我的博客欢迎在csdn上关注我，如果有问题欢迎在底下的评论区交流，谢谢。

控制器类型

k8s的控制器一共有如下几种：

• ReplicationController（已弃用）和ReplicaSet
• Deployment
• DaemonSet
• StatefulSet
• Job/CronJob
• Horizontal Pod Autoscaling

下面对每种进行详细介绍

ReplicationController和ReplicaSet

RC和RS的作用一致，都是确保pod的副本数量维持在期望水平，但是RS可以根据容器的label进行集合式的选择，这个RC是做不到的，所以RC被RS淘汰了。

Deployment

Deployment为pod和RS提供一个声明式（declarative）方法，替代以前的RC来管理应用。

命令式编程：一步步告诉程序应该执行的命令
声明式编程：只声明一个结果，并不给出具体步骤，然后让计算机去实现

典型的应用场景如下：

• 定义Deployment来创建pod和RS
• 滚动升级和回滚应用
  通过创建新的RS在下面创建pod，并停止旧RS来进行升级。重新启动旧RS而停止新RS来达到回滚的目的。
• 扩容和缩容
• 暂停和继续Deployment

在可选RS和Deployment的情况下，优先选择Deployment。

DaemonSet

DaemonSet确保全部或一些Node上运行一个pod的副本。当有Node加入集群时，也会为该Node创建一个pod副本。

典型的应用场景如下：

• 运行集群存储的Daemon，例如glusterd，ceph
• 运行日志收集Daemon，例如fluentd，logstash
• 运行监控的Daemon，例如Prometheus Node Exporter，collectd等

Job

在pod里面部署一些脚本单次运行，并确保这些pod成功结束。

CronJob

类似linux的Cron，用来在给定时间点或者是周期循环执行任务。

StatefulSet

StatefulSet为pod提供了唯一的标识，可以保证部署和scale的顺序。区别于RS的无状态服务，StatefulSet是为了解决有状态服务而创建的。典型应用场景如下：

• 稳定的持久化存储，即pod重新调度后还是能访问到完全相同的存储
• 稳定的网络标识，即pod重新调度后其podname和hostname不变
• 有序部署，有序扩展，从0到N-1，通过前面说的Init容器来实现
• 有序收缩，有序删除，从N-1到0，后启动的pod先停止，避免报错

HPA

HPA有点像上面这些控制器的附属品，通过一些指标，例如cpu，去控制之前提到的控制器达到自动扩缩容的目的。HPA不直接控制pod。

实际操作

以下所有yaml文件都托管在Github:
https://github.com/Victor2Code/centos-k8s-init/tree/master/test%20yaml

RS实际操作

和前面生成pod一样，rs也是通过yaml文件来定义。所有字段的详细解释可以通过kubectl explain rs或者kubectl explain ReplicaSet来查看。

几个重要的字段总结一下

字段	类型	说明
apiVersion	string	extensions/v1beta1
kind	string	ReplicaSet
spec	object
spec.replicas	integer	副本的期望数目，默认为1
spec.selector	object	对pod的选择条件
spec.selector.matchLabels	object
spec.template	object	描述rs管理的pod的信息
spec.template.metadata	object	和pod的定义一样，不过注意labels内容要和上面的一致
spec.template.spec	object	和pod的定义一样

补充apiversion查询手册https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/

或者通过kubectl explain xx 来查询apiversion怎么填

通过yaml文件test-rs.yaml创建一个rs

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: test-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rs-app
  template:
    metadata:
      labels:
        app: rs-app
    spec:
      containers:
        - name: mynginx
          image: mynginx:v1
          ports:
            - containerPort: 80

这里pod里面只有一个容器，使用的是我重新tag的nginx镜像。

在所有可能被分配pod的node上通过命令docker tag nginx mynginx:v1去重新打标签，目的是为了不让k8s每次去下载latest镜像

创建之后可以看到起了3个pod

[root@k8s-master k8s-test]# kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
curl-6bf6db5c4f-kljp4   1/1     Running   1          3d18h   10.244.1.2    k8s-node1    <none>           <none>
hellok8s                2/2     Running   0          2d23h   10.244.1.6    k8s-node1    <none>           <none>
test-init-main          1/1     Running   31         2d1h    10.244.1.8    k8s-node1    <none>           <none>
test-rs-74mw2           1/1     Running   0          64m     10.244.1.17   k8s-node1    <none>           <none>
test-rs-89l2s           1/1     Running   0          64m     10.244.1.16   k8s-node1    <none>           <none>
test-rs-w8zw8           1/1     Running   0          64m     10.244.0.4    k8s-master   <none>           <none>
test-start-stop         1/1     Running   0          37h     10.244.1.15   k8s-node1    <none>           <none>

上面一共有7个pod，其中以test-rs开头的3个pod是通过rs自动创建的，可以看到其中2个在node1上，另一个在master上。另外4个pod是之前的实验创建的，它们并不归任何控制器管。

下面我们尝试删除所有的pod，当然这个命令只会删除default命名空间下的pod，不会删除kube-system下的

[root@k8s-master k8s-test]# kubectl delete pod --all
pod "curl-6bf6db5c4f-kljp4" deleted
pod "hellok8s" deleted
pod "test-init-main" deleted
pod "test-rs-74mw2" deleted
pod "test-rs-89l2s" deleted
pod "test-rs-w8zw8" deleted
pod "test-start-stop" deleted

接着再查看pod

[root@k8s-master k8s-test