1.什么是Deployment
2.Deployment的使用
3.Deployment的更新机制
4.Deployment的滚动更新实践
1.什么是DeploymentDeployment官方文档：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/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:3#创建3个副本集revisionHistoryLimit:3# 保留3个历史Deployment记录selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-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/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:strategy:type:RollingUpdate#策略为滚动更新rollingUpdate:maxUnavailable:0# 最大不可用两maxSurge:1#最大增量replicas:5selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:80
在以上文件中：
spec.strategy.type
RollingUpdate，策略为滚动更新（就如同金丝雀部署）
Recreate类型，该策略下将杀掉正在运行的Pod，然后创建新的。
spec.strategy.RollingUpdate.maxUnavailable：更新过程中Pod数量可以低于Pod期望副本的数量或百分比（默认25%）
spec.strategy.RollingUpdate.maxSurge：更新过程中Pod数量可以超过Pod期望副本的数量或百分比（默认25%）
版权声明：本文内容来自个人博客segmentfault:苏凌峰，遵循CC 4.0 BY-SA版权协议上原文接及本声明。本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行可。原文链接：https://segmentfault.com/a/1190000045033136如有涉及到侵权，请联系，将立即予以删除处理。在此特别鸣谢原作者的创作。此篇文章的所有版权归原作者所有，与本公众号无关，商业转载建议请联系原作者，非商业转载请注明出处。