pod控制器的作用

pod控制器的作用

1、动态pv和pvc

deployment是控制器

pod空气器:工作负载，workload用于管理pod的中间层，确保podi资源符合预期的状态

预期状态

1、·副本数

2、容器重启策略

3、镜像拉取策略

pod、出现故障时重启等等

pod的控制器类型

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

三个组件：

pod的副本数

标签的选择器，判断哪个pod归自己管理

扩缩容

2deployment控制器，他是工作在repalicaset之上，管理无状态应用，目前是最好的控制器，支持滚动更新和回滚

提供声明式配置

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

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

ingress logstash flannel

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

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

pod与控制器之间的关系:

1、controllers；管理控制器。

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

startegy:

  rollingUpdata:

?    maxSurge:25%

?    maxUnavailable:25%

这是Deployment的默认更细策略

rollingUpdate:滚动更新

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

，不能超过25%

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

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

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

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

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

headless-service:无头服务，没有clusterIp，必须要有动态pvc

apiVersion: v1
kind: Service
metadata:
  name: nginx-web
spec:
  ports:
  - port: 80
    targetPort: 80
  clusterIP: ""
  selector:
    app: nginx1

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  labels:
    app: nginx2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginc-sts
  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:k8s集群当中一种特殊的服务类型，不分配Cluseter给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.10 做一个地址映射

为什么要用healdless:

有序，独立个体

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

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

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

为什么要有volumeClaimTemplates:

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

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

不是是固定节点的应用，不是固定ip的一个用

更新发布比较频繁

支持自动伸缩，节点的资源不过，可以自动扩容

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

常用于运行那些仅需要执行一次的任务

应用场景:数据库迁移、批处理脚本执行、视频解码业务

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

第一点:必须要指定容器的重启策略 onfailure和Never

第二点:执行失败的次数也是受限的，默认是6次，但是可以指定用backoffLimit:

backoffLimit: 4 #允许失败的次数是4次，4次之后，restartPolicy策略，来进行容器的重启或者不重启。

第三点:更新yaml文件。必须要先删除任务，再更新，不能动态更新的。

容器化部署，部署过数据库吗：

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

5、cronjob:周期性任务，像linux的crontab一样语法一样:分 时 日 月 周

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

总结：

这五个都是控制器创建的pod，都是依赖于控制器

deployment:典型的无状态的应用，最好用的，也是最多的

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

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

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

cronjob:定时任务

写一个yaml用cronjob定期检测80端口是否存活 ,在加上存活探针检测80端口，用到tcpSocker

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: hello
        spec:
          containers:
          - name: hello
            image: nginx:1.22
            command: ["/bin/bash", "-c", "date; echo hello is ok"]
            livenessProbe: #定义存活探针
              tcpSocket:
                port: 80
          restartPolicy: Never
      backoffLimit: 4 #允许任务失败的4次，4次后restartPolicy策略。来进行容器的重启或
不重启
~                                                                                   
~                                                                                   
~