集群中需要部署 Nginx Ingress 作为 Ingress Controller，并且对外暴露了统一的流量入口，参考 在 TKE 上部署 Nginx Ingress。
Nginx Ingress 可以用在哪些发布场景 ?使用 Nginx Ingress 来实现金丝雀发布，可以用在哪些场景呢？这个主要看使用什么策略进行流量切分，目前 Nginx Ingress 支持基于 Header、Cookie 和服务权重这 3 种流量切分的策略，基于它们可以实现以下两种发布场景。
场景一: 将新版本灰度给部分用户假设线上运行了一套对外提供 7 层服务的 Service A 服务，后来开发了个新版本 Service A' 想要上线，但又不想直接替换掉原来的 Service A，希望先灰度一小部分用户，等运行一段时间足够稳定了再逐渐全量上线新版本，最后平滑下线旧版本。这个时候就可以利用 Nginx Ingress 基于 Header 或 Cookie 进行流量切分的策略来发布，业务使用 Header 或 Cookie 来标识不同类型的用户，我们通过配置 Ingress 来实现让带有指定 Header 或 Cookie 的请求被转发到新版本，其它的仍然转发到旧版本，从而实现将新版本灰度给部分用户:
假设线上运行了一套对外提供 7 层服务的 Service B 服务，后来修复了一些问题，需要灰度上线一个新版本 Service B'，但又不想直接替换掉原来的 Service B，而是让先切 10% 的流量到新版本，等观察一段时间稳定后再逐渐加大新版本的流量比例直至完全替换旧版本，最后再滑下线旧版本，从而实现切一定比例的流量给新版本:
我们通过给 Ingress 资源指定 Nginx Ingress 所支持的一些 annotation 可以实现金丝雀发布，需要给服务创建两个 Ingress，一个正常的 Ingress，另一个是带 nginx.ingress.kubernetes.io/canary: "true" 这个固定的 annotation 的 Ingress，我们姑且称它为 Canary Ingress，一般代表新版本的服务，结合另外针对流量切分策略的 annotation 一起配置即可实现多种场景的金丝雀发布，以下对这些 annotation 详细介绍下:
nginx.ingress.kubernetes.io/canary-by-header: 表示如果请求头中包含这里指定的 header 名称，并且值为 always 的话，就将该请求转发给该 Ingress 定义的对应后端服务；如果值为 never 就不转发，可以用于回滚到旧版；如果是其它值则忽略该 annotation。
nginx.ingress.kubernetes.io/canary-by-header-value: 这个可以作为 canary-by-header的补充，允许指定请求头的值可以自定义成其它值，不再只能是 always 或 never；当请求头的值命中这里的自定义值时，请求将会转发给该 Ingress 定义的对应后端服务，如果是其它值则将会忽略该 annotation。
nginx.ingress.kubernetes.io/canary-by-header-pattern: 这个与上面的 canary-by-header-value 类似，唯一的区别是它是用正则表达式对来匹配请求头的值，而不是只固定某一个值；需要注意的是，如果它与 canary-by-header-value 同时存在，这个 annotation 将会被忽略。
nginx.ingress.kubernetes.io/canary-by-cookie: 这个与 canary-by-header 类似，只是这个用于 cookie，同样也是只支持 always 和 never 的值。
nginx.ingress.kubernetes.io/canary-weight: 表示 Canary Ingress 所分配流量的比例的百分比，取值范围 [0-100]，比如设置为 10，意思是分配 10% 的流量给 Canary Ingress 对应的后端服务。
上面的规则会按优先顺序进行评估，优先顺序如下： canary-by-header -> canary-by-cookie -> canary-weight
注意: 当 Ingress 被标记为 Canary Ingress 时，除了nginx.ingress.kubernetes.io/load-balance和 nginx.ingress.kubernetes.io/upstream-hash-by 之外，所有其他非 Canary 注释都将被忽略。
上手实践下面我们给出一些例子，让你快速上手 Nginx Ingress 的金丝雀发布，环境为 TKE 集群。
使用 YAML 创建资源本文的示例将使用 yaml 的方式部署工作负载和创建 Service，有两种操作方式。
方式一：在 TKE 或 EKS 控制台右上角点击 YAML 创建资源，然后将本文示例的 yaml 粘贴进去:
方式二：将示例的 yaml 保存成文件，然后使用 kubectl 指定 yaml 文件来创建，如: kubectl apply -f xx.yaml 。
部署两个版本的服务