Contour 1.19 release: 我们需要的不仅仅是ingress，也许是gateway

Contour继续添加新功能，以帮助大家更好地管理集群中的ingress操作。我们的最新release版本Contour 1.9.0现在包括：

• 对外部授权的支持，从而可以根据授权服务器验证请求。
• CORS支持
• 支持提供用于TLS的客户端证书，以验证后端服务
• 迁移到v1自定义资源定义（CRD）。

外部授权的支持

现在，可以利用Contour的外部授权支持来授权对ingress资源的传入请求。现在，Contour启用了Envoy中的外部授权网络过滤器，该过滤器调用外部授权服务以检查传入请求是否被授权。如果网络过滤器认为该请求是未授权的，则连接将被关闭。

对这项新功能的支持依赖于名为ExtensionService的新自定义资源定义（CRD）。这个新的API描述了Envoy如何连接到外部授权服务器。

外部验证的事件顺序：

1. 将一个外部授权服务部署到您的群集：此服务与您的Auth Provider进行对话，并确定是否应授权该请求。
2. 创建ExtensionService CRD：此CRD允许在上一步中创建的外部授权服务可用，以便Contour可以使用该gRPC端点配置Envoy。
3. 创建HTTPProxy资源：ingress对象中的VirtualHost引用将虚拟主机链接到授权服务的ExternalService CRD。
4. 在每个客户请求中，Envoy都会向外部验证服务发送授权检查以确定授权。

CORS 支持

Contour的HTTPProxy API现在支持指定CORS策略，该策略配置了Envoy的CORS过滤器，以允许网络应用程序请求来自不同来源的资源。
CORS使用其他HTTP标头来告诉浏览器，使运行在一个起点上的Web应用程序可以访问来自其来源（域，协议或端口）不同的选定资源。

在此示例中，跨域请求将被允许用于任何域（请注意*值):

apiVersion: projectcontour.io/v1
kind: HTTPProxy
spec:
  virtualhost:
    fqdn: local.projectcontour.io
    corsPolicy:
        allowCredentials: true
        allowOrigin: 
          - "*" # allows any origin
        allowMethods:
          - GET
          - POST
          - OPTIONS
        allowHeaders: 
          - authorization
          - cache-control
        exposeHeaders: 
          - Content-Length
          - Content-Range
        maxAge: "10m" # preflight requests can be cached for 10 minutes. 
  routes:
    - conditions:
      - prefix: /
      services:
        - name: s1
          port: 80

支持提供用于TLS的客户端证书，以验证后端服务

Contour现在支持可选地指定Envoy应该提供给Kubernetes的Kubernetes secret，以作为TLS的客户端证书，以便上游服务可以验证来自Envoy的连接。

v1 CRD

现在，Contour生成v1自定义资源定义（CRD）作为其示例YAML的一部分。这使Contour可以充分利用v1 API的功能，包括验证，默认设置，通过kubectl解释的API文档等。一年多以前，在Kubernetes 1.16中普遍提供了CRD。
此更改将Contour的最低支持Kubernetes版本提高到1.16。

总结

1：Contour的最低支持Kubernetes版本提高到1.16 。在万物皆可CRD的今天，operator 盛行的时代。大家需要尽快升级自己的Kubernetes到1.16，可以想象以后越来越多的开源operator都会支持1.16+以上的k8s。

2：Contour 最新版本支持了cors和外部认证，加上已经支持的熔断，重试，超时等服务治理策略。可以想象到，其后续版本会支持限流等gateway具备的功能。

我们需要的不仅仅是ingress，也许是gateway。