作者回复: k8s默认支持的就是滚动发布(rolling update)，假设你有一个svc v1版本已经发布到k8s，svc v1假设有10个pod实例，那么下次你发布svc的v2新版本，在deployment yml文件中只需修改镜像版本，然后kubectl apply这yml文件，k8s就会自动进行滚动发布，将v2的pod实例陆续拉入，v1的pod实例陆续拉出，例如，k8s会先拉入2个v2的pod实例，然后拉出2个v1的pod实例，间隔一段时间，再拉入2个v2的pod实例，然后拉出2个v1的pod实例，间隔一段时间，依次类推，一直到v2的pod实例全部拉入，v1的pod实例全部拉出，这就是滚动发布的过程，每次拉入拉出的数量(maxSurge)是可以配置的，具体可参考k8s文档:https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

作者回复: 金丝雀是很好理解的，升级时候先上一台新版本去试水，这台新版本就是金丝雀，金丝雀没有问题，继续发全量新版本，同时下老版本；如果金丝雀有问题，则下金丝雀，取消升级。再升级还是这样做。 金丝雀源于过去矿工下矿井前，为防止一氧化碳等中毒，先放一个金丝雀下去试，用在发布上也是这个道理，先上一台新版本去试。

作者回复: 课程只是为了演示形象才用了“www-web-deployment-canary”这样一个名字，实际后面可以跟版本号，例如原来是www-web-v1.0，然后下一版是www-web-v1.1，再下一版www-web-v1.2，诸如此类。不管用哪种版本机制，上新版前都可以先上一个做金丝雀测试，而且这个版本号留着的话发布历史也很清晰。

作者回复: 采用金丝雀发布进行切换的时候，新老版本是要求同时并存一段时间的(老版本不能马上停掉，需要等一个周期时间，例如观察5分钟后下线，这样也是为了后面可以按需回滚)，切换以后，新的流量会到新版本，切换瞬间有些老的流量还是会连在老服务上，可以不受影响，等这些老流量下次再请求的的时候，就会被切到新版本服务上去。

作者回复: 蓝绿切换后，老版是继续留着一段时间，不是马上kill掉的，这样那些连着老版本的请求将继续得到处理，直到处理完毕，但是新的请求将不会再路由到老版本，而是都路由到新版本，所以蓝绿发布一般是安全的。

作者回复: Istio/ServiceMesh是K8s推荐的流量治理(或多版本控制)机制，这个机制的好处是可以做到应用无关，不足是运维门槛成本较高。 其它方案可以考虑软件方式实现，一般采用功能开关或A/B测试技术实现，这个机制需要侵入代码，但是灵活性更高，参考项目： https://github.com/checkr/flagr https://github.com/markphelps/flipt https://github.com/intuit/wasabi