Льготный период? - AWS EC2 Контейнер для обслуживания и балансировки эластичной нагрузки
Когда эластичный балансировщик нагрузки (ELB) связан с группой автоматического масштабирования, можно указать льготный период, в течение которого новые экземпляры EC2 не будут прекращены, даже если ELB пометит их как нездоровые. Можно ли указать аналогичный льготный период, в течение которого новые задачи ECS не будут уничтожены и перезапущены связанной с ними службой ECS, даже если экземпляр ECS, в котором выполняется задача, был помечен ELB как нездоровый?
Обновить:
В нашем текущем сценарии использования докер-контейнер, выполняемый как задача ECS, содержит экземпляр JBoss, который загружает несколько кэшей при запуске. Загрузка этих кэшей может занять несколько минут. Однако служба ECS регистрирует экземпляр контейнера в ELB, как только контейнер запущен. Это означает, что трафик может быть направлен в новый контейнер, прежде чем он будет готов принять его. Мы могли бы увеличить интервал проверки работоспособности и "пороги работоспособности / нездоровья" на ELB, чтобы запретить ELB направлять трафик к экземпляру и службе ECS перезапускать контейнер до тех пор, пока не будут загружены кэши. Однако увеличение интервала и пороговых значений работоспособности нежелательно, поскольку, если экземпляр был помечен как нездоровый после загрузки кэшей, служба ECS должна как можно скорее перезапустить контейнер (что требует более короткого интервала проверки работоспособности и меньших пороговых значений).).
Таким образом, возможно ли применить льготный период, в течение которого трафик не будет направляться в новый контейнер с помощью ELB, а служба ECS не будет перезапускать контейнер (даже если он не пройдет проверку работоспособности)? Или, если это не так, есть ли какие-либо предложения относительно решения для нашего варианта использования?
1 ответ
После обсуждения со службой поддержки выясняется, что ECS не может поддержать наш текущий вариант использования.
Существует обходной путь, который решает одну из проблем, с которыми мы сталкиваемся. Этот обходной путь заключается в создании отдельного необходимого контейнера для проверки работоспособности и в той же задаче ECS, что и в реальном контейнере приложения. Целью контейнера проверки работоспособности является мониторинг контейнера приложения, чтобы определить, когда приложение было запущено полностью. Если он обнаруживает, что приложение не удалось запустить, оно завершается, в результате чего служба ECS выполняет цикл задачи. ELB затем настраивается для выполнения своих проверок работоспособности в контейнере проверки работоспособности, который всегда будет сообщать, что он подключен через соответствующий порт. Этот обходной путь предотвратит повторное выполнение службой ECS задачи ECS из-за неудачных проверок работоспособности.
Однако ELB немедленно начнет маршрутизацию трафика в контейнер приложения. Это будет сделано, даже если контейнер приложения еще не готов к приему трафика (например, потому что он все еще ожидает загрузки кэша). В настоящее время нет способа отложить отправку ELB трафика в контейнер приложения, поскольку служба ECS не предоставляет льготный период поддержки. Нам удалось обойти эту проблему, предоставляя сообщения в контейнеры нашего приложения через SQS и получая их только из очереди, когда их кэши полностью загружены. Однако в будущем у нас есть варианты использования (например, обслуживание веб-запросов), когда это невозможно. С этой целью я намерен поднять запрос на предоставление льготного периода.
Кроме того, оба Kubernetes (http://kubernetes.io/v1.0/docs/user-guide/walkthrough/k8s201.html) и марафон (https://mesosphere.github.io/marathon/docs/health-checks.html) уже поддерживает эту опцию для проверки работоспособности, если кто-то, читающий это, рад, что не использует управляемый сервис.