一、什么是 pod 的控制器
Pod控制器,又称之为工作负载(workload),是用于实现管理pod的中间层
确保pod资源符合预期状态;pod的资源故障时会进行重启;
当重启策略无效时,则会重新新建pod的资源
二、pod控制器的多种类型
1、ReplicaSet
代用户创建指定数量的pod副本,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。
ReplicaSet 的主要三个组件
1)用户期望的pod副本数量
2)标签选择器,判断哪个pod归自己管理
3)当现存的pod数量不足时,会根据pod资源模板进行新建
帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是RelicaSet不是直接使用的控制器,而是使用Deployment
2、Deplayment
工作在ReplicaSet 之上,用于管理无状态应用,是目前来说最好的控制器;
支持滚动更新和回滚功能,还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
3、DaemonSet
用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如ELK服务
特性:服务是无状态的
服务必须是守护进程
4、StatefulSet
管理有状态应用
5、Job
只要完成就立即退出,不需要重启或重建
6、CronJob
周期性任务控制,不需要持续后台运行
三、pod 与控制之间的关系
controllers:在集群上管理和运行容器的 pod 对象, pod 通过 label-selector 相关联。
Pod 通过控制器实现应用的运维,如伸缩,升级等。
1、Deployment
部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新,例如只更新一个新的image
应用场景:web服务
通过陈述式生成声明式的yaml文件
kubectl create deployment nginx-dep --imae=nginx:1.15 --port=80 --replicas=1 --dry
查看控制器配置
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
......
查看历史版本,升级,回滚
2、SatefulSet
部署有状态应用
稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现
有序收缩,有序删除(即从N-1到0)
Headless 无头模式
k8s 中pod 因为故障导致重启或新建会导致pod名称和IP地址发生改变;(IP改变会导致数据丢失以及服务无法访问)
k8s 中的数据库的 ip 也会因此发生改变,为了避免这种情况;通过设置Headless无头模式
Headless 通过dns解析来让外部访问
headless 会定义好service的名称,分配时不会分配ip
为什么要有 volumeClainTempalte
实现K8S 里 DNS 功能的插件:
skyNDS
清单定义StatefulSet
拉取一个centos:7 镜像
倒叙删除
k8s 内部负载均衡是根据访问量来算的,所以可能会导致一直访问到同一个服务器
那是k8s内部的负载均衡 ,会根据资源占比进行调度,会调度到资源少的,请求少的pod
滚动更新
除了创建时是正序,其他如删除、更新时都是倒叙进行
DaemonSet
DaemonSet会在每个node节点都会创建;删除也是同时删除
Job
重启的是pod 不是容器
5、CronJob
可以用于进行周期性备份,把xx文件拷贝出来,存储到xxx
周期性创建pod
总结
创建pod的两种方式
自主式pod和以控制器创建的pod
什么是有状态、无状态?
无状态就是类似于nginx 的静态页面,一般不会进行改变;每次访问内容都是一样的
有状态则类似于数据库,每天都会进行改变;每次访问都是不一样的
声明式 == yaml文件
陈述式 == 命令
kafka消息队列
Pod 控制器
①deployment 部署无状态应用的管理RS 和 pod 创建Pod,主要是维护pod副本数量与期望状态一致
创建和删除pod是并行执行的;升级时也是 先创建一部分再删除一部分
②statfulset 部署有状态的应用时,每个pod的名称唯一且不变,每个pod 拥有自己专属的持久化存储(PV和PVC)
在 k8s 集群内部可以通过{pod_name}.{service_name}.{namespace}.svc.cluster.local 解析出pod 的IP(基于headless service 和 coreDNS)
在创建和pod时是有顺序的,串行执行;升级时也是串行执行,会删除旧的pod,再创建新pod;
删除和升级时是倒叙执行的(从标识符最大的 n-1 开始,一直到最小的 0)
③Daemonset 理论上在k8s 集群的所有node节点上创建相同的pod(无论node节点什么时候加入到k8s 集群),但是会受到node节点上污点影响
④部署一次性任务的pod,正常完成后容器立即退出并且不重启容器(restartpolicy 不设置Always),也不会重建异常完成后重试任务
重建次数根据 backofflimit 配置(默认为6次)
⑤CronJob 周期性部署任务的pod,正常完成后容器会立即退出,并不会重启容器(restartpolicy 不设置Always),也不不会重建pod
schedule 配置周期性的事件表分时日月周 * * * * *
无状态
常规service和无头服务的区别
扩展伸缩
可以通过 logs 和 describe 来排查pod的异常信息
html 页面的协议
SLB 负载均衡
网关:转发请求,获取信息