K8S Deployment 控制器 理论+代码+图例=深入浅出

已于 2025-04-30 14:51:06 修改
阅读量1k 收藏 14
点赞数 28
CC 4.0 BY-SA版权
分类专栏： K8S 文章标签： kubernetes 运维 服务器
于 2025-02-05 22:30:41 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/matrixlzp/article/details/145418687

一、理论介绍

今天我们来实验 Deployment 控制器（也叫工作负载）。官网描述如下：

1、是什么？

Deployment 是一个非常重要的资源对象，它为 Pod 和 ReplicaSet 提供了声明式的更新能力，常用于管理无状态应用程序的部署和更新。

2、为什么需要？

为 Pod 和 ReplicaSet 提供了声明式的更新能力。

所谓声明式更新指的是用户只需描述期望的资源最终状态，比如定义 Deployment、Service 等资源的 YAML 文件，详细说明资源的属性、副本数量、使用的镜像等信息。Kubernetes 系统会自动对比当前资源的实际状态和期望状态，然后采取必要的操作，使实际状态逐渐趋近并最终达到期望状态。

声明式更新最常用的命令，就是 kubectl apply -f <directory>

3、缺点

无法部署有状态应用。

1.1、基础信息

kubectl explain deploy
# deploy 是 deployment 的缩写

apiVersion：当前资源使用的 api 版本，是 GROUP/VERSION 的组合。

kind：资源类型，跟 KIND 保持一致。

metadata：元数据。定义资源名称、标签、注解等。

spec：规范、规约。定义 Pod 副本数、Pod 标签选择器、Pod 模板。

status：状态信息，只读，一般不会去修改。

 1.2、DeplymentSpec 规约

kubectl explain deploy.spec

minReadySeconds：pod 变为就绪状态之后，还⾄少需要保持多少秒，才能被视为真正可⽤的，以继续后续部署过程。一般配合就绪探针使用。

paused：指示 deployment 是否被暂停。执行 kubectl rollout pause 后会被设置为 true。详细参考下文金丝雀发布。

replicas：Pod 副本数。

revisionHistoryLimit：保留的旧的 ReplicaSet 历史版本数。默认是 10。

Deployment 通过创建 ReplicaSet 来间接管理 Pod。

Deployment 控制器是建立在 rs 之上的一个控制器，可以管理多个 rs，每次更新镜像版本，都会生成一个新的 rs，把旧的 rs 替换掉，多个 rs 同时存在，但是只有一个 rs 运行。

Deployment 通过回滚 ReplicaSet 来回滚镜像版本。

selector：标签选择器。用于查找它所要管理的 Pod。它必须跟 Pod 模板的标签（template.metadata.labels）相匹配。

template：Pod 模板。定义 Pod 的模板。

可以看到 template 内部主要就是定义 Pod 的规范（PodSpec）它跟 Pod 定义里的规范（Pod.spec）是同一个类型。

strategy：pod 更新策略。

  • type：有两种取值 Recreate, RollingUpdate（默认）。

               ○ Recreate：重建式。删除所有已经存在的 Pod，再重新创建新的 Pod。

               ○ RollingUpdate：滚动更新式。以配置的速率来控制 pod 的增加和减少。

                                      配置详见 rollingUpdate 字段。

  • rollingUpdate：当 type=RollingUpdate 时，这个字段才起作用。

               ○ maxSurge：决定了在滚动升级期间，除了 replicas 配置的期望的副本数之外，                                          最多允许超出的 pod 实例的数量。它有两种取值方式，

                                      第一种是绝对值，第二种是根据百分比。

                                      默认值为 25%。

                                      绝对值按百分比向上取整（rounding up）。

               ○ maxUnavailable：决定了在滚动升级期间，

                                      最多允许几个不可用（相对于replicas）。它有两种取值方式，

                                      第一种是绝对值，第二种是根据百分比。

                                      默认值为 25%。

                                     绝对值按百分比向下取整（rounding down）。

               ○ 就比如 replicas=5，maxSurge=25%，maxUnavailable=25%，那么在滚动升级                                         期间，最多可以超出 5*25%=1.25 --> 2个。最多的时候，可以有                                             5+2=7 个 pod 在运行（不保证全部可用）。

                                     最多可以有 5*25%=1.25 --> 1个不可用。则最少有 5-1=4 个 pod 可                                         以提供服务。

1.3、滚动更新过程

  • 当 replicas=3，maxSurge=1，maxUnavailable=0 时，滚动更新的过程如下图。

