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

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: 定时任务。通知，备份或者探测 cronjob定期检测nginx的80端口是 tcptocker */1 * * * *