NGINX.COM
Web Server Load Balancing with NGINX Plus

我们很高兴地宣布推出 NGINX Ingress Controller for Kubernetes 版本 1.8.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.8.0 的推出充分彰显了我们致力于提供灵活、强大且易用的 Ingress Controller 的承诺。Ingress Controller 可以使用 Kubernetes Ingress 资源和 NGINX Ingress 资源进行配置:

版本 1.8.0 的主要增强和改进包括:

  • 集成 NGINX App Protect —— NGINX App Protect 是领先的 NGINX 应用安全解决方案,能够为 Web 应用提供深度签名和结构化保护。
  • 面向 NGINX Ingress 资源的可扩展性 —— 资源中尚未实施的 NGINX 特性进行自定义的用户,目前支持两种互补机制:配置 snippets 和自定义模板。
  • URI 重写以及修改请求和响应头 —— 这些特性可支持您精细控制(添加、删除和忽略)传递给上游以及传递回客户端的请求和响应头。
  • 策略和 IP 地址访问控制列表 —— 通过将策略以及流量管理功能抽象成独立的K8S对象,不同团队可以在多个地方进行定义并部署。访问控制列表 (ACL) 可用于过滤流经 NGINX Ingress Controller 的出入站网络流量。
  • 其他新增特性 ——

    • Readiness 探测
    • 在 VirtualServer 和 VirtualServerRoute 资源及 Helm 图表中支持多个 Ingress Controller
    • 关于 VirtualServer 和 VirtualServerRoute 资源的状态信息
    • NGINX Ingress Operator for Red Hat OpenShift 更新

什么是 NGINX Ingress Controller for Kubernetes?

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

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

NGINX Ingress Controller 1.8.0 有哪些新增特性?

集成 NGINX App Protect

随着更多企业竭力加速数字化转型,针对应用的攻击日益增加。更为复杂的新型漏洞攻击每天都在上演。与网络防火墙和杀毒解决方案不同,NGINX App Protect 作为一种智能 Web 应用防火墙 (WAF),可以快速有效地缓解恶意攻击。

NGINX Ingress Controller 版本 1.8.0 嵌入了 NGINX App Protect,可支持您使用熟悉的 Kubernetes API 管理 App Protect 安全策略和配置。

这款集成解决方案具有三大独特优势:

  • 保护应用边界 —— 在架构设计合理的 Kubernetes 部署中,Ingress Controller 是数据平面流量流向 Kubernetes 内所有运行服务的唯一入口点,这使其成为部署安全代理的理想位置。
  • 整合数据平面 —— 将 WAF 嵌入到 Ingress Controller 中消除了对独立 WAF 设备的需求。这可以降低复杂性、成本和故障点的数量。
  • 整合控制平面 —— 使用 Kubernetes API 管理 WAF 配置有助于更轻松地实现 CI/CD 流程的自动化。NGINX Ingress Controller 配置符合 Kubernetes 基于角色的访问控制 (RBAC) ,因此 WAF 配置可安全地委派给专门的 DevSecOps 团队。

如欲了解详细概述,请查看相关博客使用 NGINX App Protect 保护 Kubernetes 中的应用。如欲了解在 NGINX Ingress Controller 中如何对 NGINX App Protect 进行配置和故障排除的完整说明,请查看Ingress Controller 文档。如欲了解有关其他 App Protect 用例的信息,请查看 NGINX App Protect 文档

您必须同时订阅 NGINX Plus 和 NGINX App Protect 服务才能将 App Protect 内置到 NGINX Ingress Controller 镜像中。

使用 Snippets 和自定义模板扩展 NGINX Ingress 资源

在以前的版本中,您可以使用 snippets 和自定义模板将 NGINX 配置插入到标准 Kubernetes Ingress 资源中。Snippets 支持您将 NGINX 以原生配置的方式部署到 NGINX 的大多数配置上下文中。自定义模板支持您生成其他配置块(例如default server),并将其应用于 ConfigMaps。版本 1.8.0 将 snippets 和自定义模板的使用扩展到了 NGINX Ingress 资源、VirtualServer 和 VirtualServerRoute。

Snippets 和自定义模板支持管理员为标准 Kubernetes Ingress 资源或 NGINX Ingress 资源中尚未发布的用例和功能实施配置。一个特别重要的用例便是当将 NGINX 代理的非 Kubernetes 应用迁移到 Kubernetes时,借助snippets和自定义模板,您可以继续使用 NGINX Ingress 资源中尚未发布的 NGINX 特性,例如高速缓存速率限制

此示例配置显示了如何在不同 NGINX 配置上下文中,通过采用不同设置的 snippets 配置高速缓存和速率限制:

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
  namespace: cafe
spec:
  http-snippets: |
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
    proxy_cache_path /tmp keys_zone=one:10m;
  host: cafe.example.com
  tls:
    secret: cafe-secret
  server-snippets: |
    limit_req zone=mylimit burst=20;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80
  - name: coffee
    service: coffee-svc
    port: 80
  routes:
  - path: /tea
    location-snippets: |
      proxy_cache one;
      proxy_cache_valid 200 10m;
    action:
      pass: tea
  - path: /coffee
    action:
      pass: coffee