rs1 控制三个 v1 pod，滚动更新开始后，先在 rs2 上新建一个 v2 pod，待该 pod 就绪后，在 rs1 上删除一个 v1 pod 的同时，又在 rs2 上新建一个 v2 pod。依次类推，直到全部都是由 rs2 控制。

  • 当 replicas=3，maxSurge=1，maxUnavailable=1 时，滚动更新的过程如下图。

rs1 控制三个 v1 pod，滚动更新开始后，先在 rs2 上新建两个 v2 pod 并在 rs1 上删除一个 v1 pod，待该两个 v2 pod 就绪后，马上又在 rs1 上删除两个 v1 pod 并新建一个 v2 pod。待这最后一个 pod 就绪后，所有的 pod 就全部都是由 rs2 控制。

 分析上图会发现，当 maxUnavailable=1，在更新过程中有一段时间会出现，可用的 pod 数，少于 replicas=3 期望的副本数（3-maxUnavailable=2）的情况，这在高可用系统中是不允许的。

比如，我有一个应用，它需要3个 pod 才能稳定提供服务。现在在更新的过程中，有一段时间，它有1个 pod 不可用，那势必造成另外两个 pod 流量短时间内激增。

  • 最佳实践：maxUnavailable 设置为 非0 的话，在滚动升级期间会有可用 pod 数少于期望副本数的情况。从高可用的角度来讲，这个值最好设置为 0。

 二、镜像准备

假设有如下三个节点的 K8S 集群：

k8s31master 是控制节点

k8s31node1、k8s31node2 是工作节点

容器运行时是 containerd

使用 springboot 打包两个镜像 hellok8s-1.0.jar.gz 和 hellok8s-2.0.jar.gz。

hellok8s:1.0

@RestController
public class HelloController {

    @GetMapping("/sayHello")
    @ResponseBody
    public String sayHello() {
        # 蓝
        return "Hello,I am Blue";
    }
}

hellok8s:2.0

@RestController
public class HelloController {

    @GetMapping("/sayHello")
    @ResponseBody
    public String sayHello() {
        # 绿
        return "Hello,I am Green";
    }
}

它们的区别仅在输出的问候信息不同，一个 Blue、一个 Green.

  •  导入镜像
# node1 执行
[root@k8s31node1 ~]# ctr -n=k8s.io images import hellok8s-1.0.jar.gz
[root@k8s31node1 ~]# ctr -n=k8s.io images import hellok8s-2.0.jar.gz
# node2 执行
[root@k8s31node2 ~]# ctr -n=k8s.io images import hellok8s-1.0.jar.gz
[root@k8s31node2 ~]# ctr -n=k8s.io images import hellok8s-2.0.jar.gz

三、Deployment 自动化部署

  • 资源文件编写

deploy-first.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hellok8s
  template:
    metadata:
      labels:
        app: hellok8s
    spec:
      containers:
      - name: hellok8s
        image: hellok8s:1.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
  • replicas=2，期望副本数是 2。
  • selector.matchLabels 要与 template.metadata.labels 相匹配。
  • startupProbe 是启动探针、readinessProbe 是继续探针、livenessProbe 是存活探针。

             ○ httpGet 是探测模式，以 http 请求方式探测。

             ○ initialDelaySeconds 初始探测延迟时间，表示容器启动后多少秒开始探测。

             ○ periodSeconds 表示两次探测的时间间隔是多少秒。

  • 执行并查看
kubectl apply -f deploy-first.yaml
kubectl get deploy

[root@k8s31master deploy]# kubectl get deploy
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
my-deploy   0/2          2                      0                   3s
[root@k8s31master deploy]# kubectl get deploy
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
my-deploy   2/2          2                      2                   12s

  1. NAME ：deployment 的名称。
  2. READY：显示 deployment 有多少副本数。它遵循 ready/desired的模式。
  3. UP-TO-DATE： 显示已更新到所需状态的副本数。
  4. AVAILABLE：已就绪的副本数。
  5. AGE ：显示应用程序已运行的时间。
  •  查看 ReplicaSet
kubectl get rs

创建 deploy 的时候也会创建一个 rs（ReplicaSet）。

  1. NAME： ReplicaSet 的名称。命名规范为 [deployment-name]-[pod-template-hash]。 
  2. DESIRED：期望的副本数。
  3. CURRENT：当前正在运行的副本数。
  4. READY： 已就绪的副本数。
  5. AGE ：显示应用程序已运行的时间。
