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/v1kind: HTTPProxyspec:  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。