使用 NGINX Ingress Controller 增强 TCP/UDP 负载平衡和 WAF 配置

虽然标准 Kubernetes Ingress 资源非常适合配置和配置基本的 Ingress 负载均衡，但它不包含使Kubernetes 达到生产级所需的自定义功能。 相反，非 NGINX 用户只能使用注释、ConfigMap 和自定义模板，这些方法容易出错、难以使用、不安全，并且缺乏细粒度的范围界定。 NGINX Ingress 资源是我们解决这一问题的答案。

NGINX Ingress 资源适用于 NGINX 开源版本和基于 NGINX Plus的 NGINX Ingress Controller 版本。 它们提供本机的、类型安全的和缩进的配置样式，从而简化了 Ingress 负载均衡的实现。 在这篇博客中，我们重点介绍 NGINX Ingress Controller 1.11.0 中引入的两个功能，这些功能使配置 WAF 和负载均衡策略变得更加容易：

• TransportServer 资源– TransportServer 资源定义 TCP、UDP 和 TLS Passthrough 负载均衡的配置。 我们添加了健康检查、状态报告和配置片段以增强 TCP/UDP 负载均衡。
• NGINX Ingress WAF 策略– 当您使用 NGINX Ingress Controller 部署 NGINX App Protect 3.0 时，您可以利用 NGINX Ingress 资源将 WAF 策略应用于特定的 Kubernetes 服务。

TransportServer 资源的增强

NGINX Ingress Controller 1.11.0 在以下领域扩展了TransportServer (TS) 资源：

• 片段
• 健康检查
• 支持多种 TS 资源

笔记： 1.11.0 版本中 TransportServer 资源的新增功能是正在积极开发的技术预览版。 在未来的版本中，它们将逐渐达到稳定的、可用于生产的质量标准。

传输服务器片段

在NGINX Ingress Controller中，我们引入了 VirtualServer 和 VirtualServerRoute（VS 和 VSR）资源的配置片段，使您能够为基于 HTTP 的客户端原生扩展 NGINX Ingress 配置。 1.11.0 版本引入了 TS 资源的片段，因此您可以轻松利用 NGINX 和 NGINX Plus 的全部功能来提供基于 TCP/UDP 的服务。 例如，您可以使用代码片段添加拒绝和允许指令，这些指令使用 IP 地址和范围来定义哪些客户端可以访问服务

api版本：k8s.nginx.org/v1alpha1kind： 传输服务器
元数据：
名称：cafe
规范：
主机：cafe.example.com
服务器片段：|
拒绝 192.168.1.1；
允许 192.168.1.0/24；
上游：
- 名称：tea
服务：tea-svc
端口： 80

健康检查

为了监控 Kubernetes 集群的运行状况，NGINX Ingress Controller 不仅考虑应用pod 本地的Kubernetes 探测，还会密切关注基于 TCP/UDP 的上游服务之间的网络状态，使用被动运行状况检查来评估正在进行的事务的运行状况，并使用主动运行状况检查（NGINX Plus 独有）定期使用合成连接请求探测端点。

健康检查对于断路和处理应用错误非常有用。 您可以使用 TS 资源的healthCheck字段中的参数自定义健康检查，这些参数设置探测之间的间隔、探测超时、探测之间的延迟时间等。

此外，您还可以从 NGINX Ingress Controller 设置健康探测的上游服务和端口目标。 这在以下情况下很有用：上游应用的运行状况由另一个进程或子系统在不同的侦听器上公开，该进程或子系统监视应用的多个下游组件。

使用ingressClassName支持多个 TransportServer 资源

当您更新和应用 TS 资源时，验证配置是否有效以及是否成功应用于相应的 Ingress Controller 部署很有用。 1.11.0 版本引入了 TS 资源的ingressClassName字段和状态报告。 ingressClassName字段确保在具有多个部署的环境中，TS 资源由特定的 Ingress Controller 部署处理。

要显示一个或所有 TS 资源的状态，请运行kubectl get transportserver命令；输出包括状态（ Valid或Invalid ）、最近更新的原因以及（对于单个 TS）自定义消息。

$ kubectl get transportserver NAME STATE REASON AGE dns-tcp Valid AddedOrUpdated 47m $ kubectl describe transportserver dns-tcp ... . . .
地位：
  信息：  已添加或更新 default/dns-tcp 的配置原因：   添加或更新状态：    有效的

如果多个 TS 资源争夺同一个主机/侦听器，NGINX Ingress Controller 将选择具有最旧时间戳的 TS 资源，以确保在这种情况下获得确定的结果。

使用本机 NGINX App Protect 支持定义 WAF 策略

NGINX Ingress 资源不仅使配置更容易、更灵活，还使您能够将流量控制委托给不同的团队，并对拥有应用子路由的用户施加更严格的权限限制，如 VirtualServerRoute (VSR) 资源中所定义。 通过向合适的团队授予对合适的 Kubernetes 资源的访问权限，NGINX Ingress 资源可让您对网络资源进行细粒度的控制，并减少用户受到攻击或黑客攻击时对应用的潜在损害。

版本 1.11.0 引入了原生 Web应用防火墙 (WAF)策略对象，将这些优势扩展到 Kubernetes 部署中 NGINX App Protect 的配置。 该策略利用了1.8.0 版本中引入的APLogConf和APPolicy对象，并且可以附加到 VirtualServer (VS) 和 VSR 资源。 这意味着安全管理员可以拥有具有 VS 资源的整个 Ingress 配置范围，同时通过引用 VSR 资源将安全责任委托给其他团队。

