1.Pod Controller控制器介绍

• 控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod，相当于一个状态机，用来控制Pod的具体状态和行为。controller会自动创建相应的pod资源，并在当pod发生故障的时候按照策略进行重新编排
• 通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等
  通俗来说就是【幕后老板】
• yaml文件中 kind 填写对应的类型即可

以下是 Kubernetes 中常见的几种 Pod 控制器：

• ReplicaSet（副本集）：ReplicaSet 用于确保指定数量的 Pod 副本正在运行。它通过标签选择器选择要管理的 Pod，并根据定义的副本数进行自动扩展或缩减。当 Pod 发生故障或需要扩展时，ReplicaSet 将自动创建或删除 Pod。

• Deployment（部署）：Deployment 是一个高级控制器，它在 ReplicaSet 的基础上提供了更高级的功能。它允许用户定义滚动升级策略、回滚到先前的版本以及管理应用程序的发布和更新。Deployment 通过创建和管理 ReplicaSet 来确保应用程序的可靠性和可伸缩性。

• StatefulSet（有状态副本集）：StatefulSet 用于管理有状态的应用程序，例如数据库。与 ReplicaSet 不同，StatefulSet 提供了稳定的网络标识和稳定的存储卷，确保每个 Pod 有唯一的标识和持久化存储。它还支持有序部署和伸缩，以确保有状态应用程序的一致性和可靠性。

• DaemonSet（守护进程集）：DaemonSet 用于在集群中的每个节点上运行一个 Pod 副本。它适用于在每个节点上运行一组特定的系统任务或守护进程，例如日志收集、监控代理等。DaemonSet 会自动在新加入集群的节点上创建 Pod，同时在节点离开集群时自动删除 Pod。

• Job（工作）：用于管理一次性任务（One-time task）。它负责确保 Pod 完成任务并维持所需的副本数。

这些 Pod 控制器可以根据不同的需求选择适合的控制器来管理和控制 Pod。它们提供了对 Pod 的生命周期、自动化管理、故障恢复和伸缩等功能的支持，从而简化了应用程序的部署和管理。

2.ReplicaSet控制器

一种副本控制器，简称rs，主要是控制由其管理的pod，使pod副本的数量始终维持在预设的个数，并支持pod数量扩缩容，镜像版本升级，官方建议不要直接使用ReplicaSet，用Deployments更好，并提供很多其它有用的特性。

示例文件 replicaset-nginx.yaml：

apiVersion: apps/v1
kind: ReplicaSet   
metadata:
  name: gq-rs
  namespace: dev
spec:
  replicas: 5
  selector: 
    matchLabels:
      app: gq-nginx-pod
  template:
    metadata:
      labels:
        app: gq-nginx-pod
    spec:
      containers:
      - name: gq-nginx
        image: nginx:1.23.0

执行：

#创建
kubectl apply -f replicaset-nginx.yaml

其他操作：

#查看
kubectl get pods,deploy,replicaset -o wide -n dev

# 命令行缩容
kubectl scale rs xdclass-rs --replicas=2 -n dev

# 删除，可以直接删除rs；也可以通过yaml删除
kubectl delete -f replicaset-nginx.yaml

3.Deployment控制器

• 通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本，适合无状态的服务部署
• 当某个应用有新版本发佈时，Deployment会同时操作两个版本的ReplicaSet
• 其内置多种滚动升级策略，会按照既定策略降低老版本的Pod数量，同时也创建新版本的Pod
• Deployment控制器不直接管理Pod对象，而是 Deployment 管理ReplicaSet, 再由ReplicaSet管理Pod对象
• 总结：Deployment、ReplicaSet、Pod三者之间是一种阶梯控制的关系

示例文件 deploy-nginx-pod.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gq-deploy
  namespace: dev
spec:
  replicas: 5
  selector: 
    matchLabels:
      app: gq-nginx-pod
  template:
    metadata:
      labels:
        app: gq-nginx-pod
    spec:
      containers:
      - name: gq-nginx
        image: nginx:1.23.0

执行：

#创建
kubectl apply -f deploy-nginx-pod.yaml

# 查看deployment
kubectl get deployment -n dev

#查看
kubectl get pods,deploy,replicaset -o wide -n dev


# 删除，通过yaml删除
kubectl delete -f deploy-nginx-pod.yaml

检查集群中的 Deployment 时，所显示的字段有：

• NAME 列出了集群中 Deployment 的名称。
• READY 显示应用程序的可用的“副本”数,格式是“就绪个数/期望个数”。
• UP-TO-DATE 显示为了达到期望状态已经更新的副本数。
• AVAILABLE 显示可用的副本数。
• AGE 应用程序运行的时间。

Deployment 控制器滚动升级（Rolling Update）

K8S的Deployment控制器滚动升级 (金丝雀发布 or 灰度发布）

• 对各个实例批次进行单独更新,而非同一时刻对所有实例进行全部更新，达到不中断服务的更新升级方式
• Deployment控制器 给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas)
• Deployment更新有两种方式
  • Recreate ： 删除全部旧的pod，然后创建新的pod
  • RollingUpdate：滚动升级更新，删除部分，更新部分，在整个更新过程中，存在两个版本的pod

yaml示例 deploy-myapp-pod.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3  # 副本数量
  revisionHistoryLimit: 5  # 保存的修订版本历史记录数量
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest  # 需要更新的镜像版本
        ports:
        - containerPort: 8080  # 容器的端口
      strategy:
        type: RollingUpdate  # 使用 Rolling Update 策略
        rollingUpdate:
          maxUnavailable: 1  # 在升级过程中最多允许的不可用 Pod 数量
          maxSurge: 1  # 在升级过程中最多允许的额外创建的 Pod 数量

