pod控制器

pod控制器

pv pvc 动态pv

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

预期状态:

1、副本数

2、容器的重启策略

3、镜像拉取策略

pod出现故障时的重启等等

pod控制器的类型:

1、replicaSet:指定pod副本的数量

   三个组件:

(1)pod的副本数

(2)标签选择器,判断哪个pod归自己管理

(3)扩缩容

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

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

4、DaemonSet:可以在所有节点部署一个相同的pod,他没有副本数。可以限制部署的节点。也是无状态的应用。服务必须是一个守护进程

5、Job:工作pod控制器,执行完成之后即刻退出,不要重启

6、Cronjob:周期性的定时任务控制器,不需要在后台持续运行

pod和控制器之间的关系:

1、controllers:管理控制器

pod通过label-------->selector进行关联

如无特殊需要可以不加这个字段

strategy

  Type:Recreate

#在spec里加这个就代表每次有更新,都会把旧的pod全部停止,然后再启动新的实例。服务可能会短暂的中断

strategy:

  rollingUpdate:

maxSurge: 25%

maxUnavailable: 25%

这是Deployment的默认更新策略

rollingUpdate:滚动更新

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

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

2、无状态应用,pod名称是无序的,任务所有pod都是一体的,共享存储NFS

所有deployment下的pod共享一个存储

statfulSet:有状态的应用。pod的名称都是有序的,所有的pod都是独立的,存储卷也是独立的

顺序0-n,delete删除也不会改变pod的序号,扩缩容也是有序的扩缩容

headless service:无头服务,没有clusterIP

必须要有动态的pvc

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地址

为什么要有volumeClaimTemplates?

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

statefluset在定义的时候就规定了每个pod是不能同一个存储卷,所以才需要动态pv

应用场景:

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

更新发布比较频繁

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

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

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

我们也可以通过指定的方式,只把deamonset部署在指定的节点

没有副本数选择,不需要设置

控制器类型的资源创建方式:基于控制器创建的pod,delete只是相当于重启

apiVersion: apps/v1

kind: DaemonSet

metadata:

  name: nginx-deamon

  labels:

    app: nginx5

#提高代码的可读性,别人读,不同业务可以通过namespace隔离,命名时要根据业务专业命名

spec:

  selector:

    matchLabels:

      app: nginx5

  template:

    metadata:

      labels:

        app: nginx5

    spec:

      containers:

      - name: nginx

        image: nginx:1.22

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

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

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

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

第一个:必须指定的容器策略onfailure never

第二个:执行失败的次数也是受限的,默认是6次

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

apiVersion: batch/v1

kind: Job

metadata:

  name: centos

spec:

  template:

    spec:

      containers:

      - name: centos

        image: centos:7

        command: ["/bin/bash","-c","test -e /etc/passwd"]

      restartPolicy: Never

  backoffLimit: 4

pod控制器_第1张图片

#运行任务失败的次数是4次,4次到了之后,reatartPolicy的策略,来进行容器的重启或者不重启

面试题:

容器化部署,部署过数据库没有?

数据库是核心资产,不会容器化部署

前端你们会容器化部署吗?

nginx可以容器化部署

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

分 时 日 月 周

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

apiVersion: batch/v1beta1

kind: CronJob

metadata:

  name: hello(随便起)

spec:

  schedule: "*/1 * * * *"

  concurrencyPolicy: Allow

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

  startingDeadlineSeconds: 15

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

  successfulJobsHistoryLimit: 3

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

  jobTemplate:

    spec:

      template:

        spec:

          containers:

          - name: hello

            image: centos:7

            command: ["/bin/bash","-c","test -e /etc/passwd"]

          restartPolicy: Never

  backoffLimit: 4

总结:

五个都是控制器创建的pod

都是依赖于控制器

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

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

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

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

cronjob:定时任务

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

你可能感兴趣的:(kubernetes,docker,容器,云原生,运维,linux)