GitLab CI/CD上传S3制品报413请求实体过大问题求助

针对你遇到的2.08GB镜像制品上传413错误，结合已做的配置调整，以下是额外的排查线索：

• 检查GitLab Workhorse的请求体限制
  GitLab Workhorse是处理前端请求的核心组件，默认可能存在请求体大小限制。在GitLab的配置文件（Omnibus部署为gitlab.rb，K8s Helm部署为values.yaml）中，设置gitlab_workhorse['client_max_body_size'] = '0'（0代表无限制）或明确指定大于2.08GB的值（如'3g'），配置完成后重启Workhorse组件。

• 升级GitLab Runner至兼容版本
  当前GitLab实例为v15.9.1，但Runner版本为v15.4.2，版本差距超过3个小版本，可能存在兼容性问题。建议将Runner升级至v15.9.x系列，确保与GitLab实例版本匹配。

• 检查GitLab内部Nginx的请求体限制
  若使用GitLab官方Helm Chart部署，GitLab自带的Nginx服务也可能有client_max_body_size限制。在values.yaml中添加或修改：

  nginx:
    clientMaxBodySize: "3g"
  

  Omnibus部署则在gitlab.rb中设置nginx['client_max_body_size'] = '3g'，之后重新部署GitLab实例。

• 确认GitLab Rails的制品大小配置
  除了界面上设置的实例/组/项目级最大制品大小，需确保gitlab.rb中的gitlab_rails['artifacts_max_size']值与界面配置一致，或设置为更大值（如2180，单位为MB）。Omnibus部署需执行gitlab-ctl reconfigure使配置生效，K8s部署则重新应用Chart配置。

• 排查集群内其他代理组件的限制
  如果GitLab实例前还有其他代理层（如Istio、Linkerd等服务网格，或额外的Ingress控制器），需检查这些组件的请求体大小限制：

  • Istio：在Gateway或VirtualService中设置maxRequestBytes为足够大的值；
  • 其他代理：查找对应组件的client_max_body_size或类似配置项，调整为无限制或大于2.08GB。

• 验证上传超时配置
  虽然当前错误是413，但过长的上传时间可能触发超时间接导致失败，可检查以下配置：

  • GitLab Workhorse的proxy_read_timeout设置为至少600秒；
  • GitLab Rails的artifacts_object_store_upload_timeout设置为合适的超时阈值。

内容的提问来源于stack exchange，提问作者drey247