Я оказался в ситуации, когда мне необходимо уменьшить масштаб экземпляров контейнера в зависимости от их фактического срока службы. Похоже, что свежие экземпляры удаляются первыми при уменьшении масштаба через API марафона. Есть ли какая-либо конфигурация, о которой я не знаю, для реализации такой стратегии или политики при масштабировании экземпляров на apache marathon?
На данный момент я использую marathon-lb-autoscale для автоматической настройки числа запущенных экземпляров. Что на самом деле происходит под капотом, так это то, что marathon-lb-autoscale выполняет запрос PUT, обновляя свойство instances текущего приложения, когда req/s увеличивается или уменьшается.
scale_list.each do |app,instances|
req = Net::HTTP::Put.new('/v2/apps/' + app)
if [email protected]?
req.basic_auth(@options.marathonCredentials[0], @options.marathonCredentials[1])
end
req.content_type = 'application/json'
req.body = JSON.generate({'instances'=>instances})
Net::HTTP.new(@options.marathon.host, @options.marathon.port).start do |http|
http.request(req)
end
end
end
Я не знаю, используется ли конфигурация upgradeStrategy учитывать при масштабировании экземпляров. С настройками по умолчанию я не могу заставить работать ожидаемое поведение.
{
"upgradeStrategy": {
"minimumHealthCapacity": 1,
"maximumOverCapacity": 1
}
}
ДЕЙСТВИТЕЛЬНЫЙ
- экземпляр 1
- экземпляр 2
PUT /v2/apps/my-app {instances: 3}- экземпляр 1
- экземпляр 2
- экземпляр 3
PUT /v2/apps/my-app {instances: 2}- экземпляр 1
- экземпляр 2
ОЖИДАЛ
- экземпляр 1
- экземпляр 2
PUT /v2/apps/my-app {instances: 3}- экземпляр 1
- экземпляр 2
- экземпляр 3
PUT /v2/apps/my-app {instances: 2}- экземпляр 2
- экземпляр 3
