Развертывание через google-kubernetes-engine: внутренняя ошибка сервера [500] (Google Cloud Platform) - PullRequest
Новая
       23

Развертывание через google-kubernetes-engine: внутренняя ошибка сервера [500] (Google Cloud Platform)

2 голосов
/ 26 марта 2020

Я использую Helm Диаграммы для развертываний на google-kubernetes-engine и использую в ней скользящее обновление.

В настоящее время у меня 10 стручков. Когда я делаю развертывание с использованием rolling-update, я ожидаю, что появится новый модуль, и трафик c остановится из-за того, что старый модуль упал, а затем он будет изящно снят. И так далее для следующих стручков.

Но в моем случае, когда создается новый модуль, старый модуль немедленно отключается, и я начинаю получать Internal Server Error [500] для запросов, выполняемых этим модулем.

Как мне избежать этого? 

      livenessProbe:
        httpGet:
          path: /health
          port: 4000
        initialDelaySeconds: 1
        periodSeconds: 10
      readinessProbe:
        httpGet:
          path: /health
          port: 4000
        initialDelaySeconds: 1
        periodSeconds: 10

1 Ответ

1 голос
/ 26 марта 2020

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

Стратегия обновления важна для определения количества недоступных модулей, которые вы можете иметь во время обновления. На данный момент простоя, вы можете установить это значение 0 и настроить разумное значение maxSurge.

Следующий шаг - убедиться, что у вас настроены соответствующие готовые пробники. Как только новый модуль помечен как готовый, контроллер попытается удалить один (или несколько) из старых модулей. Ваш модуль получит SIGTERM и перейдет к обработке, однако он настроен для этого. Это означает:

A) Убедитесь, что readinessProbe помечает модуль как готовый только после того, как он полностью может принять траффи c (/ health может работать, даже если приложение не работает, убедитесь, что это не так. случай).

B) Ваши старые модули должны правильно и изящно обрабатывать SIGTERM, это делается на прикладном уровне. Имейте в виду, что по умолчанию контроллер позволит корректно завершить работу модулей после отправки SIGTERM.

...