Комментарии 18
Прекрасная статья, спасибо. Есть ли смысл использовать Spring Cloud (Eureka Registry, Config Server, Zuul) и Kubernetes вместе?
Вроде бы, в kubernetes уже есть service discovery и load balancer и динамический роутинг если какой то сервис умрет
Думаю союз Spring cloud и Kubernetes хорошая и логичная идея. Spring cloud — это технология нацеленная на организацию взаимодействия между компонентами в микросервисной архитектуре, а Kubernetes — платформа по управлению контейнерами. Если у Вас микросервисная архитектура или Вы хотите переписать на микросервисы, то Kubernetes поможет организовать управление и мониторинг контейнеров.
Опубликовали продолжение, часть 2: создание кластера и работа с ним
Подскажите, пожалуйста, когда стоит использовать Kubernetes, а когда Docker Swarm? Для меня swarm выглядит куда проще в настройке и поддержке.
Swarm проиграл маркетинговую войну.
Мы в компании рассматривали и то, и другое, в итоге действительно остановились на swarm, как на более прозрачном решении (разбирались с коллегой с нуля, опыта девопса почти не было).
В нашем понимании, k8s больше подходит для сервисов, которые можно закинуть куда-то в облака и двигать ползунки масштабирования, оценивая, как растут графики и утекают денежки из кошелька.
В нашем же случае мы уперлись в бутылочное горлышко в плане mysql, с которым не очень понятно, как его масштабировать в рамках контейнеров (у нас нагрузка пока не очень большая, и мы пока даже не реплицировали базу в ридонли реплики, но думаем над этим).
В итоге мы остановились на трех хороших серваках, над которыми поднят swarm, настроено много реплик api-сервисов / фронтендов, а базы один-единственный контейнер (с пробросом файлов на хост для надежности) и вполне себе справляется.
Возможно в дальнейшем при росте нагрузки мы будем рассматривать партицирование, и тогда наверное уже будем как-то вновь смотреть в сторону k8s. А пока что наш выбор — swarm.
Ну и swarm очень хорошо получилось подружить с teamcity. Все собирается автоматом, тестируется и с нулевым даунтаймом выгружается, без головной боли.
В нашем понимании, k8s больше подходит для сервисов, которые можно закинуть куда-то в облака и двигать ползунки масштабирования, оценивая, как растут графики и утекают денежки из кошелька.
В нашем же случае мы уперлись в бутылочное горлышко в плане mysql, с которым не очень понятно, как его масштабировать в рамках контейнеров (у нас нагрузка пока не очень большая, и мы пока даже не реплицировали базу в ридонли реплики, но думаем над этим).
В итоге мы остановились на трех хороших серваках, над которыми поднят swarm, настроено много реплик api-сервисов / фронтендов, а базы один-единственный контейнер (с пробросом файлов на хост для надежности) и вполне себе справляется.
Возможно в дальнейшем при росте нагрузки мы будем рассматривать партицирование, и тогда наверное уже будем как-то вновь смотреть в сторону k8s. А пока что наш выбор — swarm.
Ну и swarm очень хорошо получилось подружить с teamcity. Все собирается автоматом, тестируется и с нулевым даунтаймом выгружается, без головной боли.
Зависит от объёма кластера и нагрузки на него. Кубернетес таки местами устанавливает адекватные настройки системы, в отличие от сварма, полагающегося на админа, к примеру.
Далее, немного разные сети, в кубернетесе, к примеру, по-умолчанию все связаны со всеми, что несколько проще для понимания и даёт мЕньшую нагрузку на conntrack (если не настраивать систему, как большинство докерастов делает, позже упрётся в net.netfilter.nf_conntrack_max, который ещё и поправляется кубернетесом в бОльшую сторону).
Ну и незакрывающиеся баги тоже влияют, отчего у нас некоторое время назад _пришлось_ отказаться от сварма о девяти узлах в пользу просто кучки докеров и ручной оркестрации из-за того, что сварм после какого-то количества сетей (порядка трёх десятков) стал терять связность между контейнерами — тоже показатель (на гитхабе на момент переезда соответствующие issue открыты уже 4 года). В сторону кубернетеса смотрим, но пока именно смотрим — слишком много переделывать придётся на работающей системе.
Далее, немного разные сети, в кубернетесе, к примеру, по-умолчанию все связаны со всеми, что несколько проще для понимания и даёт мЕньшую нагрузку на conntrack (если не настраивать систему, как большинство докерастов делает, позже упрётся в net.netfilter.nf_conntrack_max, который ещё и поправляется кубернетесом в бОльшую сторону).
Ну и незакрывающиеся баги тоже влияют, отчего у нас некоторое время назад _пришлось_ отказаться от сварма о девяти узлах в пользу просто кучки докеров и ручной оркестрации из-за того, что сварм после какого-то количества сетей (порядка трёх десятков) стал терять связность между контейнерами — тоже показатель (на гитхабе на момент переезда соответствующие issue открыты уже 4 года). В сторону кубернетеса смотрим, но пока именно смотрим — слишком много переделывать придётся на работающей системе.
Собираю сейчас кластер на амазоне(ну как собираю — в прод пока не пускали, но запустили и решаем что удобнее — эластик или сварм) и потому возникло пару вопросов. Пожалуйста, если не сложно, ответьте:
сварм после какого-то количества сетей (порядка трёх десятков) стал терять связность между контейнерамиоверлейных сетей? обычных? сколько было мэнеджеров и влияло ли их добавление? каковы симптомы были? — просто сварм терял ноду или она выпадала из докер-машины?
Оверлейных, конечно… Впрочем, добавление ~40 контейнеров в одну оверлейную сеть примерно так же влияло, только нагрузка требовалась бОльше.
Узлов было 8, всех пришлось сделать менеджерами как обход другого бага, на этот раз с днс внутри контейнера (на момент переделки тоже не был закрыт несколько лет).
Симптомы — тупо не было связи между контейнерами на разных узлах, никаких потерь узлов и т.п.
Подозреваю, что с host network если не все проблемы, то бОльшая часть решилась бы, но host network — это для бОльшей части контейнеров перебор, там не зря nginx с ssl auth был установлен на фронте.
Узлов было 8, всех пришлось сделать менеджерами как обход другого бага, на этот раз с днс внутри контейнера (на момент переделки тоже не был закрыт несколько лет).
Симптомы — тупо не было связи между контейнерами на разных узлах, никаких потерь узлов и т.п.
Подозреваю, что с host network если не все проблемы, то бОльшая часть решилась бы, но host network — это для бОльшей части контейнеров перебор, там не зря nginx с ssl auth был установлен на фронте.
т.е. у вас не оставалось ни одного управляющего менеджера? все были под нагрузкой? а что с DNS случилось?
Менеджер в сварме не застрахован от размещения контейнеров, если не писать для этого отдельное правило руками в каждом .yml. До oom/высокого LA если и доходило, то точно не за несколько месяцев до переделки, так что тут пофиг, вобщем-то, хоть и несколько неправильно.
Что касается dns — на воркерах сварма часть контейнеров не видела ип-адреса соседей по сети. Только на воркерах. На некоторое время решалось рестартом всех зависимых друг от друга стеков в определённом порядке, но это геморрой. Однозначно решилось переделкой всех воркеров на менеджеры.
Что касается dns — на воркерах сварма часть контейнеров не видела ип-адреса соседей по сети. Только на воркерах. На некоторое время решалось рестартом всех зависимых друг от друга стеков в определённом порядке, но это геморрой. Однозначно решилось переделкой всех воркеров на менеджеры.
Очень интересно! Можете поподробнее рассказать про «три десятка сетей», какую задачу решает такое их количество?
Здравствуйте, планирую начать по вашей методичке, но первым же делом встал вопрос
Сначала расскажем о том, как запустить на компьютере приложение, основанное на микросервисах.на каком таком компьютере? (VM подойдет? какие ресурсы оптимальны?) и какая базовая ОС должна быть на нём?
Руководство по Kubernetes, часть 1:
– немного java
– немного python
– немного о контейнерах
Извините, а где хоть что-то про Kubernetes? Заголовок один сплошной кликбейт.
– немного java
– немного python
– немного о контейнерах
Извините, а где хоть что-то про Kubernetes? Заголовок один сплошной кликбейт.
Да уж и ссылки нет на вторую часть, в которой якобы все есть. И навигация на хабре так себе, листай пока не найдешь
Еле накопал habr.com/ru/company/ruvds/blog/438984
Еле накопал habr.com/ru/company/ruvds/blog/438984
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по Kubernetes, часть 1: приложения, микросервисы и контейнеры