pod 控制器

发布时间:2024年01月15日

pod 控制器:

pv pvc 动态pv

pod控制器:工作负载,workload,用于管理pod的中间层,确保pod资源符号预期的状态。

预期状态:

1,副本数

2,容器的重启策略

3,镜像拉取策略

pod出现故障时的重启等等。

pod控制器的类型:

1,replicaSet:指定pod副本的数量。

三个组件:

一,pod的副本数

二,标签选择器,颇多哪个pod归自己管理

三,扩缩容

2,Deployment控制器,他是工作在replicaSet之上。管理无状态应用。目前是最好的控制器。支持广东更新和回滚。提供声明式配置。

3,statefulSet:控制器的一种,管理有状态的应用,可以可以设置副本数,可以扩缩容。pod的序号的固定的,重启之后,pod的名称也不会发生变化。有状态

4,DaemonSet:可以在使用节点的部署一个pod,他没有副本数。可以限制部署的节点。也是无状态的应用。一般来说,服务必须的后台守护进程。 ingress logstash flannel

5,job:工作pod控制器,执行完成即可退出,不用重启,不需要重建

6,cronjob:周期的定时容器控制器。不需要在后台持续运行

pod和控制器之间的关系

1,controllers:管理控制器。

pod提供label------>selector进行关联

补充:

startegy:

type: Recreate

#每次有更新,都会把旧的pod全部停止,然后再启动新的实例。服务可能会短暂的终端。

无特殊需要,这个字段不要加

默认策略:

strategy:

rollingUpdate:

maxSurge: 25%

maxUnavailable: 25%

这是Deployment的默认更新策略

rollingUpdate:滚动更新。

maxSurge: 25%升级过程中,新启动的pod数量不能超过期望pod数的25%

maxUnavailable: 25%在升级的过程中,新的pod启动好后,销毁的就的pod的数量不能超过pod的25%

2,无状态应用,pod名称的无序的,认为所有pod都是一体的。共享存储NFS

sydeployment下的pod共享一个存储。

statefulSet:有状态的应用,pod的名称的有序的,所有的pod都是独立的。存储卷也是独立的。顺序0-n,delete删除也不会改变pod的序号。扩缩容也是有序扩缩容

创建一个有序的pod

特点:headless service:无头服务,没有clusterIP

必须要有动态的pvc

删除重启的名称不变

每一个pod都是独立的个体,扩缩容都是有序的

pv的删除和本身的策略有关,和pod删除无关

headless service:k8s集群当中一种特殊的服务类型,不分配ClusterIP给service。也不会负载均衡到后端的pod。

DNS来提供服务的发现和访问。

由于Clusterip的是空,k8s集群会给每个headless service中的pod创建一个dns记录

格式:pod-name.headless-service-name.namespace.svc.cluster.local

web-0 nginx-web defaults 本地地址(pod的ip地址)

提供dns直接解析访问pod的IP地址

web-0 10.244.1.10

为什么要用headless:

有序。独立个体。

deployment的pod是没有名称的,随机字符串,无序。他需要一个集中的clusterip来集中统一为pod提供网络。

statefulset是有序的,pod的名称是固定的。重建之后pod的标识符也不变。pod的名称是唯一的标识符。系统直接提供pod名称解析IP地址。ip地址可能会变。

为什么要有volumeClaimTemplates:

有状态的副本把 集群会设计持久化存储,每个pod是独立个体,每个pod都有一个自己专用的存储点。

satefulset在定义的时候就规定看每个pod是不能同一个存储。所以才需要动态pv。

statefulset的应用场景:

不是固定节点的应用,不是固定ip的应用,

共享发布比较频繁

支持自动伸缩,节点的资源资源不够,可以自动扩容。

删除:基于控制器删除

kubectl delete statefulsets.apps web

3,daemonSet:确保每个节点上都运行一个pod副本。当node加入集群也会为他新增一个pod。当中node节点从集群当中移除时,pod也会被回收。

不能指定副本数。在每一个节点部署一个

每个节点上创建一个

在指定节点上创建

kubectl label nodes master01 ingeress=true

匹配标签来部署

daemonSet不需要指定调度策略,默认会在每个节点创建一个pod。除非污点。

我们也可以提供指定的方式,只把deamonset部署在指定的节点。

面试:daemonSe没有副本选择,不需要设置。

控制器类型的资源创建方式:基于控制器创建的pod,delete只是相当于重启,要测定删除pod,必须上传控制器。

4,job:job分为两类,job普通任务 定时任务cronjob。

job的作用,执行只需要一次性的任务。

脚本需要执行,数据库迁移,视频解码等等业务。

对于k8s系统来说,既然定义了是job,你只需要执行一次, 或者指定次数即可。不能一直允许。

第一个:必须指定容器的重启策略:OnFailure或者Never

第二个:执行失败的次数也是受限的。默认是6次,可以设置

达到限制之后才是根据restartPolicy的策略,来对容器进行重启或者不重启

第三个:重新yamI文件,先删除任务,再更新。不能动态更新。

面试:容器化部署,部署过数据库吗?核心组件不会容器化部署的。

前端你们会容器化部署吗?我们公司前端nginx就是容器化部署

5,cronjob:

周期性任务,定时执行,和linux的crontab一模一样,语法一样

分 时 日 月 周

应用场景:定时备份 通知作用。定时检测(结合探针一起做)

也需要给容器定义重启策略

查看定时任务

执行完的任务会被保留,但最多就保留3个

concurrencyPolicy: Allow

#如果执行失败的任务的保留的个数默认是1个

startjingDeadlineSeconds: 15

#pod启动之后必须在一 定的时间内开始执行,如果超过15秒没有运行,任务将不会运行,任务也会标记失败

successfuljobsHistoryLimit: 3

#保留成功的任务数,默认值就是3

可选字段

删除:基于控制器删除

总结:

五个都是控制器创建的pod

都是依赖于控制器

deployment:无状态应用,最好用,也是最多的

statefulSet:有状态应用,有序的,独立的pod

daemonSet:: 无状态应用,不能定义副本数。每个节点都运行一个pod。 可以指定节点。

job:执行一次性的任务,必须要有重启策略,同时默认失败次数6次,之一失败次数达到,重启才会生效

cronjob:定时任务,通知,备份或者探测。

cronjob定期检测nginx的80端口是否存活tcpsocker */1 * * * *

文章来源:https://blog.csdn.net/weixin_51694382/article/details/135607444
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。