NGINX.COM
Web Server Load Balancing with NGINX Plus

传统情况下,Kubernetes Ingress 资源用于在 Kubernete 中部署并配置 Ingress 负载均衡功能。虽然 Ingress 资源可以轻松配置 SSL/TLS 终止、HTTP 负载均衡以及七层路由,但它不能支持进一步的自定义。您需要使用 annotation(注释)、ConfigMaps 和自定义模板才能得以实现,但这些模板具有以下限制:

  • 作用于全局 – 非细粒度的
  • 易于出错且难以操作
  • 不安全

NGINX Ingress资源则为 NGINX 开源版的用户以及基于 NGINX Plus 的 NGINX Ingress Controller 用户提供了另一种选择。它们提供了一种原生、类型安全且缩进样式的配置方式,这简化了 Ingress 负载均衡功能的实现——这些功能包括:

  • 断路 – 用于适当处理应用错误
  • 复杂路由 – 用于 A/B 测试和蓝绿部署
  • 请求头操作 – 用于将应用逻辑卸载到 NGINX Ingress Controller
  • 双向 TLS 身份验证(mTLS)– 用于零信任或基于身份的安全防护
  • Web 应用防火墙(WAF)– 用于抵御 HTTP 漏洞攻击

NGINX Ingress 资源对现有 NGINX 用户还有一个附加的好处:它们简化了在非 Kubernetes 环境中重新配置负载均衡的过程,因此您的所有 NGINX 负载均衡器都可以使用相同的配置。

以下关于 VirtualServer(VS)对象的示例提供了基本的 Ingress controller(Ingress 控制器)功能,如 SSL/TLS 终止和基于路径的路由。借助 URI /products,输入域名 app.example.com 的请求将被路由到 products 服务,而使用 /billing URI 的请求则被路由到 billing 服务。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app
spec:
  host: app.example.com
  tls:
    secret: app-secret
  upstreams:
  - name: products
    service: products-svc
    port: 80
  - name: billing
    service: billing-svc
    port: 80
  routes:
  - path: /products
    action:
      pass: products
  - path: /billing
    action:
      pass: billing

VirtualServer 对象需要引用 Kubernetes Secret 对象来建立与客户端的 SSL/TLS 连接。该 Secret 包含诸如 SSL 证书和用于加密数据的密钥等敏感数据。有关 Secrets 的更多信息,请参阅 Kubernetes 文档

 

复杂路由

NGINX Ingress 资源可配置智能流量路由,实现以下用例:

  • 调试流量 – 将请求路由到新的测试实例
  • 流量拆分 – 将流量的子集路由到 Kubernetes service
  • 蓝绿部署 – 使最终用户平稳过渡到更新的生产工作负载

您可以根据客户端提供的连接属性来路由请求。在下面的示例中,传入流量被基于特定会话 cookie 进行路由。具有匹配会话 cookie 的经过身份验证的用户,将被路由到 app-edge 实例。

kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  upstreams:
  - name: app-edge
    service: app-edge-svc
    port: 80
  - name: app-stable
    service: app-stable-svc
    port: 80
  routes:
  - path: /
    matches:
    - conditions:
      - cookie: session
        value: suxxis-12hs6dds-dhfgry-ssss
      action:
        pass: app-edge
    action:
      pass: app-stable

在以下示例配置中,使用蓝绿部署将流量从应用的生产(蓝色)版本切换到新(绿色)版本,以验证新版本是否可以处理生产级别的流量,而且能带来实质的改进,并无需中断服务。

在示例中,我们将 90% 的传入流量定向到生产版本(products-v1),10% 的流量定向到新版本(products-v2)。如果事实证明 products-v2 性能不佳,那么这个问题只会影响少数用户,我们可以快速更改分流配置,将所有流量重新路由回 products-v1。如果 products-v2 性能良好,我们可以调整分流,(逐渐或一次性地)将更多流量路由到它,并在 products-v1 不再接收任何流量时将其停用,从而有效地将绿色实例转换为新的蓝色(生产)实例。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app
spec:
  host: app.example.com
  upstreams:
  - name: products-v1
    service: products-v1-svc
    port: 80
  - name: products-v2 
    service: products-v2-svc
    port: 80
  routes:
  - path: /products
    splits:
    - weight: 90
      action:
        pass: products-v1
    - weight: 10
      action:
        pass: products-v2

我们的 GitHub 代码库提供了许多部署 NGINX Ingress Controller 的完整示例

 

Policy(策略)

Policy 是指可以只定义一次,然后不同团队就可以将其用在应用的不同领域的 NGINX Ingress 资源。Policy 作为独立的 Kubernetes 对象被应用,可以以实现以下功能:

  • 速率限制 – 限制用户可以发出的请求数量
  • mTLS 身份验证 – 针对可配置的证书颁发机构(CA)验证客户端和服务器证书
  • 基于 IP 地址的访问控制列表 – 根据 IP 地址/子网允许或拒绝流量
  • JWT 验证 – 使用 ID 令牌对用户进行身份验证,以实现单一登录
  • WAF – 保护您的应用免受威胁和漏洞

下方示例展示了如何用 Policy 对象配置速率限制。在 rate 字段中定义的速率限制(在本示例中为每秒 1 个请求)适用于每个包在请求中并由 ${binary_remote_address} 变量捕获的源 IP 地址。

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

必须在 VirtualServer(VS)和 VirtualServerRoute(VSR)对象中引用 Policy,NGINX Ingress Controller 才能将其应用于流量。

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: /
    action:
      pass: webapp

有关 NGINX Ingress 资源的更多详细信息,请参阅此文档