kubernetes--Pod控制器详解
目录
一、Pod控制器及其功用：
二、pod控制器的多种类型：
1、ReplicaSet:
1.1 ReplicaSet主要三个组件组成：
2、Deployment：
3、DaemonSet：
4、StatefulSet：
5、Job：
6、Cronjob：
三、Deployment控制器：
示例：
查看控制器配置
查看历史版本
四、SatefulSet：
1. 示例：
2. StatefulSet的组成部分：
3. 为什么要有headless：
4. 为什么要有volumeClaimTemplate：
5. 常规service和无头服务区别：
6. 总结：
五、DaemonSet：
1. DaemonSet 的一些典型用法：
2. 示例：
3. 总结：
六、Job：
1. 示例：
2. 参数解释
3. backoffLimit：
4. 总结：
七、CronJob ：
1. 示例：
2. cronjob其它可用参数的配置：
3. 总结：
一、Pod控制器及其功用：
Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。
二、pod控制器的多种类型：
1、ReplicaSet:
代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。
1.1 ReplicaSet主要三个组件组成：
- 用户期望的pod副本数量
- 标签选择器，判断哪个pod归自己管理
- 当现存的pod数量不足，会根据pod资源模板进行新建
帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。
2、Deployment：
- 工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置。
- ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
3、DaemonSet：
用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
特性：服务是无状态的
服务必须是守护进程
4、StatefulSet：
管理有状态应用
5、Job：
只要完成就立即退出，不需要重启或重建
6、Cronjob：
周期性任务控制，不需要持续后台运行
三、Deployment控制器：
- 部署无状态应用
- 管理Pod和ReplicaSet
- 具有上线部署、副本设定、滚动升级、回滚等功能
- 提供声明式更新，例如只更新一个新的image
- 应用场景：web服务
示例：
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
kubectl create -f nginx-deployment.yaml
kubectl get pods,deploy,rs
查看控制器配置
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-04-19T08:13:50Z"
generation: 1
labels:
app: nginx #Deployment资源的标签
name: nginx-deployment
namespace: default
resourceVersion: "167208"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
progressDeadlineSeconds: 600
replicas: 3 #期望的pod数量，默认是1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25% #升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
maxUnavailable: 25% #升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
type: RollingUpdate #滚动升级
template:
metadata:
creationTimestamp: null
labels:
app: nginx #Pod副本关联的标签
spec:
containers:
- image: nginx:1.15.4 #镜像名称
imagePullPolicy: IfNotPresent #镜像拉取策略
name: nginx
ports:
- containerPort: 80 #容器暴露的监听端口
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always #容器重启策略
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
......查看历史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1 四、SatefulSet：
- 部署有状态应用
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
- 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
- 有序收缩，有序删除（即从N-1到0）
常见的应用场景：数据库
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
1. 示例：
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None #不创建custerip，也就是无头服务的service
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3 #三个副本
template: #定义容器的模板
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 10 #10秒内pod没关闭，就强制杀死
containers:
- name: nginx
image: nginx:1.14.1
ports:
- containerPort: 80
name: web
volumeMounts: #容器内挂载
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates: #存储卷的申请模板
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ] #可读可写，仅能一个节点挂载
storageClassName: "nfs-client-storageclass" #使用动态创建的pv
resources: #设置请求的资源大小
requests:
storage: 2Gi
由于StatefulSet资源依赖于一个实现存在的Headless类型的Service资源，所以需要先定义一个名为nginx的Headless Service资源，用于为关联到每个Pod资源创建DNS资源记录。接着定义了一个名为web的StatefulSet资源，它通过Pod模板创建了3个Pod资源副本，并基于volumeClaimTemplates向存储类进行了请求大小为2Gi的专用存储卷。
2. StatefulSet的组成部分：
- Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
- volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
- StatefulSet：用于管控Pod资源。
3. 为什么要有headless：
在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。
4. 为什么要有volumeClaimTemplate：
大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClaimTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。
5. 常规service和无头服务区别：
- service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
- Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。
6. 总结：
- 部署有状态应用（有实时的数据需要存储）
- 每个Pod名称标识都是唯一且固定不变的
- 每个Pod都可以有自己专属的持久化存储（基于PVC模板volumeClaimTemplates实现的）
- 需要提前创建一个Headless Service资源（无头服务，ClusterIP可以为Node），并在StatefulSet资源清单配置中使用serviceName字段指定Headless Service资源名称
- 可以在Pod内通过
. .<命名空间>[.svc.cluster.local]格式解析出PodIP（基于Headless Service和CoreDNS实现的） - 创建、滚动升级、扩容、缩容Pod副本时都是有序进行的（默认为串行执行的，由spec.podManagementPolicy字段决定的，默认值为OrderedReady，为Parallel则并行执行）
- 创建、扩容是升序执行的（顺序为Pod标识号从0到n-1） 滚动升级、缩容是倒序执行的（顺序为Pod标识号从n-1到0）
五、DaemonSet：
DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
1. DaemonSet 的一些典型用法：
- 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
- 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
- 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。
应用场景：Agent
//官方案例（监控）
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
2. 示例：
vim ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonSet
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80kubectl apply -f ds.yaml
//DaemonSet会在每个node节点都创建一个Pod3. 总结：
- 通常用于部署daemon级别的无状态应用
- 理论上可以在K8S所有node节点上创建相同的Pod资源，无论node节点什么时候加入到K8S集群（需要考虑到污点和cordon不可调度的影响）
- 不需要配置Pod副本数字段replicas
六、Job：
Job分为普通任务（Job）和定时任务（CronJob），常用于运行那些仅需要执行一次的任务
应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
1. 示例：
vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
2. 参数解释
.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。
.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。
- 在所有node节点下载perl镜像，因为镜像比较大，所以建议提前下载好
docker pull perl
kubectl apply -f job.yaml
kubectl get pods
//结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......
//清除job资源
kubectl delete -f job.yaml 3. backoffLimit：
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
restartPolicy: Never
backoffLimit: 2kubectl apply -f job-limit.yaml
kubectl get job,pods
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/1 4m34s 4m34s
NAME READY STATUS RESTARTS AGE
pod/busybox-dhrkt 0/1 Error 0 4m34s
pod/busybox-kcx46 0/1 Error 0 4m
pod/busybox-tlk48 0/1 Error 0 4m21s
kubectl describe job busybox
......
Warning BackoffLimitExceeded 43s job-controller Job has reached the specified backoff limit
4. 总结：
- 部署一次性的短期任务的Pod资源，Pod不会持久运行
- 任务正常完成后Pod容器会正常退出且不再重启（restartPolicy字段需要设置为Never或OnFailure），并也不会再重建Pod
- 如果任务执行失败导致Pod容器异常退出，Job会根据backoffLimit字段决定重建Pod重试任务的次数（默认值为6）
七、CronJob ：
周期性任务 类似Linux的Crontab。
应用场景：通知，备份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
1. 示例：
//每分钟打印hello
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure2. cronjob其它可用参数的配置：
spec:
concurrencyPolicy: Allow #声明了 CronJob 创建的任务执行时发生重叠如何处理（并发性规则仅适用于相同 CronJob 创建的任务）。spec仅能声明下列规则中的一种:
●Allow (默认)：CronJob 允许并发任务执行。
●Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
●Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。
startingDeadlineSeconds: 15 #它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务，且标记失败.如果此字段未设置，那任务就没有最后期限。
successfulJobsHistoryLimit: 3 #要保留的成功完成的任务数（默认为3）
failedJobsHistoryLimit：1 #要保留多少已完成和失败的任务数（默认为1）
suspend：true #如果设置为 true ，后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。
schedule: '*/1 * * * *' #必需字段，作业时间表。在此示例中，作业将每分钟运行一次
jobTemplate: #必需字段，作业模板。这类似于工作示例kubectl create -f cronjob.yaml
kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 25s 3. 总结：
- 部署周期性的短期任务的Pod资源，Pod不会持久运行
- 任务正常完成后Pod容器会正常退出且不再重启（restartPolicy字段需要设置为Never或OnFailure），并也不会再重建Pod
- 必须要配置schedule字段设置任务执行的周期表，格式为 "分 时 日 月 周"