Kubernetes 1.19：流量入口和路由的未来

客座文章最初由eficode顾问Michael Vittrup Larsen在eficode博客上发表

https://www.eficode.com/blog/kubernetes-1-19-the-future-of-traffic-ingress-and-routing

Kubernetes社区正在放弃Ingress，并将重新设计流量路由，以更好地适应多团队和多角色。

Kubernetes 1.19和Ingress资源

在Kubernetes 1.19中，定义HTTP流量在Kubernetes中如何进入和路由的Ingress资源从beta升级为GA。当Ingress资源处于测试状态时，在引入主机名通配符的Kubernetes 1.18中可以看到些活动。我认为Kubernetes的流量接入和路由的未来发展将使用其他资源类型。我们在Kubernetes 1.18中看到的活动，以及在1.19中将Ingress升级到GA/v1，可以看作是在确定Ingress资源的设计之前解决最紧迫的问题。

固定的修订资源将只接收错误修复和向后兼容的修改，所以将来我们不太可能看到对Ingress资源的重大更改。在beta状态中花费的时间延长了，加上Ingress资源的广泛使用，也意味着它已经长时间处于defacto-GA状态，在不破坏向后兼容性的情况下无法显著改进。我们可以称之为“修复，（忘记）并向前看”--锁定设计，只解决前进中的bug，并为改进的设计创建新的资源类型。

Ingress资源的问题是，如果没有从当前设计的重大转变，设计就不是真正的“可进化的”。这意味着，如果我们想要创新从而显著改变Ingress资源，我们将需要创建种新的资源类型。从Kubernetes service API SIG和Gateway API正在进行的工作中，这一点也很明显。

https://github.com/kubernetes-sigs/service-apis

https://kubernetes-sigs.github.io/service-apis/concepts/

那么，Ingress资源的主要问题是什么？我们应该期望从Ingress资源类型的版本2中得到什么模型？Well，继续读下去……

Kubernetes Ingress资源

Kubernetes中的Ingress资源是公开基于HTTP的服务的正式方式。在过去的18个Kubernetes版本中，Ingress资源作为beta资源过着不确定的生活--是的，自从Kubernetes v1.1以来！作为beta API的时间很长，以及用于扩展和修改Ingress资源行为的特定于Ingress控件的注释的激增，都说明了Ingress资源的设计不如其他Kubernetes资源好。在下一节中，我们将描述Ingress资源的可伸缩性问题和解决方法。

角色分离

Ingress资源的一个问题是它将以下内容组合成一个资源定义：

1. Identity-域名
2. Authentication-TLS证书
3. Routing-将哪些URL路径路由到哪些Kubernetes服务

如果一个人管理个稍微复杂的站点，例如一个由多个独立团队管理的组件，我们在理想情况下希望将上述问题委托给不同的角色。例如：

• 安全/基础设施管理-管理域名和TLS证书
• 站点管理-管理路由到由单个团队管理的组件/应用程序
• 应用程序团队-管理路由到不同的应用程序版本，金丝雀（灰度发布），蓝/绿版本，等等。

假设我们有个站点example.com，它由两个组件组成，登录（login）和主站点（mainsite），每个组件由一个单独的团队管理。我们可以演示不同的角色和流量路由，如下图所示。蓝框说明一个角色，红框说明一个流量路由定义。路由定义使用URL路径或HTTP头作为选择器。

这里的“安全管理员”角色通过域名和TLS证书（可能还包括DNS，这超出了本描述的范围）管理站点标识。域名和TLS证书很少更改，对这个角色的访问应该受到严格限制。如果使用Let's Encrypt来管理证书，那么访问受限还意味着站点管理员或应用程序团队不能触发证书续订。这降低了达到Let's Encrypt证书速率限制的可能性，也就是说，不存在由于速率限制而无法获得TLS证书的风险。

https://letsencrypt.org/

“站点管理”角色定义了顶级的路由，例如路由到我们两个团队管理的两个应用程序。只有当我们从站点添加或删除应用程序时，此路由才会改变。

