Pull to refresh

Comments 46

Живенькая статья. Хотя за админов обидно :) И ещё, если бы примеров нормальных показали, было бы ещё лучше, под кат их, удобнее. В любом случае, спасибо, прочитал с удовольствием.
А что такое «примеров нормальных»? :)
Я не рискнул мастер мускуля поднимать в контейнере для продакшена, поскольку за полчаса не понял как сделать мастер-мастер репликацию или, хотя бы, слейвы делать мастерами, когда мастер дохнет. Вернее, за пару часов не смог дать оценку даже для самого себя, сколько времени мне понадобится на это даже без докера.

А с пользовательскими файлами решил просто: для контейнеров это локальный путь, для докера — volume с nfs драйвером, а для меня — nfs шара, которую подняли амины.
> поскольку за полчаса не понял как сделать мастер-мастер репликацию

Нужно читать сайт и блок перконы (http://percona.com), ключевые термины — pxc (синхронная репликация в mysql почти из коробки) и proxysql (который с недавних пор они пакуют в pxc).
Что касается nfs-шар — ну такое…

Во-первых, это медленно. Во-вторых, на той стороне nfs это тоже надо реплицировать, бэкапить, вот это всё.
Ну, nfs был выбран прежде всего, потому, что админы знают как его поддерживать. Собственно, любой сторадж, который поддерживается докером как volume подходит, кроме локального mount, для этой схемы. Следующим у нас на очереди для экспериментов был wmware storage (докер-хосты wmware виртуалки и их локальные диски и так wmware storage).

1) это медленно
2) все равно нужно решать вопросы с надежностью


:)

1) медленно — это вы про сам протокол или про идею хранить данные на сетевом хранилище в принципе?

Про идею хранить то, что предполагается как прямой io в сети.
Никто из разработчиков никогда про это не подумает. И однажды это больно укусит строителя такой системы за жопу.

"Никогда не говори никогда" :) Монтирование файловых систем (в том числе по сети) — очень распространенный приём (по крайней мере в Linux) и в худшем случае разработчик должен задокументировать, что та или иная функциональность рассчитана исключительно на локальные файловые системы, нарушает принцип "всё файл".

Не согласен. Разработчик в общем случае не должен предполагать какая ФС (а может и иерархия файловых систем, как часто бывает в случае docker или сетевых ФС) и в каком режиме она примонтирована под тем или иным путём и рассчитывать на особенности её поведения. Если предполагает, то должен свои предположения задокументировать.

Мало ли с чем ты не согласен. :)
Есть объективная реальность.

В объективной реальности файлы могут быть самыми разными и есть функции проверки различных свойств и способностей этих файлов. В некоторых субъективных реальностях эти функции игнорируются, а файлы субъективно наделяются свойствами по умолчанию, которых объективно у них нет.

В объективной реальности можно использовать файлы как локальный нетребовательный кеш для временных или промежуточных данных, что не помещаются в память.

И, внезапно, при смонтированном nfs или gluster можно получить абсолютно неприятные последствия. Поскольку он вроде бы как и есть, но с таким latency… что лучше бы его не было вообще

Статья зашла на одном дыхании.
Огромное спасибо от начинающего devOps'ера

Пожалуйста. Вообще тут описаны довольно тривиальные вещи, это скорее такое обобщение того, что мы делали без претензий на прорыв.
начинающим: использовали бы consul-registrator с регистрацией int network для контейнеров, не пришлось бы пихать отдельный сервис в каждый контейнер, зачем лишние телодвижения? Организация «дешёвой» сети несколько странная для админа, лучше уж какой-нить ospf или calico, но это уже придирки и на любителя, который сети изучал и знает, как не надо делать, т.е. присутствует некоторое стереотипное мышление по сетям.
У меня у самого сейчас, к несчастью, нечто похожее, т.к. кубернетес начальство не хочет, честно говоря, когда серверов больше 15, хотя бы раз в 5, уже возникают некоторые сложности.
Ну и плюс докерный healthcheck, а не консульный. У меня zabbix автоматом ругается, если контейнер начинает чудить, т.к. на контейнеры есть lld, хотя можно и консульный использовать, но неудобно опрашивать несколько dc, т.к. lld скрипт становится весьма развесистым.
> Зачем вот это все?

Ну с Kubernetes вам не понадобился бы тот же Consul для service discovery, не пришлось бы решать проблему 1 pid на контейнер и настройкой сети под каждый отдельный хост.
Можно было бы автоматически экспозить ваши сервисы как вам хочется, настроить выдачу persistent volumes, хранить конфиги/секреты как отдельные сущности, запускать привелегированные контейнеры и все такое

