Kubernetes pod сеть повесить трубку - PullRequest
0 голосов
/ 22 октября 2019

Я использую кластер Kubernetes в Google Cloud (версия 1.13.7-gke.24). Один и тот же код работает на машине более 3 месяцев без проблем. Сегодня я обнаружил, что один из модулей отключился от сети более чем на 24 часа.

Сначала я проверил, есть ли у модуля подключение к Интернету, обычно оно есть. Я использовал curl для запроса некоторых известных интернет-сайтов - все они были вне досягаемости. То же самое произошло, когда я попытался запустить apt-get update или apt-get upgrade.

Во-вторых, я проверяю журналы своих приложений и обнаружил исключения, подобные этому:

Unable to log to provider GoogleStackdriverLogProvider, ex: Grpc.Core.RpcException: Status(StatusCode=Unavailable, Detail="Connect Failed")
   at Google.Api.Gax.Grpc.ApiCallRetryExtensions.<>c__DisplayClass0_0`2.<<WithRetry>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at ***.LogService.Providers.GoogleStackdriverLogProvider.WriteAsync(IEnumerable`1 entries) in LogService/Providers/GoogleStackdriverLogProvider.cs:line 71

Эти журналыисходят из кода, который я запускаю и который отправляет новые журналы в Google Stackdriver. Обратите внимание, что эти журналы хранятся в одном и том же центре данных - нет необходимости в интернете для их отправки, и, тем не менее, приложение не может добраться до места назначения.

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

Краткое описание:

Internet connectivity - NO
VPC connectivity - YES
GCP services connectivity - YES

Другие примечания:

  • Мне удалось ssh в проблемный модуль.
  • Перезапуск модуляисправил проблему.
  • Этого раньше не было. Я запускаю это развертывание более года.
  • Проблемной капсуле было 4 с половиной дня, когда я ее убивал.
  • Эта проблема затронула только один модуль. Все остальные (более 100 модулей) работали без проблем.

Что делать, чтобы предотвратить дальнейшую проблему?

1 Ответ

2 голосов
/ 27 октября 2019

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

К сожалению, если перезапустить контейнер недостаточно, модуль перейдет в состояние crashLoopBackOff. Вы можете настроить оповещения, которые уведомят вас о переходе модулей в это состояние, чтобы инициировать удаление модуля.

Хотя предотвратить это может быть невозможно, вы можете автоматизировать его восстановление

...