Это происходило пару раз с тех пор, как мы переместили наш кластерный проект с Google на AWS.
У нас есть том EFS, который смонтирован в кластере с балансировкой нагрузки в проекте Beanstalk.
Я буду что-то настраивать, либо загружаю большой ZIP-файл на этот том EFS (через экземпляр в кластере с балансировкой нагрузки), либо распаковываю его из сеанса ssh в экземпляре кластера, и я внезапно обнаружу экземпляр вырвался из-под меня, и обнаружил, что кластер породил два (или более) новых экземпляра и отключает тот, к которому я обращался.
Что здесь происходит? Все экземпляры - это экземпляры «t2-micro»; они неадекватны для длительной нагрузки и исчерпали ли максимальную мощность? Кто-нибудь видел что-нибудь подобное?
Итак, у вас есть это t2.micro в Группа автоматического масштабирования (ASG) Я полагаю?
И эта ASG настроена на масштабирование вверх / вниз в зависимости от средней загрузки процессора?
Вы перегружаете его большими манипуляциями с ZIP-файлами, исчерпываете Кредиты ЦП, CloudWatch замечает, что средняя загрузка ЦП превышает пороговое значение, и запускает новый экземпляр. Как и ожидалось.
Это снижает среднюю загрузку ЦП, и ASG завершает работу самого длительного экземпляра (того, над которым вы работаете). Как и ожидалось.
Я предполагаю, что ваши пороги увеличения / уменьшения слишком близки друг к другу (возможно, у вас есть масштабирование при нагрузке> 60% и уменьшение при загрузке <50%) - настройте больший разрыв, например 60% / 30%).
Не перегружайте T2 / T3, используйте T2 / T3 без ограниченийили используйте какой-либо другой тип экземпляра, например M4, M5 или C5, который не использует кредиты ЦП и обеспечивает стабильную производительность.
Рассматривать экземпляры в ASG как неизменный - вам следует никогда необходимо войти в экземпляр в ASG, вся их настройка должна выполняться автоматически с помощью сценариев Launch Config. Потому что никогда не знаешь, когда они начнутся или остановятся.
Надеюсь, это поможет :)