在 Kubernetes 中将大于 400 KB 有效负载的 POST 失败

我在 AWS 中使用 EKS (Kubernetes(，我在向在该 Kubernetes 的容器中运行的任何 Web 服务器发布大约 400 KB 的有效负载时遇到问题。我达到了某种限制，但它不是大小的限制，它似乎在 400 KB 左右很多次工作，但有时我会得到(使用 Python 请求进行测试(

requests.exceptions.ChunkedEncodingError: ("Connection broken: ConnectionResetError(104, 'Connection reset by peer')", ConnectionResetError(104, 'Connection reset by peer'))

我用不同的容器(Alpine上的python web服务器，CentOS上的Tomcat服务器，nginx等(对此进行了测试。

我越

是将大小增加到 400 KB，我得到的一致性就越高：通过对等方重置连接。

有什么想法吗？

感谢您的回答和评论，帮助我更接近问题的根源。我确实将 AWS 集群从 1.11 升级到 1.12，并在 Kubernetes 中从一个服务访问另一个服务时清除了此错误。但是，使用公共 dns 从 Kubernetes 集群外部访问时，错误仍然存在，因此负载均衡器也是如此。因此，经过更多测试后，我发现现在问题出在 ALB 或 Kubernetes 的 ALB 控制器上：https://kubernetes-sigs.github.io/aws-alb-ingress-controller/所以我切换回生成老一代 ELB 的 Kubernetes 服务，问题得到了解决。ELB 并不理想，但目前这是一个很好的解决方法，直到 ALB 控制器得到修复或我有正确的按钮来修复它。

正如您在此答案中提到的，该问题可能是由 ALB 或 Kubernetes 的 ALB 控制器引起的：https://kubernetes-sigs.github.io/aws-alb-ingress-controller/。

你能检查一下Nginx入口控制器是否可以与ALB一起使用吗？

Nginx 的请求大小默认值设置为 1Mb。可以使用以下注释进行更改：nginx.ingress.kubernetes.io/proxy-body-size 。

另外，您是否在任何地方配置连接保持活动状态或连接超时？

对等方重置的连接，即使在集群内的服务之间，听起来可能是 conntrack 的已知问题。此修复涉及运行以下内容：

echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

您可以使用以下守护程序集自动执行此操作：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: startup-script
  labels:
    app: startup-script
spec:
  template:
    metadata:
      labels:
        app: startup-script
    spec:
      hostPID: true
      containers:
      - name: startup-script
        image: gcr.io/google-containers/startup-script:v1
        imagePullPolicy: IfNotPresent
        securityContext:
          privileged: true
        env:
        - name: STARTUP_SCRIPT
          value: |
            #! /bin/bash
            echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
            echo done

正如这个答案所暗示的，您可以尝试更改您的 kube-proxy 操作模式。要编辑您的 kube 代理配置：

kubectl -n kube-system edit configmap kube-proxy

搜索模式：">并尝试"iptables"，">用户空间">或"ipvs"。每次更改配置映射时，请删除 kube-proxy pod(s(，以确保它正在读取新的配置映射。

我们在 Azure 及其防火墙方面遇到了类似的问题，它阻止发送超过 128KB 的补丁请求。在团队中研究和思考这种方法的优缺点后，我们的解决方案完全不同。

我们将"更大"的请求放入 blob 存储中。之后，我们将一条消息放入队列中，其中包含之前创建的文件名。队列将接收带有文件名的消息，从存储中读取 blob，将其转换为您需要的任何对象，并能够在此大对象上应用任何业务逻辑。处理完邮件后，文件将被删除。

最大的优点是我们的 API 不会被大请求及其长时间运行的作业阻塞。

也许这可能是在 kubernetes 容器中解决问题的另一种方法。

看你，莱昂哈德

相关内容

最新更新

热门标签：