NGINX Ingress Controller 版本 1.9.0

NGINX Ingress Controller 版本 1.9.0。此版本建立在 Kubernetes 平台（包括 Red Hat OpenShift、Amazon Elastic Container Service for Kubernetes (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE)、IBM Cloud Private、Diamanti 等）Ingress 负载均衡解决方案的持续开发基础之上。

版本 1.9.0 的推出充分彰显了我们致力于提供灵活、强大且易用的 Ingress Controller 的承诺，它 Controller 可以对 Kubernetes Ingress 资源和 NGINX Ingress 资源进行配置：

• Kubernetes Ingress 资源 提供了 Ingress Controller实施的极致兼容性，并且可使用注释和自定义模板进行扩展，以生成复杂配置。
• NGINX Ingress 资源 提供特定的 NGINX 配置方案，与自定义通用 Kubernetes Ingress 资源的方式相比更为丰富和安全。在版本 1.8.0 以及更高版本中，您可以使用代码段和自定义模板扩展 NGINX Ingress 资源，从而继续在 NGINX Ingress 资源中使用尚不支持的 NGINX 特性，例如高速缓存和 OIDC 身份验证。

版本 1.9.0 的主要增强和改进包括：

• 全新 WAF 功能  – NGINX App Protect 现在可支持更多 WAF 策略定义，包括 JSON 模式验证、用户定义的 URL 和用户定义的参数。有关 NGINX App Protect 与 NGINX Ingress Controller 相关集成的信息，请查看我们的博客。
• 更多策略  – 策略被定义为单独 Kubernetes 对象中的规则集，可应用于 Ingress 负载均衡器。可以将策略委派给不同的团队，并在执行完成后进行整合。版本 1.9.0 引入了三个附加策略：JWT 验证、速率限制和 mTLS 身份验证。
• 改善的可视性  – 此版本丰富了现有的 Ingress Controller指标，并添加了新指标，包括上游特定指标、重载原因、请求延迟和分发等。Grafana 仪表盘经过扩展，能够利用这些指标提供更多可视化功能。
• 服务网格集成 – NGINX Ingress Controller可以与新发布的 NGINX 服务网格 无缝集成，从而将在网格中运行的应用安全地交付给外部服务。

• 其他新增特性  –

  • 轻松处理主机冲突
  • Kubernetes Ingress v1 API 更新
  • 在标准Kubernetes环境中支持 NGINX Ingress Operator for OpenShift

什么是 NGINX Ingress Controller？

NGINX Ingress Controller for Kubernetes 是一个在 Kubernetes 环境中与 NGINX Open Source 或 NGINX Plus 实例一起运行的守护进程。该守护进程负责监视 Kubernetes Ingress 资源 和 NGINX Ingress 资源，以识别需要 Ingress 负载均衡的服务请求。一旦发现此类请求，它将自动配置 NGINX 或 NGINX Plus，从而将流量路由到这些服务并进行负载均衡。

现已推出多种 NGINX Ingress Controller实施 。正式的 NGINX 实施性能高，可随时投入生产，并且适合长期部署。我们旨在为各个版本提供出色的稳定性，以及可在全企业范围内部署的丰富特性。我们免费为 NGINX Plus 用户提供全方位支持，并致力于为 NGINX Open Source 用户提供出色的稳定性和可支持性。

NGINX Ingress Controller 1.9.0 有哪些新增特性？

三个新策略

我们在 NGINX Ingress Controller版本 1.8.0 中将策略 作为单独的 Kubernetes 对象引入，以便对流量管理功能进行抽象化。策略可以由不同的团队在多个位置进行定义和应用，这带来了诸多优势：封装和简化的配置、多租户、可重用性和可靠性。您只需在相应的 VirtualServer (VS) 或 VirtualServerRoute (VSR) 对象中引用策略名称即可将策略附加到应用上。这不仅为您提供了部署灵活性，甚至还支持您将策略应用到应用的特定区域。

（作为更新，VS 对象为域名定义了 Ingress 负载均衡配置。您可以将 VS 配置扩展到由子路组成的多个 VSR 中。）

