Kubernetes liveness probe не работает, когда журналы показывают ответ 200

Я использую https://pypi.org/project/django-health-check/ для проверки здоровья в приложении Django, запущенном через kubernetes_wsgi со следующим YAML:

        livenessProbe:
          httpGet:
            path: /ht/
            port: 8020
            httpHeaders:
              - name: Host
                value: pdt-staging.nagyv.com
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 10
        readinessProbe:
          httpGet:
            path: /ht/
            port: 8020
            httpHeaders:
              - name: Host
                value: pdt-staging.nagyv.com
          initialDelaySeconds: 20
          timeoutSeconds: 5

Журналы стручка утверждают, что зондирование прошло успешно:

INFO:twisted:"-" - - [22/Jul/2022:22:11:07 +0000] "GET /ht/ HTTP/1.1" 200 1411 "-" "kube-probe/1.22"

В то же время, события в капсуле отрицают следующее:

Liveness probe failed: Get "http://10.2.1.43:8020/ht/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

... и через некоторое время капсула регулярно перезапускается.

Похоже, что капсула полностью функционирует. Я также могу достичь конечной точки /ht/. Кажется, все работает, за исключением зондов liveness probes.

Я читал о медленных ответах, вызывающих проблему, но это довольно быстро.

Есть идеи, в чем может быть проблема?

python-контейнеры обычно занимают много памяти, в целом, по сравнению с другими. Когда вы запускаете django на gunicorn, контейнер по умолчанию использует около 150M (для меня) вашей памяти (зависит от объема исходного кода[для нас исходный код был около 50M]). Это также зависит от пакетов pip, установленных в контейнере для вашего приложения. Хорошей практикой является предоставление обычно на 20% больше памяти, чем ожидается для django с gunicorn. Вам также следует увеличить timeoutSeconds до 30 или 20 в зависимости от количества трафика, которое вы обрабатываете в одном контейнере. Плюс, либо readinessProbe, либо livenessProbe на контейнере, оба зонда будут создавать слишком много шумного трафика на контейнер. Плюс, используйте HPA для масштабирования вашего приложения, масштабируйте приложение на 60% процессора и 60% памяти, чтобы контролировать всплеск трафика.

Поскольку вы используете потоки, будьте осторожны с количеством активных соединений с БД. Вы также экспортируете метрики здоровья django (в prometheus), что является дополнением к функциональности приложения, не забудьте добавить дополнительные ресурсы для этого. Скретчинг prometheus также может создавать слишком много накладных расходов на контейнер, поэтому выбирайте количество скретчей Prometheus в одном контейнере и scrape_interval с умом. Вы же не хотите, чтобы ваш контейнер обслуживал только внутренний трафик.

Для получения более релевантной ссылки на эту проблему: https://github.com/kubernetes/kubernetes/issues/89898

Вернуться на верх