k8s---pod控制器

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,他没有副本数。可以限制部署的节点。也是无状态的应用。服务必须是一个守护进程。ingress logstashflannel

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

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

pod和控制器的关系:

1、controllers:管理控制器。

pod通过label-----------》selector进行关联。

1、Deployment控制器

strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25%

这是Deployment的默认更新策略

rollingUpdate:滚动更新

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx1
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx1
  strategy:
      type: Recreate
#每次有更新,都会把旧的pod全部停止,然后再启动新的实例。服务可能会短暂的终端。无特殊需要可不加
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - image: nginx:1.22
        name: nginx

k8s---pod控制器_第1张图片

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

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

2、statefulSet 有状态应用

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

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

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

apiVersion: v1
kind: Service
metadata:
  name: nginx-web
  labels:
    app: nginx2
spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: ""
  selector:
    app: nginx2
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  labels:
    app: nginx2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx2
  serviceName: "nginx-web"
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: html
    spec:
      accessModes: ["ReadWriteMany"]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 2Gi

headless service:无头服务,没有clusterIP,必须要有动态的pvc。

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

类似于在集群中给pod做了一个映射

为什么要用headless????

有序。独立个体。

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

statefulset是有序的,pod的名称是固定的。重建之后pod的标识符也不变。pod的名称是唯一的标识符。

系统直接通过pod名称解析ip地址。IP地址会不会变???

答案:ip地址会变,类似于访问www.baidu.com 但访问的IP不是同一个。

为什么要有动态的pv???

只要是有状态的副本集群都会涉及持久化存储,每个pod是独立个体,每个pod都有自己专用的存储点。

statefulset在定义的时候就规定了每个pod是不能同一个存储卷。

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

更新发布比较频繁,名称不变。

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

3、daemonSet

daemonSet:确保每个节点上都运行一个副本,当有node加入集群,也会为他新增一个pod

当node节点从集群当中移除时,pod也会被回收。

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

我们也可以通过指定的方式,只把deamonset部害在指定的节点。没有副本数选择,不需要设置

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

千万不要delete

部署在所有节点

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-deamon
  labels:
    app: nginx1
#提高代码可读性,别人读
spec:
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      containers:
      - image: nginx:1.22
        name: nginx
#不定义副本数,DaemonSet在每一个node上部署一个。

指定节点部署

此处定义了node02节点标签 ingress=true

​
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx2-deamon
  labels:
    app: nginx2
#提高代码可读性,别人读
spec:
  selector:
    matchLabels:
      app: nginx2
  template:
    metadata:
      labels:
        app: nginx2
    spec:
      containers:
      - image: nginx:1.22
        name: nginx2
      nodeSelector:
        ingress: "true"
#不定义副本数,DaemonSet在指定node上部署一个。
#除非污点,不部署

4、job

job:job分为两类:job普通任务 和 cronjob定时任务

job:执行只需要一次性的任务。

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

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

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

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

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

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

可以,数据库是核心资产,不会容器化部署。你们公司是容器化部署吗?

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

nginx可以容器化部署。

apiVersion: batch/v1
kind: Job
metadata:
  name: centos-job
spec:
  template:
    spec:
      containers:
      - image: centos:7
        name: centos
        command: ["/bin/bash","-c","test -e /etc/passwd1"]
      restartPolicy: Never
  backoffLimit: 4
#允许任务失败的次数,4次后,restartPolicy的策略,来进行容器的重启或者不重启。

5、cronjob

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

分时日月周   * * * * * 

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

定时任务yaml文件

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: centos-cronjob
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
#如果执行失败的任务的保留的个数 默认是1个
  startingDeadlineSeconds: 15
#pod启动之后必须在一定的时间内开始执行,如果超过15秒没有运行,任务将不会运行,任务也会标记失败
  successfulJobsHistoryLimit: 3
#保留成功的任务数,默认值就是3
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - image: centos:7
            name: centos
            command: ["/bin/bash","-c","date; echo lyw"]
          restartPolicy: Never

总结:

五个都是控制器创建的pod,都是依赖控制器

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

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

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

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

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

你可能感兴趣的:(kubernetes,docker,容器)