我们在此版本中添加了三个新策略，为版本 1.8.0 中引入的基于 IP 地址的访问控制列表 (ACL) 策略提供了补充。新增的 JSON Web 令牌 (JWT) 验证和速率限制策略侧重于保护 Kubernetes 边界内的基础架构和应用资源，可确保它们既不会被非法用户滥用，也不会被合法用户超载。mTLS 策略支持在服务之间进行端到端加密，同时维持有效负载可视性，以便 Ingress Controller可以为应用请求和响应提供路由和安全性。

JSON Web 令牌验证策略

安全团队可能希望确保仅中央身份提供者授权的用户才能访问应用。他们可通过将 JWT 策略应用到 VS 和 VSR 资源来实现这一点。

第一步是创建一个 Kubernetes Policy 对象来定义 JWT 策略。以下示例策略明确要求 JWT 令牌必须来自 token HTTP 标头，并根据 Kubernetes Secret (jwk-secret) 进行验证，以确定客户端提供的令牌是否由中央身份提供者签发。

apiVersion: k8s.nginx.org/v1alpha1
kind: Policy
metadata:
  name: jwt-policy
spec:
  jwt:
    realm: MyProductAPI
    secret: jwk-secret
    token: $http_token

Policy 定义创建完成后，可通过引用 policies 字段下的策略名称将其应用于 VS 或 VSR 资源。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: jwt-policy
  upstreams:
  - name: webapp
    service: webapp-svc
    port: 80
  routes:
  - path: /
    action:
      pass: webapp

通过应用此 VS 对象，可以提供 JWT 身份验证，并确定客户端是否被授权访问 webapp 上游。此功能不仅支持身份验证，而且还支持单点登录 (SSO)——用户只需使用一组凭证登录一次即可使用多个应用。它还非常适合 Kubernetes 环境，因为在 Kubernetes 环境中应用是用语言和框架编写的，很难遵守安全组织规定的身份验证标准。通过在 Ingress Controller中配置身份验证，还可以免去开发人员在其应用中实施身份验证或解析 JWT 的负担。

值得注意的是，JWT 策略的默认行为是将 JWT 令牌传递到上游，这在每项服务都需要对请求者进行身份验证的零信任环境中非常有用。

借助版本 1.8.0 中针对 VS 和 VSR 引入的 标头修改功能，应用无需解析 JWT 即可访问 JWT 中的特定声明，并将声明作为请求标头转发到上游。这可确保应用不会在未经身份验证的用户上投入过多的计算资源，这对于共享计算平台（例如 Kubernetes）尤为重要。

速率限制策略

安全和可靠性团队通常希望通过将入站请求速率限制为真实用户的典型值来保护上游服务免遭 DDoS 和密码猜测攻击，并可以选择在将请求发送到上游应用之前对其进行排队。此外，他们可能希望设置一个状态码，以用于被拒绝和超载的请求响应中。

可以采用很多方法来识别用户特性来做限速，其中一种是通过源 IP 地址（使用 $binary_remote_addr 嵌入式变量）。在以下策略定义中，我们将每个唯一 IP 地址限制为每秒 10 个请求，并使用给拒绝超载的请求设置状态码 503 (Service Unavailable) 。如欲了解所有可用的速率限制选项，请查看我们的速率限制文档。

apiVersion: k8s.nginx.org/v1alpha1
kind: Policy 
metadata:
  name: rate-limit-policy
spec:
  rateLimit:
    rate: 10r/s
    key: ${binary_remote_addr}
    zoneSize: 10M
    rejectCode: 503

可以将速率限制策略应用于 VS 资源，以响应自定义错误页面或将用户重定向到另一个集群，从而在资源过载时有效地适应应用。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: webapp
spec:
  host: webapp.example.com
  policies:
  - name: rate-limit-policy
  upstreams:
  - name: webapp
    service: webapp-svc
    port: 80
  routes:
  - path: /
    errorPages:
    - codes: [503]
      redirect:
        code: 301
        url: https://cluster-domain-backup.com
    action:
      pass: webapp

mTLS 策略

