Можем ли мы иметь --pod-eviction-timeout = 300 м? - PullRequest
Новая
       47

Можем ли мы иметь --pod-eviction-timeout = 300 м?

1 голос
/ 01 апреля 2020

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

Чтобы предотвратить вытеснение стручка, мы настроили все пакеты как гарантированное качество обслуживания. Я знаю, что даже в этом случае выселение стручка может произойти, если в системе возникнет нехватка ресурсов. У нас есть мониторы, которые предупреждают нас, когда в модуле и узле возникает нехватка ресурсов. Таким образом, мы узнаем путь прежде, чем стручок будет выселен. Это помогает нам принять меры до того, как pod будет выселен.

Другие причины для вытеснения pod состоят в том, что если узел находится в неготовом состоянии, то kube-controller-manager проверит тайм-аут pod-eviction-timeout и он будет выселять стручки после этого тайм-аута. У нас есть монитор, чтобы предупредить нас, когда узел переходит в состояние неготовности. Теперь, после этого предупреждения, мы хотели предпринять некоторые меры для очистки со стороны приложения, поэтому приложение будет корректно завершено. Чтобы выполнить эту очистку, нам нужно больше, чем несколько часов, но по умолчанию время ожидания pod-eviction-timeout составляет 5 минут.

Можно ли увеличить время вытеснения капсулы до 300 м? Каковы последствия увеличения этого тайм-аута до такого предела?

PS: Я знаю, что в течение этого времени ожидания, если модуль использует больше ресурсов, тогда kubelet может сам выселить этот модуль. Хотелось узнать какой еще эффект от ожидания такого долгого времени?

1 Ответ

0 голосов
/ 01 апреля 2020

Как сказал @ coderanger , ваши пределы неверны, и это следует исправить вместо понижения самоисцеления возможностей Кубернетеса.

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

  • , если у вас возникают проблемы с pod, все еще находящимся отправлять запросы, когда он не отвечает, вы должны реализовать LB впереди или поставить в очередь запросы,
  • , если у вас возникает проблема с IP-адресами, которые меняются после перезапуска pod, это следует исправить с помощью DNS и service вместо прямого подключения к модулю,

  • , если ваш pod выселяется, проверьте, зачем, установите ограничения и запросы,

    Что касается узла, то здесь есть действительно хороший пост в блоге о Повышении надежности Kubernetes: более быстрое обнаружение нода вниз , это противоположно тому, что вы думаете делать, но также упоминает, почему 340s слишком много

    Как только узел помечен как нездоровый, диспетчер контроллера куба удаляет свои модули, основываясь на –pod-eviction-timeout = 5m0s * 1 030 *

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

Если вы все еще хотите изменить значения по умолчанию на более высокие, вы можете посмотреть на изменение этих параметров:

  • kubelet: частота обновления состояния узла = 10 с
  • диспетчер контроллера: период мониторинга узла = 5 с
  • контроллер-менеджер: узел-монитор-льготный период = 40 с
  • контроллер-менеджер: pod-eviction-timeout = 5m

для более высоких.

Если вы предоставите более подробную информацию, я постараюсь помочь больше.

...