【k8s】7、pod控制器详解
文章目录
- 一、Pod控制器介绍
- 二、ReplicasSet（RS）控制器
- 1、创建ReplicaSet
- 2、扩缩容
- 3、镜像升级
- 4、删除replicaset
- 三、Deployment控制器
- 1、创建deployment
- 2、扩缩容
- 3、镜像更新
- 3.1 重建更新
- 3.2 滚动更新
- 4、版本回退
- 5、金丝雀发布
- 6、删除deployment
- 四、Horizontal Pod Autoscaler（HPA）
- 1、安装metrics-server
- 2、准备deployment和service
- 3、部署HPA
- 4、测试
- 五、DaemonSet控制器（DS）
- 六、Job控制器
- 七、CronJob控制器（CJ）
- 八、StatefulSet控制器
- 1、statefulset原理
- 2、创建statefulset控制器
- 3、扩缩容
- 4、滚动更新
- 九、总结
一、Pod控制器介绍
Pod是kubernetes的最小管理单元，在kubernetes中，按照Pod的创建方式可以将其分为两类
- 自主式Pod： kubernetes直接创建出来的Pod，这种Pod删除后就没有了，也不会重建
- 控制器创建的Pod： kubernetes通过控制器创建的Pod，这种Pod删除之后还会自动重建。
#什么是Pod控制器？Pod控制器是管理Pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态，如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。
在kubernetes中，有很多类型的Pod控制器，每种都有自己的适合的场景，常见的有下面这些：
| pod控制器 | 功能 |
|---|---|
| Replication Controller | 比较原始的Pod控制器，以及被废弃，由ReplicaSet替代 |
| ReplicaSet |
①保证副本数量一致维持在期望值 ②支持Pod数量扩缩容 ③镜像版本升级 |
| Deployment | 通过控制ReplicaSet来控制Pod，并支持滚动升级，回退版本 |
| Horizontal Pod Autoscaler | 可以根据集群负载自动水平调整Pod的数量，实现消峰填谷 |
| DaemonSet | 在集群中的指定Node上运行且运行一个副本，一般用于守护进程类的任务 |
| Job | 它创建出来的Pod只要完成任务就立即退出，不需要重启或重建，用于执行一次任务 |
| Cronjob | 它创建的Pod服务周期性任务控制，不需要持续后台运行 |
| StatefulSet | 管理有状态应用 |
二、ReplicasSet（RS）控制器
ReplicaSet的主要作用是保证一定数量的Pod正常运行，它会持续监听这些Pod的运行状态，一旦发生故障，就会重启或重建，同时它支持对Pod数量的扩缩容和镜像版本的升降级。
ReplicaSet的资源清单文件
apiVersion: apps/v1 #版本号
kind: ReplicaSet #类型
metadata: #元数据name: #资源名称namespace: #所属命名空间labels: #标签controller: rs
spec: #其它属性replicas: 3 #副本数量selector: #标签选择器matchLabels: #Labels匹配规则app: nginx-podmatchExpressions: #Expressions匹配规则- {key: app,operator: In,values: [nginx-pod]}template: #模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80--------------------------------------------------------------
#上述新了解配置解释replicas: 指定副本数量，其实就是当前rs创建出来的Pod数量，默认为1
selector: 选择器，它的作用是建立Pod控制器和Pod之间的关联关系，采用的Label Selector机制，在Pod模板上定义label，在控制器上定义选择器，就可以表明控制器能管理哪些Pod了。
template: 模板，就是的当前控制器创建Pod所使用的模板。
1、创建ReplicaSet
创建pc-replicaset.yaml文件
apiVersion: apps/v1
kind: ReplicaSet
metadata:name: pc-replicasetnamespace: dev
spec:replicas: 3selector: matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1
kubect create -f pc-replicaset.yaml
#创建rs控制器kubectl get rs pc-replicaset -n dev -o wide
#查看rckubectl get pod -n dev
#查看pod的状态
2、扩缩容
方法一：直接edit在线编辑修改
kubectl edit rs pc-replicaset -n dev
#编辑rs的副本数量，修改里面的spec.replicas:6即可
方法二：命令行直接修改
kubectl scale rs pc-replicaset --replicas=2 -n dev
#使用cscale命令实现扩缩容，后面的replicas=n，直接指定目标数量即可
3、镜像升级
方法一：在线编辑edit文件
kubectl edit rs pc-replicaset -n dev
#编辑rs的容器镜像
方法二：命令直接升级版本
kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev
#指定换成任何的版本
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dqyEoNIM-1668959407562)(C:\Users\Ydq\AppData\Roaming\Typora\typora-user-images\image-20221007173134861.png)]
4、删除replicaset
kubectl delete rs pc-replicaset -n dev
#直接删除replicaset控制器，所有pod都会删除。//删除步骤: kubernetes删除RS之前，会将replicasclear调整为0，等待所有的Pod被删除后，再执行RS对象删除kubectl delete -f pc-replicaset -n dev
#通过yaml文件删除(推荐使用)kubectl delete rs pc-replicaset -n dev --cascade=false
#如果希望仅仅删除RS对象，保留Pod，可以模板添加对象命令
三、Deployment控制器
为了更好的解决服务编排问题，kubernetes在V1.2版本开始，引入了Deployment控制器，值得一提的是，这种控制器并不直接管理Pod，而是通过管理ReplicaSet 来间接管理Pod。
- 也就是说：Deployment管理ReplicaSet，ReplicaSet管理Pod，所以Deployment比ReplicaSet功能更加强大。
Deployment主要功能有下面几个：
- 支持ReplicaSet的所有功能
- 支持发布的停止、继续
- 支持滚动更新和回滚版本
Deployment的资源清单文件
apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据name: # deploy名称 namespace: # 所属命名空间 labels: #标签controller: deploy
spec: # 详情描述replicas: 3 # 副本数量revisionHistoryLimit: 3 # 保留历史版本(默认是3个)paused: false # 暂停部署，默认是falseprogressDeadlineSeconds: 600 # 部署超时时间（s），默认是600strategy: # 策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxSurge: 25% # 最大额外可以存在的副本数，可以为百分比，也可以为整数maxUnavailable: 25% # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels: # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80
1、创建deployment
创建pc-deployment.yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:name: pc-deploymentnamespace: dev
spec: replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1
2、扩缩容
deployment控制器的扩缩容和replicaset的方法一样，都可以进行在线编辑和使用scale命令进行扩缩容。
使用edit进行扩容
kubectl edit deployment pc-deployment -n dev
#修改deployment的副本数量
使用scale命令缩容
kubectl scale deployment pc-deployment --replica=2 -n dev
#进行副本的减少
3、镜像更新
deployment支持两种更新策略：重建更新 和 滚动更新 ，可以通过 strategy 指定策略类型，支持两个属性。
- deployment 默认就是滚动更新
strategy #指定新的Pod替换旧的Pod的策略， 支持两个属性：type #指定策略类型，支持两种策略Recreate #在创建出新的Pod之前会先杀掉所有已存在的PodRollingUpdate #滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本Pod
------//如果配置了滚动更新，就需要配置下面的-----rollingUpdate #当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属性：maxUnavailable #用来指定在升级过程中不可用Pod的最大数量，默认为25%。maxSurge # 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%。
3.1 重建更新
重新编辑pc-deployment.yaml 文件，添加更新策略
sepc:strategy: #策略type: Recreate #重建更新
进行升级版本测试验证
kubectl set image deployment pc-deployment -n dev nginx=nginx:latest
#将deployment下面的版本全部升级至最新kubect get pods -n dev -w
#一开始先进行时实监控
3.2 滚动更新
重新编辑pc-deployment.yaml文件，添加滚动更新策略(这个为默认策略)
下面也可进行手动配置
spec:strategy:type: RollingUpdaterollingUpdate:maxSurge: 25%maxUnavailable: 25%
升级版本测试
kubectl set image deployment pc-deployment nginx=nginx:latest -n dev
#升级新的版本kubectl get pods -n dev -w
#提前时实监控
4、版本回退
当我们进行deployment版本升级时，因为它是操作replicaset控制器的，可以查看一下rs的变化。
#为什么旧的RS依然存在呢？//这就是deployment的特殊的功能，它管控这replicaset来进行版本回退的操作。
deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看
kubectl rollout ： 版本升级相关功能，支持下面的选项
- status ： 显示当前升级状态
- history： 显示升级历史记录
- pause： 暂停版本升级过程
- resume： 继续已经暂停的版本升级过程
- restart ： 重启版本升级过程
- undo： 回滚到上一级版本（可以使用 –to-revision 回滚到指定版本）
版本回滚
kubectl rollout undo deployment pc-deployment -n dev
#返回到上一个版本
kubectl rollout undo deployment pc-deployment -n dev --to-revision=3
#返回到指定的版本
5、金丝雀发布
Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。
比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
升级，然后暂停
kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev && kubectl rollout pause deployment pc-deployment -n dev
#将版本升级至1.17.2版本，升级一个，然后暂停升级kubectl rollout status deployment pc-deployment
#查看更新状态(新开一个终端，会占用前台)//监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令kubectl get rs -n dev -o wide
#查看replicaset控制器的版本信息
新版本确认没问题，进行全部滚动升级
kubectl rollout resume deployment pc-deployment -n dev
#继续更新kubectl get rs -n dev -owide
#查看replicaset的版本信息
6、删除deployment
kubectl delete deployment pc-deployment -n dev或kubectl delete -f pc-deployment ##以上两种都可以删除
//删除deployment后，其下的rs和pod也被删除
四、Horizontal Pod Autoscaler（HPA）
在kubernets中，我们可以对pod进行有效的扩容和缩容，但是所有的操作都是通过kuberctl scale 命令实现的，无法达到自动化的要求，kubernetes可以通过检测Pod的使用情况，实现Pod数量的自动调整，于是就产生了 Horizontal Pod Autoscaler（HPA）这种控制器。
HPA可以获取每个Pod的利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod数量的调整，起始HPA与之前的Deployment一样，也是属于Kubernetes资源对象， 它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确认是否需要针对性的调整Pod的副本数。这就是HPA的实现原理.
1、安装metrics-server
- metrics-server可以用来收集集群中的资源使用情况
yum -y install git
#下面git(用来从远程仓库克隆一个版本到本地)git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
#克隆版本v0.3.6到本地cd metrics-server/deploy/1.8+/
vim metrics-server-deployment.yamlhostNetwork: true #24行后面，添加image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6 #33行，修改args: #34行后面，添加
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
kubectl apply -f ./
#安装metrics-serverkubectl get pod -n kube-system
#查看是否安装运行成功kubectl top node
#查看资源使用情况kubectl top pod -n kube-system
2、准备deployment和service
vim deployment-nginx.yamlapiVersion: v1
kind: Deployment
metadata: name: nginxnamespace: dev
spec:selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1resources:limits:cpu: "1"requests:cpu: "100m"
kubectl create -f deployment-nginx
#创建deplymentkubectl expose deployment nginx --type=NodePort --port=80 -n dev
#创建servicekubectl get deployment,pod,svc -n dev
#查看个资源信息
3、部署HPA
创建pc-hap.yaml 文件
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:name: pc-hpanamespace: dev
spec:minReplicas: 1 #最小pod数量maxReplicas: 10 #最大pod数量targetCPUUtilizationPercentage: 3 # CPU使用率指标scaleTargetRef: # 指定要控制的nginx信息apiVersion: apps/v1kind: Deploymentname: nginx
4、测试
使用压测工具对service地址 20.0.0.55:32179 进行压测，然后通过控制台查看hpa和pod的变化
压测工具地址: https://zhuanlan.zhihu.com/p/41212281#根据网站地址，进行安装postman，进行压测。
访问测试
保存访问路径
开始进行压测
开始进行压测，压测到一定程度后，就关闭，查看hpa的监控数
#下面进行监控各种资源，查看监控变化
查看hap的变化
查看pod的变化
查看deployment变化
五、DaemonSet控制器（DS）
DaemonSet 类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本，一般适用于日志收集、节点监控等场景。 也就是说，如果一个Pod提供的功能时节点级别的（就是每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。
DaemonSet控制器的特点：
- 每当向集群中添加一个节点时，指定的Pod副本也将添加到该节点上。
- 当节点从集群中移除时，Pod也就被垃圾回收了。
DaemonSet的资源清单
apiVersion: apps/v1 # 版本号
kind: DaemonSet # 类型
metadata: # 元数据name: # ds名称 namespace: # 所属命名空间 labels: #标签controller: daemonset
spec: # 详情描述revisionHistoryLimit: 3 # 保留历史版本updateStrategy: # 更新策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxUnavailable: 1 # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels: # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80
案例：
创建pc-daemonset.yaml 文件
apiVersion: apps/v1
kind: DaemonSet
metadata:name: pc-daemonsetnamespace: dev
spec: selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1
下面创建pod，进行查看
kubectl create -f pc-daemonset.yamlkubectl get ds -n dev -o widekubectl get pods -n dev -o wide
六、Job控制器
job控制器主要负责批量处理（一次要处理指定数量任务） 短暂的一次性的任务。
也就是说，Job控制器就是相当于创建一个或多个pod。专门用来执行一次性的任务，执行完成之后，pod就会处于完成状态。
Job特点：
- 当 Job 创建的Pod执行成功结束时，Job将记录成功结束的Pod数量
- 当成功结束的Pod达到指定的数量时，Job将完成任务。
Job的资源清单文件
apiVersion: batch/v1 # 版本号
kind: Job # 类型
metadata: # 元数据name: # 名称 namespace: # 所属命名空间 labels: #标签controller: job
spec: # 详情描述completions: 1 # 指定job需要成功运行Pods的次数。默认值: 1 (就是说:pod成功运行的次数)parallelism: 1 # 指定job在任一时刻应该并发运行Pods的数量。默认值: 1(多少pod可以并行执行)activeDeadlineSeconds: 30 # 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止。backoffLimit: 6 # 指定job失败后进行重试的次数。默认是6manualSelector: true # 是否可以使用selector选择器选择pod，默认是falseselector: # 选择器，通过它指定该控制器管理哪些podmatchLabels: # Labels匹配规则app: counter-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [counter-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: counter-podspec:restartPolicy: Never # 重启策略只能设置为Never或者OnFailurecontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]------------------------------------------------------------------
#关于重启策略设置的说明：
如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了，当然不对，所以不能设置为Always
案例：
创建pc-job.yaml
apiVersion: batch/v1
kind: Job
metadata:name: pc-jobnamespace: dev
spec:manualSelector: true #允许是使用标签selector:matchLabels:app: counter-podtemplate:metadata:labels:app: counter-podspec:restartPolicy: Nevercontainers:- name: counterimage: busybox:1.30command: ["/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]
下面创建pod查看执行结果
kubectl create -f pc-job.yaml
#创建podkubectl get job -n dev -o wide -w
#提前监控job的资源kubectl get pods -n dev -w
#提前监控pod状态
下面修改Pod运行的总数量和并行数量
spec: completions: 6parallelism: 3然后重新运行job，观察效果，此时会发现，job会每次运行3个pod，总共运行6个pod
下面创建并执行查看结果
七、CronJob控制器（CJ）
CronJob 控制器以Job控制器资源为其管控对象，并借助它管理Pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但是CronJob 可以以类似于Linux 操作系统的周期性任务作业计划的方式控制器运行的时间点及重复运行的方式。
也就是说，Crontab可以在特定的时间点（反复的）去运行Job任务。
CronJab的资源清单文件
apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 类型
metadata: # 元数据name: # CJ名称 namespace: # 所属命名空间 labels: #标签controller: cronjob
spec: # 详情描述schedule: # cron格式的作业调度运行时间点,用于控制任务在什么时间执行concurrencyPolicy: # 并发执行策略，用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业failedJobHistoryLimit: # 为失败的任务执行保留的历史记录数，默认为1successfulJobHistoryLimit: # 为成功的任务执行保留的历史记录数，默认为3startingDeadlineSeconds: # 启动作业错误的超时时长jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象;下面其实就是job的定义metadata:spec:completions: 1parallelism: 1activeDeadlineSeconds: 30backoffLimit: 6manualSelector: trueselector:matchLabels:app: counter-podmatchExpressions: 规则- {key: app, operator: In, values: [counter-pod]}template:metadata:labels:app: counter-podspec:restartPolicy: Never containers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 20;done"]--------------------------------------------------------------
需要重点解释的几个选项：
schedule: cron表达式，用于指定任务的执行时间*/1 * * * *<分钟> <小时> <日> <月份> <星期>分钟: 值从 0 到 59.小时: 值从 0 到 23.日: 值从 1 到 31.月: 值从 1 到 12.星期: 值从 0 到 6, 0 代表星期日多个时间可以用逗号隔开; 范围可以用连字符给出；*可以作为通配符； /表示每...concurrencyPolicy:Allow: 允许Jobs并发运行(默认)Forbid: 禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行Replace: 替换，取消当前正在运行的作业并用新作业替换它
创建pc-cronjob.yaml 文件
apiVersion: batch/v1beta1
kind: CronJob
metadata:name: pc-cronjobnamespace: devlabels:controller: cronjob
spec:schedule: "*/1 * * * *"jobTemplate:metadata:spec:template:spec:restartPolicy: Nevercontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]
下面进行创建pod，查看执行结果
kubectl create -f pc-cronjob.yamlkubectl get cronjobs -n dev
#查看cronjob控制器kubectl get jobs -n dev
#查看job控制器kubectl get pods -n dev
#查看pod
八、StatefulSet控制器
1、statefulset原理
部署有状态应用的控制器
像前面所看到到控制器，比如ReplicaSet、Deployment、DaemonSet都是面向无状态的服务，他们所管理的Pod的IP、名字、启动顺序等都是随机的。
而StatefulSet控制器是有状态的控制器，管理所有有状态的服务，比如mysql、mongodb等
##有状态服务和无状态服务怎么理解？//无状态服务，也就是请求一次数据，没有上下文的关系，请求中包含所有需要的信息。例如：token令牌。//有状态服务，他它会根据存储的内容上下文关联，需要依靠以前的数据来请求相应的数据内容，如http的session会话保持。
StatefulSet本质上是Deployment的一种变体，在v1.9版本中已经成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序。在StatefulSet中，Pod名字称为网络标识（hostname），还必须要用到共享存储。
在Deployment中，与之对应的服务是service， 而在StatefulSet中与之对应的headless service（headless service，即无头服务） 与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。
除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：
$(podname).(headless server name)
FQDN： $(podname).(headless server name).namespace.svc.cluster.local
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）
从上面的应用场景可以发现，statefulset由以下几个部分组成
- Headless service： 无头服务，用于为pod资源标识符 生成可解析的DNS记录。
- VolumeClaimTemplates： 存储卷的申请模板，基于静态或动态的pv供给方式，为pod资源提供专有的固定存储。
- statefulset： 用于管控pod资源。
为什么要有headless service 无头服务？
在用Deployment时，每一个Pod名称是没有顺序的，是随机字符串，因此是Pod名称是无序的，但是在statefulset中要求必须是有序 ，每一个pod不能被随意取代，pod重建后pod名称还是一样的。而pod IP是变化的，所以是以Pod名称来识别。pod名称是pod唯一性的标识符。
为了实现标识符的稳定，这时候要用到无头服务，它可以给每个Pod一个唯一的名称 。
为什么需要volumeclaimtemplate？
大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据时不一样的，每个节点都需要自己专用的存储节点。而在deployment 中的pod模板中创建的存储卷是一个共享pod是不适应的，多个pod使用同一个存储卷，而statefulset定义中的每个pod都不能使用同一个存储卷，由此基于pod模板创建pod时不适应 的。
这就需要引入volume Clain Template ，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而请求绑定一个PV，从而有自己的专用的存储卷。
2、创建statefulset控制器
目前服务器中已经创建好了storageclass 自动创建pv的功能。下面进行创建statefulset控制器创建pod，在 volumeClaimTemplates 中定义好storageclass的名称，在创建statefulset后，它会自动创建pvc和pv。
vim statefulset.yaml
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: None #不创建custerip，也就是无头服务的serviceselector: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: nginximage: nginx:1.14.1ports:- containerPort: 80name: webvolumeMounts: #容器内挂载- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates: #存储卷的申请模板- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ] #可读可写，仅能一个节点挂载storageClassName: "nfs-client-storageclass" #使用动态创建的pvresources: #设置请求的资源大小requests:storage: 2Gi
解析上面： 由于StatefulSet资源依赖于一个实现存在的Headless类型的Service资源，所以需要先定义一个名为nginx的Headless Service资源，用于为关联到每个Pod资源创建DNS资源记录。接着定义了一个名为web的StatefulSet资源，它通过Pod模板创建了3个Pod资源副本，并基于volumeClaimTemplates向存储类进行了请求大小为2Gi的专用存储卷。
下面开始创建
kubectl apply -f statefulset.yaml
#创建service和statefulset。kubectl get pods -w kubectl get pvc -w kubectl get pv -w
3、扩缩容
kubectl scale statefulset web --replicas=5kubectl scale statefulset web --replicas=2
4、滚动更新
kubectl set image statefulset web nginx=nginx:1.17.1
#升级版本
九、总结
无状态：
- deployment 认为所有的pod都是一样的
- 不用考虑顺序的要求
- 不用考虑在哪个node节点上运行
- 可以随意扩容和缩容
有状态
- 实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
- 实例之间不对等的关系，以及依靠外部存储的应用。
常规service和无头服务区别
service： 一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
Headless service： 无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。
【k8s】7、pod控制器详解相关推荐
- 学习笔记之-Kubernetes（K8S）介绍，集群环境搭建，Pod详解，Pod控制器详解，Service详解，数据存储，安全认证，DashBoard
笔记来源于观看黑马程序员Kubernetes(K8S)教程 第一章 kubernetes介绍 应用部署方式演变 在部署应用程序的方式上,主要经历了三个时代: 传统部署:互联网早期,会直接将应用程序部署 ...
- kubernetes之Pod控制器详解
kubernetes之Pod控制器详解 文章目录 kubernetes之Pod控制器详解 Pod控制器介绍 ReplicaSet(RS) Deployment(Deploy) Pod控制器介绍 Pod ...
- [k8s] 第六章 Pod控制器详解(Controller-manager)
本章节主要介绍各种Pod控制器的详细使用. Pod控制器介绍 Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类: 自主式pod:kuberne ...
- k8s pod控制器详解（ReplicaSet、Deployment、Horizontal Pod Autoscaler）
一.Pod控制器介绍 Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类: 自主式pod:kubernetes直接创建出来的Pod,这种pod删 ...
- Kubernetes学习笔记（二）：Pod控制器详解：资源元信息、ReplicaSet、Deployment、DaemonSet、Job、CronJob
1.资源元信息 Kubernetes的资源对象组成:主要包括了Spec.Status两部分.其中Spec部分用来描述期望的状态,Status部分用来描述观测到的状态 Kubernetes的元数据部分. ...
- Pod控制器详解-Deployment(Deploy)
Pod控制器介绍 Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类: 自主式pod:kubernetes直接创建出来的Pod,这种pod删除后 ...
- k8s之pod管理详解
一.控制器 1.Pod 的分类: 自主式 Pod:Pod 退出后不会被创建 控制器管理的 Pod:在控制器的生命周期里,始终要维持 Pod 的副本数目 2.控制器类型: Replication Con ...
- 【云原生之k8s】k8s管理工具kubectl详解
[云原生之k8s]k8s管理工具kubectl详解 前言 一.陈述式管理 (1)陈述式资源管理方法 (2)k8s相关信息查看 ①查看版本信息 ②查看节点信息 ③查看资源对象简写 ④查看集群信息 ⑤配置 ...
- kubernetespod控制器详解上
kubernetespod控制器详解上 pod调度策略之污点和容忍 污点(Taints) 通过在Pod上添加属性,来确定Pod是否要调度到指定的Node上,其实我们也可以站在Node的角度上,通过在N ...
最新文章
- hibernate中session接口方法总结
- 转：智能卡测试操作系统技术
- 音视频开发（16）---海康IPC+NVR+EasyDarwin+EasyPusher+VLC实现Web实时播放RTSP视频
- 二叉树的构建及各种遍历回顾
- Dart语言详解（一）——详细介绍
- overleaf表格_Latex中插入表格
- 10款提高工作效率的工具软件，你值得拥有！
- 想不到吧，实体类能自己CRUD，MyBatis-Plus AR模式了解下
- 电脑硬盘双击打不开，提示格式化怎么办？
- openstack 网络更改版
- python -m的那些实用功能
- 方阵主对角线元素之和
- 图说三极管的三个工作状态
- ECCV 2022 | 稀有类别提升31%！如何解决3D检测中长尾问题？（Waymo最新）
- Android官方SDK下载（含API文档）
- 数字孪生定义、意义及案例
- python爬取淘票票正在热映电影
- _031_Redis_Redis 复制、Sentinel的搭建和原理说明
- C语言编译能否被七整除,C++编程判断一个整数能否被3、5、7整除的几种方法
- 【TV Picture Quality - 04】TV常见操作界面