对 snippets 和自定义模板进行慎重检查非常重要,因为无效的 snippets 或模板会阻止 NGINX 重新加载其配置。虽然在这种情况下,流量处理并不会中断(NGINX 继续在现有有效配置下运行),但是您还可以使用其他机制来提高稳定性:

  • 一个全局启用/禁用 snippets 的设置。
  • 通常只有管理员才能应用 ConfigMap,这是配置自定义模板的唯一机制。

URI 重写以及修改请求和响应头

版本 1.8.0 在上游和下游连接中新增了 URI 重写以及修改请求和响应头的特性。这实质上通过添加一个过滤和修改层将终端用户与后端服务器实现解耦。现在,我们可以直接在 VirtualServer 和 VirtualServerRoute 资源中使用此功能,并且可以针对特定路径对其进行配置。

URI 重写以及修改请求和响应头特性可支持您快速解决生产环境中无法预料的可靠性问题,而无需后端开发人员排除故障或重写代码。这反过来提高了 Kubernetes 中应用的可用性、安全性和弹性。

典型用例包括:

  • URI 重写 —— 管理员可能希望在一个非应用代码所在的路径上发布应用。例如,您可以将应用向外定向到 /coffee ,并通过 Ingress Controller 将请求重定向到应用后端正在监听的根 (/) URI。
  • 高速缓存 —— 应用开发人员并不能总是正确设置高速缓存 header,或者根本不设置高速缓存 header。管理员可以使用 header 修改来修补已部署应用中的 header。

您可以通过 proxy 操作将请求传递到上游,从而在配置 VirtualServer 或 VirtualServerRoute 中配置 header 修改和 URI 重写。

在此示例配置中,当 Ingress Controller 代理对 /tea 路径的客户端请求时,它会在将请求转发到上游之前修改 Content-Type (内容-类型)请求头。它还将按 rewritePath 字段中所指定的,把 /tea URI 重写为 /。在将服务器响应传递回客户端之前,Ingress Controller 会添加一个新的 Access-Control-Allow-Origin header 字段,并隐藏、忽略和传递其他几个 header 字段。

apiVersion: k8s.nginx.org/v1 
kind: VirtualServer 
metadata: 
  name: cafe 
spec: 
  host: cafe.example.com 
  upstreams: 
  - name: tea 
    service: tea-svc 
    port: 80 
  - name: coffee 
    service: coffee-svc 
    port: 80 
  routes: 
  - path: /tea 
    action: 
      proxy: 
        upstream: tea 
        requestHeaders: 
          pass: true 
          set:
          - name: Content-Type 
            value: application/json 
        responseHeaders: 
          add: 
          - name: Access-Control-Allow-Origin
            value: "*" 
            always: true 
          hide: 
          - x-internal-version 
          ignore: 
          - Expires 
          - Set-Cookie 
          pass: 
          - Server 
        rewritePath: /
  - path: /coffee
    action:
      pass: coffee

此示例配置说明了如何在条件匹配时将header操作和 URI 重写嵌入到 action 块中,从而实现更复杂的流量处理:

apiVersion: k8s.nginx.org/v1 
kind: VirtualServer 
metadata: 
  name: cafe 
spec: 
  host: cafe.example.com 
  upstreams: 
  - name: tea 
    service: tea-svc 
    port: 80 
  - name: tea-post 
    service: tea-post-svc 
    port: 80 
  routes: 
  - path: /tea
    matches: 
    - conditions: 
      - variable: $request_method 
        value: POST  
      action: 
        proxy: 
          upstream: tea-post 
          requestHeaders: 
            pass: true 
            set: 
            - name: Content-Type 
              value: application/json 
          rewritePath: /
    action:
      pass: tea

策略和 IP 地址访问控制列表

大多数组织都是多个团队合作交付应用。例如,NetOps 负责打开端口和过滤流量,SecOps 负责确保一致的安全状态,还有多个应用所有者为多个后端应用服务提供 Ingress 负载均衡策略。

考虑到每个组织委派角色的方式不尽相同,NGINX Ingress 支持您以最大的灵活性定义各团队负责的特定配置部分,最后整合并执行。它还可支持多租户,同时最大程度地简化了管理员的委派工作。

为了支持多租户,NGINX Ingress Controller 版本 1.8.0 引入了 policy 策略,第一个受支持的策略类型是:基于 IP 地址的访问控制列表 (ACL)。

  • 通过将策略以及流量管理功能抽象成独立的K8S对象,不同团队可以在多个地方进行定义并部署。使用该方法配置 NGINX Ingress Controller 更简单、更自然,并且带来了许多优势:类型安全、委派、多租户、封装以及简化的配置、可重用性和可靠性。
  • 借助基于 IP 地址的 ACL,您可以过滤网络流量并精确控制允许或拒绝访问特定 Ingress 资源的 IP 地址(或 IP 地址组,用 CIDR 表示法定义)。

