Contour 学习笔记（二）：使用级联功能实现蓝绿部署和金丝雀发布

上篇文章介绍了 Contour 分布式架构的工做原理，顺便简单介绍了下 IngressRoute 的使用方式。本文将探讨 IngressRoute 更高级的用法，其中级联功能是重点。

1. IngressRoute 大入门

上篇文章在 examples/example-workload 目录下建立了一个示例应用，咱们来回顾一下它的 IngressRoute 配置：

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
 labels:
 app: kuard
 name: kuard
 namespace: default
spec: 
 virtualhost:
 fqdn: kuard.local
 routes: 
 - match: /
 services: 
 - name: kuard
 port: 80
复制代码

• virtualhost : 该字段是 root IngressRoute，表示此域的顶级入口点。
• fqdn : 该字段指定了完整的域名，能够经过在 HTTP 请求头中指定 Host: 字段来访问该服务。

这是最简单是使用方法，看起来没什么特别的，咱们来稍做修改一下：

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
 labels:
 app: kuard
 name: kuard
 namespace: default
spec: 
 virtualhost:
 fqdn: kuard.local
 routes: 
 - match: /test
 services: 
 - name: kuard
 port: 80
复制代码

将 match: / 改成 match: /test，而后从新应用新规则。这时若是你访问 url kuard.local/test 是不通的，由于 kuard 服务自己并无 /test 这个路径，咱们能够强制将路径重写为 /：

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
 labels:
 app: kuard
 name: kuard
 namespace: default
spec: 
 virtualhost:
 fqdn: kuard.local
 routes: 
 - match: /test
 prefixRewrite: "/"
 services: 
 - name: kuard
 port: 80
复制代码

从新 apply 以后，再次访问 url kuard.local/test 就通了。

这里能够和标准的 ingress 对象对比一下，IngressRoute 的优点在于它能够分别对每一个路由设置 rewrite 规则，而 Nginx Ingress Controller 只能设置全局的 rewrite 规则，由于它用的是 annotations。虽然能够经过其余手段来实现，但相对来讲会比较麻烦。

2. 级联功能介绍

下面咱们来看看 IngressRoute 的级联功能，这是个很是有特点的功能，你能够经过级联多个路由规则，上层 IngressRoute 的配置被下层继承。例如，咱们能够将 url 路径 / 的路由规则级联到其余的 IngressRoute 中，其余的 IngressRoute 能够来自不一样的 namespace。

举个例子，咱们能够先建立一个这样的 IngressRoute：

$ cat > delegate-from-main.yaml <<EOF apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
 name: delegate-from-main
spec:
 routes:
 - match: /
 services:
 - name: kuard
 port: 80
EOF
复制代码

$ kubectl apply -f delegate-from-main.yaml

$ kubectl get ingressroute delegate-from-main -o jsonpath='{.status.currentStatus}'
orphaned
复制代码

该 IngressRoute 的状态为 orphaned，由于它没有包含一个合法的 fqdn。接下来须要建立一个 root IngressRoute 来和它进行级联：

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
 labels:
 app: kuard
 name: kuard
 namespace: default
spec: 
 virtualhost:
 fqdn: kuard.local
 routes: 
 - match: /
 delegate:
 name: delegate-from-main
 namespace: default
复制代码

这时若是再检查 IngressRoute delegate-from-main 的状态，就会发现它从 orphaned 状态变成了 valid 状态，kuard.local 也可以顺利访问。

了解了级联功能的用法以后，下面就来看看它的应用场景。

• **场景一：**可使用级联功能来作蓝绿部署和灰度发布，只须要在上层 IngressRoute 中稍做修改，切换到另外一个下层 IngressRoute，就能够切换流量的处理规则。
• **场景二：**管理员能够利用级联功能将部分 ingress 的权限放行到其余的 namespace 中，在这些 namespace 中，用户能够自由更新与 root IngressRoute 级联的相关的 IngressRoute。例如，若是管理员想防止其余用户配置非法的域名或路径，能够将该部分的配置权限放到 root IngressRoute 中，其余 namespace 中的下层 IngressRoute 中只能配置各自的路径相关信息。

接下来主要探讨场景一。

3. 蓝绿部署

