Можно ли задать --pod-eviction-timeout=300 м?

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

  Как только узел помечен как неработоспособный, диспетчер контроллера kube удалит его поды на основе –pod-eviction-timeout=5 мин. С.

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

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

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

к высшим.

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