要求严苛的安全团队需要确保 Ingress Controller可以依据配置的证书颁发机构 (CA) 的要求验证客户端和上游服务出示的证书。一旦双方（客户端和服务器）相互完成验证，它们之间便会建立加密连接。鉴于 Kubernetes 是一个多租户平台，管理员可配置额外的安全层，以确保在进行业务逻辑处理之前，仅将通过身份验证的客户端代理到可识别的上游服务。

我们将介绍两个共同实现双向 TLS (mTLS) 的策略：一个入站 mTLS 策略和一个出站 mTLS 策略。入站 mTLS 策略用于验证客户端提交的证书，出站 mTLS 策略用于验证上游服务出示的证书。这些策略可以配置不同的 CA ，并在仅需要客户端或服务器端验证的情况下，将其独立地应用于 VS 或 VSR 资源。

下面的示例显示了如何将这两个策略（入站和出站mTLS）应用于 VS 资源。我们定义了一个入站 mTLS 策略，用于根据Kubernetes Secret引用的 clientCertSecret 字段验证客户端证书，同时还定义了一个出站 mTLS 策略，用于依据受信任的 CA 的要求验证服务器证书时要使用的配置（TLS 密码和协议）。

apiVersion: k8s.nginx.org/v1alpha1
kind: Policy 
metadata:
  name: ingress-mtls-policy-cafe
spec:
  ingressMTLS:
    clientCertSecret: secret-name
--
apiVersion: k8s.nginx.org/v1alpha1
kind: Policy 
metadata:
  name: egress-mtls-policy-cafe
spec:
  egressMTLS:
    tlsSecret: tls-secret-name
    verifyServer: true
    trustedCertSecret: egress-trusted-ca-secret
    protocols: TLSv1.3

然后，我们可以将这两个策略应用到 VS 资源上，以配置 Ingress Controller上的 mTLS。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  ...  
  policies:
    -name: ingress-mtls-policy-cafe
    -name: egress-mtls-policy-cafe

在某些情况下，您可能希望在应用级别而非 Ingress Controller级别配置入站 mTLS。为此，您可以使用 optional_no_ca值填充策略的 verifyClient 字段，然后通过将 VS 或 VSR 资源的 requestHeader 字段设置为包含客户端副本的 $ssl_client_escaped_cert 变量，将证书作为标头传递给应用。如欲了解更多详细信息，请查看文档。

改善的可视性

版本 1.9.0 引入了几个新的 Ingress Controller指标，并对现有指标进行了丰富，所有这些指标可以帮助您了解应用和用户的行为。为了更好地了解指标之间的相互关系，我们还添加了新的 Grafana 仪表盘。

有关 Prometheus 指标的 Kubernetes 上下文

导出到 Prometheus 的上游特定 Ingress Controller指标现在使用相应的 Kubernetes 服务名称、Pod 和 Ingress 资源名称进行注释。通过将性能与 Kubernetes 对象相关联，可以简化应用的故障排除过程。例如，发现与性能不佳的上游组对应的 Pod（就每秒请求数而言）可以帮助您找到根本原因或采取纠正措施并删除 Pod。

我们在此处展示了 Prometheus 中 nginx_ingress_controller_upstream_server_response_latency_ms_count 指标上的注释示例。

重新加载原因

借助 NGINX Plus Ingress Controller，后端服务端点无需重新加载NGINX Plus 配置，即可进行更改。借助 NGINX Open Source Ingress Controller，端点更改需要重新加载配置，因此我们现在报告重新加载的原因，并对重新加载进行持续跟踪。 nginx_ingress_controller_nginx_reloads_total 指标报告由于端点更改和其他原因导致的重载次数。您可以使用此信息来计算由于端点更改而导致的重载百分比，从而帮助您确定在高度动态的 Kubernetes 环境中，频繁的端点更改触发的配置重新加载是否会引起性能问题。

下表显示了与重新加载相对应的两个注释。红线代表由端点更改触发的配置重新加载次数，绿线代表其他原因导致的重新加载次数。

Worker 进程详情

每当 Ingress Controller发生配置重新加载时，就会生成一组新的 NGINX worker 进程，并且之前的 worker 进程会继续运行，直到与它们绑定的所有连接都终止。尽管这种正常的重新加载不会中断应用流量，但这也意味着以前的 worker 进程在退出之前会继续消耗资源。因此，频繁重新加载配置会导致资源匮乏和停机。

