目录
一、Pod控制器概述
1.Pod控制器简介
Pod控制器,又称之为工作负载(workload),是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试进行重启,当根据重启策略无效,则会重新新建pod的资源。
2.Pod控制器的类型
2.1ReplicaSet
ReplicaSet:代用户创建指定数量的pod副本,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。
ReplicaSet主要三个组件组成:
- 用户期望的pod副本数量
- 标签选择器,判断哪个pod归自己管理
- 当现存的pod数量不足,会根据pod资源模板进行新建
帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是RelicaSet不是直接使用的控制器,而是使用Deployment。
2.2Deployment
工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
2.3DaemonSet
用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如ELK服务
特性:服务是无状态的
服务必须是守护进程
2.4StatefulSet
管理有状态应用
2.5Job
只要完成就立即退出,不需要重启或重建
2.6Cronjob
周期性任务控制,不需要持续后台运行
3.Pod与控制器之间的关系
controllers:在集群上管理和运行容器的 pod 对象, pod 通过 label-selector 相关联。
Pod 通过控制器实现应用的运维,如伸缩,升级等。
二、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
#查看历史版本
kubectl rollout history deployment/nginx-deployment
三、 StatefulSet控制器
- 部署有状态应用
- 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
- 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
- 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现
- 有序收缩,滚动升级(即从N-1到0)
1.StatefulSet组成
StatefulSet由以下几个部分组成:
- Headless Service(无头服务):用于为Pod资源标识符生成可解析的DNS记录。
- volumeClaimTemplates(存储卷申请模板):基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
- StatefulSet:用于管控Pod资源。
2. 为什么要有volumeClaimTemplate?
大部分有状态副本集都会用到持久存储,比如分布式系统来说,由于数据是不一样的,每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷,多个pod使用同一个存储卷,而statefulset定义中的每一个pod都不能使用同一个存储卷,由此基于pod模板创建pod是不适应的,这就需要引入volumeClaimTemplate,当在使用statefulset创建pod时,会自动生成一个PVC,从而请求绑定一个PV,从而有自己专用的存储卷。
3.应用场景
- 动态性强:Pod会飘到别的node节点
- 更新发布频繁:互联网思维小步快跑,先实现再优化,老板永远是先上线再慢慢优化,先把idea变成产品挣到钱然后再慢慢一点一点优化
- 支持自动伸缩:一来大促,肯定是要扩容多个副本
4.如何实现服务发现?
服务发现:就是应用服务之间相互定位的过程。
K8S里服务发现的方式——DNS,使K8S集群能够自动关联Service资源的“名称”和“CLUSTERIP”,从而达到服务被集群自动发现的目的。
实现K8S里DNS功能的插件:
- skyDNS:Kubernetes 1.3之前的版本
- kubeDNS:Kubernetes 1.3至Kubernetes 1.11
- CoreDNS:Kubernetes 1.11开始至今
#安装CoreDNS,仅二进制部署环境需要安装CoreDNS
方法一:
下载链接:https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base
vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/g
sed -f transforms2sed.sed coredns.yaml.base > coredns.yaml
方法二:上传 coredns.yaml 文件
kubectl create -f coredns.yaml
kubectl get pods -n kube-system
5.更新策略
状态集的字段允许您配置 并禁用容器、标签、资源请求/限制的自动滚动更新,以及 状态集中 Pod 的注释。有两种可能的值:.spec.updateStrategy
- OnDelete:当 StatefulSet 设置为 时 , 状态集控制器不会自动更新 Pod 中的 有状态集。用户必须手动删除 Pod 才能使控制器 创建新的 Pod,以反映对 StatefulSet 所做的修改。
.spec.updateStrategy.type
OnDelete
.spec.template
- RollingUpdate:更新策略在 有状态集。这是默认的更新策略。
RollingUpdate
6.部署statefulset
官方文档:StatefulSets | Kubernetes
vim statefulset-pvc.yaml
apiVersion: v1
kind: Service
metadata:
name: svc-myapp
labels:
app: svc-myapp
spec:
ports:
- port: 80
name: http
protocol: TCP
targetPort: 80
type: ClusterIP
clusterIP: None #无头服务clusterIP需为None
selector:
app: myapp
---
apiVersion: apps/v1
kind: StatefulSet #设置pod的控制器
metadata:
name: myapp-sts
spec:
selector:
matchLabels:
app: myapp #控制器关联pod的标签,与下方pod模板标签一致
serviceName: svc-myapp
replicas: 3
template:
metadata:
labels:
app: myapp #定义pod的标签,需与控制器下符合的标签相同
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: nginx:1.14
ports:
- containerPort: 80
volumeMounts:
- name: mypvc #指定pvc名称
mountPath: /usr/share/nginx/html
volumeClaimTemplates: #pvc的配置模板
- metadata:
name: mypvc
spec:
accessModes: [ "ReadWriteOnce" ] #指定访问模式
storageClassName: "nfs-client-storageclass" #指定storageclass的名称
resources:
requests:
storage: 2Gi #指定pv大小
kubectl apply -f statefulset-pvc.yaml
#查看创建的pod
kubectl get pods
#查看pod是否与pv绑定
kubectl get pvc,pv
四、 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。
应用场景:Agent
官方案例(监控):DaemonSet | Kubernetes
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: 80
kubectl apply -f ds.yaml
//DaemonSet会在每个node节点都创建一个Pod
kubectl get pods
nginx-deployment-4kr6h 1/1 Running 0 35s
nginx-deployment-8jrg5 1/1 Running 0 35s
五、Job控制器
- Job分为普通任务(Job)和定时任务(CronJob)
- 常用于运行那些仅需要执行一次的任务
- 应用场景:数据库迁移、批处理脚本、kube-bench扫描、离线数据处理,视频解码等业务
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 #Pod任务失败后,尝试重启的最大次数
#参数解释
.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
pi-bqtf7 0/1 Completed 0 41s
#结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......
#清除job资源
kubectl delete -f job.yaml
六、CronJob控制器
- 周期性任务,像Linux的Crontab一样。
- 周期性任务
- 应用场景:通知,备份
Running Automated Tasks with a CronJob | Kubernetes
#每分钟打印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: OnFailure
kubectl create -f cronjob.yaml
#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: #必需字段,作业模板。这类似于工作示例