kubectl describe rs my-deploy-569b69f85d

  •  查看 Pod
kubectl get pod

四、Deployment 实现 Pod 的动态扩容

修改 deploy-first.yaml，replicas: 2 改为 3

replicas: 3

  • 重新运行并查看
kubectl apply -f deploy-first.yaml
kubectl get pod -owide

可以看到 新创建了一个 pod，名称是 my-deploy-569b69f85d-hzfzg

  • 访问接口

 可以看到，三个 pod 的服务是一样的，返回的都是 Blue。

五、Deployment 实现 Pod 的滚动更新

修改 deploy-first.yaml，image: hellok8s:1.0 改为 2.0

image: hellok8s:2.0

  • 重新运行并监控
kubectl apply -f deploy-first.yaml
kubectl get pod -owide -w
NAMEREADYSTATUSAGEIPNODE
my-deploy-569b69f85d-cw7wt1/1Running52m10.244.9.3k8s31node2
my-deploy-569b69f85d-hzfzg1/1Running12m10.244.165.29k8s31node1
my-deploy-569b69f85d-qrm5p1/1Running52m10.244.165.28k8s31node1
my-deploy-7cf64887cf-kbjwg0/1Pending0s<none><none>
my-deploy-7cf64887cf-kbjwg0/1Pending0s<none>k8s31node2
my-deploy-7cf64887cf-kbjwg0/1ContainerCreating0s<none>k8s31node2
my-deploy-7cf64887cf-kbjwg0/1ContainerCreating1s<none>k8s31node2
my-deploy-7cf64887cf-kbjwg0/1Running1s10.244.9.6k8s31node2
my-deploy-7cf64887cf-kbjwg0/1Running11s10.244.9.6k8s31node2
my-deploy-7cf64887cf-kbjwg1/1Running11s10.244.9.6k8s31node2
my-deploy-569b69f85d-hzfzg1/1Terminating13m10.244.165.29k8s31node1
my-deploy-7cf64887cf-89w8b0/1Pending0s<none><none>
my-deploy-7cf64887cf-89w8b0/1Pending0s<none>k8s31node1
my-deploy-7cf64887cf-89w8b0/1ContainerCreating0s<none>k8s31node1
my-deploy-569b69f85d-hzfzg1/1Terminating13m10.244.165.29k8s31node1
my-deploy-569b69f85d-hzfzg0/1Error13m10.244.165.29k8s31node1
my-deploy-7cf64887cf-89w8b0/1ContainerCreating1s<none>k8s31node1
my-deploy-569b69f85d-hzfzg0/1Error13m10.244.165.29k8s31node1
my-deploy-569b69f85d-hzfzg0/1Error13m10.244.165.29k8s31node1
my-deploy-7cf64887cf-89w8b0/1Running2s10.244.165.30k8s31node1
my-deploy-7cf64887cf-89w8b0/1Running11s10.244.165.30k8s31node1
my-deploy-7cf64887cf-89w8b1/1Running11s10.244.165.30k8s31node1
my-deploy-569b69f85d-qrm5p1/1Terminating53m10.244.165.28k8s31node1
my-deploy-7cf64887cf-crw520/1Pending0s<none><none>
my-deploy-7cf64887cf-crw520/1Pending0s<none>k8s31node2
my-deploy-7cf64887cf-crw520/1ContainerCreating0s<none>k8s31node2
my-deploy-569b69f85d-qrm5p1/1Terminating53m10.244.165.28k8s31node1
my-deploy-569b69f85d-qrm5p0/1Error53m10.244.165.28k8s31node1
my-deploy-7cf64887cf-crw520/1ContainerCreating1s<none>k8s31node2
my-deploy-569b69f85d-qrm5p0/1Error53m10.244.165.28k8s31node1
my-deploy-569b69f85d-qrm5p0/1Error53m10.244.165.28k8s31node1
my-deploy-7cf64887cf-crw520/1Running2s10.244.9.5k8s31node2
my-deploy-7cf64887cf-crw520/1Running11s10.244.9.5k8s31node2
my-deploy-7cf64887cf-crw521/1Running11s10.244.9.5k8s31node2
my-deploy-569b69f85d-cw7wt1/1Terminating53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt1/1Terminating53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt0/1Error53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt0/1Error53m10.244.9.3k8s31node2
my-deploy-569b69f85d-cw7wt0/1Error53m10.244.9.3k8s31node2
  •  过程分析

