Comments 32
Если вы ищете более легкий способ, вы можете развернуть Кубернетес на облачном провайдере, таком как Google Kubernetes Engine или Amazon Elastic Kubernetes Service. Это означает, что вы можете избавиться от необходимости заниматься администрированием инфраструктуры и сосредоточиться на вашем приложении, и ваш провайдер заботится о надежности и масштабируемости.
Kubernetes может сделать жизнь администраторов небольших и средних компаний проще, поскольку он предоставляет мощные инструменты для управления инфраструктурой и приложениями. Например, Kubernetes позволяет автоматизировать развертывание, масштабирование и управление состоянием приложений, что может снизить нагрузку на администраторов и уменьшить вероятность ручного ошибочного действия. Кроме того, Kubernetes поддерживает множество облачных провайдеров и инструментов, которые могут помочь компаниям легко интегрировать его в свою существующую инфраструктуру
Если вы ищете более легкий способ, вы можете развернуть Кубернетес на облачном провайдере
Только там цены могут очень даже кусаться, особенно для небольших компаний или частных лиц.
С точки зрения самой цитаты я бы не согласился. Mannaged Kubernetes по цене выйдет так же (практически) как и развёрнутый руками на VM того же облачного хостера. Ну и с точки зрения поддержки это решение будет проще и дешевле (хороший админ будет стоить как разница в цене с хостингом без mannaged). Я считал цены, например, сколько обойдётся держать кластер развёрнутый руками в ruvds (они реально довольно демократичны в цене и надёжности), и сколько обойдётся mannaged с автоскейлингом. Вышло так, что последний выйдет всего на 20% дороже, но в перспективе дешевле, потому что можно на время холостого хода сжимать кластер и разворачивать по мере увеличения нагрузки.
Единственное, что тут возникает вопрос целесообразности. Я в статье говорил как раз об отсутствии большой и пиковой нагрузки. Для таких конечно больше даже подойдёт bare-metal, потому что он окупит себя за полгода использования (по сравнению с облаком), но потребует некоторых усилий. Если в компании только разработчики, которые вообще ничего не умеют админить, то там вынужденно будет облако. Если же есть админы, куча железок и компания до 1к сотрудников из продаж и производства, то там выгоднее (зачастую, но не всегда) bare-metal.
На мой взгляд это не так. Managed избавляет лишь от администрирования control plane. А это 5% работы от администрирования кластера. У меня есть как managed в нескольких облаках так и on-prem кластера. Количество работы практически одинаковое. Я бы даже сказал в облаках работы больше из-за нюансов облаков. Взять тот же eks.
Поэтому managed может обойтись даже дороже с точки зрения ФОТ. Админ по прежнему нужен, только более дорогой, спецы по облакам на рынке дороже стоят.
Ну мы же говорим не про кровавый enterprise. Я понимаю о чём вы говорите. Но речь про небольшие конторы, где kubernetes это просто способ управления небольшой инфраструктурой для практически личных нужд.
Я бы так сказал, что mannaged нужен там, где вообще нет практически никакой экспертизы и всё, кроме разработки на аутсорсе. Хотя, имхо, я бы всё равно взял тот же Rancher или Deckhouse, вместо того чтоб повисать на каком-то облачном провайдере.
Managed kubernetes в aws начинается от 76$ в месяц, и это только control plane, с 0 нод.
В целом managed намного проще даже k3s. И 76$ норм цена за 3 мастера и полную автоматизацию по управлению ими.
Но если нужно ещё дешевле, есть k3os, это bare metal k3s (переделанный alpine), операционная система которая сама менеджится через кубернетес (например обновить ОС).
AWS это в принципе зло) Там столько нюансов связанных с тарификацией, что он в принципе убивает стартапы. Столько статей было про то, как какая-то фича по странному стечению обстоятельств выедала весь бюджет за сутки. В этом плане есть за что похвалить VK (MCS), ЯОблако, Селектел и прочих, что у них всё сильно проще зачастую.
Если в компании только разработчики, которые вообще ничего не умеют админить, то там вынужденно будет облако
Если разработчики совсем не умеют админить, то им все равно придется как минимум нанять аутсорсера, чтобы он сконфигурировал им кластер в облаке, потому что там тоже куча своих нюансов. Мне кажется, что Кубер даже в виде managed service все же не для таких компаний, если бы спрашивали меня, таким пожалуй лучше смотреть в сторону Heroku или Google App Engine.
Если в компании только разработчики, которые вообще ничего не умеют админить, то там вынужденно будет облако
Там вынужденно появится админ или разработчики научатся админить.
С точки зрения самой цитаты я бы не согласился. Mannaged Kubernetes по цене выйдет так же (практически) как и развёрнутый руками на VM того же облачного хостера.
Это не так, control plane тоже стоит денег, что будет особенно заметно в случае с небольшим кластером.
Если вы ищете более легкий способ, вы можете развернуть Кубернетес на облачном провайдере
А вы это говорите потому, что сами пробовали, пользуетесь, и сравнивали, или просто на основе рекламы из интернета? ;) Т.к. я, несколько лет работая с k8s кластерами, не стал бы вот так с ходу утверждать, что k8s в облаке - "более легкий способ".
Если задача в том чтобы запускать docker образы или по описанию из docker-compose то есть хорошее решение в виде https://github.com/portainer/portainer . Очень простая конфигурация и поддержка установки на несколько хостов
Кстати, хорошая штука. Пользовался в Openmediavault, чтобы nextcloud и прочие сервисы поднять. Если forever single node, то вполне себе решение. Ничему новому, конечно, администратор не научится, но решение годное. Из одиночек ещё есть промышленная штука TrueNAS Scale и там многое "из коробки" будет и там очень хороший гуй.
Хотя я наверное не так посыл понял. Portainer можно развернуть в кластере, чтобы поднимать отдельно взятые контейнеры. Но я бы рекомендовал учиться пользоваться сразу промышленными инструментами вроде манифестов и helm'а.
Что угодно, лишь бы не использовать продукты от хэшиков и оставаться в рыночке k8s.
https://habr.com/ru/post/711440/#:~:text=Когда же всё это разворачиваешь руками
Ну зачем сразу все руками, на Ansible + Terraform можно неплохо полуавтоматизировать процесс, и даже наделать параметризированных заготовок для быстрого развертывания под типовые задачи, сделайте несколько хороших шаблонов для основных ситуаций в вашей фирме, и наслаждайтесь
Это ещё один слой абстракции, который нужно входящему в сообщество знать или уметь. Ну и обслуживание такого кластера будет той ещё задачкой. Т.е. для нас с вами это в принципе ещё парочка инструментов, а для других курсы за 100 килорублей и полгода-год жизни. Я утрирую, но смысл в том, что можно проще и есть хорошие инструменты.
И опять нормально про балансировщик никто не рассказал. Что, куда, как.
Я, конечно, документацию читал и даже примерно представляю как должно быть это все организовано... Но хотелось бы увидеть решения более опытных коллег.
Практически во всех статьях кубер и балансировщик сидят в одной локальной сети и никто не рассказывает как на этот ваш кластер правильно подать единственный белый IP. Всегда "это не входит в рамки статьи"
Обычно для таких маленьких инсталляций достаточно прокинуть с NAT порт на IP балансировщика. Но если у вас не NAT, то тут будет очень интересный квест с тем, чтобы наладить работу VXLAN и защитить необходимые порты, не потеряв работоспособности. Некоторые делают магию, в которой внутренний трафик идёт по VPN-туннелям, но вы опять же задолбаетесь настраивать и поддерживать такое. Я вообще не вижу практической пользы от этого для маленьких не сильно нагруженных установок.
Здесь очень подробно с таблицами расписано многое, но честно говоря такой вариант развёртывания больше проблем принесёт, чем облегчения. Если у вас один белый IP, то лучше спрятать за NAT и маршрутизатором. Если поставить как я показал в инструкции к "кетчупу", то на выходе у nginx ingress'а будет один конкретный локальный IP, на который с маршрутизатора направляете смело весь трафик c 80 и 443 портов. Нужно какой-то иной тип трафика завернуть или другой порт - создаёте Service с типом LoadBalancer, который так же получит из пула локальный IP и заворачиваете трафик на него.
Если же провайдер выделяет целую подсеть, то можно настроить Metallb на BGP вариант и каждый IP будет сразу наружу смотреть. Но этот сценарий уже потребует чуточку больше квалификации от устанавливающего, как минимум лучшего понимания работы сети, динамической маршрутизации и самого модуля Metallb.
Опять же, если я не правильно вас понял и у вас внешний балансировщик, то можно поднять сервис ingress с Nodeport и внешним балансировщиком завернуть трафик сразу на несколько нод по этому порту.
Я в экспериментах делал через host network, без metallb. Т.е. ingress (nginx) разворачивал на определенных нодах и на IP этих нод заворачивал трафик. В случае с NAT это не особо отказоустойчиво, но если на нодах с ingress есть белый IP адрес, то отказоустойчивость можно уже сделать через DNS.
У меня обычный набор виртуалок от обычного облачного провайдера с возможностью локальной сети между виртуалками. Белый IP есть на каждой ноде, но на большинстве я этот интерфейс отключаю ради безопасности.
Добавил небольшую заметку про балансировку в статью. Возможно будет полезно
Почему-то не упомянут rke от того же ранчера.
Крайне удобная штука. Пользуюсь уже года 4 - никаких проблем с ним нет. Мастер на vds за рублей 700 вроде, не помню даже. Максимально было в кластере около десятка машин и ~400 подов - проблем с кластером не было никогда.
Хз как rke себя поведет на малинках, но на обычных vds прекрасно себя чувствует.
Плюс в том, что там всегда безлимит трафика. Это окупает все эти «сожмемся пока нет нагрузки».
RKE, как и RKE2 не упомянут намерено. Во-первых, он чуточку жирнее (Control plane требует больше ресурсов для запуска, возможно потому что etcd и и куча ванильного k8s). Во-вторых, эта утилита требует сохранения стейта установки кластера. Если для k3s достаточно самого кластера, то rke привязывается к этому самому стейту. Это хорошо для gitops и так себе для админов стартующих один кластер на всю организацию. В-третьих, управление и обслуживание у них отличается.
Если так в лоб сравнить, то rke это утилита для деплоя почти (не возьмусь утверждать) ванильного кубера и нацелен больше на управление через облака (тут раскрывается вся их мощь node driver и cluster driver, когда можно дописать драйвер на любое облако с api), в то время как k3s это прям сразу облегчённый кубик, которому вообще пофиг где и как запуститься, работающий с sql-базой и живущий самостоятельной жизнью (без привязки к стейтам и прочему).
Плюс в том, что там всегда безлимит трафика. Это окупает все эти «сожмемся пока нет нагрузки».
Мы сейчас про внешний или внутренний трафик говорим? Внутренний вроде как почти везде, кроме AWS бесплатен. Насчёт VPS'ок это подходит как раз для небольших развёртываний без пиковых нагрузок. Т.е. для внутренних каких-то сервисов, маленьких интернет-магазинов и т.п. туда не придёт хабраэффект и не положит всё. И это реально дешевле если есть пачка админов (я считал местного известного vps хостера и местное облако - разница 30%).
Я, кстати, хотел в следующей статье про rke и rancher написать. Там нужно будет изрядно потрудиться, поэтому нужно время.
Про внешний трафик. Он меня всегда печалит в облаках - стоит как самолет.
Да, rke хранит стейт. Не знаю на счет "управления через облака". Оно просто разворачивает k8s через пачку контейнеров на указанных машинах по ssh. Стейт нужен вам, но не кластеру. Кластер вообще не знает через что он там запущен и точно так же живет самостоятельной жизнью.
По ресурсам. Прямо сейчас машина с 4 CPU / 12 RAM занята на 14-30% и 5 Gb. В данный момент пять воркеров, 199 подов. Скорее всего, k3s потребует чуть меньше, но разница там будет совсем уж +-500 руб в месяц.
Раз уж зашла тема, а расскажите зачем нужна пачка админов для обычного проекта? Ну т.е. я реально не понимаю, что они там будут делать. Во многих статьях про k8s рассказывают про мифическое "администрирование кластера" и начинают сравнивать "стоимость облака vs ЗП админа k8s". Что они там делают сутками? Что там постоянно ломается?
Тот же rke развернуть для обычного интернет магазина...ну там вообще никакой админ не нужен, хватит того самого разработчика этого же магазина. Причем одного.
Сколько машин нужно среднему интернет-магазину? Одна? Десять? Двадцать? Это все без проблем потянет средненький разработчик этого же магазина, ибо админить там особо нечего. Один раз разверните и пользуйтесь. Сломать кластер изнутри ненамеренно очень сложно.
Помню как-то раз я по ошибке снес свой кластер. Ну вот подчистую. Ошибся немного :) Знаете сколько времени заняло восстановить десяток машин в рабочее состояние? Около часа. Час времени работы даже очень крутого k8s-админа не будет стоить столько, сколько выкатит облако в сравнении с зоопарком vds.
Про внешний трафик. Он меня всегда печалит в облаках - стоит как самолет.
Если мы говорим не про AWS, то что же такое надо гонять через кластер, чтобы ощутить стоимость внешней сети? Я сейчас глянул тот же ЯОблако и там Исходящий трафик, свыше 100 ГБ в месяц 1,5300 ₽. Всё что меньше 100ГБ в месяц вообще бесплатно. Не представляю себе как раскачать на 4 CPU / 12 RAM занята на 14-30% и 5 Gb такой трафик эффективно. Если только от VPS в S3 заворачивать трафик и настроить отдачу HLS-трафика.
расскажите зачем нужна пачка админов для обычного проекта? Ну т.е. я реально не понимаю, что они там будут делать. Во многих статьях про k8s рассказывают про мифическое "администрирование кластера" и начинают сравнивать "стоимость облака vs ЗП админа k8s". Что они там делают сутками? Что там постоянно ломается?
С одним кластером не так много чего делают: обновляют (кластер обновить без downtime довольно интересная задача может быть), следят за актуальными версиями приложений и пакетов, мониторят CVE там всякие, соответствия всяким там PCI-DSS и прочим стандартам (тут важно понимать специфику кластера и его рабочих нагрузок) и многое другое по мелочи. В принципе, с одним кластером который загружен примерно в половину это максимум человеко-неделя в месяц. Если кластеров уже 10 в разных ДЦ, провайдерах и прочем, то тут всё будет кратно увеличиваться.
Но это не самая важная проблема. Ещё кучу рутинного времени занимает упаковка сервисов в CI/CD в кластере, да так чтоб с каким-нибудь ArgoCD да через Argo Workflows, да мгновенно и с согласованностью и с мягким переходом пользователей. В общем и целом работы и без того хватает, а тут ещё за кластером следить, да так чтоб без даунтаймов. Поэтому и считают, что на всю эту обслугу нужны будут люди кратно количеству кластеров.
Сколько машин нужно среднему интернет-магазину? Одна? Десять? Двадцать? Это все без проблем потянет средненький разработчик этого же магазина, ибо админить там особо нечего.
Давайте просто прикинем о какой вилке по зп для среднего разработчика магазина мы говорим? Теперь давайте просто откроем тот же hh и посмотрим как много там могут разработчики среднего уровня. Теперь посчитаем просто на калькуляторе. Я в принципе, считаю нужно подбирать инструмент под нагрузку. Если кластер поднимать только для одного интернет магазина, да ещё и монолита без особых изысков к скейлингу, то это вообще оверхед. Простой systemd внутри vps гораздо лучше справится, а выйдет гораздо дешевле. Если архитектура проекта это с десяток сервисов, каждый из которых можно равномерно скейлить и нужно горизонтальное масштабирование, то там лучше справится куб.
Помню как-то раз я по ошибке снес свой кластер. Ну вот подчистую. Ошибся немного :) Знаете сколько времени заняло восстановить десяток машин в рабочее состояние? Около часа.
Кубового админа обычно берут не ради одного часа на восстановление, а чтобы этого даунтайма в час никогда не случилось. Собственно большой кластер куба это про отсутствие даунтайма как такового.
Однако, хочу уточнить, что сама тема статьи как раз о том, что для небольших инсталляций, где downtime в час это прям ок и никто не умрёт, можно использовать очень удобно k3s, который как раз и рассчитан не небольшие статические кластеры для небольшого количества сервисов. В принципе, его можно адаптировать под high-volume/highload нагрузки, но с нюансами.
Ну у меня на проекте файлы генерятся и иногда 20-30 Гб может выжрать один пользователь за несколько часов. А пользователей много. Когда-то использовал S3 от Селектела для раздачи файлов, но оно стало отжирать больше, чем все серверы вместе взятые, так что проще было перейти на безлимитный VDS с minio.
кластер обновить без downtime довольно интересная задача может быть
Если мы говорим об обновлении версии k8s, то тот же rke умеет это делать без простоя. Там разве что ingress перезагружается, но это несколько секунд. Несколько раз обновлялся сам лично. Но, опять же, это разовая работа, а не ежемесячная поддержка.
Я понял, у нас отличается представление "обычного проекта". Я скорей говорю о приземленном, пусть интернет-магазине, который попилили (или сделали изначально) на микросервисы и засунули в кубер для более удобного управления и масштабирования. У которого нет десятка программистов, потому что им там нечем заняться. У которого CI/CD сводится к git push и helm upgrade на новые версии контейнеров.
Если у вас 10 кластеров в разных ДЦ, то это уже не обычный проект, как мне кажется.
Ладно. от темы статьи мы уходим :)
k3s я тоже когда-то смотрел, но rke мне приглянулся больше. Могу на своем опыте сказать, что для небольшого проекта это отличный выбор.
Я, кстати, хотел в следующей статье про rke и rancher написать. Там нужно будет изрядно потрудиться, поэтому нужно время.
Будет интерсно почитать
Не куб, а кубик: kubernetes для не-highload