在我们实际的业务，上线发布工作中，为了保障产品或者代码的可靠性以及可用性，都会考虑采用灰度发布策略，来实现业务的发布变更，在业务使用kubernetes云原生发布后，业务快速的故障切换以及更便捷的部署，大大提高了运维效率，下面介绍集中kubernetes 灰度发布工具及策略

      1，kubernetes自带灰度发布策略

      maxSurge: 指定升级期间存在得总Pod对象数量最多可超出期望值的个数，其值可以是0或者正整数，也可以是一个期望值的百分比，例如: 如果期望值为3，当前的属性值为1，则表示Pod对象的总数不能超过4个

      maxUnavailable: 升级期间正常可用的Pod副本数(包括新旧版本) 最多不低于期望值的个数，其值可以是0或者正整数，也可以是期望值的百分比：默认值为1，该值意味着如果期望值是3，则升级期间至少要有两个Pod对象处于正常提供服务的状态

      虽然kubernetes 自带了这两种灰度发布控制策略，但是仅仅是对Pod的不可用量进行了控制，并未对流量策略，以及自动化控制多个灰度发布步骤进行控制，所以并非能完全的满足现实中的业务灰度发布需求

      2，kubernetes 扩展灰度发布工具介绍

      kruise rollout

      对原生的Wodkload控制器以及用户定义的Application Yaml定义无需做任何修改，只需要自定义kruise rollout发布策略Yaml，对发布过程进行控制，保证原生资源的干净，一致

      采用旁路渐进式交付能力，即先创建资源新资源，再删除原有资源的方式

      易用性强，对用户而言，开箱即用，并且有很好的扩展性，支持自定义Workload，并对Nginx，Isito 等多种Traffice调度方式也有很好的支持

      支持的kubernetes 资源对象Deployment，StatefuSet，DaemonSet，OpenKruise资源对象CloneSet，Advanced StatefulSet，Advanced DaemonSet

      灰度发布方式：支持金丝雀发布，标准分批发布，A/B Testing

      Argo Rollout

      Argo Rollout是Kubernetes 控制器和一套Crd，它为Kubernetes提供了蓝绿发布，金丝雀发布，金丝雀分析，实验和渐进是交付功能，并且与ingress controller，利用其流量整形功能再更新期间将流量逐步转移到新版本，为云原生应用和服务实现自动化，基于Gitops 的逐步交付

      支持kubernetes 原生的deployment 滚动更新，并且通过就绪探针对了基本的安全保障

      灰度发布方式: 支持蓝绿更新策略，金丝雀更新策略，细粒度的，加权的流量转移，自动回滚，升级或判断，可定制的指标查询和业务kpi分析

      支持的kubernetes 资源对象，只支持Deployment

      非旁路式交付，采用完全托管的模式，并且不支持热插拔，即无法通过随时删除Agro Rollout Yaml 来恢复至原生的Kubernetes Deployment模式