我们 deploy-first.yaml 没有配置 spec.strategy，都走默认配置，等效于

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate: 
      maxSurge: 25%
      maxUnavailable: 25%
......
......
......

replicas=3

maxSurge=3*0.25=0.75=1（向上取整）最大允许超出 1 个。

maxUnavailable=3*0.25=0.75=0（向下取整）最大允许不可用为 0 个。也就是无论何时，系统都要保持至少3个副本可用。

 Deployment 滚动升级时的三个副本数和默认maxSurge、maxUnavailable 配置关系如下：

  1. 滚动更新之前，系统里面有3个 v1.0 的副本 cw7wt、qrm5p、hzfzg。
  2. 滚动更新开始后，kubelet 创建一个 v2.0 版本的 pod  kbjwg。因为有就绪探针，此时它并没有处于可用状态。系统中现在有3个可用副本，一个不可用副本。
  3. 等到 kbjwg 就绪探针探测成功后，系统中有4个可用副本。
  4. 紧接着 kubelet 删除一个 v1.0 的 pod hzfzg 并创建一个 v2.0 版本的 pod 89w8b。
  5. 以此类推，直到3个 v2.0 版本的 pod 都处于可用状态，这个时候 kubelet 才删除最后一个 v1.0 pod cw7wt。

 整个过程可以抽象成下面这张图：

  •  访问接口

可以看到，所有 pod 的版本，已经都被替换为 2.0 了。

  •   查看 ReplicaSet
kubectl get rs

可以看到有 2 个 rs 存在， my-deploy-569b69f85d 就是升级之前 v1.0 的 deploy 生成的 rs。

  • 扩展

 对于 replicas=3，maxSurge=1，maxUnavailable=1 大家可以很容易画出下面这张图。

大家可以根据我上面的思路，自行画看看。

 六、Deployment 实现 Pod 的版本回退

  • 查看控制器的滚动历史
kubectl rollout history deploy my-deploy

  • 版本号从1开始，依次递增
  • 版本号 0 表示最后的修订。

  • 创建 deploy 如果不给定 --record 参数，版本历史中的 CHANGE-CAUSE 这⼀栏会为空。这也会使⽤户很难辨别每次的版本做了哪些修改。
  •  回滚到⼀个特定的 Deployment 版本

通过在 undo 命令中指定⼀个特定的版本号，便可以回滚到那个特定的版本。例如，如果想回滚到第⼀个版本，可以执⾏下述命令:

kubectl rollout undo deploy/my-deploy --to-revision=1
或者
kubectl rollout undo deploy my-deploy --to-revision=1

  • 查看 ReplicaSet
kubectl get rs

 ReplicaSet 版本，回滚到上一个版本。

  •  访问接口

 可以看到，所有 pod 的版本，已经都被替换为 1.0 了。

  •  回滚到上一个版本
kubectl rollout undo deploy/my-deploy

 直接 undo 就行，因为 --to-revision 默认等于0，就是上一个版本。

 七、Deployment 实现 Pod 的动态缩容

副本数从 3 缩容到 2

kubectl patch deployment my-deploy -p '{"spec":{"replicas":2}}'
# patch 以打补丁的方式，修改资源
# -p  patch 的缩写

八、Deployment 实现 Pod 的重建式更新

修改 deploy-first.yaml，把 pod 更新策略变成 Recreate。

  • 执行并监控
