contour

Contour是开源的Kubernetes入口控制器，
为Envoy边缘和服务代理提供控制平面.
Contour支持动态配置更新和多团队入口委托，同时保持轻量级配置文件。

特点

内置envoy

Contour是基于Envoy，高性能L7代理和负载均衡器的控制平面

灵活的架构

轮廓可以部署为Kubernetes部署或守护程序集

TLS证书授权

管理员可以安全地委派通配符证书访问

架构原理

Envoy，提供高性能的反向代理。
Contour，充当Envoy的管理服务器并为其提供配置。

部署

kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

HTTPProxy

除了支持原生的ingres规则外，因为ingress-nginx 注解很驳杂，不利于使用，
contour还抽象了HTTPProxy概念，

HTTPProxy的主要优势

安全地支持多团队Kubernetes集群，并具有限制哪些命名空间可以配置虚拟主机和TLS凭据的能力。
允许包括来自另一个HTTPProxy（可能在另一个命名空间中）的路径或域的路由配置。
在一条路由中接受多种服务，并在它们之间负载均衡流量。
本机允许定义服务加权和负载平衡策略而无需注释。
在创建时验证HTTPProxy对象，并为创建后的有效性进行状态报告。

如下ingress配置

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:name: basic
spec:rules:- host: foo-basic.bar.comhttp:paths:- backend:serviceName: s1servicePort: 80

可以用以下httpproxy规则表示

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: basic
spec:virtualhost:fqdn: foo-basic.bar.comroutes:- conditions:- prefix: /services:- name: s1port: 80protocol: h2c

如果要支持gprc等http2流量只需要设置 spec.routes[].conditions.services[].protocol

多上游配置

contour支持多上游配置，方便的实现多版本流量控制

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: weight-shiftingnamespace: default
spec:virtualhost:fqdn: weights.bar.comroutes:- services:- name: s1port: 80weight: 10- name: s2port: 80weight: 90

请求和响应头策略

服务或路由还支持操作标头。可以按照以下步骤设置标头或从请求或响应中删除标头

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: header-manipulationnamespace: default
spec:virtualhost:fqdn: headers.bar.comroutes:- services:- name: s1port: 80requestHeadersPolicy:set:- name: X-Foovalue: barremove:- X-BazresponseHeadersPolicy:set:- name: X-Service-Namevalue: s1remove:- X-Internal-Secret

流量镜像

每个路由都可以将服务指定为镜像。镜像服务将接收发送到任何非镜像服务的读取流量的副本。镜像流量被视为只读，镜像的任何响应都将被丢弃。

该服务对于记录流量以供以后重播或对新部署进行冒烟测试很有用。

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: traffic-mirrornamespace: default
spec:virtualhost:fqdn: www.example.comroutes:- conditions:- prefix: /services:- name: wwwport: 80- name: www-mirrorport: 80mirror: true

响应超时

可以将每个路由配置为具有超时策略和重试策略，如下所示：

# httpproxy-response-timeout.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: response-timeoutnamespace: default
spec:virtualhost:fqdn: timeout.bar.comroutes:- timeoutPolicy:response: 1sidle: 10sretryPolicy:count: 3perTryTimeout: 150msservices:- name: s1port: 80

负载均衡策略

支持以下负载均衡算法

可供选择的选项：

RoundRobin：按循环顺序选择每个正常的上游端点（如果未选择，则为默认策略）。
WeightedLeastRequest：最少请求策略使用O（1）算法，该算法选择两个随机的健康端点，并选择活动请求较少的端点。注意：此算法非常简单，足以进行负载测试。如果需要真正的加权最小请求行为，则不应使用它。
Random：随机策略选择随机的健康端点。

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: lb-strategynamespace: default
spec:virtualhost:fqdn: strategy.bar.comroutes:- conditions:- prefix: /services:- name: s1-strategyport: 80- name: s2-strategyport: 80loadBalancerPolicy:strategy: WeightedLeastRequest

会话亲和

会话亲缘关系（也称为粘性会话）是一种负载平衡策略，通过该策略，
来自单个客户端的一系列请求将始终路由到同一应用程序后端。
Contour支持基于的每个路由的会话相似性loadBalancerPolicy strategy: Cookie。

