Сообщение Strage в журнале PostgreSQL «неполный стартовый пакет» при запуске в Kubernetes

Question

У меня есть автономный сервер PostgreSQL, работающий на Kubernetes. Я заметил в журнале следующие сообщения:

      incomplete startup packet

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

      readinessProbe:
  exec:
    command:
      - /postgresql/readiness.sh
  initialDelaySeconds: 45
  timeoutSeconds: 5
  periodSeconds: 10
livenessProbe:
  exec:
    command:
      - /postgresql/liveness.sh
  initialDelaySeconds: 45
  timeoutSeconds: 5
  periodSeconds: 10

где скрипты /postgresql/liveness.sh это примерно так:

      #!/bin/sh
if [ $(ps -ef | grep -v grep | grep postgres | wc -l) -lt 11 ]; then
    exit 1
else
    exit 0
fi

а также /postgresql/readiness.sh вот так:

      #!/bin/sh
su - user -c "/var/user/packages/postgres-11.9/bin/psql -p 2544 -d postgres -c \"SELECT 1\"" > /dev/null 2>&1

Проблема в том, что я все еще вижу сообщение в журналах и не знаю, как проверить, работают ли два зонда. Любое предложение?

Answer 1

Я нашел проблему. Если вы развертываете PostgreSQL в Kubernetes и предоставляете его как службу на облачной платформе, вам необходимо использовать балансировщик нагрузки. Этот балансировщик нагрузки проверяет работоспособность вашего приложения, отправляя пакеты работоспособности на порт PostgreSQL, и, поскольку это недопустимая команда PostgreSQL, приложение отвечает сообщением выше.

IBM Cloud не предлагает решения этой проблемы, и я думаю, что это сообщение можно проигнорировать. Чтобы сделать это менее раздражающим, просто установите правильное значение для проверки интервала (в моем случае 60 секунд вместо 5). Чем выше значение, тем меньше он будет раздражать, но будет меньше реагировать на сбои.

Кроме того, чтобы избежать неконтролируемого зондирования Kubernetes, всегда предоставляйте:

• проверка готовности
• зонд живучести
• начать зонд

В моем вопросе вы можете увидеть, как определить его для PostgreSQL. Единственное, что не упомянуто, - это стартовый зонд, который вы можете определить таким образом:

      startProbe:
  exec:
    command:
      - /postgresql/liveness.sh
  initialDelaySeconds: 45
  timeoutSeconds: 5
  periodSeconds: 10

для startProbe можно использовать тот же сценарий живучести, поскольку приложение можно считать запущенным, когда все процессы запущены и работают. Однако активный и запущенный процесс не означает, что он может принять соединение, и здесь срабатывает проверка готовности.

Answer 2

Я не могу сказать вам, что именно вызывает сообщения в вашем случае, но вы получите это сообщение об ошибке, если что-то устанавливает TCP-соединение с сервером базы данных, а затем отправляет мусор, а не действительный стартовый пакет.

Первые четыре байта сообщения интерпретируются сервером PostgreSQL как длина сообщения. Если сообщение короче этого, вы получите эту ошибку.

Ты можешь измениться чтобы PostgreSQL регистрировал IP-адрес клиента ( ), то вы знаете, откуда происходит соединение. Вам нужно будет выяснить, что на этой машине делает это. Часто это программа мониторинга, которая просто проверяет TCP-соединение без фактического установления соединения с базой данных.