在以下示例中， waf-prod策略应用于路由到webapp-prod上游的用户。 为了在不同团队拥有的命名空间之间委托/v2路由的安全责任，突出显示的路由指令引用了 VSR 资源。

api版本：k8s.nginx.org/v1kind： VirtualServer 元数据：名称：webapp 规范：主机：webapp.example.com 策略：-名称：waf-prod tls：秘密：app-secret 上游：-名称：webapp-prod 服务：webapp-svc 端口： 80 条路线： - 路径：/v2路线：test/test - 路径：/v1 操作：传递：webapp-prod

管理测试命名空间的团队可以使用该命名空间中的 VSR 资源设置自己的参数和 WAF 策略。

api版本：k8s.nginx.org/v1kind： VirtualServerRoute
元数据：
名称：测试
命名空间：测试
规范：
主机：webapp.example.com
上游：
-名称：webapp
服务：webapp-test-svc
端口： 80
子路由：
- 路径：/v2
策略：
- 名称：waf-test
操作：
传递：webapp

此示例按命名空间分离租户，并对测试命名空间中的webapp-test-svc服务应用不同的 WAF 策略。 它说明了如何将资源委托给不同的团队并用对象封装它们，从而简化新功能的测试而不中断生产中的应用。

1.11.0 版本中还有哪些新功能？

通过 NGINX Ingress Controller 1.11.0，我们继续致力于提供灵活、强大且易于使用的生产级 Ingress 控制器。 除了 WAF 和 TS 改进之外，版本 1.11.0 还包括以下增强功能：

• 验证更多注释——避免更多配置错误
• 策略状态信息– 在将策略对象应用到 Ingress 配置之前显示其状态
• Istio 兼容性– 在 Istio 环境中利用 NGINX Ingress Controller 的高级功能
• 上游端点的集群 IP 地址- 使用服务/集群 IP 地址填充 NGINX Ingress Controller 配置中的上游端点

验证更多注释

基于版本 1.10.0 中引入的注释验证改进，我们现在正在验证以下附加注释：

如果在应用 Ingress 资源时注释的值无效，则 Ingress Controller 将拒绝该资源并从 NGINX 中删除相应的配置。

政策状态信息

kubectl get policy命令现在报告策略的状态（有效或无效）和（对于单个 TS）自定义消息以及最近更新的原因。

$ kubectl get policy NAME STATE AGE webapp-policy 有效期 30 秒 $ kubectl describe policy webapp-policy . . .
地位：
  信息：  已添加或更新 default/webapp-policy 的配置原因：   添加或更新状态：    有效的

与 Istio 的兼容性

NGINX Ingress Controller 现在可以用作在 Istio 服务网格内运行的应用程序的 Ingress 控制器。 这使得用户可以继续使用 NGINX Ingress Controller 在基于 Istio 的环境中提供的高级功能，而无需采取变通方法。 这种整合涉及两个要求：

• 将 Istio sidecar 注入 NGINX Ingress Controller 部署
• 仅向后端发送一个 HTTP Host 标头

为了满足第一个要求，请在 NGINX Ingress 部署文件的注释字段中包含以下项目。

注释：traffic.sidecar.istio.io/includeInboundPorts：“” 
traffic.sidecar.istio.io/excludeInboundPorts： “80,443”         
  Traffic.sidecar.istio.io/excludeOutboundIPRanges： “10.90.0.0/16,10.45.0.0/16” sidecar.istio.io/inject：'true'

第二个要求是通过改变requestHeaders字段的行为来实现的。 在以前的版本中，使用以下配置将两个Host标头发送到后端： $host和指定值bar.example.com 。

api版本：k8s.nginx.org/v1kind： VirtualServer 元数据：名称：foo 规格：主机：foo.example.com 上游：- 名称：foo 端口： 8080 服务：backend-svc use-cluster-ip：true 路由：- 路径：“/” 操作：代理：上游：foo requestHeaders：设置：- 名称： 主机值：bar.example.com

在 1.11.0 及更高版本中，仅发送指定的值。 要发送$host ，请完全省略requestHeaders字段。

上游端点的集群 IP 地址

NGINX Ingress Controller 配置中的上游端点现在可以使用服务/集群 IP 地址填充，而不是 pod 端点的各个 IP 地址。 要启用 NGINX Ingress Controller 将流量路由到 Cluster‑IP 服务，请在 VS 或 VSR 配置的上游部分中包含use-cluster-ip: true字段：

上游：- 名称：tea 服务：tea-svc 端口： 80 use-cluster-ip：true - 名称：coffee 服务：coffee-svc 端口： 80使用集群 IP: true

资源

有关 1.11.0 版本的完整更新日志，请参阅发行说明。

要尝试使用 NGINX Plus 和 NGINX App Protect 的 NGINX Ingress Controller for Kubernetes，请立即开始30 天免费试用或联系我们讨论您的用例。

要使用 NGINX 开源尝试 NGINX Ingress Controller，您可以获取发布源代码，或从DockerHub下载预构建的容器。

有关 Ingress 控制器之间差异的讨论，请参阅我们博客上的“我正在使用哪个适用于 Kubernetes 的 NGINX Ingress 控制器？” 。