这文档说：
nginx.ingress.kubernetes.io/limit-connections：单个IP地址允许的并发连接数，超过此限制会返回503错误。nginx.ingress.kubernetes.io/limit-rps：每秒接受来自指定 IP 的请求数。突发限制设置为此限制乘以突发乘数，默认乘数为 5。当客户端超出此限制时，limit-req-status-code默认返回：503。
如果请求限制，HTTP 错误代码可以覆盖， 尽管。
这HTTP 规范说：
响应状态代码
HTTP 429 Too Many Requests表示用户在给定的时间内发送了太多请求（“速率限制”）。
问题：为什么 nginx 首先决定使用 HTTP 503？看起来 HTTP 429 是最能描述该问题的响应代码。
答案1
最近我发现此讨论主题，引用@niels-keurentjes
它们有不同的语义。503 表示服务器错误（5xx 范围），具体来说，在这种情况下，后端服务器受到过载保护。客户端永远无法预测这种情况的发生，因此这不是客户端错误。503 表示“我很乐意为您提供帮助，但由于服务不可用，因此无法提供帮助”。
然而，429 是客户端错误（4xx 范围），因为客户端超出了明确定义和指定的限制。因此，429 意味着“我不会帮助你，因为你在称呼我时犯了一个错误”。
它们是完全不同的错误。并且，除非另有说明，基本假设是服务器没有预定义的速率限制，因此超过一个是服务器的原因。503 本身就是正确且最佳的默认值。
429 可能经常是速率限制的预期答案，但前提是客户端应该/可以更了解情况。这就是 4xx 和 5xx 之间的区别。
我认为他的观点有道理。
答案2
@Marc Wittke 通过引用的讨论线索给出了极好的答案。
作为 API 或端点的消费者，我将给出一个实际的答案：
503 无法让 API 的消费者知道哪里出了问题，只能猜测。服务不可用是因为我无法控制的原因（其他原因导致服务不可用）还是我可以控制的原因（请求率）。
429 是正确的，它用一个状态代码描述了问题的解决方案：发送更少的请求。如果您想要一个设计良好的自文档化 API，那么这就是正确的答案。
您可以在服务器块配置中使用此行重新定义 nginx 行为（请参阅官方 nginx 博客文章)：
limit_req_status 429;