文章目录
- 一、ReplicaSet(RS)(保证Pod能够正常运行)
- 二、Deployment(Deploy)(管理ReplicaSet,支持发布停止、继续、版本升级回退)
- [三、Horizontal Pod Autoscaler(HPA)(根据Pod使用情况自动调整Pod数量)](#三、Horizontal Pod Autoscaler(HPA)(根据Pod使用情况自动调整Pod数量))
- 四、DaemonSet(DS)(每个节点都运行一个副本)
- 五、Job(处理短暂的一次性任务)
- 六、ConJob(CJ)(特定时间点反复执行job任务)
Pod创建方式
自主式pod :kubernetes直接创建出来的pod,这种pod删除后就没有了,也不会重建
控制器创建的pod:通过控制器创建的pod,这种pod删除了之后还会自动重建
Pod控制器:Pod控制器是管理pod的中间层,使用了pod控制器之后,我们只需要告诉pod控制器,想要多少个什么样的pod就可以了,它就会创建出满足条件的pod并确保每一个pod处于用户期望的状态,如果pod在运行中出现故障,控制器会基于指定策略重启动或者重建pod。
Pod控制器类型
ReplicationController :比较原始的pod控制器,已经被废弃,由ReplicaSet替代
ReplicaSet :保证指定数量的pod运行,并支持pod数量变更,镜像版本变更
Deployment :通过控制ReplicaSet来控制pod,并支持滚动升级、版本回退
Horizontal PodAutoscaler :可以根据集群负载自动调整Pod的数量,实现削峰填谷
DaemonSet :在集群中的指定Node上都运行一个副本,一般用于守护进程类的任务
Job :它创建出来的pod只要完成任务就立即退出,用于执行一次性任务
Cronjob :它创建的pod会周期性的执行,用于执行周期性任务
StatefulSet:管理有状态应用
一、ReplicaSet(RS)(保证Pod能够正常运行)
ReplicaSet的主要作用是保证一定数量的pod能够正常运行,它会持续监听这些pod的运行状态,一旦pod发生故障,就会重启或重建。同时它还支持对pod数量的扩缩容和版本镜像的升级。
yaml
apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型
metadata: # 元数据
name: # rs名称
namespace: # 所属命名空间
labels: # 标签
controller: rs
spec: # 详情描述
replicas: 3 # 副本数量
selector: # 选择器,通过它指定该控制器管理哪些pod
matchLabels: # Labels匹配规则
app: nginx-pod
matchExpressions: # Expressions匹配规则
- {key: app, operator: In, values: [nginx-pod]}
template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
replicas :指定副本数量,其实就是当前rs创建出来的pod的数量,默认为1
selector :选择器,它的作用是建立pod控制器和pod之间的关联关系,采用的LabelSelector机制在pod模板上定义label,在控制器上定义选择器,就可以表明当前控制器能管理哪些pod了
template:模板,就是当前控制器创建pod所使用的模板板,里面其实就是前一章学过的pod的定义
创建文件
yaml
apiVersion: apps/v1 #版本号
kind: ReplicaSet #类型
metadata: # 元数据
name: demo #rs名称
namespace: dev #所属命名空间
spec: #详情描述
replicas: 3 #副本数量
selector: #选择器,通过它指定该控制器管理哪些pod
matchLabels: #Labels匹配规则
app: nginx-pod
template: #模板,当副本数量不足时,会根据下面的模板创建pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
创建rs:
kubectl create -f demo.yaml查看rs:
get kubectl demo -n dev -o wide(DESIRED:期望副本数量CURRENT:当前副本数量READY:已经准备好提供服务的副本数量)查看当前控制器创建出来的pod:
kubectl get pod -n dev(这里发现控制器创建出来的pod的名称是在控制器名称后面拼接了-xxxxx随机码)
扩缩容
编辑rs的副本数量,修改spec:replicas:6即可:
kubectl edit rs demo -n dev查看pod:
kubectl get pods -n dev当然也可以直接使用命令实现:
kubectl scale rs demo --replicas=2 -n dev(使用scale命令实现扩缩容,后面--replicas=n直接指定目标数量即可)命令运行完毕,立即查看,发现已经有4个开始准备退出了:
kubectl qet pods -n dev(稍等片刻,就只剩下2个了)
镜像升级
编辑rs的容器镜像 -image:nginx:1.17.2:
kubectl edit rs demo -n dev再次查看,发现镜像版本已经变更了:
kubectl get rs -n dev -o wide同样的道理,也可以使用命令完成这个工作:
kubectl set image rs demo nginx=nginx:1.17.1 -n dev(kubectl set image rs rs名称 容器=镜像版本 -n namespace)再次查看,发现镜像版本已经变更了:
kubectl get rs -n dev -o wide
删除ReplicasSet
使用kubectl delete命令会删除此RS以及它管理的Pod:
kubectl delete rs demo -n dev(在kubernetes删除RS前,会将RS的replicasclear调整为0,等待所有的Pod被删除后,在执行RS对象的删除)查看:
kubectl get pod -n dev -o wide如果希望仅仅删除RS对象(保留Pod),可以使用kubectl delete命令时添加--cascade=false选项(不推荐):
kubectl delete rs pc-replicaset -n dev --cascade=false也可以使用yaml直接删除(推荐):
kubectl delete -f demo.yaml
二、Deployment(Deploy)(管理ReplicaSet,支持发布停止、继续、版本升级回退)
为了更好的解决服务编排的问题,kubernetes在V1.2版本开始,引入了Deployment控制器。值得一提的是,这种控制器并不直接管理pod,而是通过管理ReplicaSet来间接管理Pod,即:Deployment管理ReplicaSet,ReplicaSet管理Pod。所以DeploymenttReplicaSet功能更加强大。
主要功能
支持ReplicaSet的所有功能
支持发布的停止、继续
支持版本滚动升级和版本回退
资源清单文件
yaml
apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型
metadata: # 元数据
name: # rs名称
namespace: # 所属命名空间
labels: # 标签
controller: deploy
spec: # 详情描述
replicas: 3 # 副本数量
revisionHistoryLimit: 3 # 保留历史版本,默认是10
paused: false # 暂停部署,默认是false
progressDeadlineSeconds: 600 #部署超时时间(s),默认是600
strategy: # 策略
type: RollingUpdate # 滚动更新策略
rollingUpdate: # 滚动更新
maxSurge: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数
maxUnavailable: 30% # 最大不可用状态的Pod的最大值,可以为百分比,也可以为整数
selector: # 选择器,通过它指定该控制器管理哪些pod
matchLabels: # Labels匹配规则
app: nginx-pod
matchExpressions: # Expressions匹配规则
- {key: app, operator: In, values: [nginx-pod]}
template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort:80
创建文件
yaml
apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据
name: demo # rs名称
namespace: dev # 所属命名空间
spec: # 详情描述
replicas: 3 # 副本数量
selector: # 选择器,通过它指定该控制器管理哪些pod
matchLabels: # Labels匹配规则
app: nginx-pod
template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
创建deployment:
kubectl create -f demo.yaml --record=true(--record=true 记录每次的版本变化)查看deployment:
kubectl get deploy demo -n dev(UP-TO-DATE 最新版本的pod的数量AVAILABLE.当前可用的pod的数量)查看rs:
kubectl get rs -n dev(发现rs的名称是在原来deployment的名字后面添加了一个10位数的随机串)查看pod:
kubectl get pods -n dev
扩缩容
变更副本数量为5个:
kubectl scale deploy demo --replicas=5 -n dev查看deployment:
kubectl get deploy demo -n dev查看pod:
kubectl get pods -n dev编辑deployment的副本数量,修改spec:replicas:4即可:
kubectl edit deploy demo -n dev查看pod:
kubectl get pods -n dev
镜像更新
Deployment支持两种镜像更新的策略:
重建更新和滚动更新(默认),可以通过strategy选项进行配置。
yaml
strategy: 指定新的Pod替换旧的Pod的策略,支持两个属性:
type: 指定策略类型,支持两种策略
Recreate: 在创建出新的Pod之前会先杀掉所有已存在的Pod
RollingUpdate: 滚动更新,就是杀死一部分,就启动一部分,在更新过程中,存在两个版本Pod
rollingUpdate: 当type为RollingUpdate时生效,用于为RollingUpdate设置参数,支持两个属性:
maxUnavailable: 用来指定在升级过程中不可用Pod的最大数量,默认为25%。
maxSurge: 用来指定在升级过程中可以超过期望的Pod的最大数量,默认为25%。
重建更新
在上面文件的spec节点下添加更新策略,如下内容
yaml
spec:
strategy: #策略
type: Recreate #重建更新策略
创建deploy进行验证
变更镜像:
kubectl set image deployment demo nginx=nginx:1.17.2 -n dev观察升级过程:
kubectl get pods -n dev -w
滚动更新
在上面文件的spec节点下添加更新策略,如下内容
yaml
spec:
strategy: #策略
type: RollingUpdate #重建更新策略
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
创建deploy进行验证
变更镜像:
kubectl set image deployment demo nginx=nginx:1.17.2 -n dev观察升级过程:
kubectl get pods -n dev -w查看rs:
kubectl get rs -n dev发现原来的rs的依旧存在,只是pod数量变为了0,而后又新产生了一个rs,pod数量为4其实这就是deployment能够进行版本回退的奥妙所在,后面会详细解释
版本回退
deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能,下面具体来看.
kubectlrollout:版本升级相关功能,支持下面的选项:
status :显示当前升级状态
history :显示升级历史记录
pause :暂停版本升级过程
resume :继续已经暂停的版本升级过程
restart :重启版本升级过程
undo:回滚到上一级版本(可以使用--to-revision回滚到指定版本)
查看当前升级版本的状态:kubectl rollout status deploy demo -n dev查看升级历史记录:
kubectl rollout history deploy demo -n dev可以发现有三次版本记录,说明完成过两次升级
版本回滚
版本回滚:
kubectl rollout undo deployment demo --to-revision=1 -n dev(--to-revision=1回滚到指定版本,省略则默认上一个版本)查看:
kubectl get deploy -n dev -o wide(镜像版本回退到了第一版)查看rs:
kubectl get rs -n dev(发现第一个rs中有4个pod运行,后面两个版本的rs中pod为运行)其实deployment之所以可是实现版本的回滚,就是通过记录下历史rs来实现的,一旦想回滚到哪个版本,只需要将当前版本pod数量降为0,然后将回滚版本的pod提升为目标数量就可以了
金丝雀发布
Deployment支持更新过程中的控制,如"暂停(pause)"或"继续(resume)"更新操作。
比如有一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。
更新deployment的版本,并配置暂停deployment:kubectl set image deploy demo nginx=nginx:1.17.4 -n dev && kubectlrollout pause deployment demo -n dev观察更新状态:
kubectl rollout status deploy demo -n dev监控更新的过程,可以看到已经新增了一个资源,但是并未按照预期的状态去删除一个旧的资源,就是因为使用了pause暂停命令
kubectl get rs -n dev -o wide
kubectl get pods -n dev删除deployment,其下的rs和pod也将被删除:
kubectl delete -f demo.yaml
三、Horizontal Pod Autoscaler(HPA)(根据Pod使用情况自动调整Pod数量)
HPA控制器:可以
通过监测Pod的使用情况,实现pod数量的自动调整。HPA可以获取每个pod利用率,然后和HPA中定义的指标进行对比,同时计算出需要伸缩的具体值,最后实现pod的数量的调整。其实HPA与之前的Deployment一样,也属于一种Kubernetes资源对象,它通过追踪分析目标pod的负载变化情况,来确定是否需要针对性地调整目标pod的副本数。
安装metrics-server
metrics-server可以用来收集集群中的资源使用情况
安装git:
yum install git -y获取metrics-server,注意使用的版本:
git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server修改deployment,注意修改的是镜像和初始化参数:
cd /root/metrics-server/deploy/1.8+/、vim metrics-server-deployment.yaml修改如下内容
yaml
...
hostNetwork: true
serviceAccountName: metrics-server
columes:
- name: tmp-dir
emptyDir: {}
containers:
- name: metrics-server
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
imagePullPolicy: Always
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname, InternalDNS,ExternalDNS,ExternalIP
volumeMounts:
...
安装metrics-serverroot@master 1.8+:
kubectl apply -f ./查看pod运行情况:
kubectl get hpa -n kube-system使用kubectl top node 查看资源使用情况(稍微等待一会查看):
kubectl top node、kubectl top pod -n kube-system至此,metrics-server安装完成
准备deployment和service
为了操作简单,直接使用命令
创建deployment:
kubectl run nginx --image=nginx:latest --requests=cpu=100m -n dev创建service:
kubectl expose deployment nginx --type-NodePort --port=80 -n dev查看:
kubectl get deployment,pod,svc -n dev
部署HPA
创建文件,内容如下
yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: demo
namespace: dev
spec:
minReplicas: 1 #最小pod数量
maxReplicas: 10 #最大pod数量
targetCPUUtilizationPercentage: 3 # CPU使用率指标 3%
scaleTargetRef: #指定要控制的nginx信息
apiVersion: apps/v1
kind: Deployment
name: nginx
创建hpa:
kubectl create -f demo.yaml查看hpa:
kubectl get hpa -n dev
测试:使用压测工具对service地址192.168.109.100:31136进行压测,然后通过控制台查看hpa和pod的变化
四、DaemonSet(DS)(每个节点都运行一个副本)
DaemonSet类型的控制器可以保证
集群中的每一台(或指定)节点上都运行一个副本,一般适用于日志收集、节点监控等场景。也就是说,如果一个pod提供的功能是节点级别的(每个节点都需要且只需要一个),那么这类Pod就活合使用DaemonSet类型的控制器创建
控制器的特点
每当向集群中添加一个节点时,指定的pod副本也将添加到该节点上
当节点从集群中移除时,pod也就被垃圾回收了
资源清单文件
yaml
apiVersion: apps/v1 #版本号
kind: DaemonSet #类型
metadata: # 元数据
name: #rs名称
namespace: #所属命名空间
labels: #标签
controller: daemonset
spec: #详情描述
revisionHistoryLimit: 3 #保留历史版本
updateStrategy: # 更新策略
type: RollingUpdate #滚动更新策略
rollingUpdate: #滚动更新
maxUnavailable: 1 #最大不可用状态的 Pod的最大值,可以为百分比,也可以为整数
selector: #选择器,通过它指定该控制器管理哪些pod# Labels匹配规则
matchLabels:
app: nginx-pod
matchExpressions: # Expressions匹配规则
- {key: app, operator: In, values: [nginx-pod]}
template: #模板,当副本数量不足时,会根据下面的模板创建pod副本
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- containerPort: 80
创建文件
yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: demo
namespace: dev
spec:
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
创建daemonset:
kubectl create -f demo.yaml查看daemonset:
kubectl get ds -n dev -o wide查看pod,发现在每个Node上都运行一个pod:
kubectl get pods -n dev -o wide删除daemonset:
kubectl delete -f demo.yaml
五、Job(处理短暂的一次性任务)
Job,主要用于负责批量处理短暂的一次性任务。Job特点如下:
当Job创建的pod执行成功结束时,Job将记录成功结束的pod数量
当成功结束的pod达到指定的数量时,Job将完成执行
资源清单文件
yaml
apiVersion: apps/v1 #版本号
kind: Job # 类型
metadata: # 元数据
name: # rs名称
namespace: #所属命名空间
labels: # 标签
controller: job
spec: #详情描述
completions: 1 # 指定job需要成功运行Pods的次数。默认值:1
parallelism: 1 # 指定job在任一时刻应该并发运行Pods的数量。默认值:1
activeDeadlineSeconds: 30 # 指定job可运行的时间期限,超过时间还未结束,系统将会尝试进行终止。
backoffLimit: 6 # 指定job失败后进行重试的次数。默认是6
manualSelector: true # 是否可以使用selector选择器选择pod,默认是false
selector: # 选择器,通过它指定该控制器管理哪些pod# Labels匹配规则
matchLabels:
app: counter-pod
matchExpressions: # Expressions匹配规则
- {key: app, operator: In, values: [nginx-pod]}
template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
metadata:
labels:
app: counter-pod
spec:
restartPolicy: Never # 重启策略只能设置为Never或者OnFailure
containers:
- name: counter
image: counter:1.30
ports:
- containerPort: 80
重启策略restartPolicy设置说明
onFailure :job会在pod出现故障时重启容器,而不是创建pod,failed次数不变
Neved :job会在pod出现故障时创建新的pod,并且故障pod不会消失,也不会重启,failed次数加1
Always:就意味着一直重启,意味着job任务会重复去执行了
创建文件
yaml
apiVersion: batch/v1
kind: Job
metadata:
name: demo
namespace: dev
spec:
manualSelector: true
selector:
matchLabels:
app: counter-pod
template:
metadata:
labels:
app: counter-pod
spec:
restartPolicy: Never
containers:
- name: counter
image: counter1.30
command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $1;sleep 3;done"]
创建job:
kubectl create -f demo.yaml查看job:
kubectl get job -n dev -o wide -w接下来,调整下pod运行的总数量和并行数量即:在spec下设置下面两个选项
completions: 6 #指定job需要成功运行Pods的次数。默认值:1
parallelism: 3 #指定job在任一时刻应该并发运行Pods的数量。默认值:1
然后重新运行job,观察效果,此时会发现,job会每次运行3个pod,总共执行了6个
kubectl get pods -n dev -w删除job:
kubectl delete -f demo.yaml
六、ConJob(CJ)(特定时间点反复执行job任务)
Cronjob控制器以job控制器资源为其管控对象,并借助它管理pod资源对象,Job控制器定义的作业任务在其控制器资源创建之后便会立即执行,但Cronjob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说,
Cronjob可以在特定的时间点(反复的)去运行job任务。
资源清单文件
yaml
apiVersion: batch/v1beta1 #版本号
kind: CronJob #类型
metadata: # 元数据
name: #rs名称
namespace: #所属命名空间
labels: #标签
controller: cronjob
spec: #详情描述
schedule: #cron格式的作业调度运行时间点,用于控制任务在什么时间执行
concurrencyPolicy: #并发执行策略,用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业
failedJobHistoryLimit: #为失败的任务执行保留的历史记录数,默认为1
successfulJobHistoryLimit: #为成功的任务执行保留的历史记录数,默认为3
startingDeadlineSeconds: #启动作业错误的超时时长
jobTemplate: #job控制器模板,用于为cronjob控制器生成job对象;下面其实就是job的定义
metadata:
spec:
completions: 1
parallelism: 1
activeDeadlineSeconds: 30
backoffLimit: 6
manualSelector: true
selector:
matchLabels:
app: counter-pod
matchExpressions: # Expressions匹配规则
- {key: app, operator: In, values: [nginx-pod]}
template:
metadata:
labels:
app: counter-pod
spec:
restartPolicy: Never #重启策略只能设置为Never或者OnFailure
containers:
- name: counter
image: counter:1.30
ports:
- containerPort: 80
yaml
需要重点解释的几个选项:
schedule: cron表达式,用于指定任务的执行时间
*/1 * * * * # 1表示每个小时第一分钟 /1 表示每一分钟
<分钟><小时><日><月份><星期>
分钟值从0到59.
小时值从0到23.
日值从1到31.
月值从1到12.
星期 值从0到6,0代表星期日
多个时间可以用逗号隔开; 范围可以用连字符给出;*可以作为通配符;/表示每...
concurrencyPolicy:
Allow: 允许Jobs并发运行(默认)
Forbid: 禁止并发运行,如果上一次运行尚未完成,则跳过下一次运行
Replace: 替换,取消当前正在运行的作业并用新作业替换它
创建文件
yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: demo
namespace: dev
labels:
controller: cronjob
spec:
schedule:"*/1 * * * *"
jobTemplate:
metadata:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: counter
image: counter1.30
command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $1;sleep 3;done"]
创建cronjob:
kubectl create -f demo.yaml查看cronjob:
kubectl get cronjobs -n dev查看job:
kubectl get jobs -n dev查看pod:
kubectl get pods -n dev删除cronjob:
kubectl delete -f demo.yaml




