Deployment的管理与使用(6)

Posted 2023-04-21

参考技术A

介 绍 Deployment 相 关 概 念 ， 包 括 什 么 是 控 制 器 ， 如 何 创 建Deployment，什么是kubectl，如何进行deployment的扩容和升级等。 deployment是最常用的控制器。
 描述kubernetes中各种控制器
 创建和使用deployment
 使用kubectl命令行工具

注意：创建多个pod时候，1.先创建deployment。2.deployment自动创建RS。3.RS管理POD的副本数量。
不适用RS直接控制POD的原因在于，RS不仅可以控制POD的数量，还可以对POD版本进行升级和回退。

 Command：指定你希望进行的操作，如create，get，describe，delete等。
 TYPE：指定操作对象的类型，如deployment，RS，Pod等
通过 kubectl api-resources命令可以查看资源类型
 NAME：指定对象的名字
 Flags: 可选的标志位 （如 ： -o wide -n cube-system等）

示例：展示的deployment的创建，验证了会同事创建rs和pod

编辑一个yaml文件

命令

yaml文件
扩：修改/root/deploy.yaml, replicas: 3修改为 replicas: 5。重新apply
缩：修改/root/deploy.yaml, replicas: 5修改为 replicas: 2。重新apply

缩的动作时机就是杀pod的动作，可以设置执行缩（kill）的时间，比如30秒后进行缩的动作。保证存量进程可以在这段时间内继续执行。

将nginx的版本由1.7.9升级到1.8.1

利用yaml文件 :
deploy2.yaml 升级至 1.8.1 。
升级采取滚动升级的方式进行（down1个up1个，down第2个up第2个），从下面get rs 命令可以看到多出了一个nginx current是0的记录，该记录为原始的rs记录，数量已经变成了0，新版本以由新的nginx-deployment-59988f74c7替代。后面可利用在升级至1.9.1验证再一次的滚动操作。

deploy3.yaml 升级至 1.9.1

利用deploy3.yaml文件升级，验证再一次的滚动操作

查看升级历史,没有使用--record 所以没有记录信息(none)，可以通过--revision=编号进行查看。

回滚操作

删除deployment(控制器)
因为无法直接删除pod（删除后rs会自动重建），要想删除POD只能通过删除控制器（deployment）来实现（删除deployment引出删除rs进而删除容器）

应用编排与管理：Deployment

Deployment：管理部署发布的控制器
主要作用

• 定义一种pod的期望数量
• 配置pod发布方式
• 更新中发生问题，可以一键回滚

Deployment的yaml文件

一个 Deployment 中，哪些 labels/selector 必须一致：
deployment.Spec.Selector 与 deployment.Spec.Template.Labels 一致

• kubectl get deployment 命令可查看deployment总体情况
• kubectl get pod可以查看到部署的情况：Pod 的 ownerReferences 即 Pod 所属的 controller 资源，并不是 Deployment，而是一个 ReplicaSet。这个 ReplicaSet 的 name，其实是 nginx-deployment 加上 pod.template-hash，所有的 Pod 都是 ReplicaSet 创建出来的，而 ReplicaSet 它对应的某一个具体的 Deployment.template 版本。

更新镜像

• kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
• kubectl 后面有一个 set image 固定写法，这里指的是设定镜像；其次是一个 deployment.v1.apps，这里也是一个固定写法，表明要操作的资源类型，deployment 是资源名、v1 是资源版本、apps 是资源组，这里也可以简写为 deployment 或者 deployment.apps，比如说写为 deployment 的时候，默认将使用 apps 组 v1 版本。
• 更新的 deployment 的 name，nginx-deployment；再往后的 nginx 其实指的是 template，也就是 Pod 中的 container.name；这里我们可以注意到：一个 Pod 中，其实可能存在多个 container，需要指定想要更新的镜像的 container.name，就是 nginx。
  

快速回滚

• 回滚的时候，其实是创建了 3 个旧版本的 pod，而并非把先前的 3 个 pod 恢复。
• 发布会新建replicaSet，回滚不会

Deployment和ReplicaSet的关系

Deployment控制器

• 原理：所有的控制器都是通过 Informer 中的 Event 做一些 Handler 和 Watch。这个地方 Deployment 控制器，其实是关注 Deployment 和 ReplicaSet 中的 event，收到事件后会加入到队列中。而 Deployment controller 从队列中取出来之后，它的逻辑会判断 Check Paused，这个 Paused 其实是 Deployment 是否需要新的发布，如果 Paused 设置为 true 的话，就表示这个 Deployment 只会做一个数量上的维持，不会做新的发布。
  • Check paused 为 Yes 也就是 true 的话，那么只会做 Sync replicas。也就是说把 replicas sync 同步到对应的 ReplicaSet 中，最后再 Update Deployment status，那么 controller 这一次的 ReplicaSet 就结束了。
  • paused 为 false 的话，它就会做 Rollout，也就是通过 Create 或者是 Rolling 的方式来做更新，更新的方式其实也是通过 Create/Update/Delete 这种 ReplicaSet 来做实现的。

ReplicaSet控制器

• 当 Deployment 分配 ReplicaSet 之后，ReplicaSet 控制器本身也是从 Informer 中 watch 一些事件，这些事件包含了 ReplicaSet 和 Pod 的事件。从队列中取出之后，ReplicaSet controller 的逻辑很简单，就只管理副本数。也就是说如果 controller 发现 replicas 比 Pod 数量大的话，就会扩容，而如果发现实际数量超过期望数量的话，就会删除 Pod。

spec字段解析

• MinReadySeconds：Deployment 会根据 Pod ready 来看 Pod 是否可用，但是如果设置了 MinReadySeconds 之后，比如设置为 30 秒，那 Deployment 就一定会等到 Pod ready 超过 30 秒之后才认为 Pod 是 available 的。Pod available 的前提条件是 Pod ready，但是 ready 的 Pod 不一定是 available 的，它一定要超过 MinReadySeconds 之后，才会判断为 available；
• revisionHistoryLimit：保留历史 revision，即保留历史 ReplicaSet 的数量，默认值为 10 个。这里可以设置为一个或两个，如果回滚可能性比较大的话，可以设置数量超过 10；
• paused：paused 是标识，Deployment 只做数量维持，不做新的发布，这里在 Debug 场景可能会用到；
• progressDeadlineSeconds：前面提到当 Deployment 处于扩容或者发布状态时，它的 condition 会处于一个 processing 的状态，processing 可以设置一个超时时间。如果超过超时时间还处于 processing，那么 controller 将认为这个 Pod 会进入 failed 的状态。

升级策略字段

• Deployment 在 RollingUpdate 中主要提供了两个策略，一个是 MaxUnavailable，另一个是 MaxSurge。这两个字段解析的意思，可以看下图中详细的 comment，或者简单解释一下：

  • MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；
  • MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量。

• 比如当用户的资源足够，且更注重发布过程中的可用性，可设置 MaxUnavailable 较小、MaxSurge 较大。但如果用户的资源比较紧张，可以设置 MaxSurge 较小，甚至设置为 0，这里要注意的是 MaxSurge 和 MaxUnavailable 不能同时为 0。

  • 两者同时为 0 的话，MaxSurge 保证不能新扩 Pod，而 MaxUnavailable 不能保证 ReplicaSet 中有 Pod 是 available 的，这样就会产生问题。所以说这两个值不能同时为 0。用户可以根据自己的实际场景来设置对应的、合适的值。