蓝绿部署简单来说就是在生产环境中有两套系统：一套是正在提供服务的系统，标记为“绿色”；另外一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，而且正在运行的系统，只是系统版本和对外服务状况不一样。

最初，没有任何系统，没有蓝绿之分。

而后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。

后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统以外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

蓝色系统不对外提供服务，用来作啥？

用来作发布前测试，测试过程当中发现任何问题，能够直接在蓝色系统上修改，不干扰用户正在使用的系统。（注意，两套系统没有耦合的时候才能百分百保证不干扰）

蓝色系统通过反复的测试、修改、验证，肯定达到上线标准以后，直接将用户切换到蓝色系统：

切换后的一段时间内，依旧是蓝绿两套系统并存，可是用户访问的已是蓝色系统。这段时间内观察蓝色系统（新系统）工做状态，若是出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工做正常，不对外提供服务的绿色系统已经再也不须要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。 原先的绿色系统能够销毁，将资源释放出来，用于部署下一个蓝色系统。

经过 IngressRoute 的级联功能能够很方便地实现蓝绿部署策略，首先建立一个上层的 root IngressRoute（假设名为 root-blog），而后将域名 yangcs.net/blogs 的路由策略级联到下层的 IngressRoute（名为 blog）。咱们会同时部署”蓝色“版本和”绿色“版本的应用，此时只有”绿色“版本接收流量。

---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: root-blog
  namespace: root-ingressroute
spec:
  virtualhost:
    fqdn: yangcs.net
    tls:
      secretName: yangcs-net
  routes:
    - match: /blog
      delegate:
        name: blog
        namespace: marketing
---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: blog
  namespace: marketing
spec:
  routes:
    - match: /blog
      services:
        - name: green
          port: 80

---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: blog2
  namespace: marketing
spec:
  routes:
    - match: /blog
      services:
        - name: blue
          port: 80
复制代码

在对蓝色版本进行测试验证以后，就能够将用户切换到蓝色应用了：

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
 name: root-blog
 namespace: root-ingressroute
spec:
 virtualhost:
 fqdn: yangcs.net
 tls:
 secretName: yangcs-net
 routes:
 - match: /blog
 delegate:
 name: blog2
 namespace: marketing
复制代码

4. 金丝雀发布

金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。它和蓝绿有点像，可是它更加规避风险。你能够阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署，你能够在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它，能够最大限度的下降影响。

若是没有错误发生，把剩余的 V1 版本所有升级为 V2 版本。若是有错误发生，则直接回退到老版本，发布失败。下图示范了金丝雀部署：

其实金丝雀发布的名称来源于一个典故。在 17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体特别敏感，空气中哪怕有极其微量的瓦斯，金丝雀也会中止唱歌。当瓦斯含量超过必定限度时，人类毫无察觉，但金丝雀却会毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀做为”瓦斯检测指标“，以便在危险状况下紧急撤离。映射到这里就是先发布一小部分来试探总体是否可以正常运行，若是能正常运行则进行彻底部署的发布方式，目前仍然是很多成长型技术组织的主流发布方式。

IngressRoute 能够经过分配权重来实现金丝雀发布，和蓝绿部署同样，首先建立一个上层的 root IngressRoute（名为 root-blog），而后将域名 yangcs.net/blogs 的路由策略级联到下层的 IngressRoute（名为 blog）。在下层的 IngressRoute 中将流量按不一样权重转发到不一样的后端服务。

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
 name: blog
 namespace: marketing
spec:
 routes:
 - match: /blog
 services:
 - name: green
 port: 5
 - name: blue
 port: 95
复制代码

若是没有错误发生，就将 green 的权重调整为 100，blue 的权重调整为 0。至此就完成了金丝雀发布。

本文主要介绍了 IngressRoute 级联功能的用法，探讨了如何使用级联功能来实现蓝绿部署和金丝雀发布，后面的文章将会陆续探讨其余的流量治理功能。

5. 参考资料

• 蓝绿部署、金丝雀发布（灰度发布）、A/B测试的准肯定义

微信公众号

扫一扫下面的二维码关注微信公众号，在公众号中回复◉加群◉便可加入咱们的云原生交流群，和孙宏亮、张馆长、阳明等大佬一块儿探讨云原生技术