У меня есть развертывание службы весенней загрузки A с балансировкой нагрузки, скажем, в кластере Kubernetes с 3 узлами.
У меня также есть требование включить быстрое управление конфигурацией без необходимости перестраивать + развертывать полностью переработанный образ.
Для этого я собрал конфигурационный сервер весенней загрузки, а также реализовал перезапуск Actuator на сервисе A, который при вызове своей конечной точки / restart в локальном развертывании единственного экземпляра обновляется и загружается со свойствами, полученными с конфигурационного сервера.
Пока все хорошо, но ...
Как можно достичь вышеупомянутого, когда служба A развернута в более крупномасштабном развертывании k8s с 3, 30 или 300 экземплярами службы A?
Конечная точка вызова / обновления должна обрабатываться балансировщиком нагрузки, как и любой другой вызов REST в кластере, то есть он направляется в один из экземпляров службы.
Есть ли в springboot-on-k8s стандартный способ вызова каждого экземпляра службы, игнорируя LB?




Я не знаю стандартного шаблона для этого.
Каждый из ваших модулей приложения, который соответствует селектору для вашей службы, будет зарегистрирован как конечная точка для этой службы. Если вы запустите kubectl get endpoints, вы должны увидеть все внутренние IP-адреса кластера для модулей, поддерживающих вашу службу.
Вы можете создать некоторую логику для вызова этой конечной точки / обновления для каждой конечной точки службы.
Типичный способ сделать это при развертывании Kubernetes - развернуть новые модули с обновленной конфигурацией, а не перенастраивать запущенные модули, как упоминал Бал Чуа. Обычно поды должны быть неизменяемыми, и их повторная конфигурация на месте является антипаттерном. Вам не нужно ничего перестраивать, если вы вынесете свою конфигурацию в конфигурационную карту или секрет.
Я согласен с тем, что модули неизменяемы, но, поскольку в определении модуля нет изменений, kubernetes не будет выполнять обновление. Вам придется уменьшить его до нуля, что приведет к простою. Отношение к стручкам как к неизменным всегда было нашей привычкой. Но в таких случаях нам просто нужно немного нарушить правила.
Я согласен с тобой @BalChua. Использование метки даты - хороший обходной путь, который я использовал и раньше.
На самом деле мы не используем перезапуск исполнительного механизма, вместо этого мы используем стратегию развертывания RollingUpdate. Когда мы хотим «перезапустить» поды, мы запускаем патч kubectl.
kubectl patch deployment web -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"
Хорошая документация по стратегии обновления.
Тем не менее, задаваться вопросом, существует ли стандартизованный подход, мне кажется, что я изобретаю колесо заново.