客座文章最后由eficode参谋Michael Vittrup Larsen在eficode博客上发表

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正在进行的工作中，这一点也很显著。

那么，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证书的危险。

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

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

在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/v1kind: HTTPProxymetadata: name: example-com-root namespace: security-admin-onlyspec: 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/v1kind: HTTPProxymetadata: name: site-fanout namespace: site-admin-onlyspec: 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/v1kind: HTTPProxymetadata: name: login namespace: loginspec: 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资源之前验证它们时。

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

很可能--永远不会有。

Kubernetes的趋势是，扩大产生在CRD（自定义资源定义）上--这是种动静办法，在Kubernetes的外围之外引入扩大。这意味着像Contour和Istio这样的我的项目将引入他们本人的CRD，容许咱们定义流量Ingress和路由。因为这些起因，一个新的常见的Ingress定义不太可能被引入到Kubernetes的外围。

点击浏览网站原文。

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。