系统学习K8s——工作负载之Deployment

1.什么是Deployment

2.Deployment的使用

3.Deployment的更新机制

4.Deployment的滚动更新实践

1.什么是Deployment
Deployment官方文档：Deployment官方文档

通过前面这篇文章，我们学习了pod。系统学习K8s——工作负载之Pod，里面提到过，我们一般不直接创建pod，而是用Deployment创建Pod，这样创建的Pod拥有自愈能力，Deployment自身还提供了一些滚动更新，自动扩缩容的能力。

• Deployment为Pods和ReplicaSets提供声明式更新的能力。
• Deployment部署的Pod有自恢复能力，但是Pod本身并没有自恢复能力。
• 我们负责编写Deployment的期望状态，而Deployment Controller(控制器) 更改实际状态，使其变为期望状态。
• 我们部署一个应用一般不写Pod，而是编写一个Deployment

2.Deployment的使用

我们尝试部署一个Deployment，可以把下面内容复制的linux，然后使用kubectl apply -f nginx.yaml 部署，也可以直接使用lens部署。

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 #创建3个副本集
  revisionHistoryLimit: 3 # 保留3个历史Deployment记录
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

部署成功

在以上文件中：

• 创建名为nginx-deployment（由metadata.name声明）的deployment。该名称将成为后续创建 ReplicaSet 和 Pod 的命名基础。
• 该deployment创建一个ReplicaSet，它创建三个Pod 副本（由spec.replicas 字段标明），这里是创建三个nginx。
• spec.selector字段所定义创建的ReplicaSet如何查找要管理的Pod。在这里，选择Pod模板中定义的标签（app: nginx）。
• spec.revisionHistoryLimit是一个可选字段，用来设定出回滚所要保留的旧ReplicaSet数量，这些会占用资源，默认情况下，保留10个。

更多详情字段，可见 编写 Deployment 规约

3.Deployment的更新机制

• 仅当Deployment Pod模板发生改变的时候，例如pod的容器镜像更新，标签内容更新等，才会触发Deployment上线。其他更新（pod的副本数更新等）不会触发上线，副本数的更新只会让pod数量增加或者减少。
• 上线原理：创建新的replicas，准备就绪后，替换旧的replicas。旧的replicas可能不会被删除，得看revisionHistoryLimit指定保留了几个版本。

更新一般分为两种方式，蓝绿部署和金丝雀部署。

蓝绿部署：

此种部署方式会先启动好所有新的服务，新的集群启动完毕之后，会一口气把所有旧服务的流量打到新集群上，然后旧的服务集群会一起下线。在此部署方式中，有两个环境（新版本环境和旧版本环境），通过切换路由或负载均衡器的方式，将用户的流量从旧环境切换到新环境，从而完成版本更新。

• 优点

  • 零停机：用户无感知
  • 高可用：即使出现问题，也可以立刻切换回稳定版本。

• 缺点

  • 资源占用：需要维护两套环境，资源要被占用一半。
  • 部署时间长，因为要等待新的环境完全启动完，时间是比较久的。

• 适用场景

  • 对系统稳定性要求高，不能容忍停机。
  • 需要有副本进行快速回滚。
  • 有足够的资源维护多个环境

金丝雀部署：
此部署是一种逐步将新版本的应用一个个上线，然后逐步将旧版本的应用一个个下线，观察在其生产环境的运行情况，逐步扩大新版本的范围。金丝雀部署通常通过负载均衡器服务网格来控制流量的分发，还要配合健康检查+优雅停机以保证对用户的影响最小化。

• 优点：

  • 节约资源：只需要维护一个环境。
  • 风险控制：逐步扩大范围，可以及时发现并解决版本问题。

• 缺点

  • 流量控制：需要精确地控制流量分发，以免影响用户扩。
  • 部署复杂：需要借助负载均衡器等来精确控制，部署过程复杂。

• 适用场景

  • 对新版本稳定有一定担忧，希望通过实际运行来验证的场景。
  • 拥有大量用户，需要谨慎控制更新影响的范围。

4.Deployment的滚动更新实践

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  strategy:
    type: RollingUpdate #策略为滚动更新
    rollingUpdate:
      maxUnavailable: 0 # 最大不可用两
      maxSurge: 1 #最大增量
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

在以上文件中：

• spec.strategy.type

  • RollingUpdate，策略为滚动更新（就如同金丝雀部署）
  • Recreate类型，该策略下将杀掉正在运行的Pod，然后创建新的。
• spec.strategy.RollingUpdate.maxUnavailable：更新过程中Pod数量可以低于Pod期望副本的数量或百分比（默认25%）
• spec.strategy.RollingUpdate.maxSurge：更新过程中Pod数量可以超过Pod期望副本的数量或百分比（默认25%）