NGINX.COM
Web Server Load Balancing with NGINX Plus

无论 HTTP 请求是恶意的(暴力破解密码或 DDoS 攻击)还是正常的(用户批量访问),大量的 HTTP 请求都有可能导致服务不堪重负,从而导致应用崩溃。这个问题有一个简单的解决办法:使用速率限制控制每个用户在特定时间段内的请求数量。然而,在 Kubernetes 环境中,到达某个 service 的大部分流量(即那些与其他 service 通信的流量)可能不在 Ingress controller 的权限范围内。在这种情况下,可以使用 service mesh 来设置速率限制策略。

借助 NGINX Service Mesh,您可以在 10 分钟内轻松完成速率限制的配置。请观看以下实际操作演示,并继续阅读下文,了解如何定义和应用速率限制策略。

Demo:使用 NGINX Service Mesh 配置速率限制

Demo使用三个插入 NGINX Service Mesh sidecar 的容器:一个后端 service、一个前端 service 和一个 bash 终端,同时还部署了 NGINX Service Mesh 控制平面。

前端 service 每秒都会向后端 service 发送一个请求,我们可以在前端 service 的日志中看到对这些请求的响应:

backend v1
backend v1
backend v1
backend v1

应用速率限制策略 (1:00)

假设我们不希望后端 service 接收这么多请求,我们可以将限速策略定义为具有以下字段的自定义资源:

  • destination—— 后端 service,接收请求的service;
  • sources—— 前端 service,发出请求的客户端列表,每个客户端都实施了速率限制。此demo我们只定义一个source。
  • rate—— 速率限制。此处为每分钟 10 个请求,或者每 6 秒钟 1 个请求。
apiVersion: specs.smi.nginx.com/v1alpha1
kind: RateLimit
metadata:
  name: backend-rate-limit
  namespace: default
spec:
  destination:
    kind: Service
    name: backend-svc
    namespace: default
  sources:
  - kind: Deployment
    name: frontend
    namespace: default
  name: 10rm
  rate: 10r/m
  burst: 0
  delay: nodelay

我们运行以下命令,以启用速率限制策略:

$ kubectl create -f rate-limit.yaml

在前端 service 的日志中,我们发现每 6 个请求中有 5 个被拒绝,并显示以下消息:

<html>
<head><title>503 Service Temporarily Unavailable</title</head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.19.5</center>
</body>
</html>

将速率限制应用到所有客户端 (2:32)

速率限制仅适用于 sources 字段中指定的客户端(前端 service)。sources 字段未指定的其他客户端则不受速率限制,后端 service 依然会接受接受大量的未限制发送速率的客户端请求。我们可以通过在 bash 批量发送请求来查看;sources 字段未指定的其他客户端每个请求都会收到表示成功的 backend v1 响应。

怎么将速率限制应用到所有客户端?我们可以通过两种方法实现。第一种是将所有客户端的名称添加到 sources 字段中。在客户端较多的情况下,会相对复杂。第二种更为简单,删除 sources 字段,这样程序会识别所有客户端并加入速率限制策略。我们可以通过运行以下命令来编辑策略:

$ kubectl edit ratelimits.specs.smi.nginx.com backend-rate-limit

保存编辑好的策略后,我们再次从 bash 发出请求,发现其中超过速率限制的请求被拒绝,并显示如上所示的格式化的 503 错误。

允许突发请求 (3:43)

我们还可以将其他几个字段添加到策略中以自定义速率限制。我们知道有些应用是“突发流量”,这时它们会快速连续地发送多个请求。为此,我们可以添加 burst 字段。比如我们将 burst 字段设置为 3,这意味着后端 service 会在每 6 秒钟内接受多个额外的请求。超出此范围的请求均将被拒绝。

delay 字段用于控制如何将被允许的突发请求反馈到后端 service。如果没有该字段(即默认情况下),突发请求会根据速率限制排队处理,并与新请求交错发送。如果要立即处理突发请求,我们可以将 delay 字段的值设置为 nodelay

您还可以将 delay 字段设置为整数。例如,如果我们将其设置为 3 并将 burst 字段增加到 5,那么在每 6 秒钟内,当发出 5 个或以上突发请求时,其中 3 个立即发送,2 个排队等待,其余将被拒绝。

我们设置 burst: 3delay: nodelay ,在日志中观察效果。可以看到,在拒绝请求之前接受了三个额外的请求:

backend v1
backend v1
backend v1
backend v1
<html>
<head><title>503 Service Temporarily Unavailable</title</head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.19.5</center>
</body>
</html>
. . .

取消速率限制 (6:30)

运行以下命令,禁用速率限制策略并接受所有请求:

$ kubectl delete -f rate-limit.yml

使用NGINX Service Mesh 进行速率限制

有关突发参数和延迟参数的详细信息,请参阅参考文档。有关其他流量管理模式的探讨,请阅读我们的博文《如何通过高级流量管理提高 Kubernetes 的弹性》

您还可以观看以下 NGINX Service Mesh 功能演示视频:

NNGINX Service Mesh 完全免费,您可立即下载并在 10 分钟内完成部署!有关使用方法,请查看我们的文档,并通过 GitHub 告诉我们您的使用体验。

Hero image
Kubernetes:
从测试到生产

通过多种流量管理工具提升弹性、可视性和安全性

关于作者

Saylor Berman

Software Engineer

关于 F5 NGINX

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