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

Question

Я использую 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 килобайт, тем более последовательным я получаю: сброс соединения по пиру.

Есть идеи?

Answer 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 или у меня есть нужная кнопка, чтобы исправить это.

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

kubectl -n kube-system edit configmap kube-proxy

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

Answer 5

Сброс соединения по пиру, даже между службами внутри кластера, звучит так, как будто это может быть известная проблема с 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