【问题标题】:413 error with Kubernetes and Nginx ingress controllerKubernetes 和 Nginx 入口控制器出现 413 错误
【发布时间】:2018-09-29 19:03:24
【问题描述】:

我正在尝试更改 client_max_body_size 值,因此我的 nginx 入口不会返回 413 错误。

我已经测试了几个解决方案。
这是我的测试配置图:

kind: ConfigMap
apiVersion: v1
data:
  proxy-connect-timeout: "15"
  proxy-read-timeout: "600"
  proxy-send-timeout: "600"
  proxy-body-size: "8m"
  hsts-include-subdomains: "false"
  body-size: "64m"
  server-name-hash-bucket-size: "256"
  client-max-body-size: "50m"
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app: ingress-nginx

这些改动一点效果都没有,加载后在nginx控制器日志中可以看到reloading config map的信息,但是nginx.conf中的值是一样的:

root@nginx-ingress-controller-95db685f5-b5s6s:/# cat /etc/nginx/nginx.conf | grep client_max                                                                                                       
                        client_max_body_size                    "8m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";
                        client_max_body_size                    "1m";

我的 nginx-controller 配置使用这个图像:quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.13.0

如何强制 nginx 更改值?我需要对所有入口进行全局更改。

【问题讨论】:

    标签: nginx kubernetes


    【解决方案1】:

    您可以使用 annotation nginx.ingress.kubernetes.io/proxy-body-size 在 Ingress 对象中设置 max-body-size 选项,而不是更改基本 ConfigMap。

    以下是使用示例:

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: my-app
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    ...
    

    【讨论】:

    • 我想全局设置它,但实际上这种方法更好,因为我在项目存储库中有我的 yaml 文件。所以不会丢失。谢谢。
    • 所以client-max-body-size 配置行可以完全从metadata.annotations 中删除?
    • @payne 视情况而定。请参阅stackoverflow.com/a/67923692/1086907。如果body太大,需要client-max-body-size来提升性能。见Annotations: Client Body Buffer Size
    【解决方案2】:

    要全局设置它,这个configmap.md 文档可能会有所帮助。原来要设置的变量是proxy-body-size,而不是client-max-body-size

    部署helm chart时,可以设置--set-string controller.config.proxy-body-size="4m"

    【讨论】:

      【解决方案3】:

      更新:

      我遇到了同样的问题,但没有任何解决方案有效。在阅读了无数的博客和文档后,我发现他们都改变了命名约定。

      它不再用“proxy-body-size”表示,或者这对我来说永远不起作用。

      下面的链接显示要使用的正确 configmap 变量是“client-max-body-size”

      https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/

      【讨论】:

      • 对于那些阅读,此评论适用于使用 NGINX 发布的入口控制器时。如果您使用的是 Kubernetes 发布的 NGINX 控制器,则属性名称仍然是 proxy-body-size。您可以通过注释键来判断这一点,对于 Kubernetes 发布的 nginx.ingress.kubernetes.io/xxxxx 而不是 NGINX 发布的 nginx.org/xxxxx
      • 我鼓励 Nginx 和 Kubernetes 的人们聚在一起,开发一个共同的规范
      【解决方案4】:

      我已经在 configmap 上尝试了 proxy-body-size 和 client-max-body-size 并滚动重启了 nginx 控制器 pod,当我 grep pod 中的 nginx.conf 文件时,它返回默认值 1m .我正在尝试在 Azure Kubernetes 服务 (AKS) 中执行此操作。我正在与他们支持的人一起工作。他们说它不在他们身上,因为它似乎是一个 nginx 配置问题。

      奇怪的是,我们在 Azure 中有其他集群,这不是问题,直到我们在一些较新的部署中发现了这一点。他们提出的最初修复是这个线程中的内容,但它只是拒绝改变。

      下面是我的配置图:

      # Please edit the object below. Lines beginning with a '#' will be ignored,
      # and an empty file will abort the edit. If an error occurs while saving this file will be
      # reopened with the relevant failures.
      #
      apiVersion: v1
      data:
        client-max-body-size: 0m
        proxy-connect-timeout: 10s
        proxy-read-timeout: 10s
      kind: ConfigMap
      metadata:
        annotations:
          control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"nginx-nginx-ingress-controller-7b9bff87b8-vxv8q","leaseDurationSeconds":30,"acquireTime":"2020-03-10T20:52:06Z","renewTime":"2020-03-10T20:53:21Z","leaderTransitions":1}'
        creationTimestamp: "2020-03-10T18:34:01Z"
        name: ingress-controller-leader-nginx
        namespace: ingress-nginx
        resourceVersion: "23928"
        selfLink: /api/v1/namespaces/ingress-nginx/configmaps/ingress-controller-leader-nginx
        uid: b68a2143-62fd-11ea-ab45-d67902848a80
      

      发出滚动重启后: kubectl rollout 重启部署/nginx-nginx-ingress-controller -n ingress-nginx

      Grepping nginx 入口控制器 pod 以查询值现在显示:

      kubectl exec -n ingress-nginx nginx-nginx-ingress-controller-7b9bff87b8-p4ppw cat nginx.conf | grep client_max_body_size
                  client_max_body_size                    1m;
                  client_max_body_size                    1m;
                  client_max_body_size                    1m;
                  client_max_body_size                    1m;
                  client_max_body_size                    21m;
      

      我尝试更改它的位置无关紧要。在全局或 Ingress 路由的 configmap 上……上面的这个值永远不会改变。

      【讨论】:

      • 我可以确认这一点,我们正在运行完全相同的问题。 AKS 版本 1.18.4。
      【解决方案5】:

      我可以通过在修改 configmap 后重新部署 nginx-ingress 控制器来修复它。

      kubectl patch deployment your_deployment -p "{\"spec\": {\"template\": {\"metadata\": { \"labels\": {  \"redeploy\": \"$(date +%s)\"}}}}}"
      

      【讨论】:

        【解决方案6】:

        您始终可以进行全局更改并完全禁用它

        kubectl -n ingress-nginx patch configmap \
        nginx-configuration -p '{"data": {"proxy-body-size": "0"}}'
        

        或设置为 5tb

        kubectl -n ingress-nginx patch configmap \
        nginx-configuration -p '{"data": {"proxy-body-size": "5tb"}}'
        

        【讨论】:

          【解决方案7】:

          也许最近有些人被困在这里。我们刚刚发现注释 nginx.ingress.kubernetes.io/proxy-body-size 不再被应用,正确的是:

            annotations:
              nginx.org/client-max-body-size: "999m"
          

          希望这对其他人有所帮助。

          【讨论】:

          • 顺便说一下,这两个注解用于两个不同的 nginx 入口控制器。前缀中的域是一个很好的参考。
          • @Draculater 确实如此。问题是谷歌搜索将人们发送到这篇文章,我认为(可能是错误的),但这不是正确的问题,这个回复可以缩短他们对解决方案的搜索。
          猜你喜欢
          • 2018-10-29
          • 2020-01-20
          • 1970-01-01
          • 2018-02-16
          • 2020-04-09
          • 2020-12-05
          • 2020-04-24
          • 2022-01-26
          • 1970-01-01
          相关资源
          最近更新 更多