基于envoy的分布式网关-contour

contour

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

特点

  • 内置envoy

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

  • 灵活的架构

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

  • TLS证书授权

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

架构原理

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

基于envoy的分布式网关-contour_第1张图片

部署

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.com
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80

可以用以下httpproxy规则表示

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

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

多上游配置

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

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: weight-shifting
  namespace: default
spec:
  virtualhost:
    fqdn: weights.bar.com
  routes:
    - services:
        - name: s1
          port: 80
          weight: 10
        - name: s2
          port: 80
          weight: 90

请求和响应头策略

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

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: header-manipulation
  namespace: default
spec:
  virtualhost:
    fqdn: headers.bar.com
  routes:
    - services:
        - name: s1
          port: 80
          requestHeadersPolicy:
            set:
              - name: X-Foo
                value: bar
            remove:
              - X-Baz
          responseHeadersPolicy:
            set:
              - name: X-Service-Name
                value: s1
            remove:
              - X-Internal-Secret

流量镜像

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

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

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: traffic-mirror
  namespace: default
spec:
  virtualhost:
    fqdn: www.example.com
  routes:
    - conditions:
      - prefix: /
      services:
        - name: www
          port: 80
        - name: www-mirror
          port: 80
          mirror: true

响应超时

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

# httpproxy-response-timeout.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: response-timeout
  namespace: default
spec:
  virtualhost:
    fqdn: timeout.bar.com
  routes:
  - timeoutPolicy:
      response: 1s
      idle: 10s
    retryPolicy:
      count: 3
      perTryTimeout: 150ms
    services:
    - name: s1
      port: 80

负载均衡策略

支持以下负载均衡算法

可供选择的选项:

  • RoundRobin:按循环顺序选择每个正常的上游端点(如果未选择,则为默认策略)。
  • WeightedLeastRequest:最少请求策略使用O(1)算法,该算法选择两个随机的健康端点,并选择活动请求较少的端点。注意:此算法非常简单,足以进行负载测试。如果需要真正的加权最小请求行为,则不应使用它。
  • Random:随机策略选择随机的健康端点。
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: lb-strategy
  namespace: default
spec:
  virtualhost:
    fqdn: strategy.bar.com
  routes:
    - conditions:
      - prefix: /
      services:
        - name: s1-strategy
          port: 80
        - name: s2-strategy
          port: 80
      loadBalancerPolicy:
        strategy: WeightedLeastRequest

会话亲和

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

# httpproxy-sticky-sessions.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: httpbin
  namespace: default
spec:
  virtualhost:
    fqdn: httpbin.davecheney.com
  routes:
  - services:
    - name: httpbin
      port: 8080
    loadBalancerPolicy:
      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_第2张图片

你可能感兴趣的:(the,way,to,kubernetes,servicemesh)