客座文章最后由 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 资源的一个问题是它将以下内容组合成一个资源定义：
- Identity- 域名
- Authentication-TLS 证书
- 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/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: /mainsitesite-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 资源之前验证它们时。
咱们什么时候会在 Kubernetes 看到个新的 Ingress 资源？
很可能 – 永远不会有。
Kubernetes 的趋势是，扩大产生在 CRD（自定义资源定义）上 – 这是种动静办法，在 Kubernetes 的外围之外引入扩大。这意味着像 Contour 和 Istio 这样的我的项目将引入他们本人的 CRD，容许咱们定义流量 Ingress 和路由。因为这些起因，一个新的常见的 Ingress 定义不太可能被引入到 Kubernetes 的外围。
点击浏览网站原文。
CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月，隶属于 Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。