解析：

• maxUnavailable

升级过程中不可用Pod的最大数量，默认为25%
在滚动更新时，我们可以忍受多少个 Pod 无法提供服务
值越小越能保证服务稳定,更新越平滑

• maxSurge

升级过程中可以超过期望的Pod的最大数量，默认为25%；
在滚动更新时，可以有多少个额外的 Pod
值调的越大，副本更新速度越快

查看控制器

kubectl describe deploy my-app 

滚动升级

升级 nginx 版本，可以使用以下命令执行滚动升级操作：

#追加 --record 以保存正在更改资源的 kubectl 命令，方便查看history版本列表修改命令
kubectl set image deployment/nginx-deployment nginx=nginx:1.24.0 --record

动态查看升级过程，存在多个不同版本

kubectl get pods -n dev -w

发布回滚

• kubectl rollout 版本升级相关介绍
  • history 升级历史记录
  • undo 默认回滚上一版本 ，使用–to-revision回滚到指定版本
  • pause 暂停版本升级发布
  • resume 继续恢复刚暂停的版本升级
  • status 升级状态
• 查看历史版本列表

kubectl rollout history deployment/my-app -n dev

• 查看具体某一个历史版本信息

kubectl rollout history deployment/my-app -n dev --revision=2

• 回滚上一版本

kubectl rollout undo deployment/my-app -n dev

• 查看升级情况

kubectl rollout status deployment/my-app -n dev

• 回滚指定版本

kubectl rollout undo deployment/my-app -n dev --to-revision=2

• 删除deployment

kubectl delete -f deploy-myapp-pod.yaml

DaemonSet控制器

DaemonSet是Kubernetes中的一种控制器，用于确保在集群中的每个节点上运行一个Pod的副本。它适用于需要在每个节点上运行后台任务或守护进程的场景。

示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset  # DaemonSet的名称
  labels:
    app: my-app  # 标签用于选择DaemonSet控制的Pod
spec:
  selector:
    matchLabels:
      app: my-app  # 选择器标签，用于选择控制的Pod
  template:
    metadata:
      labels:
        app: my-app  # Pod的标签
    spec:
      containers:
      - name: my-container  # 容器的名称
        image: my-image  # 容器的镜像
        # 容器的其他配置...

      # 如果有多个容器，可以继续在这里添加容器的定义
      # - name: another-container
      #   image: another-image
      #   ...

  # 更新策略
  updateStrategy:
    type: RollingUpdate  # 使用滚动更新策略
    rollingUpdate:
      maxUnavailable: 1  # 每次更新不可用的最大Pod数量
      maxSurge: 1  # 允许超出所需Pod数量的最大副本数

执行命令

#创建
kubectl apply -f daemonset-nginx.yaml

#只有一个节点,多个节点的话，每个节点都有一个pod
kubectl get pod,deploy,rs,ds -n dev

DaemonSet的更新策略：

• 在更新DaemonSet时，可以指定不同的更新策略，例如"RollingUpdate"或"OnDelete"。
• "RollingUpdate"策略逐步更新每个节点上的Pod，以确保高可用性。
• "OnDelete"策略只有在旧的DaemonSet被删除后，才会创建新的DaemonSet。

Job控制器

Job控制器是Kubernetes中的一种资源控制器，用于管理一次性任务（One-Time Tasks）。它负责确保Pod中的任务成功完成，并可以按需创建多个Pod来并行或串行地执行任务。

Job控制器的主要特点和用途包括：

• 一次性任务：Job控制器用于管理一次性的任务，例如批处理作业、定时任务等。每个任务只会执行一次，不会自动重启。

• 并行执行：Job控制器可以并行创建多个Pod来执行任务。可以通过设置Pod数量来控制并发度。

• 任务完成检查：Job控制器会监控任务的执行情况，并确保任务成功完成。当一个Pod成功完成任务后，Job控制器会终止该Pod并创建下一个Pod继续执行任务，直到所有任务完成。

• 任务重试：如果任务失败或超时，Job控制器会根据重试策略重新创建Pod来重新执行任务，直到达到最大重试次数。

• 完成状态：当所有任务成功完成后，Job控制器会将Job的状态标记为完成。可以根据Job的完成状态进行相应的操作，例如清理资源、发送通知等。

示例：

apiVersion: batch/v1
kind: Job
metadata:
  name: my-app
  namespace: dev
spec:
  parallelism: 3 #job并发运行Pods的数量，默认 1
  completions: 4 #job需要成功运行Pods的次数,默认 1
  backoffLimit: 5 #job失败后进行重试的次数，默认是6
  activeDeadlineSeconds: 100 #job运行超时时间，当job超过timeout时间，则job的状态也会更新为failed
  template:
    spec:
      restartPolicy: Never #job重启策略，OnFailure或Never 
      containers:
      - name: demo
        image: busybox:1.35.0 
        # 容器的启动命令列表,在pod中的容器初始化完毕后运行命令
        command: ["sh", "-c", "echo Performing backup... && sleep 10 && echo Backup completed."]  

在上述示例中，completions字段指定了要完成的Pod数量，这里设置为1，表示只需要一个Pod成功完成任务即可。template字段定义了Pod的模板，包含了容器的配置信息。

通过创建和管理Job资源，可以方便地执行一次性的任务，并确保任务的成功完成。你可以根据实际需求来配置Job控制器的参数，例如设置重试策略、定义任务的并发度等。