k8s控制器（二）______Deployment控制器

Deployment控制器

Deployment通过控制ReplicaSet控制pod的，并不是直接控制Pod。kubernetes建议我们使用Deployment，Deployment控制器是工作在ReplicaSet之上，Deployment控制器为Pod和ReplicaSet提供了一个声明式更新的方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSets控制器，通过Replicaset创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源。

典型的使用场景：

1、创建无状态的应用，即单个或部分Pod故障不影响整体状态。
2、滚动更新和回滚。

简单的yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dy
  labels:
    web: nginx
  namespace: default
spec:
  minReadySeconds: 10
  #新创建的Pod成为就绪状态之前，Deployment控制器等待的最短时间（秒数）。确保Pod中的业务程序能正常工作之前有做狗的时候完成初始化和准备工作。
  paused: false
  progressDeadlineSeconds: 60
  #该字段用于指定部署操作的进度检查的超时时间（以秒为单位）。这个字段的作用是为了确保部署操作能够在指定的时间内完成，并在超时后进行相应的处理。
  replicas: 8
  revisionHistoryLimit: 5
  #该用于指定要保留的 Deployment 版本历史记录的最大数量。Deployment 版本历史记录包含了过去创建的每个 Deployment 的详细信息，包括创建时间、更新时间、副本数量等。
  #如果设置为 0，则不会保留任何历史记录；如果设置为负值，则表示将保留所有历史记录。
  selector:
    matchLabels:
      ser: nginx-test
  strategy:
  #定义滚动更新策略
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      name: nginx
      #namespeace
      labels:
        ser: nginx-test
    spec:
      nodeSelector:
        app: to
      hostname: nginx-dy
      containers:
      - image: docker.io/library/nginx:v1
        name: nginx-dy
        imagePullPolicy: IfNotPresent
        ports:
        - name: nginx-post
          containerPort: 80

在yaml文件中标签选择器selector下的标签配置（ser: nginx-test）和template.metadata.labels下配置的标签要一致。这样控制器才知道他要管理那个Pod。

yaml文件解析

   minReadySeconds: 10

新创建的Pod成为就绪状态之前，Deployment控制器等待的最短时间（秒数）。确保Pod中的业务程序能正常工作之前有做狗的时候完成初始化和准备工作。

   paused: false

Deployment将暂停其更新过程，即不会进行新的部署、扩容或缩容操作。

   progressDeadlineSeconds: 60 

该字段用于指定部署操作的进度检查的超时时间（以秒为单位）。这个字段的作用是为了确保部署操作能够在指定的时间内完成，并在超时后进行相应的处理。

   evisionHistoryLimit: 5

该用于指定要保留的 Deployment 版本历史记录的最大数量。Deployment版本历史记录包含了过去创建的每个Deployment的详细信息，包括创建时间、更新时间、副本数量等。如果设置为0，则不会保留任何历史记录；如果设置为负值，则表示将保留所有历史记录。默认为10

   strategy：

定义滚动更新策略的子字段。他有两个子字段RollingUpdate和type。

在type下有两种策略：

一种为Recreate表示使用重建策略，即在进行部署、更新或回滚时，首先删除当前所有的Pod，然后创建新的Pod。
一种是RollingUpdate表示使用滚动更新策略，即逐步替换旧的 Pod，以确保在更新过程中服务不中断。
（注：RollingUpdate在type字段下是一个对象）

在RollingUpdate下有两个参数maxSurge和maxUnavailable：

maxSurge设置为 1，表示在滚动更新期间允许一个额外的Pod副本。maxUnavailable设置为0，表示在滚动更新期间不允许任何不可用的 Pod 副本。

1、查看历史版本

kubectl rollout history deployment nginx-dy

得到信息：

[root@master yaml]# kubectl rollout history deployment nginx-dy
 deployment.apps/nginx-dy 
 REVISION  CHANGE-CAUSE
  1         <none>

2、修改yaml文件。把image修改为：docker.io/library/nginx:v2更新Pod。查看历史版本。

[root@master yaml]# kubectl rollout history deployment nginx-dy
 deployment.apps/nginx-dy 
 REVISION  CHANGE-CAUSE
  1         <none>
  2         <none>

3、验证Pod使用的image进行版本回滚。

kubectl rollout undo deployment/nginx-dy --to-revision=1