k8s 应用更新策略：灰度发布和蓝绿发布

• 生产环境如何实现蓝绿部署？

• 什么是蓝绿部署？

• 蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的、正在运行的系统，只是系统版本和对外服务情况不同。

• 开发新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
   

  

• 蓝色系统不对外提供服务，用来做什么呢？

• 用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。
  （注意，两套系统没有耦合的时候才能百分百保证不干扰）

• 蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统：

  

• 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
• 当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

• 蓝绿部署的优势和缺点

• 优点：
  1、更新过程无需停机，风险较少
  2、回滚方便，只需要更改路由或者切换 DNS 服务器，效率较高

• 缺点：
  1、成本较高，需要部署两套环境。如果新版本中基础服务出现问题，会瞬间影响全网用户；如果新版本有问题也会影响全网用户。
  2、需要部署两套机器，费用开销大
  3、在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险
  4、负载均衡器/反向代理/路由/DNS 处理不当，将导致流量没有切换过来情况出现

• 通过 k8s 实现线上业务的蓝绿部署

• Kubernetes 不支持内置的蓝绿部署。目前最好的方式是创建新的 deployment，然后更新应用程序的 service 以指向新的 deployment 部署的应用

• 创建绿色部署环境（旧的部署环境）

• 下面步骤在 k8s 的控制节点操作：
  # kubectl create ns blue-green
  # vim lv.yaml

  

  

  创建前端 service
  vim service_lanlv.yaml

  

  

• 创建蓝色环境(新的部署环境)
  vim lan.yaml

  

  

• 在浏览器访问 http://k8s-master 节点 ip:30062 显示如下：
  

• 修改 service_lanlv.yaml 配置文件，修改标签，让其匹配到蓝程序（升级之后的程序）

  

  

• 实验完成之后，把资源先删除，以免影响后面实验：
  kubectl delete -f lan.yaml
  kubectl delete -f lv.yaml
  kubectl delete -f service_lanlv.yaml

• 通过 k8s 实现滚动更新-滚动更新流程和策略

• 滚动更新简介

• 滚动更新是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式，一次滚动发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义），例如第一批 1 台，第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢

• 在 k8s 中实现滚动更新
• 首先看下 Deployment 资源对象的组成：
  kubectl explain deployment
  kubectl explain deployment.spec
  
   paused    #暂停，当更新的时候创建 pod 先暂停，不是立即更新
   revisionHistoryLimit     #保留的历史版本数，默认是 10 个
  strategy