基于容器云平台灰度发布功能是如何设计实现的？

灰度发布通常是互联网类应用，快速迭代，以新版本逐步发布替换旧版本，以验证新版本是否存在重大缺陷，在新版本有问题的情况下可以快速回滚。
实现方式有多种，容器云平台层就是用同一个服务对应多个不同的容器实例，在发布新版本时，这些容器实例可以实现逐步的替换（服务名不变），就实现了灰度发布功能。
还有一种方法是通过流量负载分发，这种方式可以部署服务为多个版本，每个版本引流部分流量，需要有路由负载分发组件支持。
或者可以直接在容器云平台外部署API网关，在网关层实现路由分发，支持更多选择

灰度发布功能，服务网格能做，不过可能对现有的技术体系和服务管控有比较大的冲击，而且服务网格还不是真正的很成熟。
容器云能很快的创建应用的新版本服务实例，剩下的结合负载均衡器结合业务做流量分发管理就能实现灰度发布。
1.创建新的应用版本集群，老的应用版本并存，这样资源的使用要多不少，逐步扩大新版本的分发流量比例，并且逐步减少老应用版本实例数
2.采用滚动升级的方法，比如运行一个新应用版本实例，删除老的应用版本实例。逐步替换。

另外灰度发布是一个很复杂的体系工程，除了流量管理外，还涉及新旧版本存储数据如何平滑迁移以及如何回滚

我们目前并没有用istio来做灰度发布，主要是对于istio在生产环境使用还有一些顾虑。目前灰度发布的流量切换还是通过F5负载均衡实现。K8S层面可以申请两个命名空间，其中一个用于灰度版本的发布。一旦验证通过，在F5上做流量切换即可。F5的member添加和删除已经完全自动化，所以流量切换或者回切都会很方便。

灰度发布的方案其实有很多，关键在于使用的容器云平台的架构是怎样的， 比如：

1. 基于F5做灰度
2. 基于K8S Ingress controller 做灰度
3. 基于SpringCloud架构的ribbon组件做灰度
4. 基于Istio架构方案做灰度（采用sidecar对应用流量进行了转发，通过Pilot下发路由规则）
5. 自研基于Nginx方案做灰度
6. 基于Kubernetes SLB引流：更新客户端或DNS解析，将Kubernetes 集群SLB地址追加到客户端或DNS中，实现流量引入。（不推荐，引流成本高，回滚风险高）

istio k8的方案很完备
mesos的话可以通过拆分成两个应用实现灰度版本，通过服务发现和服务注册组件配合istio实现引流