Но swarm да — он проще…
Именно. А ещё swarm можно развернуть локально, а кубер — почти нет. :)

Это была тема довольно долгой и горячей дискуссии на РИТ сразу после моего выступления.

Кубер нравится админам своей фичастостью. Для разработчика он добавляет ещё один, довольно широкий, пласт абстракции и новую предметную область. И это проблема.

Но вообще, если посмотреть на то что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем. Это ОЧЕНЬ простая система, которая ОЧЕНЬ завязана на внутренние соглашения в команде и знание про окружающий ландшафт. Поэтому она довольно бодро работает.
Ну, если вам не зашел minikube, всегда можно сделать окружения kubernetes для разработчика, где заставить их тестировать код.

Ну проблема в том, что «заставлять» — против моей личной идеологии, а значит надо дать инструменты. :)

Ну, назовем это не заставить, а поставить в список обязанностей протестировать код на вот таком вот тестовом кластере.


А пользоваться кубером вроде просто, особенно если уже есть pod для приложения. Но у меня такого нет, я только читал.

Нет, не просто.

Разное окружение при разработке и на проде (или тестовой среде) — это плохо.
> которая ОЧЕНЬ завязана на внутренние соглашения в команде и знание про окружающий ландшафт
Это же минус. Зная kubernetes, я могу в любой компании\проекте эти знания использовать.
> Это ОЧЕНЬ простая система
Конечно, когда вы ее релизовывали. Поработав с kubernetes, он тоже становиться простым и понятным, если смотреть со стороны разработчика, а не devops. Им то наверное посложнее.
> Зная kubernetes, я могу в любой компании\проекте эти знания использовать.
нуууу…

> Поработав с kubernetes, он тоже становиться простым и понятным, если смотреть со стороны разработчика

В чём угодно можно разобраться — вопрос только в целесообразности введения ещё одного уровня абстракции.
Ну с Kubernetes вам не понадобился бы тот же Consul для service discovery

Это не плюс а минус.


Consul стабильнее, чем ectd работал даже пребывая в виде зародыша альфа-версии

А ещё swarm можно развернуть локально, а кубер — почти нет. :)

Это ещё почему?


kubeadm init

Затем положить конфиг для CNI, и разрешить деплой на мастере:


kubectl taint nodes --all node-role.kubernetes.io/master- 

Вот вам и готовый локальный кластер.


В последнее время все сильно упростилось и развернуть кубер немногим сложнее чем тот же swarm.


Другое дело — целесообразность такого решения:
Например, я использую Docker дома в виртуалке и доволен этим решением. Не вижу смысла в Kubernetes, если все что нужно — это просто запускать контейнеры из Docker Hub на локалхосте.
Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.


Да, он несколько сложнее в освоении, но если разобраться вы получите отличный инструмент, который подойдет для решения широкого спектра задач.
Мое мнение, что Swarm — он слишком ограничивает.


что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем

Да, но заметьте, вам пришлось прибегать и к сторонним решениям, например обучать каждый сервис регистрироваться в Consul. Хоть это и не такая большая проблема, но придет время и вам захочется большего. Придется создавать новые сервисы и придумывать новые абстракции, когда в Kubernetes это все уже реализовано в единой экосистеме.

Придется создавать новые сервисы и придумывать новые абстракции, когда в Kubernetes это все уже реализовано в единой экосистеме.

Или перейти на Kubernetes или конкурентов, когда это станет экономически выгодно. Время на изучение, время на внедрение сложных систем (а Kubernetes простым не назвать) — это инвестиции в долгосрочные перспективы, а не в краткосрочные.


Вот представьте себя даже на месте ПМ, не говоря о собственнике бизнеса. Приходит вы к нему и говорите: "у нас сейчас инфраструктура на Docker swarm, предлагаю дать мне задачу изучить Kubernetes и перевести инфраструктуру на него". Примерный список вопросов к предложению:


  • чем не устраивает текущая?
  • сколько вашего времени потребует изучение?
  • сколько внедрение?
  • какие дополнительные ресурсы кроме вашего рабочего времени?
  • что мы получим от внедрения? Экономию ресурсов на разработку и доставку фич? Экономию ресурсов на эксплуатацию? Возможность нанимать менее квалифицированных разработчиков/девопсов/админов? Уменьшение потерь от простоев? Уменьшение числа и(или) длительности простоёв?

Это так, только навскидку.

