POST больше 400 килобайт полезной нагрузки на контейнер в Кубернетес не удается

Я использую EKS (Kubernetes) в AWS, и у меня возникают проблемы с размещением полезной нагрузки около 400 килобайт на любой веб-сервер, который работает в контейнере в этом Kubernetes. Я установил какое-то ограничение, но оно не ограничено по размеру, кажется, что оно работает на уровне около 400 килобайт много раз, но иногда я получаю (тестирование с использованием запросов Python)

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

Я тестирую это с разными контейнерами (веб-сервер python на Alpine, сервер Tomcat на CentOS, nginx и т.д.).

Чем больше я увеличиваю размер более 400 килобайт, тем более последовательным я получаю: сброс соединения по пиру.

Есть идеи?

ОТВЕТЫ

Ответ 1

Спасибо за ваши ответы и комментарии, помогли мне приблизиться к источнику проблемы. Я обновил кластер AWS с 1.11 до 1.12, и это устранило эту ошибку при доступе от сервиса к сервису в Kubernetes. Тем не менее ошибка все еще сохраняется при доступе из-за пределов кластера Kubernetes с использованием общедоступного DNS, таким образом, балансировщик нагрузки. Поэтому после тестирования я обнаружил, что теперь проблема заключается в ALB или контроллере ALB для Kubernetes: https://kubernetes-sigs.github.io/aws-alb-ingress-controller/ Поэтому я переключился на Kubernetes сервис, который генерирует ELB старого поколения, и проблема была исправлена. ELB не идеален, но на данный момент это хороший обходной путь, пока контроллер ALB не починится или у меня не появится нужная кнопка, чтобы исправить это.

Ответ 2

Сброс соединения по пиру, даже между службами внутри кластера, звучит так, как будто это может быть известной проблемой с conntrack. Исправление включает в себя запуск следующего:

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

И вы можете автоматизировать это с помощью следующего DaemonSet:

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

Ответ 3

Как следует из этого ответа, вы можете попробовать изменить режим работы kube-proxy. Чтобы отредактировать ваши конфиги kube-proxy:

kubectl -n kube-system edit configmap kube-proxy

Найдите режим: "" и попробуйте "iptables", "userspace" или "ipvs". Каждый раз, когда вы изменяете свою конфигурационную карту, удаляйте свои под-модули kube-proxy, чтобы убедиться, что она читает новую конфигурационную карту.

Ответ 4

Как вы упомянули в этом ответе, проблема может быть вызвана ALB или контроллером ALB для Kubernetes: https://kubernetes-sigs.github.io/aws-alb-ingress-controller/.

Можете ли вы проверить, можно ли использовать контроллер Nginx Ingress с ALB?

Nginx имеет значение по умолчанию размера запроса, равное 1 МБ. Его можно изменить с помощью этой аннотации: nginx.ingress.kubernetes.io/proxy-body-size.

Также вы конфигурируете соединение-поддержание активности или таймауты соединения где-нибудь?

Ответ 5

у нас была похожая проблема с Azure и его брандмауэром, который запрещает отправлять более 128 КБ в качестве запроса на исправление. После изучения и размышлений о плюсах и минусах этого подхода в команде наше решение совершенно другое.

Мы помещаем наши "большие" запросы в хранилище BLOB-объектов. После этого мы помещаем сообщение в очередь с именем файла, созданным ранее. Очередь получит сообщение с именем файла, прочитает большой двоичный объект из хранилища, преобразует его в объект, который вам нужен, и может применить любую бизнес-логику к этому большому объекту. После обработки сообщения файл будет удален.

Самым большим преимуществом является то, что наш API не блокируется большим запросом и его длительной работой.

Может быть, это может быть еще один способ решить вашу проблему в контейнере kubernetes.

Увидимся, Леонард