# httpproxy-sticky-sessions.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:name: httpbinnamespace: default
spec:virtualhost:fqdn: httpbin.davecheney.comroutes:- services:- name: httpbinport: 8080loadBalancerPolicy:strategy: Cookie

还有其他的一些功能，详见httpproxy说明

跨集群流量管理gimbal

通过gimbal可以实现夸集群的流量统一管理，
通过监视单个Kubernetes群集的可用服务和端点并将它们同步到主机Gimbal群集中来实现此目的。 Discoverer将利用Kubernetes API的监视功能来动态接收更改，而不必轮询API。
所有可用的服务和端点都将同步到与源系统匹配的相同名称空间。发现者将仅负责一次监视单个集群。如果需要监视多个集群，则将需要部署多个发现者。

安装

# Sample secret creation
$ kubectl create secret generic remote-discover-kubecfg --from-file=./config --from-literal=backend-name=nodek8s -n gimbal-discovery

总结

contour 做为envoy的控制平面，可以动态下发各种流量管理策略，其实现的功能都是较为常用的功能保证了envoy的高性能
，可以轻松实现一个分布式gateway，但是对于部分功能例如限流，并没有进行支持，在使用中我们自行实现了这部分功能.

扫描关注我:

基于envoy的分布式网关-contour相关推荐

网易数帆基于 Envoy 的云原生网关实践
本文根据 InfoQ 公开课<如何基于开源Envoy,构建高性能云原生微服务网关>整理,有删减. 简介:Envoy 是由 Lyft 开源的高性能网络代理软件.相比于 Nginx.HAPro ...
网易基于 Envoy 的云原生网关实践
简介:Envoy 是由 Lyft 开源的高性能网络代理软件.相比于 Nginx.HAProxy 等经典代理软件,Envoy 具备丰富的可观察性和灵活的可扩展性,并且引入了基于 xDS API 的动态配 ...
搭建gloo网关（基于envoy）的wasm实验环境（阿里云、本机）
背景 WebAssembly是一种可以将多种语言编译成目标字节码,并在相应的wasm虚拟机中运行的技术. 在service mesh中,通常使用envoy作为proxy sidecar.而envoy是 ...
vxlan 分布式网关数据包转发过程_Vxlan基础
一.为什么需要Vxlan 普通的VLAN数量只有4096个,无法满足大规模云计算IDC的需求,而IDC为何需求那么多VLAN呢,因为目前大部分IDC内部结构主要分为两种L2,L3.L2结构里面,所有的 ...
无capwap隧道的分布式网关实现思路
什么是无线漫游? 无线漫游是指终端在不同AP覆盖范围之间移动且保持用户业务不中断的行为. 实现WLAN漫游的两个AP必须使用相同的SSID和安全模板(安全模板名称可以不同,但是安全模板下的配置必须相同 ...
基于canoe 新建一个lin工程_基于CANoe的高性能网关测试系统的构建
< 工业控制计算机 > 2010 年第 23 卷第 8 期进行整车电气系统架构设计时 , 由于动力系统 Powertrain 与车身系统 Comfort 在控制要求上的不同 , 通常将整 ...
基于Netty的分布式聊天系统
基于Netty的分布式聊天系统 Gitee地址:https://gitee.com/yuyuuyuy/micro-mall 文章目录基于Netty的分布式聊天系统前言一.IM系统架构的探讨二. ...
etcd 笔记（08）— 基于 etcd 实现分布式锁
1. 为什么需要分布式锁? 在分布式环境下,数据一致性问题一直是个难点.分布式与单机环境最大的不同在于它不是多线程而是多进程.由于多线程可以共享堆内存,因此可以简单地采取内存作为标记存储位置.而多进程 ...
rabbitmq 查询版本_基于rabbitmq解决分布式事务
分布式事务要解决的问题是保证二个数据库数据的一致性,本地事务ACID属于刚性事务,基于CAP理论,分布式事务的核心要点柔性事务,最终一致性. 基于rabbitmq解决分布式事务要点如下生产者采用发送 ...

基于envoy的分布式网关-contour