传统情况下,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 资源的更多详细信息,请参阅此文档。