为了帮助您有效地管理此限制，我们提供了一个内置指标，可显示在任何给定时间正在运行的 worker 进程数量。有了这个指标，您便可以在做决定停止配置更改或从头重建 Ingress Controller措施时，做出适当的措施。

以下是nginx_ingress_controller_nginx_worker_processes_total 指标的 Prometheus Plot。红线表示当前的 worker 进程数，绿线表示重新加载后仍在运行的之前的 worker 进程数。

请求延迟和分发

Ingress Controller现在可报告每个上游应用的请求延迟。该指标将延迟分布到存储桶中，可帮助您更好地了解应用的性能和用户体验。

在 Prometheus 中，该指标被称为 nginx_ingress_controller_upstream_server_response_latency_ms_bucket 。

请注意，Ingress Controller如要将此指标提供给 Prometheus，必须在命令行中包含–enable-latency-metric 标志。如欲了解详细信息，请查看文档。

Grafana 仪表盘

版本 1.9.0 添加了几个可利用所有可用指标的 Grafana 仪表盘，大大增强了可视化功能。该仪表盘还可识别与指标相关的 Kubernetes 对象。

该仪表盘不仅提供有关应用的洞察，并且还可以帮助您快速确定不良行为，以简化故障排除过程并支持您迅速采取适当行动。

服务网格集成

DevOps 团队需要使用 Ingress Controller 将服务网格中的应用连接到集群外部的服务。Ingress Controller 可以与新发布的 NGINX 服务网格(NSM) 无缝集成，特别是外部服务有关的入站和出站 mTLS 功能。

对于入站 mTLS，Ingress Controller可通过从 CA 接收网格证书和密钥来参与网格 TLS。对于出站 mTLS，可以将 Ingress Controller 配置为充当网格的出站端点，以便 NSM 控制的服务可与不属于网格的外部服务安全地进行通信。

其他新增特性

优雅地处理主机冲突

可以为同一主机创建标准 Kubernetes Ingress 资源和 NGINX VirtualServer 资源。以前，这种情况下的行为是不确定的。对于引用相同主机的相同输入清单，可能会基于管理员无法控制的情况而使用不同的 NGINX 数据平面配置。更不幸的是，在发生冲突时没有错误提醒或警告。

如果发生多个资源争用同一主机的情况，版本 1.9.0 会通过选择“最老”的资源来优雅地处理主机冲突。换句话说，如果向已经拥有清单的主机提交清单，则第二个清单将被拒绝，并且 Events 和 Status这两个描述被拒绝资源的字段会报告这一冲突（例如在 kubectl describe vs命令的输出中）。

Kubernetes Ingress v1 API 更新

今年早些时候，Kubernetes 1.18 发布了 Ingress v1 apiVersion 更新，同时我们也进行了相应更改。现在，我们还支持在 IngressRule 中使用通配符主机，以及 PathType 字段下的 Exact和 Prefix 路径匹配。最后，我们采用了带有 ingressClassName 字段的 IngressClass 资源和 Ingress 对象。我们还对 CLI 参数进行了相应更改来适应这种改变。如欲了解更多详细信息，请查看文档。我们始终致力于向后兼容，因此我们仍然支持先前的配置语义。

标准 Kubernetes 环境支持 Operator

我们在今年早些时候推出了面向 OpenShift 环境的 NGINX Ingress Operator。该 Operator 现在已可用于标准 Kubernetes 环境。如欲了解部署说明，请查看我们 GitHub 存储库。

资源

有关版本 1.9.0 的完整变更日志，请查看版本 说明。

如欲试用 NGINX Plus NGINX Ingress Controller for Kubernetes，请立即下载 30 天免费试用版 或者 联系我们讨论您的用例。

如欲试用 NGINX Open Source NGINX Ingress Controller，您可以获取发布源代码或从 DockerHub 下载预构建的容器。

「梦想一旦被付诸行动，就会变得神圣，如果觉得我的文章对您有用，请帮助本站成长」

赞(0) 打赏

一分也是爱

支付宝扫一扫打赏

微信扫一扫打赏