“应用程序团队”管理每个应用程序的子组件，包括测试部署。每个应用程序团队可以定义路由，例如测试实例来实现金丝雀，蓝/绿测试，等等。

在Kubernetes中，Ingress资源在单个对象中定义域名、TLS证书和到Kubernetes服务的路由。这样做的结果是，应用程序团队想要做的，例如金丝雀测试，将需要访问修改整个站点的全局Ingress资源。这对安全性和稳定性都有影响--最明显的是，在Ingress资源中引入语法错误将导致整个站点不可访问。

Kubernetes API SIG在Gateway API上的工作旨在支持这种多角色设置。虽然网关API的实现还不存在，但该API在很大程度上受到了Contour ingress控制器的API的启发。在下面的部分中，我们将向你展示如何使用Contour实现这个多角色设置，从而了解Kubernetes中可能出现的未来网关API。

使用Contour和Envoy实现多角色设置

Envoy是一个CNCF的毕业级代理项目，而Contour是一个建立在Envoy之上的Ingress控制器。Contour通过HTTPProxy对象扩展了Ingress资源的概念，允许将一个HTTPProxy对象委托给另一个HTTPProxy对象。换句话说，它允许我们使用多个Kubernetes命名空间中的多个HTTPProxy资源来定义流量路由，并且可以访问受不同角色限制的命名空间。如下所示。

如果没有些YAML，关于Kubernetes的描述是不完整的，因此让我们查看实现上面的YAML。首先是定义站点标识的顶级HTTPProxy：

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: example-com-root
  namespace: security-admin-only
spec:
  virtualhost:
    fqdn: example.com
  tls:
    secretName: example-com-cert
  includes:
  - name: site-fanout
    namespace: site-admin-only

在security-admin-only命名空间中的example-com-root HTTPProxy资源通过域名和TLS证书定义了站点标识，并委托进一步路由到site-admin-only命名空间中的site-fanout HTTPProxy资源：

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: site-fanout
  namespace: site-admin-only
spec:
  includes:
  - name: login
    namespace: login
    conditions:
    - prefix: /login
  - name: mainsite
    namespace: mainsite
    conditions:
    - prefix: /mainsite

site-fanout HTTPProxy资源定义了/login路径下的任何内容的路由到login命名空间中的login HTTPProxy资源。管理登录应用程序的团队有login命名空间的完全访问权，因此可以创建以下HTTPProxy资源来路由到他们也控制的Kubernetes服务：

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: login
  namespace: login
spec:
  routes:
  - conditions:
    - header:
        name: x-test
        contains: true
    services:
    - name: test-login-app-service
      port: 80
  - services:
    - name: login-app-service
      port: 80

当x-test HTTP头包含true（例如蓝色/绿色测试）时，login HTTPProxy资源定义路由到test-login-app-service Kubernetes服务，否则路由到login-app-service Kubernetes服务。

Rego和Conftest

显然，上面显示的命名空间应该被Kubernetes RBAC锁定，例如“login”团队只能在他们的login命名空间内创建HTTPProxy资源。但是，你可能想知道如何将root HTTPProxy资源（如上面的example-com-root）的创建限制为security-admin-only的命名空间。

通过使用OPA GateKeeper可以限制此类资源的创建。GateKeeper是个Kubernetes准入控制器，它接受使用Rego语言定义的策略。我已经创建了个基于Rego的测试示例，测试root HTTPProxy资源。该测试是套对GitOps CI很有用的测试的一部分，例如，当你想要在部署Kubernetes资源之前验证它们时。

https://github.com/MichaelVL/kubernetes-rego-tests/blob/master/policy/contour-http-proxy.rego

我们什么时候会在Kubernetes看到个新的Ingress资源？

很可能--永远不会有。

Kubernetes的趋势是，扩展发生在CRD（自定义资源定义）上--这是种动态方法，在Kubernetes的核心之外引入扩展。这意味着像Contour和Istio这样的项目将引入他们自己的CRD，允许我们定义流量Ingress和路由。由于这些原因，一个新的常见的Ingress定义不太可能被引入到Kubernetes的核心。

为你的团队预约公开或驻场的Kubernetes培训：

https://hubs.ly/H0y0qgv0