Обычно для таких маленьких инсталляций достаточно прокинуть с NAT порт на IP балансировщика. Но если у вас не NAT, то тут будет очень интересный квест с тем, чтобы наладить работу VXLAN и защитить необходимые порты, не потеряв работоспособности. Некоторые делают магию, в которой внутренний трафик идёт по VPN-туннелям, но вы опять же задолбаетесь настраивать и поддерживать такое. Я вообще не вижу практической пользы от этого для маленьких не сильно нагруженных установок.
Здесь очень подробно с таблицами расписано многое, но честно говоря такой вариант развёртывания больше проблем принесёт, чем облегчения. Если у вас один белый IP, то лучше спрятать за NAT и маршрутизатором. Если поставить как я показал в инструкции к "кетчупу", то на выходе у nginx ingress'а будет один конкретный локальный IP, на который с маршрутизатора направляете смело весь трафик c 80 и 443 портов. Нужно какой-то иной тип трафика завернуть или другой порт - создаёте Service с типом LoadBalancer, который так же получит из пула локальный IP и заворачиваете трафик на него.
Если же провайдер выделяет целую подсеть, то можно настроить Metallb на BGP вариант и каждый IP будет сразу наружу смотреть. Но этот сценарий уже потребует чуточку больше квалификации от устанавливающего, как минимум лучшего понимания работы сети, динамической маршрутизации и самого модуля Metallb.
Опять же, если я не правильно вас понял и у вас внешний балансировщик, то можно поднять сервис ingress с Nodeport и внешним балансировщиком завернуть трафик сразу на несколько нод по этому порту.
Это ещё один слой абстракции, который нужно входящему в сообщество знать или уметь. Ну и обслуживание такого кластера будет той ещё задачкой. Т.е. для нас с вами это в принципе ещё парочка инструментов, а для других курсы за 100 килорублей и полгода-год жизни. Я утрирую, но смысл в том, что можно проще и есть хорошие инструменты.
Ну в принципе да, у облачных нет функции размазывания функций мастера по кластеру. Но для небольших кластеров это порядка 1.5к руб/мес. Не сказать, что это прям очень много, но для некоторых может оказаться прям существенно.
Статистика продаж в облаках говорит об обратном. Это потом там появляется админ, который пытается раскурить всё что накликали. Но опыт общения с бизнесом и стартапами говорит о том, что сперва выберут облако.
Это мы с вами понимаем на практике и опыте как это бывает больно.
AWS это в принципе зло) Там столько нюансов связанных с тарификацией, что он в принципе убивает стартапы. Столько статей было про то, как какая-то фича по странному стечению обстоятельств выедала весь бюджет за сутки. В этом плане есть за что похвалить VK (MCS), ЯОблако, Селектел и прочих, что у них всё сильно проще зачастую.
Ну мы же говорим не про кровавый enterprise. Я понимаю о чём вы говорите. Но речь про небольшие конторы, где kubernetes это просто способ управления небольшой инфраструктурой для практически личных нужд.
Я бы так сказал, что mannaged нужен там, где вообще нет практически никакой экспертизы и всё, кроме разработки на аутсорсе. Хотя, имхо, я бы всё равно взял тот же Rancher или Deckhouse, вместо того чтоб повисать на каком-то облачном провайдере.
С точки зрения самой цитаты я бы не согласился. Mannaged Kubernetes по цене выйдет так же (практически) как и развёрнутый руками на VM того же облачного хостера. Ну и с точки зрения поддержки это решение будет проще и дешевле (хороший админ будет стоить как разница в цене с хостингом без mannaged). Я считал цены, например, сколько обойдётся держать кластер развёрнутый руками в ruvds (они реально довольно демократичны в цене и надёжности), и сколько обойдётся mannaged с автоскейлингом. Вышло так, что последний выйдет всего на 20% дороже, но в перспективе дешевле, потому что можно на время холостого хода сжимать кластер и разворачивать по мере увеличения нагрузки.
Единственное, что тут возникает вопрос целесообразности. Я в статье говорил как раз об отсутствии большой и пиковой нагрузки. Для таких конечно больше даже подойдёт bare-metal, потому что он окупит себя за полгода использования (по сравнению с облаком), но потребует некоторых усилий. Если в компании только разработчики, которые вообще ничего не умеют админить, то там вынужденно будет облако. Если же есть админы, куча железок и компания до 1к сотрудников из продаж и производства, то там выгоднее (зачастую, но не всегда) bare-metal.
Кстати, хорошая штука. Пользовался в Openmediavault, чтобы nextcloud и прочие сервисы поднять. Если forever single node, то вполне себе решение. Ничему новому, конечно, администратор не научится, но решение годное. Из одиночек ещё есть промышленная штука TrueNAS Scale и там многое "из коробки" будет и там очень хороший гуй.
Хотя я наверное не так посыл понял. Portainer можно развернуть в кластере, чтобы поднимать отдельно взятые контейнеры. Но я бы рекомендовал учиться пользоваться сразу промышленными инструментами вроде манифестов и helm'а.
Чтобы у вас не подгорало с такой силой, уточню. Имелось в виду stateful в kubernetes. Этот механизм не так давно из альфы и беты вышел. Однако, его появление в кубе такой же костыль, как ansible-pull.
Есть инструмент и спектр задач, который он предназначен покрывать. Многие stateful сервисы не рекомендует работу в контейнерах, потому что контейнер задуман эфимерным.
Использование stateful считается самым грозным антипаттерном. Вообще не понимаю что может побудить такое использовать в продакшене.
Наверное правильнее писать о том, что использовать нужно managed сервисы вместо stateful. Вот на такую статью надо сразу в карму плюсы кидать. Управляемый облаком кубер проблему миграции таких сервисов точно не решает точно, потому что шанс поломки ровно такой же, как и всех инструментов. За managed решением всегда один или несколько open source проектов или набор самостоятельных костылей, которые пишут ровно такие же специалисты (по квалификации, внимательности и качеству написания ченжлогов), что и у того же kops, rke, k3sup и прочих деплоеров.
Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?
Не хочется ребятам антирекламу делать, потому что объективно понимаю, что всего усмотреть просто невозможно в таких больших решениях. Да и так в двух словах не опишешь. Всё свелось к тому, что хотели до времени потушить кластер, чтоб деньги не кушал, а ноды остались бодрствовать. Техподдержка просто развела руками и сказала что баг и будут исправлять, а пока только убивать кластер. Благо в тестовом контуре всё было, так что и инсталляция небольшая была. К слову, остальные сервисы тушились хорошо.
Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?
Нет, это были разные кейсы и даже у разных компаний. Если будет время напишу статью.
Когда команда небольшая, вы скорее всего будете стремиться к максимальному упрощению своей инфраструктуры
Мне скорее интересна мотивация пихать всё в куб. Может изначально облако подобрано не очень? Либо с архитектурой беда, раз на команду обслуживания нет денег. Тут больше вопросов только появляется.
Кластер кубера вещь эфимерная, имхо. Полагаться, что кластер с кучей подвижных частей хорошо и правильно обновится это заведомо проигрышная стратегия. Зачастую обновления кластера проще сделать созданием нового, переносом нагрузки и тестированием с откатом. На облаках это обычно те же деньги, что и с обновлением, но происходит контролируемо и безопасно.
Опять же, говорить что managed лучше, потому что у отдельно взятой команды с определённым коэффициентом прямоты рук что-то не получилось с отдельно взятым инструментом - ошибка выжившего наоборот. Долго юзали Rancher. Ни одной проблемы не возникло подобного рода. А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$. Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.
Managed Kubernetes это про удобство и квалификацию команды, а не про стабильность и отсутствие багов.
В принципе, если собрать Python 3.11 из сырцов, без SQLite и некоторых бинарников, которые скорее всего не нужны для kopf и python-kubernetes, то думаю 20-30мб можно получить экономии. Alpine я бы не стал использовать. Есть прецеденты неадекватного поведения. Если ещё и базовый образ изначально полегче собрать (без кучи лишних утилит, которые не нужны оператору), то можно в принципе неплохо так сжать образ. Думаю я ещё много всяких оптимизаций смогу прикрутить, чтобы сделать базовый красивый образ под операторы на Python.
Они сдвоены по одной простой причине: это франшиза. Их родных точек на страну раз-два и нифига. Остальные это просто предприимчивые люди, которые занимаются организацией пунктов выдачи.
Без CRD можно использовать конфигмапы и секреты для хранения настроек. Будет не так красиво, но решение рабочее. Запретить оператор невозможно в принципе. Это же просто сервис, который использует стандартное API. Всё до чего могут дотянуться ваши руки, можно настроить и для оператора.
Но вообще можно и отдельный сервис реализовать. Но использование нативных возможностей всегда в приоритете.
Что про vars вы какую-то сложную ерунду написали. Каталог vars в себе содержит переменные константы, в то время как defaults содержит переменные, которые можно переопределять для роли. Тогда уже понятно, что в константы можно вынести портянки с вхардкоженными списками пакетов, которые нужно поставить, а в defaults - детали конфигурации, которые можно будет изменить при запуске роли.
Ничего не написали про то, что во всех этих директориях main.yaml является точкой входа, что часто путает новичков, создающих файлы по своему усмотрению.
По зависимые роли тоже странно написали. Во-первых, это как раз гарантирует, что роль будет запущена перед вашей. А во вторых, в ней можно перегрузить переменные для запуска конкретно для вашей роли. Например, я создал роль package_installer, чтоб в других ролях не заморачиваться с установкой нужных пакетов под каждую ось. Я ставлю её в зависимости, чтобы при установке своей роли знать, что нужные мне пакеты стоят.
Ему вообще чихать на протокол. Он спокойно http/3 может использовать. Вопрос будет ли лучше от протокола. Понимаете ли вы как они устроены и в каких случаях реально дают преимущества?
Формат обмена данными
...а ещё можно использовать msgpack (который без сжатия более эффективный, кстати), yaml, xml или любой другой (хоть свой изобретайте). И внезапно интегрироваться проще, больше нативной поддержки, как уже сказали выше, уменьшает размер бандла.
Избыточность
Вот опять же, странный маркетинговый булшит или как выкинуть непонятную метрику. Размер бадла или приложения говорит, что grpc избыточен. Более того, он более эффективно справляется в межсерверном взаимодействии, чем для клиента (а собственно кто сказал, что для конкретного PWA оно будет лучше?). Вся статья из домыслов состоит и передёргиваний.
Декларативность
Прям единственная правда. Единого стандарта и правда нет, потому что где-то удобнее выдать swagger 2.0, но часто лучше OpenAPI 3.0, но в некоторых случаях достаточно удобно HATEOAS. Притом каждый очень удобно подбирается под задачу, отлично жмётся br или gzip.
Больше половины преимуществ вообще звучат в стиле "это лучше потому что новое и крутое". Как, например, HTTP/2 преподносится как крутизна, но какую конкретно проблему он решает? Если это браузер, то можно сказать никакую, потому что в 1.1 есть keep-alived и браузер поднимает 8 параллельных соединений. На самом деле, довольно много кейсов, в которых это гораздо эффективнее. Но почему тогда не HTTP/3? Он вообще ж на udp и там круто решена проблема шифрования. REST API могут в него, а grpc? Я, кстати, не шучу, мне и правда интересно может ли.
Кстати, в http2 есть push-апи, от которого решили вообще отказаться. Так что это не односторонняя связь. Обычно, когда хотят двустороннюю связь поднимают websocket и его родственников.
Я надеюсь, что эти два комментария формат троллинга законопроектов на чистоту языка. Вообще очень тяжело переводить подобные термины, но соглашусь с предыдущим оратором, что inventory и инвентарь немного разные понятия в контексте ансибл. "Перечень" - более подходящий вариант, но если говорить за контекст, то там это скорее имя собственное, потому что им названа конкретная подвижная часть.
Просто вы как будто противоречите, но на деле сказали то же самое, просто другими словами. Tox это инструмент сборки и тестирования, притом отличный. Make, вообще-то это в первую очередь тоже инструмент сборки сишечных исходников (как бы он и заточен под последовательную сборку). Их обоих можно использовать для общего назначения вместо bash (но зачем?). Но это инструменты разных экосистем.
Поэтому я и говорю: не надо тащить инструмент другой экосистемы в Python. Там есть свои.
Обычно для таких маленьких инсталляций достаточно прокинуть с NAT порт на IP балансировщика. Но если у вас не NAT, то тут будет очень интересный квест с тем, чтобы наладить работу VXLAN и защитить необходимые порты, не потеряв работоспособности. Некоторые делают магию, в которой внутренний трафик идёт по VPN-туннелям, но вы опять же задолбаетесь настраивать и поддерживать такое. Я вообще не вижу практической пользы от этого для маленьких не сильно нагруженных установок.
Здесь очень подробно с таблицами расписано многое, но честно говоря такой вариант развёртывания больше проблем принесёт, чем облегчения. Если у вас один белый IP, то лучше спрятать за NAT и маршрутизатором. Если поставить как я показал в инструкции к "кетчупу", то на выходе у nginx ingress'а будет один конкретный локальный IP, на который с маршрутизатора направляете смело весь трафик c 80 и 443 портов. Нужно какой-то иной тип трафика завернуть или другой порт - создаёте Service с типом LoadBalancer, который так же получит из пула локальный IP и заворачиваете трафик на него.
Если же провайдер выделяет целую подсеть, то можно настроить Metallb на BGP вариант и каждый IP будет сразу наружу смотреть. Но этот сценарий уже потребует чуточку больше квалификации от устанавливающего, как минимум лучшего понимания работы сети, динамической маршрутизации и самого модуля Metallb.
Опять же, если я не правильно вас понял и у вас внешний балансировщик, то можно поднять сервис ingress с Nodeport и внешним балансировщиком завернуть трафик сразу на несколько нод по этому порту.
Это ещё один слой абстракции, который нужно входящему в сообщество знать или уметь. Ну и обслуживание такого кластера будет той ещё задачкой. Т.е. для нас с вами это в принципе ещё парочка инструментов, а для других курсы за 100 килорублей и полгода-год жизни. Я утрирую, но смысл в том, что можно проще и есть хорошие инструменты.
Почему? По сути биржа это обменник "фантиков". При том не важно, какими "фантиками" там торгуют.
Ну в принципе да, у облачных нет функции размазывания функций мастера по кластеру. Но для небольших кластеров это порядка 1.5к руб/мес. Не сказать, что это прям очень много, но для некоторых может оказаться прям существенно.
Статистика продаж в облаках говорит об обратном. Это потом там появляется админ, который пытается раскурить всё что накликали. Но опыт общения с бизнесом и стартапами говорит о том, что сперва выберут облако.
Это мы с вами понимаем на практике и опыте как это бывает больно.
В защиту комментатора скажу, что накликать кластер там и правда проще. Обслуживать и оплачивать, вот это уже другой разговор.
AWS это в принципе зло) Там столько нюансов связанных с тарификацией, что он в принципе убивает стартапы. Столько статей было про то, как какая-то фича по странному стечению обстоятельств выедала весь бюджет за сутки. В этом плане есть за что похвалить VK (MCS), ЯОблако, Селектел и прочих, что у них всё сильно проще зачастую.
Ну мы же говорим не про кровавый enterprise. Я понимаю о чём вы говорите. Но речь про небольшие конторы, где kubernetes это просто способ управления небольшой инфраструктурой для практически личных нужд.
Я бы так сказал, что mannaged нужен там, где вообще нет практически никакой экспертизы и всё, кроме разработки на аутсорсе. Хотя, имхо, я бы всё равно взял тот же Rancher или Deckhouse, вместо того чтоб повисать на каком-то облачном провайдере.
С точки зрения самой цитаты я бы не согласился. Mannaged Kubernetes по цене выйдет так же (практически) как и развёрнутый руками на VM того же облачного хостера. Ну и с точки зрения поддержки это решение будет проще и дешевле (хороший админ будет стоить как разница в цене с хостингом без mannaged). Я считал цены, например, сколько обойдётся держать кластер развёрнутый руками в ruvds (они реально довольно демократичны в цене и надёжности), и сколько обойдётся mannaged с автоскейлингом. Вышло так, что последний выйдет всего на 20% дороже, но в перспективе дешевле, потому что можно на время холостого хода сжимать кластер и разворачивать по мере увеличения нагрузки.
Единственное, что тут возникает вопрос целесообразности. Я в статье говорил как раз об отсутствии большой и пиковой нагрузки. Для таких конечно больше даже подойдёт bare-metal, потому что он окупит себя за полгода использования (по сравнению с облаком), но потребует некоторых усилий. Если в компании только разработчики, которые вообще ничего не умеют админить, то там вынужденно будет облако. Если же есть админы, куча железок и компания до 1к сотрудников из продаж и производства, то там выгоднее (зачастую, но не всегда) bare-metal.
Кстати, хорошая штука. Пользовался в Openmediavault, чтобы nextcloud и прочие сервисы поднять. Если forever single node, то вполне себе решение. Ничему новому, конечно, администратор не научится, но решение годное. Из одиночек ещё есть промышленная штука TrueNAS Scale и там многое "из коробки" будет и там очень хороший гуй.
Хотя я наверное не так посыл понял. Portainer можно развернуть в кластере, чтобы поднимать отдельно взятые контейнеры. Но я бы рекомендовал учиться пользоваться сразу промышленными инструментами вроде манифестов и helm'а.
Чтобы у вас не подгорало с такой силой, уточню. Имелось в виду stateful в kubernetes. Этот механизм не так давно из альфы и беты вышел. Однако, его появление в кубе такой же костыль, как ansible-pull.
Есть инструмент и спектр задач, который он предназначен покрывать. Многие stateful сервисы не рекомендует работу в контейнерах, потому что контейнер задуман эфимерным.
Использование stateful считается самым грозным антипаттерном. Вообще не понимаю что может побудить такое использовать в продакшене.
Наверное правильнее писать о том, что использовать нужно managed сервисы вместо stateful. Вот на такую статью надо сразу в карму плюсы кидать. Управляемый облаком кубер проблему миграции таких сервисов точно не решает точно, потому что шанс поломки ровно такой же, как и всех инструментов. За managed решением всегда один или несколько open source проектов или набор самостоятельных костылей, которые пишут ровно такие же специалисты (по квалификации, внимательности и качеству написания ченжлогов), что и у того же kops, rke, k3sup и прочих деплоеров.
Не хочется ребятам антирекламу делать, потому что объективно понимаю, что всего усмотреть просто невозможно в таких больших решениях. Да и так в двух словах не опишешь. Всё свелось к тому, что хотели до времени потушить кластер, чтоб деньги не кушал, а ноды остались бодрствовать. Техподдержка просто развела руками и сказала что баг и будут исправлять, а пока только убивать кластер. Благо в тестовом контуре всё было, так что и инсталляция небольшая была. К слову, остальные сервисы тушились хорошо.
Нет, это были разные кейсы и даже у разных компаний. Если будет время напишу статью.
Мне скорее интересна мотивация пихать всё в куб. Может изначально облако подобрано не очень? Либо с архитектурой беда, раз на команду обслуживания нет денег. Тут больше вопросов только появляется.
Кластер кубера вещь эфимерная, имхо. Полагаться, что кластер с кучей подвижных частей хорошо и правильно обновится это заведомо проигрышная стратегия. Зачастую обновления кластера проще сделать созданием нового, переносом нагрузки и тестированием с откатом. На облаках это обычно те же деньги, что и с обновлением, но происходит контролируемо и безопасно.
Опять же, говорить что managed лучше, потому что у отдельно взятой команды с определённым коэффициентом прямоты рук что-то не получилось с отдельно взятым инструментом - ошибка выжившего наоборот. Долго юзали Rancher. Ни одной проблемы не возникло подобного рода. А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$. Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.
Managed Kubernetes это про удобство и квалификацию команды, а не про стабильность и отсутствие багов.
В принципе, если собрать Python 3.11 из сырцов, без SQLite и некоторых бинарников, которые скорее всего не нужны для kopf и python-kubernetes, то думаю 20-30мб можно получить экономии. Alpine я бы не стал использовать. Есть прецеденты неадекватного поведения. Если ещё и базовый образ изначально полегче собрать (без кучи лишних утилит, которые не нужны оператору), то можно в принципе неплохо так сжать образ. Думаю я ещё много всяких оптимизаций смогу прикрутить, чтобы сделать базовый красивый образ под операторы на Python.
Они сдвоены по одной простой причине: это франшиза. Их родных точек на страну раз-два и нифига. Остальные это просто предприимчивые люди, которые занимаются организацией пунктов выдачи.
Без CRD можно использовать конфигмапы и секреты для хранения настроек. Будет не так красиво, но решение рабочее. Запретить оператор невозможно в принципе. Это же просто сервис, который использует стандартное API. Всё до чего могут дотянуться ваши руки, можно настроить и для оператора.
Но вообще можно и отдельный сервис реализовать. Но использование нативных возможностей всегда в приоритете.
Что про vars вы какую-то сложную ерунду написали. Каталог vars в себе содержит переменные константы, в то время как defaults содержит переменные, которые можно переопределять для роли. Тогда уже понятно, что в константы можно вынести портянки с вхардкоженными списками пакетов, которые нужно поставить, а в defaults - детали конфигурации, которые можно будет изменить при запуске роли.
Ничего не написали про то, что во всех этих директориях main.yaml является точкой входа, что часто путает новичков, создающих файлы по своему усмотрению.
По зависимые роли тоже странно написали. Во-первых, это как раз гарантирует, что роль будет запущена перед вашей. А во вторых, в ней можно перегрузить переменные для запуска конкретно для вашей роли. Например, я создал роль package_installer, чтоб в других ролях не заморачиваться с установкой нужных пакетов под каждую ось. Я ставлю её в зависимости, чтобы при установке своей роли знать, что нужные мне пакеты стоят.
Ему вообще чихать на протокол. Он спокойно http/3 может использовать. Вопрос будет ли лучше от протокола. Понимаете ли вы как они устроены и в каких случаях реально дают преимущества?
...а ещё можно использовать msgpack (который без сжатия более эффективный, кстати), yaml, xml или любой другой (хоть свой изобретайте). И внезапно интегрироваться проще, больше нативной поддержки, как уже сказали выше, уменьшает размер бандла.
Вот опять же, странный маркетинговый булшит или как выкинуть непонятную метрику. Размер бадла или приложения говорит, что grpc избыточен. Более того, он более эффективно справляется в межсерверном взаимодействии, чем для клиента (а собственно кто сказал, что для конкретного PWA оно будет лучше?). Вся статья из домыслов состоит и передёргиваний.
Прям единственная правда. Единого стандарта и правда нет, потому что где-то удобнее выдать swagger 2.0, но часто лучше OpenAPI 3.0, но в некоторых случаях достаточно удобно HATEOAS. Притом каждый очень удобно подбирается под задачу, отлично жмётся br или gzip.
Больше половины преимуществ вообще звучат в стиле "это лучше потому что новое и крутое". Как, например, HTTP/2 преподносится как крутизна, но какую конкретно проблему он решает? Если это браузер, то можно сказать никакую, потому что в 1.1 есть keep-alived и браузер поднимает 8 параллельных соединений. На самом деле, довольно много кейсов, в которых это гораздо эффективнее. Но почему тогда не HTTP/3? Он вообще ж на udp и там круто решена проблема шифрования. REST API могут в него, а grpc? Я, кстати, не шучу, мне и правда интересно может ли.
Кстати, в http2 есть push-апи, от которого решили вообще отказаться. Так что это не односторонняя связь. Обычно, когда хотят двустороннюю связь поднимают websocket и его родственников.
У меня всё.
Я надеюсь, что эти два комментария формат троллинга законопроектов на чистоту языка. Вообще очень тяжело переводить подобные термины, но соглашусь с предыдущим оратором, что inventory и инвентарь немного разные понятия в контексте ансибл. "Перечень" - более подходящий вариант, но если говорить за контекст, то там это скорее имя собственное, потому что им названа конкретная подвижная часть.
Давайте по порядку: как статья называется?
Просто вы как будто противоречите, но на деле сказали то же самое, просто другими словами. Tox это инструмент сборки и тестирования, притом отличный. Make, вообще-то это в первую очередь тоже инструмент сборки сишечных исходников (как бы он и заточен под последовательную сборку). Их обоих можно использовать для общего назначения вместо bash (но зачем?). Но это инструменты разных экосистем.
Поэтому я и говорю: не надо тащить инструмент другой экосистемы в Python. Там есть свои.