注意: 在版本 1.8.0 中,只能在 VirtualServer 资源中引用策略,其中策略应用于 server 上下文。在未来版本中,我们计划将策略支持扩展到 VirtualServerRoute 资源,其中策略应用于 location 上下文。我们还计划为速率限制等其他功能实施策略。

下图说明了策略的使用方式。左侧的 VirtualServer 资源引用了一个名为 webapp-policy 的策略,右侧的配置代码段分别使用这个名称定义了一个策略,用于过滤(允许或拒绝)来自 10.0.0.0/8 子网的连接。将该名称分配给两个策略意味着您可以使用 Kubernetes API 将对应策略应用于 VirtualServer,从而在不同策略之间进行切换。

其他新增特性

Readiness 探测

在拥有较多 Ingress 资源(标准 Kubernetes、NGINX 或两者都有)的环境中,Pod 可能会在 NGINX 配置加载完之前上线,从而导致流量“走丢”(blackholed)。根据我们对生产级可靠性的承诺,版本 1.8.0 引入了 Kubernetes readiness 探测功能,旨在确保流量在 Ingress Controller 准备好接受流量(即 NGINX 配置加载完成,且没有正在等待的重新加载)之前不会转发到特定 Pod。

在 NGINX Ingress 资源和 Helm 图表中启用多种 Ingress Controller

在以前的版本中,多种 NGINX Ingress Controller 实例可以共存于同一集群上,但只能通过使用标准 Kubernetes Ingress 资源中的 kubernetes.io/ingress.class 注释,指定目标 NGINX Ingress Controller 部署。在版本 1.8.0 中,我们为 VirtualServer 和 VirtualServerRoute 资源添加了 ingressClassName 字段,以达到同样的目的。我们还更新了 Helm 图表,以支持部署多种 NGINX Ingress Controller。

显示 VirtualServer 和 VirtualServerRoute 资源的状态

kubectl describe 命令的输出表示 Ingress Controller 的配置是否已成功更新(在 Events 部分),并列出了其外部端点的 IP 地址和端口(在 Status 部分)。在版本 1.8.0 中,我们扩展了 VirtualServer 和 VirtualServerRoute 资源以返回此信息。对于 VirtualServerRoute 资源,Status 部分还会命名父类 VirtualServer 资源。

作为应用所有者,您可能会发现 VirtualServerRoute 资源的父类 VirtualServer 已被删除,从而导致应用无法访问。现在,您可以通过向相关的 VirtualServer 和 VirtualServerRoute 资源发出 kubectl describe 命令来解决该问题。

此示例命令显示已成功应用 cafe 的配置,在 Events 部分,TypeNormalReasonAddedorUpdated

$ kubectl describe vs cafe
. . .
Events:
  Type    Reason          Age   From                      Message
  ----    ------          ----  ----                      -------
  Normal  AddedOrUpdated  16s   nginx-ingress-controller  Configuration for default/cafe was added or updated

此示例显示,cafe VirtualServer 的配置因无效而被拒绝,在 Events 部分,TypeWarningReasonRejected。原因是有两个都被命名为 tea 的上游。

$ kubectl describe vs cafe
. . .
Events:
  Type     Reason    Age   From                      Message
  ----     ------    ----  ----                      -------
  Warning  Rejected  12s   nginx-ingress-controller  VirtualServer default/cafe 
is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"

在输出的 Status 部分,MessageReason 字段报告与 Events 部分相同的信息,以及每个外部端点的 IP 地址和端口。

$ kubectl describe vs cafe
. . . 
Status:
  External Endpoints:
    Ip:        12.13.23.123
    Ports:     [80,443]
  Message:  VirtualServer default/cafe is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"
  Reason:   Rejected

更新 NGINX Ingress Operator 用于 Red Hat OpenShift

  • 策略 —— 您现在可以利用 NGINX Ingress Controller Operator 按最终用户部署策略。
  • App Protect 扩展 – 您可以使用 Operator 来扩展 NGINX Ingress Controller 的 App Protect 的能力,以便让所有 NGINX ingress Controller 实例都可以检查流量的安全性。

资源

有关版本 1.8.0 的完整变更日志,请查看 版本说明

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

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

Hero image
Ebook: Cloud Native DevOps with Kubernetes

Download the excerpt of this O’Reilly book to learn how to apply industry‑standard DevOps practices to Kubernetes in a cloud‑native context.

关于作者

Amir Rawdat

解决方案工程师

Amir Rawdat 是 NGINX 的技术营销工程师,专门负责各种技术内容的撰写。他在计算机网络、计算机编程、故障排除和内容撰写方面拥有深厚的背景。此前,Amir 是诺基亚(Nokia)的客户应用工程师。

关于 F5 NGINX

F5, Inc. 是备受欢迎的开源软件 NGINX 背后的商业公司。我们为现代应用的开发和交付提供一整套技术。我们的联合解决方案弥合了 NetOps 和 DevOps 之间的横沟,提供从代码到用户的多云应用服务。访问 nginx-cn.net 了解更多相关信息。