Ну я деплою мастер на HA-виртуалку, а точнее прямо в LXC-контейнере.
Все миньены работают на bare metal нодах.
Как результат есть и отказоусточивость, и ресурсы утилизируются по максимуму (по умолчанию деплой на мастере не рекомендуется), и бэкапить виртуальную машину гораздо проще чем физический хост.
у нас сейчас инфраструктура на Docker swarm, предлагаю дать мне задачу изучить Kubernetes и перевести инфраструктуру на него
Кажется я начал холивар :)
Хочу заметить, я ничего против Docker Swarm не имею, и если вам уже удалось выстроить нормально работающую инфраструктуру на нем, то зачем, в срочном порядке, пытаться заменить его на что-то другое?
В последнее время все сильно упростилось и развернуть кубер немногим сложнее чем тот же swarm.
Другое дело — целесообразность такого решения:
Например, я использую Docker дома в виртуалке и доволен этим решением. Не вижу смысла в Kubernetes, если все что нужно — это просто запускать контейнеры из Docker Hub на локалхосте.
Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.
Да, он несколько сложнее в освоении, но если разобраться вы получите отличный инструмент, который подойдет для решения широкого спектра задач.
Мое мнение, что Swarm — он слишком ограничивает.
что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем
Да, но заметьте, вам пришлось прибегать и к сторонним решениям, например обучать каждый сервис регистрироваться в Consul. Хоть это и не такая большая проблема, но придет время и вам захочется большего. Придется создавать новые сервисы и придумывать новые абстракции, когда в Kubernetes это все уже реализовано в единой экосистеме.
Ну с Kubernetes вам не понадобился бы тот же Consul для service discovery, не пришлось бы решать проблему 1 pid на контейнер и настройкой сети под каждый отдельный хост.
Можно было бы автоматически экспозить ваши сервисы как вам хочется, настроить выдачу persistent volumes, хранить конфиги/секреты как отдельные сущности, запускать привелегированные контейнеры и все такое
Я режу всю рекламу на корню и белые списки тоже. Может кто-то посчитает что я не прав, но нет, я не хочу получать информацию об актуальных мне товарах таким образом.
Я не готов отключать адблок ради поддержки любимых сайтов, нет, только не таким способом.
У меня тоже было несколько интересных проектов, но я никогда не вставлял туда рекламу явно.
Мне нравится формат рекламных статей, но я терпеть не могу маленькие цветные ссылки наверху страницы, например.
Да, я помню бурления по поводу обзоров гаджетов.
У вас отличная статья и тематика такая что подходит на оба ресурса.
Но, если бы вы написали ее на Geektimes, то получили бы раза в 3 больше фидбека чем на хабре, даже не смотря на то, что там обзоры гаджетов.
Рейтинговая система тут не причем, она прекрасно работала и раньше. Просто в один прекрасный момент Хабр перестал быть хабром. Огромная часть коментаторов ушла на вновь образованный Geektimes и сторонние проекты, а Хабр разбавили со всякой маркутой, после чего все стало совсем уныло.
В результате Хабре превратился в сухой и скучный узкопрофильный сайт, где пишут в основном только рекламные статьи, и почти никто не читает.
Каждый раз захожу с надеждой, но все реже и реже, т.к. редко попадается что-то авторское и интересное.
Писать статьи тоже желание отпадает, зная что твоя статья просто затеряется среди всего этого и так и не найдет читателя.
IPSec — это один из протоколов который незавим для каждой из сторон (side-to-side vpn)
Причем как с серверной стороны (а именно центральный сервер здесь отсутствует как таковой, т.е. каждая сторона равноправна) так и со стороны оборудования (IPSec туннель можно настроить между оборудованием разных вендоров).
Считаю что в некоторых случаях он действительно может быть незаменим. Например, если вам необходимо настроить равноправный канал с какой-нибудь сторонней организацией — с большой долей вероятности это будет IPSec и чем его тут заменять непонятно.
Есть ещё такая штука как ZoneMinder, она бесплатна, камерами можно рулить через веб-интерфейс, настаивать зоны, просматривать записи, вот это все.
Возможно вам будет интересно.
Я имел ввиду девелоперы Kubernetes вынуждены говорить вам при установке: «вы должны использовать Docker не старше такой-то версии»
А вы в свою очередь имеете шанс столкнуться с некоторыми проблемами если не запретите Docker рулить iptables, т.к. этим уже занимается Kubernetes.
Ну я для подобных вещей использую ansible со стандартными модулями.
Причем если данные собранные ansible нужно сильно модифицировать перед отправкой, не вижу проблем использовать local_action с shell модулем, где данные можно подготовить с помощью того bash (или python).
В итоге получаем универсальный playbook с простыми набором задач, где каждая задача делает своё конкретное действие:
собирает данные
генерирует новые данные на основе полученных
записывает конфиг или генерит команды
отправляет конфиг или удаленно исполняет команды
На данный момент, мне кажется что это решение идеальное во всем. Так как оно универсальное, в нем легко разобраться и оно отлично работает.
PS: Вы не подумайте, мне очень интересна ваша статья и я определенно нашел в ней много полезного для себя. Но в силу того что я не очень хорошо знаю python, я бы реализовал это именно так.
А каково ваше мнение на счёт ansible?
to: fear86
С точки зрения Kubernetes — Docker по умолчанию несет в себе много ненужного, например встроенный инструментарий swarm или автоматическое конфигурирование правил iptables.
Когда выходит новая версия docker, совершенно не факт что Kubernetes будет нормально с ней работать.
В случае же с CRI-O это будет отдельный компонент, отвечающий только за контейнирезацию. Больше не нужно будет думать что разработчики Docker изменят в следующем релизе, что поломает текущее взаимодействие с Kubernetes.
Ну в production, чем надёжнее тем лучше. All-in-one установки по определю не могут быть более стабильными чем отдельно взятые компоненты в изолированных окружениях. В случае чего достаточно просто заменить отдельный компонент без ущерба для всей системы.
Второе качество — это воспроизводимость установки и простота обновления. Никому не хочется возиться с патчами и со сборкой кастомных пакетов если того действительно не требуется. Чем проще — тем лучше.
Это не говоря ещё о live-migration и high availability.
Все миньены работают на bare metal нодах.
Как результат есть и отказоусточивость, и ресурсы утилизируются по максимуму (по умолчанию деплой на мастере не рекомендуется), и бэкапить виртуальную машину гораздо проще чем физический хост.
Если интересно: вот мой конфиг, что бы заставить kubernetes работать внутри LXC-контейнера:
gist.github.com/kvaps/25f730e0ec39dd2e5749fb6b020e71fc
Не то чтобы я шибко любил его, но из всех доступных решений считаю его самым адекватным.
Кажется я начал холивар :)
Хочу заметить, я ничего против Docker Swarm не имею, и если вам уже удалось выстроить нормально работающую инфраструктуру на нем, то зачем, в срочном порядке, пытаться заменить его на что-то другое?
Это ещё почему?
Затем положить конфиг для CNI, и разрешить деплой на мастере:
Вот вам и готовый локальный кластер.
В последнее время все сильно упростилось и развернуть кубер немногим сложнее чем тот же swarm.
Другое дело — целесообразность такого решения:
Например, я использую Docker дома в виртуалке и доволен этим решением. Не вижу смысла в Kubernetes, если все что нужно — это просто запускать контейнеры из Docker Hub на локалхосте.
Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.
Да, он несколько сложнее в освоении, но если разобраться вы получите отличный инструмент, который подойдет для решения широкого спектра задач.
Мое мнение, что Swarm — он слишком ограничивает.
Да, но заметьте, вам пришлось прибегать и к сторонним решениям, например обучать каждый сервис регистрироваться в Consul. Хоть это и не такая большая проблема, но придет время и вам захочется большего. Придется создавать новые сервисы и придумывать новые абстракции, когда в Kubernetes это все уже реализовано в единой экосистеме.
Ну с Kubernetes вам не понадобился бы тот же Consul для service discovery, не пришлось бы решать проблему 1 pid на контейнер и настройкой сети под каждый отдельный хост.
Можно было бы автоматически экспозить ваши сервисы как вам хочется, настроить выдачу persistent volumes, хранить конфиги/секреты как отдельные сущности, запускать привелегированные контейнеры и все такое
Но swarm да — он проще…
Я не готов отключать адблок ради поддержки любимых сайтов, нет, только не таким способом.
У меня тоже было несколько интересных проектов, но я никогда не вставлял туда рекламу явно.
Мне нравится формат рекламных статей, но я терпеть не могу маленькие цветные ссылки наверху страницы, например.
У вас отличная статья и тематика такая что подходит на оба ресурса.
Но, если бы вы написали ее на Geektimes, то получили бы раза в 3 больше фидбека чем на хабре, даже не смотря на то, что там обзоры гаджетов.
В результате Хабре превратился в сухой и скучный узкопрофильный сайт, где пишут в основном только рекламные статьи, и почти никто не читает.
Каждый раз захожу с надеждой, но все реже и реже, т.к. редко попадается что-то авторское и интересное.
Писать статьи тоже желание отпадает, зная что твоя статья просто затеряется среди всего этого и так и не найдет читателя.
Причем как с серверной стороны (а именно центральный сервер здесь отсутствует как таковой, т.е. каждая сторона равноправна) так и со стороны оборудования (IPSec туннель можно настроить между оборудованием разных вендоров).
Считаю что в некоторых случаях он действительно может быть незаменим. Например, если вам необходимо настроить равноправный канал с какой-нибудь сторонней организацией — с большой долей вероятности это будет IPSec и чем его тут заменять непонятно.
При желании с ним даже без адблока жить вполне можно.
Возможно вам будет интересно.
А вы в свою очередь имеете шанс столкнуться с некоторыми проблемами если не запретите Docker рулить iptables, т.к. этим уже занимается Kubernetes.
Ну я для подобных вещей использую ansible со стандартными модулями.
Причем если данные собранные ansible нужно сильно модифицировать перед отправкой, не вижу проблем использовать
local_actionсshellмодулем, где данные можно подготовить с помощью того bash (или python).В итоге получаем универсальный playbook с простыми набором задач, где каждая задача делает своё конкретное действие:
На данный момент, мне кажется что это решение идеальное во всем. Так как оно универсальное, в нем легко разобраться и оно отлично работает.
PS: Вы не подумайте, мне очень интересна ваша статья и я определенно нашел в ней много полезного для себя. Но в силу того что я не очень хорошо знаю python, я бы реализовал это именно так.
А каково ваше мнение на счёт ansible?
С точки зрения Kubernetes — Docker по умолчанию несет в себе много ненужного, например встроенный инструментарий swarm или автоматическое конфигурирование правил iptables.
Когда выходит новая версия docker, совершенно не факт что Kubernetes будет нормально с ней работать.
В случае же с CRI-O это будет отдельный компонент, отвечающий только за контейнирезацию. Больше не нужно будет думать что разработчики Docker изменят в следующем релизе, что поломает текущее взаимодействие с Kubernetes.
Второе качество — это воспроизводимость установки и простота обновления. Никому не хочется возиться с патчами и со сборкой кастомных пакетов если того действительно не требуется. Чем проще — тем лучше.
Это не говоря ещё о live-migration и high availability.