Kubernetes in Action笔记 - (12) Deployment

Dec 27, 2020 kubernetes
分享到:

文章目录

Deployment是一种更高阶资源, 用于部署应用程序并以声明的方式升级应用。

在使用 Deployment 时, 实际的 pod是由 Deployment 的 Replicaset 创建和管理的, 而不是由 Deployment 直接创建和管理的。

在升级应用过程中，部署新版本的应用时，会创建新的Replicaset用于管理版本的pod。升级过程中的某个时刻，就会存在新旧两个版本的Replicaset。因此，需要引入Deployment来协调。

与Replicaset类似，Deployment也是由标签选择器、期望副数和pod模板组成的。此外,它还包含另一个字段，用于指定一 个部署策略，表示在修改Deployment资源时应该如何执行更新。

创建Deployment

 1appVersion: apps/v1beta1
 2kind: Deployment 
 3metadata:
 4  name: kubia
 5spec:
 6  replicas: 3
 7  template:
 8    metadata:
 9    name: kubia
10    labels:
11      app: kubia
12    spec:
13      containers:
14      - image: luksa/kubia:vl
15        name: nodejs

创建一个Deployment

1# 确保在创建时使用了 --record 选项。 这个选项会记录历史版本号, 在之后的操作中非常有用
2kubectl create -f kubia-deployment-v1.yaml --record

查看 Deployment 的详细信息

1kubectl get deployment
2
3kubectl describe de­ployment

查看部署状态

1 kubectl rollout status deployment kubia

升级deployment

只需修改 Deployment 资源中定义的 pod 模板, k8s 会自动将实际的系统状态收敛为资源中定义的状态

不同的 Deployment 升级策略：

  • RollingUpdate：执行滚动更新，默认值。如果应用能够支持多个版本同时对外提供服务, 则推荐使用这个策略来升级应用
  • Recreate：一次性删除所有旧版本的 pod, 然后创建新的 pod。如果应用程序不支持多个版本同时对外提供服务, 需要在启动新版本之前完全停用旧版本, 那么需要使用这种策略。但是会导致应用程序出现短暂的不可用。

下面是修改 Deployment 或其他资源的不同方式。这些方式在操作 Deployment 资源时效果都是一样的。 它们无非就是修改Deployment 的规格定义, 修改后会触发滚动升级过程。

方法 作用
kubectl edit 使用默认编辑器打开资源配置。修改保存并退出编辑器, 资源对象会被更新。例子: kubectl edit deployment kubia
kubectl patch 修改单个资源属性。例子: kubectl patch deployment kubia -p' {"spec": {"template": {"spec": {"containers": [ {"name": "nodejs", "image": "luksa/kubia:v2"}]}}}}'
kubectl apply 通过一个完整的YAML或JSON文件,应用其中新的值来修改对象。如果YAML/JSON中指定的对象不存在,则会被创建。该文件需要包含资源的完整定义(不能像kubectl patch那样只包含想要更新的字段)。例子 : kubectl apply -f kubia-deployment-v2.yaml
kubectl replace 将原有对象替换为YAML/JSON文件中定义的新对象。与apply命令相反, 运行这个命令前要求对象必须存在,否则会打印错误。例子: kubectl replace -f kubia-deployment-v2.yaml 。
kubectl setimage 修改Pod、ReplicationController、Deployment、DaemonSet、Job或ReplicaSet内的镜像。例子: kubectl set image deployment kubia nodejs=luksa/kubia:v2

回滚Deployment

取消最后一次部署的 Deployment

1kubectl rollout undo deployment kubia

undo 命令也可以在滚动升级过程中运行,并直接停止滚动升级。过程中已创建的 pod 会被删除并被老版本的 pod 替代。

使用kubectl rollout history显示升级的版本。注意：需要在创建 Deployment 时指定 --record 参数。如果不给定这个参数, 版本历史中的 CHANGE-CAUSE 这一栏会为空，这就很难辨别每次的版本做了哪些修改

1$ kubectl rollout history deployment kubia
2
3deployments "kubia"
4REVISION  CHANGE-CAUSE
52         kubectl set image deployment kubia nodejs=luksa/kubia:v2
63         kubectl set image deployment kubia nodejs=luksa/kubia:v3

回滚到一个特定的 Deployment 版本

1kubectl rollout undo deployment kubia --to-revision=l

可以通过指定 Deployment 的 revisionHistoryLimit 属性来限制历史版本数量。默认值是2，所以正常情况下在版本列表里只有当前版本和上一个版本

控制滚动升级速率

在 Deployment 的滚动升级期间,有两个属性会决定一次替换多少个pod: maxSurge 和 maxUnavailable。可以通过 Deployment 的 strategy 字段下rollingUpdate 的子属性来配置

1spec:
2  strategy:
3    rollingUpdate:
4      maxSurge: 1
5      maxunavailable: 0
6    type: RollingUpdate
属性 含义
maxSurge 决定了 Deployment 配置中期望的副本数之外,最多允许超出的 pod 实例的数量。默认值为 25% ,所以 pod 实例最多可以比期望数量多25%。如果期望副本数被设置为4，那么在滚动升级期间,不会运行超过 5 个 pod 实例。当把百分数转换成绝对值时, 会将数字四舍五入。这个值也可以不是百分数而是绝对值 ( 例如,可以允许最多多出一个或两个pod) 。
maxUnavailable 决定了在滚动升级期间，相对于期望副本数能够允许有多少 pod 实例处于不可用状态。默认值也是 25%, 所以可用 pod 实例的数量不能低于期望副本数的 75%。百分数转换成绝对值时这个数字也会四舍五入。如果期望副本数设置为 4，并且百分比为 25%。那么只能有一个pod 处于不可用状态。在整个发布过程中，总是保持至少有三个pod实例处于可用状态来提供服务。与 maxSurge 一样,也可以指定绝对值而不是百分比

暂停滚动升级

1kubectl rollout pause deployment kubia

恢复滚动升级

1kubectl rollout resume deployment kubia

阻止出错版本的滚动升级

Deployment的minReadySeconds属性指定新创建的pod至少要成功运行多久之后, 才能将其视为可用。在pod可用之前, 滚动升级的过程不会继续。

如果一个新的pod 运行出错, 并且在minReadySeconds时间内它的就绪探针出现了失败, 那么新版本的滚动升级将被阻止。

使用这个属性可以通过让k8s在pod就绪之后继续等待10秒, 然后继续执行滚动升级, 来减缓滚动升级的过程。通常情况下需要将minReadySeconds设置为 更高的值, 以确保pod在它们真正开始接收实际流量之后可以持续保持就绪状态。

图书资料：