「这是我参与2022首次更文挑战的第 15 天，活动详情查看：2022首次更文挑战」

【k8s 系列】k8s 学习二十五-3，Deployment 升级应用2

上次我们说到自己手动的做使用 RS 的方式来升级 pod ，感觉还是蛮复杂的，并且容易弄错，实际生产过程中，肯定不会这样来弄，很危险

那么今天我们来分享 Deployment 的方式来显示的升级应用吧

Deployment 的方式升级应用

对于之前的操作方式有没有感觉还是比较繁琐的，还需要自己去切换流量，自己去创建新的 RS ，甚至最后还要将旧的 RS 删除掉，甚是麻烦

我们来玩一个更加高阶的资源，也是比较容易的，为了接下来的案例清晰，我们就把上述的 RS 全部删除掉，留下 Service 后续可以使用

Deployment 是使用应用程序声明的方式来升级应用，而不是通过 RS 或者 RC 了

实际上创建一个 Deployment 资源，其实也会创建一个 RS 资源，那么 Deployment 是拿来做啥的呢？我们可以理解为协调资源的

实践 demo

创建一个 deploy ，mydeploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: newkubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: newkubia
  template:
    metadata:
      name: newkubia
      labels:
        app: newkubia
    spec:
      containers:
      - image: xiaomotong888/newkubia:v1
        name: newkubia
复制代码

咱们创建一个 deployment
命名为 newkubia
副本数为 3 个
匹配的pod 标签是 newkubia
RS 控制的模板是创建出来的容器名为 newkubia
标签也是 newkubia

kubectl create -f mydeploy.yaml --record

现在我们通过上述指令来创建一个 Deployment，和其他资源一样，Deployment 我们可以缩写为 deploy

此处的 --record 是什么意思呢？带上这个参数 deploy 会记录我们历史版本

当然，我们也可以使用如下指令来查看 deploy 的状态

kubectl rollout status deploy newkubia

当然对于 kubectl describe , edit , get 都是适用于 deploy 的

我们可以在来看看，是不是创建了一个 RS

上面的这些 pod 其实也都是这个 RS 来创建出来的我们通过 RS 和 pod 的名字就可以辨别出来

上述例子中：

RS：

newkubia-6597db5b9c

pod：

newkubia-6597db5b9c-*

这个随机字符串，实际上是 Deployment 和 RS 中的 pod 模板放在一起计算出来的哈希值

我们将第一个例子用到的 Service 标签修改为 newkubia，进入任意一个 pod ，访问一下服务地址，看看效果

如我们所期望的，也是我们想要的效果

使用 Deployment 的方式升级应用

对于使用 Deployment 升级应用，我们需要知道 Deployment 涉及 2 个升级策略：

RollingUpdate

滚动升级，这个策略会渐进式的删除旧的 pod，同时创建新的 pod，整个过程，都保持咱们的服务是可用的，deploy 升级默认是使用这种策略

Recreate

会一次性删除掉旧的 pod ，然后创建新的 pod，这种策略和之前我们说到过的方式，效果上咱们的服务会中断一段时间，这个时间具体是多久，就看你的手速了

为了我们在升级 deploy 的时候，能够肉眼看出升级过程，我们将最小的准备时间设置大一点，这样我们可以看得清楚一些，

可以 kubectl edit deploy newkubia ，在 deploy spec 下面添加 minReadySeconds: 10 ，保存即可

当然 k8s 还提供另外一个 patch 的方式来简单修改 yaml 中的少许字段：

kubectl patch deploy newkubia -p '{"spec":{"minReadySeconds":10}}'

通过图中的效果，我们确实清晰可以看到 pod 是在滚动升级的，效果是先创建了一个新版本的 pod，运行正常后，会杀掉一个旧的 pod，再创建一个新版本的 pod，最终直到滚动升级 ok

我们还是进入到任意容器内，访问 SVC ，查看效果如何

可以看到，正常访问到的 SVC ，响应的 v2 版本，再次说明咱们升级是成功的

整个过程中，我们没有手动设置过 Deployment 的升级策略，前面有说到过默认是 RollingUpdate ，我们可以查看一下咱创建的 deploy 的详情

整个升级过程中，我们就执行了一条 deploy 升级命令，是不是超级简单，不需要自己手动去增删 RS，也不需要去修改 Service 管控的标签， Deployment 一键帮助我们完成，是不是很高效

说一说回滚

咱们不仅只会升级，若升级的程序有啥问题，那么岂不是还需要再次升级一个旧的版本？

如何升级呢？还是和刚才升级的方式一致吗？当然不是

咱们升级那么简单，回滚也是可以那么简单

回滚的话，我们可以直接执行：

kubectl rollout undo deploy newkubia

查看 deploy 执行过程状态
kubectl rollout status deploy newkubia
复制代码

回滚成功，我们来检查一下 rs 和 pod ，这里可以注意下 pod 的名字和 RS 的名字的特征

那么如何指定版本回滚呢？

指定版本回滚也是可以滴，咱们可以通过如下指令查看 deploy 管理升级记录（有升级记录，是因为我们最开始创建 deploy 的时候，指定了 --record）

kubectl rollout history deploy newkubia
复制代码

指定版本回滚

kubectl rollout undo deploy newkubia --to-revision=xx
复制代码

指定版本回滚也是回滚成功了，这里我们可以继续和上述方式一样检查 rs 和 pod 的特征，然后再进入到 pod 中，访问 Service 的地址，看看效果是否是我们期望的

看到这里，会不会有这些疑问呢？

为什么我们升级 v2 版本之后之前的 RS 还在？
为什么 deploy 会有升级记录？

这里来统一分享一下理解：

deploy 会有升级记录，是因为我们在创建 deploy 的时候，指定了 --record，因此 deploy 在升级版本的时候会记录信息

升级新的版本之后，就的 RS 还在，这个就不难理解了，这个是为了我们回滚或者跳转到指定版本的时候，能够直接使用原有的 RS，底层去修改副本数就可以了

整个过程的管理方式是这样的：

deploy 管理多个 RS，RS 管理多个 pod

deploy 管理多个版本 RS ，我们可以理解为是这样的：

一开始 deploy 管理着 1 个 RS1，RS1 管理着多个 pod：v1

当我们进行升级 v2 版本的时候，deploy 便会创建 RS2，并且 RS2 管理着 Pod：v2，RS1 仍然继续保留

当我们进行回滚的时候，也是类似的，但是不会创建新的 RS，会直接使用我们要回滚的版本对应的 RS，例如回滚到 v1 版本

今天就到这里，学习所得，若有偏差，还请斧正

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是小魔童哪吒，欢迎点赞关注收藏，下次见~