у нас сейчас инфраструктура на Docker swarm, предлагаю дать мне задачу изучить Kubernetes и перевести инфраструктуру на него

Кажется я начал холивар :)


Хочу заметить, я ничего против Docker Swarm не имею, и если вам уже удалось выстроить нормально работающую инфраструктуру на нем, то зачем, в срочном порядке, пытаться заменить его на что-то другое?

А ты админ, да? :)


Кубер действительно любят админы. :)

Я думаю вся проблема в таких вот штуках.


Плюс обычно с контейнерами и кластерами идут такие штуки как rolling update, балансировка и прочие штуки, которые вроде значительно проще на Kubernetes делаются, а в swarm с этим раньше (а может и сейчас) был напряг.

Заметь, половина проблем там — с сетью.

Во-первых, это одна из причин, по которой мы не стали использовать networking докера.
Во-вторых, сейчас всё лучше.
Да, я админ)
Не то чтобы я шибко любил его, но из всех доступных решений считаю его самым адекватным.
> Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.

Это очень идеалистичный взгляд на мир. На самом деле всё вот это невозможно сделать ТОЛЬКО на уровне ops и оркестрации, не учитывая особенности приложения.

А если всё равно часть надо делать в приложении с учётом опыта разработчиков — почему не сделать это всё там? Тот вариант который я описывал в докладе не пытается решать проблему мирового голода и ответить на главный вопрос жизни, вселенной и всего остального.
Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.

CI он не решает. А только помогает.
С rolling updates на stateful вы снаружи приложения ничего не сделайте. Нужно участие самого приложения.
Про кластер рассказали в этой статье. Кибер не особо нужен


Кибер — штука хорошая.
Но она к сожалению многих вещей не решает.
Да, если у вас 1000 нод, то облегчит жизнь.
Но не более

К сожалению, с k8s в локальной инфраструктуре, все действительно не так просто, если говорить про HA развертывание с несколькими мастерами, kubeadm до сих пор разворачивает только кластер с 1 мастером, kubespray тот еще самолет с огромным количеством багов (печальный опыт и количество issue на GitHub от других испытателей), kops не дружит с Bare Metal, так что это проблема. Если есть удачный опыт в этой части буду крайне признателен.

Но при этом относительно Swarm Kubernetes — просто следующий уровень, лично я большой его фанат.
Ну я деплою мастер на HA-виртуалку, а точнее прямо в LXC-контейнере.
Все миньены работают на bare metal нодах.
Как результат есть и отказоусточивость, и ресурсы утилизируются по максимуму (по умолчанию деплой на мастере не рекомендуется), и бэкапить виртуальную машину гораздо проще чем физический хост.

Если интересно: вот мой конфиг, что бы заставить kubernetes работать внутри LXC-контейнера:
gist.github.com/kvaps/25f730e0ec39dd2e5749fb6b020e71fc
Учитывая последние новости про EKS, поход докера в поддержку кубера и разворачивание кубера одной кнопкой в docker for mac (beta) — приходится признать, что k8s становится отраслевым стандартом и глупо это игнорировать.

Но я бы не стал использовать весь диапазон его фич.

Ссылки картинками? 8-О


За что вы нас так не любите?

Это слайды из выступления. Я сейчас немножко попраздную и переделаю :)
> хотели попилить монолит на отдельные сервисы (но не микросервисы, а просто сервисы)
О, Автор! В Вашем случае, какая была разница между микро- и просто сервисом?
Я понимаю, что это холиворная тема и понятия растяжимые, но в данный момент сам замешан в распиливании монолита, и любопытно, где другие люди проводят границу?

ну в нашем случае:
— микросервис это сервис «одной функции» (не в смысле один def, а в бизнес-смысле. один справочник с crud, например)
— просто сервис это сервис «одной предметной области», например сервис «коммерция» в интернет-магазине и прайсы поставщиков разбирает, и лучший оффер выбирает, и цены считает с учётом пятка разных стратегий (и интерфейс для коммерсов для настройки этих стратегий даёт), и аналитику всякую считает и изменнённые цены пушит в системы, которым это важно… ну в общем делает «всё, что про цены». :)

Я для себя при дроблении монолита на (микро)сервисы решаю примерно так: если сервис, отвечает (читай — create/update/delete) только за одну сущность (вернее только за один агрегат), то он микросервис. Если же он для реализации своей бизнес-логики меняет несколько сущностей, про которые нельзя однозначно сказать, что одна является частью другой, то это просто сервис, минимонолит.

Спасибо за отсылку к Василию, порадовала )))

Sign up to leave a comment.