Kubernetes ограничивает количество одновременных перезапусков модуля во всем кластере

У нас есть кластер Kubernetes с 6 узлами, на котором работает около 20 больших рабочих нагрузок наборов реплик (службы Java). Запуск каждого модуля рабочей нагрузки (1 модуль на рабочую нагрузку) занимает в среднем около 30 секунд и использует много ресурсов ЦП. Это делает одновременный запуск нескольких модулей/рабочих нагрузок проблемой — до такой степени, что когда 2 или 3 запускаются одновременно на одном и том же узле, им требуется несколько минут для запуска и в конечном итоге их убивает проверка готовности. Зонд готовности довольно расслаблен, но продление льготного периода на неопределенный срок не кажется хорошей практикой.

Как можно себе представить, это делает блокирование и слив узла проблематичным — если мы сливаем узел, все поды перезапускаются одновременно где-то в другом месте и могут перегрузить воркер (или привести его к остановке, вызывая множественные перезапуски, которые в конечном итоге приводят к блокировкам базы данных). ).

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

Скрипты отлично работают для исправления сервера или обновления рабочей нагрузки, но не решают проблему сбоя узла — все работает в AWS, и когда узел выходит из строя, создается новый с помощью автомасштабирования, но это означает, что 4 модуля пытаются перезапуститься одновременно. время (обычно в воскресенье утром в 3 часа ночи, конечно).

Одна из идей состоит в том, чтобы иметь контейнер инициализации, который знает о других запускаемых рабочих нагрузках — если в настоящее время на том же узле не запускаются другие рабочие нагрузки, тогда контейнер инициализации завершает работу, позволяя запуститься основному контейнеру. Для этого потребуется учетная запись службы и разрешения, но это может быть обходной путь, но мне было интересно, есть ли более стандартный способ сделать это с помощью конфигурации (правила сходства и т. д.)?

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

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

Однако есть лучший способ добиться этого — с помощью ограничений распространения топологии pod. Указав ограничение распространения, планировщик гарантирует, что модули будут сбалансированы между доменами сбоя (будь то зоны доступности или узлы), и что сбой балансировки модулей приведет к сбою планирования.

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

вид: стручок
апиВерсия: v1
метаданные:
  имя: майпод
  этикетки:
    фу: бар
спецификация:
  топологияSpreadConstraints:
  - макс. перекос: 1
    topologyKey: зона
    whenUnsatisfiable: DoNotSchedule
    селектор меток:
      метки соответствия:
        фу: бар
  - макс. перекос: 1
    topologyKey: узел
    whenUnsatisfiable: DoNotSchedule
    селектор меток:
      метки соответствия:
        фу: бар
  контейнеры:
  - название: пауза
    изображение: k8s.gcr.io/pause:3.1

Это можно комбинировать с правилами сходства, если вы также не хотите, чтобы развертывания и их наборы реплик планировались с другими развертываниями на том же узле, что еще больше снижает эффект «группирования». Мягкая анти-привязка обычно уместна в таком случае, поэтому планировщик будет «стараться не» размещать эти рабочие нагрузки вместе, когда это возможно.