k8s各类控制器详解

一、控制器定义

控制器也是管理pod的一种手段

自主式pod：pod退出或意外关闭后不会被重新创建
控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod

当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复

二、控制器常用类型

三 replicaset控制器

3.1 replicaset功能

ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet
ReplicaSet和Replication Controller的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

3.2 replicaset参数说明

3.3 replicaset 示例

$root@k8s-master pod$ # kubectl create deployment timinglee --image myapp:v1 --replicas 2 --dry-run=client -o yaml > timinglee.yml

$root@k8s-master pod$ # ls

lee.yml timinglee.yml

$root@k8s-master pod$ # vim timinglee.yml

replicaset 示例

$root@k8s-master pod$ # ls

lee.yml timinglee.yml

$root@k8s-master pod$ # vim timinglee.yml

#replicaset是通过标签匹配pod

$root@k8s-master pod$ # kubectl label pods example-rep-9lbts app=lee --overwrite

pod/example-rep-9lbts labeled

$root@k8s-master pod$ # kubectl get pods --show-labels

NAME READY STATUS RESTARTS AGE LABELS

example-rep-22qx8 1/1 Running 0 4s app=timinglee

example-rep-9lbts 1/1 Running 0 5m22s app=lee

example-rep-dvjhp 1/1 Running 0 5m22s app=timinglee

#恢复标签后

$root@k8s-master pod$ # kubectl label pods example-rep-9lbts app=timinglee --overwrite

pod/example-rep-9lbts labeled

$root@k8s-master pod$ # kubectl get pods --show-labels

NAME READY STATUS RESTARTS AGE LABELS

example-rep-9lbts 1/1 Running 0 6m46s app=timinglee

example-rep-dvjhp 1/1 Running 0 6m46s app=timinglee

$root@k8s-master pod$ # kubectl delete replicasets.apps example-rep

replicaset.apps "example-rep" deleted

###不能对版本维护

$root@k8s-master pod$ # vim timinglee.yml

$root@k8s-master pod$ # kubectl apply -f timinglee.yml

replicaset.apps/example-rep created

$root@k8s-master pod$ # kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

example-rep-5qd56 1/1 Running 0 41s 10.244.2.30 k8s-node1.timinglee.org <none> <none>

example-rep-wsb8r 1/1 Running 0 41s 10.244.1.38 k8s-node2.timinglee.org <none> <none>

$root@k8s-master pod$ # curl 10.244.2.30

$root@k8s-master pod$ # kubectl delete replicasets.apps example-rep

replicaset.apps "example-rep" deleted

四 deployment 控制器

4.1 deployment控制器的功能

为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。
Deployment控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod
Deployment管理ReplicaSet，ReplicaSet管理Pod
Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法
在Deployment中ReplicaSet相当于一个版本

典型的应用场景：

用来创建Pod和ReplicaSet
滚动更新和回滚
扩容和缩容
暂停与恢复

4.2 deployment控制器示例

$root@k8s-master pod$ # kubectl create deployment timinglee-dp --image myapp:v1 --dry-run=client -o yaml > timinglee-dp.yml

$root@k8s-master pod$ # vim timinglee-dp.yml

4.2.1 版本迭代

$root@k8s-master pod$ # vim timinglee-dp.yml

$root@k8s-master pod$ # kubectl expose deployment timinglee-dp --port 80 --target-port 80 --dry-run=client -o yaml >> timinglee-dp.yml

$root@k8s-master pod$ # vim timinglee-dp.yml

$root@k8s-master pod$ # kubectl apply -f timinglee-dp.yml

deployment.apps/timinglee-dp unchanged

service/timinglee-dp created

$root@k8s-master \~$ # curl 10.104.142.151

Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

$root@k8s-master \~$ # iptables -t nat -nL

!NOTE

更新的过程是重新建立一个版本的RS，新版本的RS会把pod 重建，然后把老版本的RS回收

4.2.2 版本回滚

$root@k8s-master pod$ # vim timinglee-dp.yml

$root@k8s-master pod$ # curl 10.104.142.151

Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

$root@k8s-master pod$ # kubectl get pods

NAME READY STATUS RESTARTS AGE

timinglee-dp-6ddbc47678-gpkz4 1/1 Running 0 108s

timinglee-dp-6ddbc47678-kkt2c 1/1 Running 0 108s

timinglee-dp-6ddbc47678-n6qjn 1/1 Running 0 107s

timinglee-dp-6ddbc47678-zpgfj 1/1 Running 0 106s

4.2.3 滚动更新策略

$root@k8s-master pod$ # vim timinglee-dp.yml

$root@k8s-master pod$ # kubectl apply -f timinglee-dp.yml

deployment.apps/timinglee-dp configured

service/timinglee-dp unchanged

4.2.4 暂停及恢复

在实际生产环境中我们做的变更可能不止一处，当修改了一处后，如果执行变更就直接触发了

我们期望的触发时当我们把所有修改都搞定后一次触发暂停，避免触发不必要的线上更新

#####所有的更新完再上线

$root@k8s-master pod$ # kubectl rollout pause deployment timinglee-dp

deployment.apps/timinglee-dp paused

$root@k8s-master pod$ # vim timinglee-dp.yml

$root@k8s-master pod$ # curl 10.104.142.151

Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

#####资源限制

$root@k8s-master pod$ # vim timinglee-dp.yml

######恢复更新

$root@k8s-master pod$ # kubectl rollout resume deployment timinglee-dp

deployment.apps/timinglee-dp resumed

$root@k8s-master pod$ # kubectl describe pods timinglee-dp-5bb447f6b-knbw7

$root@k8s-master pod$ # kubectl delete -f timinglee-dp.yml

deployment.apps "timinglee-dp" deleted

service "timinglee-dp" deleted

五 daemonset控制器

5.1 daemonset功能

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

DaemonSet 的典型用法：

在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等
一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用
一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，并且对不同硬件类型具有不同的内存、CPU 要求

5.2 daemonset 示例

查看污点

$root@k8s-master pod$ # kubectl describe nodes k8s-node1.timinglee.org | grep Taints

Taints: <none>

$root@k8s-master pod$ # kubectl describe nodes k8s-node2.timinglee.org | grep Taints

Taints: <none>

$root@k8s-master pod$ # cp timinglee-dp.yml timinglee-dm.yml

$root@k8s-master pod$ # ls

lee.yml timinglee-dm.yml timinglee-dp.yml timinglee.yml

$root@k8s-master pod$ # vim timinglee-dm.yml

####无master （master有污点）

#####容忍污点

$root@k8s-master pod$ # kubectl delete -f timinglee-dm.yml

daemonset.apps "timinglee-dm" deleted

$root@k8s-master pod$ # vim timinglee-dm.yml

$root@k8s-master pod$ # kubectl apply -f timinglee-dm.yml

daemonset.apps/timinglee-dm created

$root@k8s-master pod$ # kubectl delete -f timinglee-dm.yml

daemonset.apps "timinglee-dm" deleted

六 job 控制器

6.1 job控制器功能

Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务

Job特点如下：

当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
当成功结束的pod达到指定的数量时，Job将完成执行

6.2 job 控制器示例：

$!NOTE$
关于重启策略设置的说明：

如果指定为OnFailure，则job会在pod出现故障时重启容器

而不是创建pod，failed次数不变

如果指定为Never，则job会在pod出现故障时创建新的pod

并且故障pod不会消失，也不会重启，failed次数加1

如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了