kubernetes(7)——控制器(ReplicaSet、Deployment、DaemonSet、job、Cronjob)
1.控制器
Pod控制器是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试 进行重启，当根据重启策略无效，则会重新新建pod的资源。
pod分类和控制器类型
Pod的分类：
- 自主式Pod：Pod退出后不会被创建
- 控制器管理的Pod：在控制器的生命周期里，始终要维持Pod的副本数目
控制器类型：
- Replication Controller和ReplicaSet
- Deployment
- DaemonSet
- StatefulSet
- Job
- CronJob
- HPA全称Horizontal Pod Autoscaler
replication、controller和reolicaset控制器
ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。
ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求。
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。
Deployment控制器
Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。
典型的应用场景：
用来创建Pod和ReplicaSet
滚动更新和回滚
扩容和缩容
暂停与恢复
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要求。
StatefulSet控制器
StatefulSet是用来管理有状态应用的工作负载API对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用"
StatefulSet用来管理Deployment和扩展一组Pod，井且能为这些Pod提供*序号和唯一性保证*。
StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
稳定的、唯一的网络标识符。
稳定的、持久的存储。
有序的、优雅的部署和缩放。
有序的、自动的滚动更新。
job、cronjob和hpa控制器
Job：
执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
Cronjob：
Cron-Job 创建基于时间调度的Jobs。
一个CronJob对象就像crontab (crontable)文件中的一行，它用Cron格式进行编写，并周期性地在给定的调度时间执行Job。
HPA：
根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放。
2. 控制器的部署和实例
控制器，之前的pod都是自主式的pod，在删除之后，pod就没有了，没有控制器去维护它
控制器管理的pod：在控制器的生命周期里，始终维持pod的副本数目
ReplicaSet应用
\vi rs.yaml
vim rs.yaml
apiVersion: apps/v1 #api版本定义
kind: ReplicaSet #定义资源类型为ReplicaSet
metadata: #元数据定义
name: replicaset-example
spec: #ReplicaSet的规格定义
replicas: 2 #定义副本数量为2个
selector: #标签选择器，定义匹配pod的标签
matchLabels:
app: nginx
template: #pod的模板定义
metadata: #pod的元数据定义
labels: #定义pod的标签，需要和上面定义的标签一致，也可以多出其他标签
app: nginx
spec: #pod的规格定义
containers: #容器定义
- name: nginx #容器名称
image: nginx #容器镜像
kubectl apply -f rs.yaml
每个容器起来之后，都会有app：nginx标签 rs去匹配pod，标签必须和底下的容器标签一致
注意：在使用指定控制器时，尽量使用apply来创建pod，apply支持更新而create不支持
kubectl get pod
kubectl get rs
可以看到一次运行了三个pod
kubectl get pod -o wide
实现了负载均衡
测试pod的拉伸，直接将yaml文件中副本的个数修改就可
把副本数量修改至现在的6个,可以看到重新更改文件时，直接成功
replicas: 6
缩减时，也直接更改副本个数就可以。
缩减时也可以直接在文件中修改（又改为3个）：
可以看到副本数量又变回3个，而且删除的3个是刚才新添加的
使用RS控制pod副本：更改某个pod的标签
更改标签
[kubeadm@server1 manifest]$ kubectl label pod replicaset-example-6vtfm app=myapp --overwrite
pod/replicaset-example-6vtfm labeled
[kubeadm@server1 manifest]$
之前是3个pod，由于改了标签，控制器又启了一个pod,控制自己维护的标签的pod始终是3个
rs是控制pod的副本的，一直将pod控制在期望状态。当pod数目不足时，会创建某些数量的pod，其他已经修改标签的会变成一个自主式的pod。
删除指定的pod：
此时该pod会被永久删除，不会再被重建
[kubeadm@server1 manifest]$ kubectl get pod
NAME READY STATUS RESTARTS AGE
replicaset-example-6vtfm 1/1 Running 0 23m
replicaset-example-k8vtv 1/1 Running 0 4m19s
replicaset-example-s6sjj 1/1 Running 0 23m
replicaset-example-whm7w 1/1 Running 0 8m52s
test 1/1 Running 2 20h
[kubeadm@server1 manifest]$ kubectl delete pod replicaset-example-6vtfm
pod "replicaset-example-6vtfm" deleted
[kubeadm@server1 manifest]$
测试先更改标签，再恢复标签会怎么样
kubectl get pod --show-labels
kubectl label pod fronted-vlpq1 app=myapp --overwrite
kubectl get pod --show-labels
kubectl label pod fronted-vlpq1 app=nginx --overwrite
kubectl get pod --show-labels
可以看到恢复标签后，修改时被新建的副本又被删除了
Deployment应用
一个Deployment控制器为Pods和ReplicaSets提供描述性的更新方式。
先删除上面的实验：kubectl delete -f rs.yaml
kubectl get pod
\vi de.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-nginx
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: reg.westos.org/k8s/myapp:v1
ports:
- containerPort: 80
[kubeadm@server1 manifest]$ kubectl apply -f de.yaml
deployment.apps/deployment-nginx created
[kubeadm@server1 manifest]$ kubectl get pod
NAME READY STATUS RESTARTS AGE
deployment-nginx-84f7d65dcf-294q8 1/1 Running 0 6s
deployment-nginx-84f7d65dcf-dqp7h 1/1 Running 0 6s
test 1/1 Running 2 20h
[kubeadm@server1 manifest]$
测试拉伸
测试做拉伸，和rs没有什么区别，因为拉伸本身就是由rs来维护的，副本的数量就是由rs来控制的
测试滚动更新，只需要在yaml文件中将myapp的版本改为v2即可
[kubeadm@server1 manifest]$ vim de.yaml
[kubeadm@server1 manifest]$ kubectl apply -f de.yaml
deployment.apps/deployment-nginx configured
[kubeadm@server1 manifest]$ kubectl get rs
NAME DESIRED CURRENT READY AGE
deployment-nginx-69ccd78d6b 2 2 2 6s
deployment-nginx-84f7d65dcf 0 0 0 13m
[kubeadm@server1 manifest]$
原来的rs还存在，并没有被删除掉，这是为了便于回滚
集群内部访问，更新成功
可以看到更新成功 回滚：与更新的方法相同，只需要修改文件内容的版本。回滚会直接使用原来的rs（更新时并没有删除）
回滚的时候，直接使用的是原来的rs，保留pod
查看回滚的状态
DaemonSet应用
DaemonSet确保全部(或者某些)节点上运行一个Pod的副本。当有节点加入集群时，也会为他们新增一个Pod。当有节点从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
首先拉取zabbix镜像并上传到harbor仓库
测试：
注意：DaemonSet控制器不需要rs来维护副本。DaemonSet确保每个节点运行一个pod副本。当有节点新加入集群时，也会为他们新增一个pod。当节点从集群删除时，对应的pod会被回收。如果删除DaemonSet会删除它创建的所有pod
测试删除一个pod
我们可以看到：删除后，DaemonSet控制器会自动再启动一个pod
job控制器
job比较适合做计算类的操作
首先拉取per镜像，上传至私有仓库
计算圆周率：
kubectl apply -f job.yaml #计算的结果在日志中
kubectl get pod -o wide
Cronjob应用
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: cronjob-example
spec:
schedule: "* * * * *" #分时日月周
jobTemplate:
spec:
template:
spec:
containers:
- name: cronjob
image: busybox
args:
- /bin/sh
- -c
- date;echo Hello from k8s cluster
restartPolicy: OnFailure
kubectl get pod -w #-w 实时监控状态
kubectl get pod
kubectl logs cronjob-example-1587266520-g6ckb
每隔一分
