阿里云容器K8s入门训练营：阿里云容器服务Kubernetes版-应用与发布管理（一）
阿里云容器服务Kubernetes版-应用与发布管理（一）
内容介绍：
一、什么是发布
二、发布方案
三、容器服务kubernetes版本发布管理-灰度发布概念
四、灰度发布实现
五、应用实践案例
六、实验操作
我首先做一个自我介绍。大家好，我是阿里云的范群山老师，本次课程将带大家了解阿里云容器服务Kubernetes的应用与发布管理。在学完本课程之后，希望能够带大家了解到为什么要进行应用发布，它的背景是什么，然后去了解应用发布的方案，比如说蓝绿发布、红黑发布、滚动发布以及灰度发布。最后就是要熟悉我们阿里云容器服务Kubernetes版应用的发布与管理，即要能够知道使用阿里云的 ACK， ASK 进行一个应用发布与管理。
一、什么是发布
首先我们带大家了解什么是发布。听到发布还有发布会这些名词，直播间的同学们可能会联想到，比如乔布斯发布苹果 4S 的场景，还有我们阿里云在进行新品发布会的一些场景，这个图片上面也展示，而我们这里要给大家讲的发布，就是我们的应用上线，软件发布的一个场景。
实际上我们线上的项目最容易出现问题的时候，就是在发布的过程当中，如果将某个变化比较大的版本一次全部上线发布给用户，这个时候会很容易遇到生产事故，这样对用户的影响会非常的大，甚至有的时候需要紧急回滚到前一步的版本，因此在发布的时候我们可以采取一些措施来防止问题的扩散。
常见的发布方案有，比如蓝绿发布、滚动发布、灰度发布，还有红黑发布。
发布方案它其实是软件开发中的一个重要的概念，它则是一种软管理和执行软件发布的方案或者流程。
一般它会有这么几个方面，比如你要做版本控制，要对软件的代码还有一些文件进行版本管理，到时方便去回退或者修复还要做编译打包，将云代码编译成为一个可执行的二进制文件，然后将它打包成一个可以被发布的软件包，还要进行测试验证，要对这个软件进行多种各样的测试，最终能够保证它符合我们的预期。
再就是发布和发布部署，可以将软件包部署到目标的环境当中，而且还要确保软件是能够正常运行和正常提供服务的。如果一旦发布出现了问题，这个时候就要怎么样及时回滚到之前稳定的版本，说简单就比如你现在要升级你的个人电脑，然后你现在把你的这个 Windows 升级，升级之后发现你的很多软件不能使用，很多软件和当前的Windows 版本不能够兼容，于是你会怎么样？你会到这个 Windows 设置里面请求他回退到你上一个版本，我们在线上去发布应用，比如发布邮箱，发布一些什么这个软件的时候，我们也可以这样做，当新版本出了问题，我为了不影响业务，不让用户的体验感差，我们可以回退到之前的版本，当然这个只是处理的方式之一，还有其他的方式，也就是我们后面要给大家介绍的发布方案。
总的发布方案它的制定和执行是能够提高软件发布的效率和质量，而且能够更好的管理和维护好软件。
二、发布方案
红黑发布它与蓝绿发布比较类似，红黑发布也是通过两个集群完成软件版本的升级，比如当前提供服务的所有机器都是e，这个运行在红色的集群 a 当中的。当需要进行发布新版本的时候，他会先在云上面申请一个黑色的集群b，然后在 b 上面部署新版本的服务，等到 b 完全升级完成之后，一次性的将这个负载均衡上面的流量全部都指向b，然后把 a 集群从负载均衡的列表当中删除，然后释放集群 a 当中所有的机器，这样就完成一个版本的升级。
所以我们可以看到，与蓝绿发布相比红黑发布，它只不过是充分利用了云计算的弹性和伸缩的优势，从而获得了两个收益。第一个它是不是简化了整个的流程，第二个也避免了在升级的过程当中，由于只用了一半的服务器去提供服务，这样可能会导致系统过载的问题，这也从侧面体现出云计算的一个优势。
我们看第一个发布方案，蓝绿发布，它是指同时去运行两个版本的应用，比如我们在做蓝绿部署的时候，我们并不会把老版本停掉，而是直接部署一套新的版本，等新的版本运行起来后，我们再将流量切换到新的版本上面去。比如我们在发布前，我们在这个蓝色的系统上面进行测试，测试完成之后我们将流量切换到这个蓝色系统上面。
同时要观察蓝色系统它的一个运行状态，如果一旦运行出现了问题，我们是不是可以及时的切回到绿色的系统。
首先它是可以减少发布影响的时间，比如你现在某个网站要进行后端的升级，没有必要完全停掉服务，然后更新，且出现问题之后是可以及时去回切到老版本的。它的缺点就是它需要两倍的硬件资源，而且需要额外进行付费。
如果你采用的是微服务的架构很难，很难按照这种模式去进行迁移，而且还要求这一个蓝绿两套系统。如果是做数据库的迁移，如果上面还有没有完成的任务，你要进行迁移，是需要付出一定的成本的。
专业来说男女发布它实际上是采用两个分开的集群，然后对软件版本进行升级的一种方式，然后它的模型就分为一个 a 一个b。如果在没有新版本上线的情况下，它一般上这个集群运行的版本是一致的，而且可以同时对外提供服务，它的部署流程具体是这样的，就是它会首先从负载均衡器的列表当中删除掉集群a，然后将让这个集群 b 单独去提供服务，在集群 a 上面去部署一个新的版本。
接下来等到集群 a 全部升级完毕后，将这个负载均衡列表全部指向a，删除掉集群b，由 a 来单独去提供服务。在集群 b上面在部署完新版本后，再把它添向负载均衡的列表当中，这样就可以完成两个集群上所有机器的版本的升级。
滚动发布这个发布方案与之前是有一些明显区别的，比如它是要先取出一部分的服务器，然后让它停止服务，让它去执行更新，更新完成之后将它重新投入使用，这样周而复始，直到集群当中所有的实例都更新成新的版本。像这个图中他们所演示的就这样，他先取出一部分的机器执行，更新完成之后让流量流向更新完成的机器。
优点是它可以不需要准备两套完整的机器，这样可以节约资源。缺点就是回滚困难，流量全部流到了新的机器上面，如果出现问题，它是没有办法去实现一个快速的回滚的，而且这样一个一个的升级，一个一个的更新，它的耗的时间是比较长的。如果你现在 80% 的机器都完成更新，然后突然出现了重大的漏洞，这个时候再回滚，它会非常的耗时和困难，对业务也会有影响。
在部署的具体的流程就是先升级一个副本，然后副本做一个验证，在升级副本的时候你就流量就不要给他，当它升级完成之后，怎么样就让它再自动的加入到集群当中。
