我们很高兴地宣布发布适用于 Kubernetes 的 NGINX Ingress Controller 1.5.0。这是我们在 Kubernetes 平台上开发受支持的 Ingress 负载均衡解决方案的一个里程碑，这些平台包括 Amazon Elastic Container Service for Kubernetes (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)、Red Hat OpenShift、IBM Cloud Private、Diamanti 等。
版本 1.5.0 包括：
- 使用 NGINX 自定义资源的新配置方法可以轻松定义入口策略
- 其他指标，由简化的 Prometheus 导出器提供
- 简化复杂 TLS 部署的配置
- 支持使用ExternalName 服务对到外部服务的流量进行负载平衡
- 专用的 Helm 图表存储库
我们的 GitHub 存储库中提供了 1.5.0 版的完整变更日志，包括错误修复、改进和更改。
什么是 Kubernetes 的 NGINX 入口控制器？
适用于 Kubernetes 的 NGINX Ingress Controller 是一个守护进程，在 Kubernetes 环境中与 NGINX Open Source 或 NGINX Plus 实例一起运行。该守护进程监视 Ingress 资源和 NGINX 自定义资源，以发现需要入口负载平衡的服务请求。然后，守护进程会自动配置 NGINX 或 NGINX Plus，以将流量路由到这些服务并对其进行负载平衡。
多个 NGINX Ingress 控制器实现可用。官方 NGINX 实现具有高性能、生产就绪性，并且适合长期部署。我们专注于提供跨版本的稳定性，以及可以在企业规模部署的功能。我们为 NGINX Plus 订阅者提供全面的技术支持，无需支付额外费用，NGINX 开源用户也能从我们对稳定性和可支持性的关注中受益。
1.5.0 版本中的新配置方法
Ingress 资源是在 Kubernetes 1.1 中引入的。此 API 对象提供了一种对简单负载均衡配置进行建模、指定 TLS 和 HTTP 终止参数以及根据请求的主机标头和路径配置到 Kubernetes 服务的路由的方法。
Ingress 资源的限制
在使用基于 Ingress 资源的配置时，我们遇到了这种简单方法的局限性。我们使用注释和 ConfigMap 扩展了 Ingress 资源，以解决其他 NGINX 功能，甚至允许用户在其 Ingress 资源中使用片段逐字嵌入 NGINX 配置。这使得 NGINX Ingress Controller 能够解决更多用例，包括请求重写、身份验证、速率限制以及 TCP 和 UDP 负载平衡。
以这种方式扩展 Ingress 资源有其自身的局限性。注释和 ConfigMap 不是 Ingress 资源规范的一部分。没有类型安全（配置验证），并且对于不同的服务使用具有不同参数的相同注释功能具有挑战性。
最终结果是配置 NGINX Ingress Controller 比我们想要的更难，并且只能可靠地支持 NGINX 用例的一小部分。
此外，Kubernetes 的大规模企业部署需要基于 RBAC 的自助配置方式。标准 Ingress 资源没有提供足够细粒度的关注点分离。我们已经通过可合并的 Ingress 资源成功解决了这个问题，我们希望在新的配置方法中借鉴这一经验。
新方法
在版本 1.5.0 中，我们正在预览一种配置入口策略的新方法。我们利用 Kubernetes API 可以使用自定义资源进行扩展的优势。这些资源看起来和感觉就像内置的 Kubernetes 资源，并提供类似的功能用户体验。使用自定义资源，我们正在尝试一种新的配置方法，以实现以下目标：
- 支持 NGINX 支持的各种真实用例
- 避免依赖注释；相反，所有功能都必须是规范的一部分
- 遵循 Kubernetes API 风格，使用户获得与使用 Ingress 资源相同或接近的体验
- 以可扩展且可预测的方式支持 RBAC 和自助服务用例
版本 1.5.0 中的配置方法（使用自定义资源）是我们未来方向的预览。当我们开发下一个版本 (1.6.0) 时，我们欢迎反馈、批评和改进此方法的建议。一旦我们对可靠的配置架构感到满意，我们就会锁定它，并将其视为稳定且完全可投入生产的。
我们还将继续支持现有的 NGINX Ingress 资源ce 与自定义资源并行，并且没有计划弃用它。我们非常清楚，NGINX Ingress Controller 的许多用户希望继续使用广泛的第三方和用户创建的工具来管理 Ingress 资源。但是，我们不会基于注释向 Ingress 资源引入任何主要的新功能。
NGINX Ingress Controller 1.5.0 功能详细信息
NGINX 自定义资源
您可以使用两个新的自定义资源配置 NGINX Ingress Controller：
- VirtualServer 资源在概念上与 Ingress 资源类似。它定义侦听虚拟服务器，包括其 TLS 参数。它还定义了这些服务器使用的上游以及选择这些上游的路由。它还可以将上游和路由委托给 VirtualServerRoute 资源。
- VirtualServerRoute 资源是 VirtualServer 资源的子集，仅包含 upstr团队和路线定义。它可以驻留在与引用它的 VirtualServer 不同的命名空间中。
有关完整的技术详细信息，请参阅我们的 GitHub 存储库中的文档。
委托、自助服务配置
在简单配置中，您可以使用<VirtualServer 资源来定义整个负载平衡配置。
当您在多角色或自助服务环境中操作时，您可以使用 VirtualServerRoute 资源的委派功能。例如，管理员 RBAC 用户可以定义面向外部的 VirtualServer，然后以安全且托管的 RBAC 方式将命名路由委托给其他角色，从而授予应用程序团队角色配置上游服务、操作蓝绿和金丝雀部署的权限，并应用复杂的路线。
下面是一个简单的配置示例，它侦听 Cafe.example.com 并将与 /tea 匹配的请求转发到 tea-svc Kubernetes 服务。
虚拟服务器
api版本：k8s.nginx.org/v1alpha1
种类：虚拟服务器
元数据：
名称： 咖啡馆
命名空间：cafe-ns
规格：
主机：cafe.example.com
上游：
– 名称：茶
服务：茶服务
端口：80
路线：
– 路径：/茶
上游：茶叶
– 路径：/咖啡
路线: 咖啡-ns/coffee
观察 /coffee 路径被委托给一个名为 Coffee 的单独 VirtualServer，该虚拟服务器位于 Coffee-ns 命名空间中。
虚拟服务器路由
api版本：k8s.nginx.org/v1alpha1
种类：虚拟服务器路由
元数据：
名称： 咖啡
命名空间：coffee-ns
规格：
主机：cafe.example.com
上游：
– 名称：拿铁
服务：拿铁-svc
端口：80
– 名称：浓缩咖啡
服务：espresso-svc
端口：80
子路线：
– 路径：/咖啡/拿铁
上游：拿铁
– 路径：/咖啡/浓缩咖啡
上游：浓缩咖啡
对coffee-ns命名空间具有RBAC访问权限的用户可以在路径http://coffee.example.com/coffee/中定义子路由，但无法编辑VirtualServer para仪表，例如 TLS 或 URL 空间的任何其他部分。
使用自定义资源实现更复杂的路由
Ingress 资源的一个常见挑战是它在匹配请求和选择上游服务方面提供的灵活性有限。在NGINX自定义资源中，我们提供了更丰富的方式将请求路由到上游。
路由（在 VirtualServer 资源中）和子路由（在 VirtualServerRoute 资源中）包含路径规范列表。然后，与路径匹配的请求将由该路径的路由策略处理：
- upstream: service-name – 所有与路径匹配的请求都会转发到指定的上游。
- route：namespace/vsroute – 与该路径匹配的所有请求都将委托给指定的 VirtualServerRoute。路由策略只能在 VirtualServer 中使用。
- splits：加权上游列表 – 请求根据权重分布在多个上游，类似于 fashion 到 NGINX 的 split_clients 模块。这对于简单的 A/B 测试用例非常有用。
- rules: 规则列表 – 对于复杂的基于内容的路由，规则政策包含条件列表 – 您要选择的值 – 以及匹配列表 – 您要匹配才能使用的值匹配的上游。
GitHub 托管的文档更详细地描述了这些路由策略。路由策略可以满足以下用例：
- API 版本控制 – 将 /api/v1 和 /api/v2 的请求路由到不同的上游服务
- A/B 测试 – 根据统计划分或请求参数选择流量，然后将其分配到不同的上游服务
- 调试路由 – 将流量路由到当前生产上游服务，但使用特定参数 (?debug=1)、cookie、源 IP 地址路由请求sses，或调试上游服务的标头
- 蓝绿部署 – 自动执行 A/B 测试和调试路由用例，以部署金丝雀（绿色）服务实例，将一部分流量路由到该实例，监控其行为，然后将流量从蓝色（生产）切换到）到绿色（新）
未来的增强功能
新的 NGINX 自定义资源是我们未来配置结构的预览，并且将成为我们添加新功能的基础。速率限制、身份验证、健康检查、会话持久性和其他功能都是未来实现的候选功能。
如果您想留下反馈，请在我们的 GitHub 存储库中提出问题。
请注意，我们将继续支持 Kubernetes Ingress 资源，但不打算引入任何基于注释的主要新功能。
改进的 Prometheus 支持
新指标
版本 1.5.0 提供了额外的功能衡量 NGINX Ingress Controller 如何配置 NGINX 的指标：
- NGINX 重新加载成功和失败的次数
- 上次重新加载的状态以及自重新加载以来经过的时间
- 构成 NGINX 配置的 Ingress 资源数量
这些指标可以帮助揭示 NGINX Ingress Controller 运行中的问题。例如，重新加载不成功表明 NGINX 配置无效；过于频繁的重新加载可能会导致 NGINX 性能下降。
简化安装
以前，Prometheus 指标由导出程序进程公开，该进程作为 NGINX Ingress Controller Pod 中的 sidecar 容器运行。从版本 1.5.0 开始，此功能已完全集成到 NGINX Ingress Controller 进程中，因此不再需要 sidecar 容器。这简化了安装并降低了 NGINX Ingress Controller 的资源利用率。
启用普罗米修斯指标，使用新的 -enable-prometheus-metrics 命令行标志启动 NGINX Ingress Controller。
更简单地共享通配符证书
如果您使用通配符证书 (*.example.com) 托管多个 TLS 服务（foo.example.com、bar.example.com），则版本 1.5.0 可以让您更轻松、更安全地发布该证书和密钥.
以前，您必须在每个 Ingress 资源中命名通配符证书密钥，并将其提供给每个需要它的命名空间。在某些环境中，这很不方便，甚至被视为安全风险。
在版本 1.5.0 中，您可以选择在 NGINX Ingress Controller 启动时在命令行定义默认 TLS 密钥。任何需要 TLS 证书但未指定 TLS 密钥的 Ingress 资源都会使用默认的 TLS 密钥。当不同命名空间中的多个 Ingress 资源需要使用相同的 TLS 密钥的情况下，此功能非常有用。
这简化了配置并减少了多用户自助服务环境中敏感数据的暴露。有关更多信息，请参阅我们的 GitHub 存储库中的示例。
支持ExternalName服务
NGINX Plus Ingress Controller 1.5.0 版本可以将请求路由到ExternalName 类型的服务。外部名称服务由 DNS 名称定义，该名称通常解析为集群外部的 IP 地址。这使得 NGINX Plus Ingress Controller 能够将请求负载均衡到集群外部的目的地。
对ExternalName服务的支持使您可以更轻松地将服务迁移到Kubernetes集群中。您可以在 Kubernetes 中运行 HTTP 负载均衡器 (NGINX Plus)，然后将流量路由到集群中的服务以及尚未移至集群的服务。
此功能仅在 NGINX Plus Ingress 控制器时可用与 NGINX Plus 一起使用，因为它依赖于 NGINX Plus 的动态 DNS 解析功能。有关更多信息，请参阅我们的 GitHub 存储库中的示例。
通过 Helm Repo 提供 Helm Chart
Helm 正在成为在 Kubernetes 上打包应用程序的首选方式。 NGINX Plus Ingress Controller 版本 1.5.0 可通过我们的 Helm 存储库获取。
通过 Helm 安装 NGINX Ingress Controller 非常简单，如下所示：
$ helm repo 添加 nginx-stable https://helm.nginx.com/stable
$ helm 仓库更新
$ helm install nginx-stable/nginx-ingress –name 发布名称
有关更多信息，请参阅 NGINX Ingress Controller 的 Helm Chart 文档（也可以在 Helm Hub 上找到）。
要尝试使用 NGINX Plus 和 NGINX App Protect 的 NGINX Ingress Controller，请立即开始 30 天免费试用，或联系我们讨论您的使用案例。
要使用 NGINX Open Source 尝试 NGINX Ingress Controller，您可以获取发行版ce 代码，或从 DockerHub 下载预构建的容器。
发表回复