一、什么是控制器
Kubernetes 中内建了很多 controller(控制器),这些相当于一个状态机,用来控制 Pod 的具体状态和行为
1、控制器类型
- ReplicationController 和 ReplicaSet
- Deployment
- DaemonSet
- StateFulSet
- Job/CronJob
- Horizontal Pod Autoscaling
2、ReplicationController 和 ReplicaSet
ReplicationController(RC)用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的 Pod 来替代;而如果异常多出来的容器也会自动回收;
在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟 ReplicationController 没有本质的不同,只是名字不一样,并且 ReplicaSet 支持集合式的 selector;
3、Deployment
Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法,用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括;
- 定义 Deployment 来创建 Pod 和 ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续 Deployment
4、DaemonSet
DaemonSet 确保全部(或者一些)Node 上运行一个 Pod 的副本。当有 Node 加入集群时,也会为他们新增一个Pod 。当有 Node 从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod
使用 DaemonSet 的一些典型用法:
- 运行集群存储 daemon,例如在每个 Node 上运行 glusterd 、 ceph
- 在每个 Node 上运行日志收集 daemon,例如 fluentd 、 logstash
- 在每个 Node 上运行监控 daemon,例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代理,或 Ganglia gmond
5、Job
Job 负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个 Pod 成功结束
6、CronJob
Cron Job 管理基于时间的 Job,即:
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
使用前提条件:当前使用的 Kubernetes 集群,版本 >= 1.8(对 CronJob)。对于先前版本的集群,版本 < 1.8,启动 API Server时,通过传递选项 --runtime-config=batch/v2alpha1=true
可以开启 batch/v2alpha1 API
典型的用法如下所示:
- 在给定的时间点调度 Job 运行
- 创建周期性运行的 Job,例如:数据库备份、发送邮件
7、StatefulSet
StatefulSet 作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计),其应用
场景包括:
- 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
- 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有 Cluster IP的Service)来实现
- 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init -containers来实现
- 有序收缩,有序删除(即从N-1到0)
8、Horizontal Pod Autoscaling
应用的资源使用率通常都有高峰和低谷的时候,如何削峰填谷,提高集群的整体资源利用率,让service中的Pod
个数自动调整呢?这就有赖于Horizontal Pod Autoscaling了,顾名思义,使Pod水平自动缩放
二、RS 的使用
1、实例
查看rs的参数
kubectl explain rs
kubectl apply -f rs.yaml
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: myapp
image: hub.atguigu.com/library/myapp:v1
env:
- name: GET_HOSTS_FROM
value: dns
ports:
- containerPort: 80
2、查看标签
[root@k8s-master01 ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
frontend-d2bzk 1/1 Running 0 72s tier=frontend
frontend-p9z8v 1/1 Running 0 72s tier=frontend
frontend-wzcq9 1/1 Running 0 72s tier=frontend
3、修改标签
修改后,rs会再次创建一个新的pod。rs会根据labels来确认自己有哪些pod。pod的labels被修改后,这个pod不再属于rs管理。
[root@k8s-master01 ~]# kubectl label pod frontend-d2bzk tier=frontend1 --overwrite=True
pod/frontend-d2bzk labeled
[root@k8s-master01 ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
frontend-d2bzk 1/1 Running 0 3m38s tier=frontend1
frontend-p9z8v 1/1 Running 0 3m38s tier=frontend
frontend-wzcq9 1/1 Running 0 3m38s tier=frontend
frontend-xll2h 1/1 Running 0 11s tier=frontend
4、删除rs。
有一个frontend-d2bzk
pod 没有被删除,原因时这个pod已经不属于rs管理。
[root@k8s-master01 ~]# kubectl delete rs --all
replicaset.extensions "frontend" deleted
[root@k8s-master01 ~]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
frontend-d2bzk 1/1 Running 0 6m55s tier=frontend1
frontend-p9z8v 0/1 Terminating 0 6m55s tier=frontend
frontend-wzcq9 0/1 Terminating 0 6m55s tier=frontend
frontend-xll2h 0/1 Terminating 0 3m28s tier=frontend
三、RS 与 RC 与 Deployment 关联
RC (ReplicationController )主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收
Kubernetes 官方建议使用 RS(ReplicaSet ) 替代 RC (ReplicationController ) 进行部署,RS 跟 RC 没有本质的不同,只是名字不一样,并且 RS 支持集合式的 selector
1、RS 与 Deployment 的关联
2、Deployment 案例
deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: hub.atguigu.com/library/myapp:v1
ports:
- containerPort: 80
3、创建
## --record参数可以记录命令,我们可以很方便的查看每次 revision 的变化
[root@k8s-master01 ~]# kubectl apply -f deployment.yaml --record
deployment.extensions/nginx-deployment created
[root@k8s-master01 ~]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 24s
4、扩容
[root@k8s-master01 ~]# kubectl scale deployment nginx-deployment --replicas 10
deployment.extensions/nginx-deployment scaled
[root@k8s-master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-5df65767f-5wt4z 1/1 Running 0 103s
nginx-deployment-5df65767f-6p5rt 1/1 Running 0 103s
nginx-deployment-5df65767f-dq549 1/1 Running 0 4m15s
nginx-deployment-5df65767f-l4dm6 1/1 Running 0 4m15s
nginx-deployment-5df65767f-tgklj 1/1 Running 0 103s
nginx-deployment-5df65767f-v24pf 1/1 Running 0 103s
nginx-deployment-5df65767f-vtv4g 1/1 Running 0 103s
nginx-deployment-5df65767f-vwmwd 1/1 Running 0 103s
nginx-deployment-5df65767f-zdhfn 1/1 Running 0 103s
nginx-deployment-5df65767f-zw8ml 1/1 Running 0 4m15s
5、修改镜像
镜像的修改会触发rs的创建。
[root@k8s-master01 ~]# kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2
deployment.extensions/nginx-deployment image updated
[root@k8s-master01 ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-5c478875d8 10 10 10 2m17s
nginx-deployment-5df65767f 0 0 0 12m
6、回滚
[root@k8s-master01 ~]# kubectl rollout undo deployment/nginx-deployment
deployment.extensions/nginx-deployment rolled back
7、查看rs历史版本
[root@k8s-master01 ~]# kubectl rollout history deployment nginx-deployment
deployment.extensions/nginx-deployment
REVISION CHANGE-CAUSE
2 kubectl apply --filename=deployment.yaml --record=true
3 kubectl apply --filename=deployment.yaml --record=true
4 kubectl apply --filename=deployment.yaml --record=true
8、回退到指定版本
[root@k8s-master01 ~]# kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment.extensions/nginx-deployment rolled back
9、查看回滚状态
[root@k8s-master01 ~]# kubectl rollout status deployment nginx-deployment
deployment "nginx-deployment" successfully rolled out
10、回退 Deployment 相关命令
kubectl set image deployment/nginx-deployment nginx=nginx:1.91
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用 --revision参数指定某个历史版本
kubectl rollout pause deployment/nginx-deployment ## 暂停 deployment 的更新
您可以用 kubectl rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成, kubectl rollout status 将返回一个0值的 Exit Code
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0
11、清理 Policy
您可以通过设置 .spec.revisonHistoryLimit
项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision;如果将该项设置为0,Deployment 就不允许回退了
12、Deployment 更新策略
Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的,它会确保至少有比期望的Pod数量少一个是up状态(最多一个不可用)
Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的,它会确保最多比期望的Pod数量多一个的 Pod 是 up 的(最多1个 surge )
未来的 Kuberentes 版本中,将从1-1变成25%-25%
$ kubectl describe deployments
13、Rollover(多个rollout并行)
假如您创建了有5个 niginx:1.7.9 replica的 Deployment,但是当前只有3个 nginx:1.7.9 的 replica 创建出来的时候,您就开始更新镜像为 nginx:1.9.1 replica 的 Deployment。在这种情况下,Deployment 会立即杀掉已创建的3个 nginx:1.7.9 的 Pod,并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的Pod 都创建完成后才开始改变航道。
四、DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: deamonset-example
labels:
app: daemonset
spec:
selector:
matchLabels:
name: deamonset-example
template:
metadata:
labels:
name: deamonset-example
spec:
containers:
- name: daemonset-example
image: wangyanglinux/myapp:v1
五、Job
特殊说明
- spec.template格式同Pod
- RestartPolicy仅支持Never或OnFailure
- 单个Pod时,默认Pod成功运行后Job即结束
- .spec.completions 标志Job结束需要成功运行的Pod个数,默认为1
- .spec.parallelism 标志并行运行的Pod的个数,默认为1
- spec.activeDeadlineSeconds 标志失败Pod的重试最大时间,超过这个时间不会继续重试
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
name: pi
spec:
containers:
- name: pi
image: hub.atguigu.com/library/perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
六、CronJob
1、CronJob Spec
.spec.schedule :调度,必需字段,指定任务运行周期,格式同 Cron
.spec.jobTemplate :Job 模板,必需字段,指定需要运行的任务,格式同 Job
.spec.startingDeadlineSeconds :启动 Job 的期限(秒级别),该字段是可选的。如果因为任何原因而错过了被调度的时间,那么错过执行时间的 Job 将被认为是失败的。如果没有指定,则没有期限
.spec.concurrencyPolicy :并发策略,该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种:
- Allow (默认):允许并发运行 Job
- Forbid :禁止并发运行,如果前一个还没有完成,则直接跳过下一个
- Replace :取消当前正在运行的 Job,用一个新的来替换
注意,当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job,它们创建的 Job 之间总是允许并发运行。
.spec.suspend :挂起,该字段也是可选的。如果设置为 true ,后续所有执行都会被挂起。它对已经开始执行的 Job 不起作用。默认值为 false 。
.spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit :历史限制,是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下,它们分别设置为 3 和 1 。设置限制的值为 0 ,相关类型的 Job 完成后将不会被保留。
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec: #CrondJob 本身的一些限制创建 Job 操作应该是 幂等的
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
[root@k8s-master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
hello-1629630780-wd9pn 0/1 Completed 0 2m32s
hello-1629630840-9f4ql 0/1 Completed 0 92s
hello-1629630900-mxhf4 0/1 Completed 0 32s
[root@k8s-master01 ~]# kubectl log hello-1629630900-mxhf4
log is DEPRECATED and will be removed in a future version. Use logs instead.
Sun Aug 22 11:15:07 UTC 2021
Hello from the Kubernetes cluster
[root@k8s-master01 ~]# kubectl log hello-1629630840-9f4ql
log is DEPRECATED and will be removed in a future version. Use logs instead.
Sun Aug 22 11:14:37 UTC 2021
Hello from the Kubernetes cluster
# 注意,删除 cronjob 的时候不会自动删除 job,这些 job 可以用 kubectl delete job 来删除
$ kubectl delete cronjob hello
cronjob "hello" deleted