50 K8S 之 Contour 控制器

作为 Contour 的数据平面，作用于 Kubernetes 集群级别的 Ingress 控制器时，Envoy 仅实现了工作在 Kubernetes 系统的前端，主要用于管控南北向的流量。

Contour 项目由 Contour 控制平面组件和 Envoy 数据平面组件组成，部署时需要由各自的控制器编排运行。Contour 提供的示例部署清单将所有资源部署在名称空间 projectcontour 中，控制平面组件由 Deployment 控制器编排，出于高可用考虑，该组件通常运行两个副本，它们通过 service/contour 为 Envoy 提供管理服务，而数据平面组件 Envoy 则由 DaemonSet 控制器编排运行在 Kubernetes 集群中的每个节点之上，它们通过 service/envoy 为客户端提供接入 Ingress 控制器的服务。

基于 Kubernetes 内置的 Ingress 发布服务时，底层使用的是 IngressNginx 还是 Contour 控制器并没有本质上的区别。但 Contour 提供的 CRD 资源类型 HTTPProxy 能够提供更为完整的路由功能集，大大丰富了 Ingress 的特性表现。

基于标头的流量匹配机制是指检测请求报文的特定头部是否存在，或者其值是否满足表述的条件，而后仅路由测试结果为 True 的请求报文，不能满足测试条件的报文将被忽略，它们可能会由后续的其他路由规则匹配后进行路由，或者由默认路由指定的后端予以服务。在 conditions 字段中的同一个列表项中同时指定的 header 和 prefix 之间是“与”关系，即报文必须同时满足两个条件，而不同列表项表达的筛选条件间为“与”关系，报文也需要同时满足其全部条件。

流量切分：HTTPProxy 支持在单个路由规则中同时指定多个后端服务，默认情况下，所有流量将以等量切分的方式平均分发到多个后端之上，每个后端内部再按照代理服务器配置的调度算法进行二级负载均衡。同时，HTTPProxy 也允许用户为每个后端服务使用 weight 字段指定一个特定流量百分比，从而将流量以指定的比例在不同的后端服务间进行分发。

基于标头的流量分割算是“基于请求内容”灰度部署的一种实现，而流量分割则是“基于流量比例”进行灰度部署的方式。与 Kubernetes 的 Deployment 控制器的滚动更新机制相比，HTTPProxy 允许用户按需指定要切分的流量比例，而非按照 Pod 数量来固定分割的方式。

流量镜像用于百分百地在两个服务间复制流量。在支持蓝绿部署的场景中，流量镜像常用于将当前服务上的真实流量引入到未发布的新版本上进行测试。但流量镜像工作于“只读”模式，因为其响应报文会被全部丢弃。

HTTPProxy 中的负载均衡策略是路由规则中的定义，每个路由规则都可以为其后端调用的服务按需指定最为合用的负载均衡机制。目前，HTTPProxy 暴露了 Envoy 在集群上支持的部分调度算法，主要有如下几个。

RoundRobin：按顺序轮询选择上游端点，此为默认策略。

WeightedLeastRequest：加权最少连接，但该算法仅随机选择两个健康的端点，并从中挑选出负载少的端点作为调度目标。

Random：从后端健康端点中随机挑选端点。

Cookie：粘性会话调度机制，把来自某客户端的所有请求始终调度给同一个后端端点。

HTTPProxy 仅支持当上游服务器响应以 5xx 状态码时重试，因此它所能够应对的错误场景有限，而 Envoy 能够支持更多的重试条件，这些条件或许在未来的 Contour 版本中能够得到支持。

Service 会对其关联的后端 Pod 经由 Endpoint 进行健康状态检测，而 Contour 的健康状态检测是在这各种检测之外，对 Service 关联的 Pod 对象又施加的一层自定义检测机制。