关于k8s:Contour-119-release-我们需要的不仅仅是ingress也许是gateway

3次阅读

共计 1637 个字符，预计需要花费 5 分钟才能阅读完成。

Contour 持续增加新性能，以帮忙大家更好地治理集群中的 ingress 操作。咱们的最新 release 版本 Contour 1.9.0 当初包含：

对外部受权的反对，从而能够依据受权服务器验证申请。
CORS 反对
反对提供用于 TLS 的客户端证书，以验证后端服务
迁徙到 v1 自定义资源定义（CRD）。

当初，能够利用 Contour 的内部受权反对来受权对 ingress 资源的传入申请。当初，Contour 启用了 Envoy 中的内部受权网络过滤器，该过滤器调用内部受权服务以查看传入申请是否被受权。如果网络过滤器认为该申请是未受权的，则连贯将被敞开。

对这项新性能的反对依赖于名为 ExtensionService 的新自定义资源定义（CRD）。这个新的 API 形容了 Envoy 如何连贯到内部受权服务器。

内部验证的事件程序：

将一个内部受权服务部署到您的群集：此服务与您的 Auth Provider 进行对话，并确定是否应受权该申请。
创立ExtensionService CRD：此 CRD 容许在上一步中创立的内部受权服务可用，以便 Contour 能够应用该 gRPC 端点配置 Envoy。
创立 HTTPProxy 资源：ingress 对象中的 VirtualHost 援用将虚拟主机链接到受权服务的ExternalService CRD。
在每个客户申请中，Envoy 都会向内部验证服务发送受权查看以确定受权。

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

Contour 当初反对可选地指定 Envoy 应该提供给 Kubernetes 的 Kubernetes secret，以作为 TLS 的客户端证书，以便上游服务能够验证来自 Envoy 的连贯。

当初，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 具备的性能。