kubectl apply -f deploy-first.yaml --record
kubectl get pod -owide -w
NAMEREADYSTATUSRESTARTSAGEIPNODE
my-deploy-569b69f85d-6bgg61/1Running1(11mago)2d8h
my-deploy-569b69f85d-k42m91/1Running1(11mago)2d8h
my-deploy-569b69f85d-jz8gb0/1Pending00s<none><none>
my-deploy-569b69f85d-jz8gb0/1Pending00s<none>k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerCreating00s<none>k8s31node1
my-deploy-569b69f85d-6bgg61/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-k42m91/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-jz8gb0/1Terminating00s<none>k8s31node1
my-deploy-569b69f85d-6bgg61/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-k42m91/1Terminating1(14mago)2d8h
my-deploy-569b69f85d-6bgg60/1Error12d8h10.244.9.9k8s31node2
my-deploy-569b69f85d-k42m90/1Error12d8h10.244.165.32k8s31node1
my-deploy-569b69f85d-6bgg60/1Error12d8h10.244.9.9k8s31node2
my-deploy-569b69f85d-6bgg60/1Error12d8h10.244.9.9k8s31node2
my-deploy-569b69f85d-k42m90/1Error12d8h10.244.165.32k8s31node1
my-deploy-569b69f85d-k42m90/1Error12d8h10.244.165.32k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerStatusUnknown02s<none>k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerStatusUnknown02s<none>k8s31node1
my-deploy-569b69f85d-jz8gb0/1ContainerStatusUnknown02s<none>k8s31node1
my-deploy-7cf64887cf-4n7660/1Pending00s<none><none>
my-deploy-7cf64887cf-w8bhs0/1Pending00s<none><none>
my-deploy-7cf64887cf-4n7660/1Pending00s<none>k8s31node1
my-deploy-7cf64887cf-8hsdj0/1Pending00s<none><none>
my-deploy-7cf64887cf-w8bhs0/1Pending00s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1Pending00s<none>k8s31node2
my-deploy-7cf64887cf-4n7660/1ContainerCreating00s<none>k8s31node1
my-deploy-7cf64887cf-w8bhs0/1ContainerCreating00s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1ContainerCreating00s<none>k8s31node2
my-deploy-7cf64887cf-4n7660/1ContainerCreating01s<none>k8s31node1
my-deploy-7cf64887cf-w8bhs0/1ContainerCreating01s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1ContainerCreating01s<none>k8s31node2
my-deploy-7cf64887cf-8hsdj0/1Running02s10.244.9.11k8s31node2
my-deploy-7cf64887cf-w8bhs0/1Running02s10.244.9.10k8s31node2
my-deploy-7cf64887cf-4n7660/1Running02s10.244.165.33k8s31node1
my-deploy-7cf64887cf-4n7660/1Running011s10.244.165.33k8s31node1
my-deploy-7cf64887cf-w8bhs0/1Running011s10.244.9.10k8s31node2
my-deploy-7cf64887cf-8hsdj0/1Running011s10.244.9.11k8s31node2
my-deploy-7cf64887cf-8hsdj1/1Running011s10.244.9.11k8s31node2
my-deploy-7cf64887cf-w8bhs1/1Running011s10.244.9.10k8s31node2
my-deploy-7cf64887cf-4n7661/1Running011s10.244.165.33k8s31node1
  • 过程分析
  • 刚开始我们有两个 1.0 版本的 pod：6bgg6、k42m9
  • 因为  deploy-first.yaml 文档 replicas=3，kubelet 尝试再创建一个 1.0 版本的 jz8gb。
  • kubelet 发现 pod 更新策略变成 Recreate。删除所有已经存在的 1.0 版本 Pod：6bgg6、k42m9、jz8gb，再重新创建新的 2.0 版本 Pod：8hsdj、w8bhs、4n766。
  • 重建式更新策略 Recreate，会删除所有已经存在的 pod，再重新创建新的 pod，所以会造成线上服务在版本更新的时候不可用，所以生产环境很少采用这种方式。
  •  查看滚动历史
kubectl rollout history deploy/my-deploy

  •  可以看到，加了 --record 参数后，CHANGE_CAUSE 会帮我们记录下更新原因了。
  • --record 参数已被官方标记为 已过时。

  • 可以通过手动添加 kubernetes.io/change-cause 注解的方式，来记录 CHANGE_CAUSE。
  • 例如，在更新 Deployment 后，运行以下命令来设置变更原因：
kubectl annotate deployment/<deployment-name> kubernetes.io/change-cause="Your change description here"
  • 确保替换 <deployment-name> 为你实际的 Deployment 名称，并将 "Your change description here" 替换为描述此次变更的实际文本。
  •  查看 rs、pod 

  •  访问接口

尝试在集群不同节点上访问接口：

[root@k8s31master ~]# curl 10.244.165.33:8080/sayHello
[root@k8s31node1 ~]# curl 10.244.9.11:8080/sayHello
[root@k8s31node2 ~]# curl 10.244.9.10:8080/sayHello

 可以看到，所有版本都升级为 2.0 了。

从这也能看出，pod 的 IP 是一种 clusterIp，集群内的任何节点都能正常访问到。

  • 删除 deploy

删除 deploy，为下面的实验做准备。

kubectl delete -f deploy-first.yaml
kubectl get deploy
kubectl get rs
kubectl get pod -owide

从这也能看出，删除 Deployment，则它所创建的 ReplicaSet、Pod 也会被一并删除。

九、Deployment 实战之 蓝绿 发布

参考我的另一篇博文。

十、Deployment 实战之 金丝雀 发布

参考我的另一篇博文。

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值