Комментарии 21
Тот самый случай, когда IT вместо решения проблем начинает создавать их. IT-отрасль все больше начинает напоминать монстра из фильма "Эволюция".
Такими размышлениями можно и свою квартиру никогда не покупать, а всегда снимать.
Мне кажется даже в вашем примере все зависит от обстоятельств, не говоря уж о k8s. Я не призываю всех поголовно отказываться от своего k8s, а просто рассказываю, что проблем у него хватает. С каждым новым релизом k8s становится все сложнее и сложнее, как по мне, а соответственно его поддержка все дороже и дороже. И с точки зрения оптимизации расходов важно найти ту самую грань, где выгоднее ставить свой k8s, а где воспользоваться готовым платным решением.
Мне кажется Kubernetes становится проще. Если раньше его развернуть было непросто, то сейчас есть kubeadm. Обновление через kubeadm upgrade или установка нового кластера. Плюс всегда можно почитать changelog. DevOps состоит не только из Kubernetes. Сопутствующие инструменты тоже изменяются и там тоже приходится разбираться. (тот же Gitlab).
То что он становится мощнее и круче - не значит проще. Согласен, что до сих пор появляются какие-то решения, которые упрощают жизнь. Однако вместе с ними появляется куча нововведений за которыми нужно следить и знать как они работают. Для этого порой changelog'a недостаточно и нужно лезть в сорцы. А там ты натыкаешься на такое... ну например на то, что я описал касательно protokube.service
Аналогию понял, но тезис, в пользу которого Вы её используете, - нет. Мне правда интересно, что Вы имели ввиду, сможете поподробнее описать недостатки размышлений автора и чем плохо "всегда снимать" ?
Например, будучи пенсионером сложно прожить только на одну пенсию, не говоря о том, что еще надо снимать квартиру. Второй вариант можно остаться без работы, серьезно заболеть и просто не будет денег на аренду жилья. А если есть жилье, то такие сложные моменты можно пережить и на крайний случай даже его продать.
В случае с облаком, я работаю в организации, где 3 года были сложности с развитием ИТ. Были деньги на интернет и электричество и если бы ресурсы были в облаках, то не было бы денег, чтобы их оплачивать. В случае с Kubernetes на своей инфраструктуре можно поднять рядом новый кластер и потихоньку переносить нагрузки, параллельно выводя ресурсы из старого кластера и поднимая новые узлы в новом кластере.
Очень странная аналогия с квартирами, особенно в условиях перегретого рынка недвижимости РФ, покупать квартиру выглядит странной затей. Что касается пенсии или безработицы, то для таких ситуаций нужны накопления, надеяться прожить на одну пенсию – это вообще самоубийство.
Про ваш опыт в компании с проблемами, скорее всего следует дополнить предложение "Были деньги на интернет и электричество и на зарплату людям, поддерживающим свой k8s".
Кластер кубера вещь эфимерная, имхо. Полагаться, что кластер с кучей подвижных частей хорошо и правильно обновится это заведомо проигрышная стратегия. Зачастую обновления кластера проще сделать созданием нового, переносом нагрузки и тестированием с откатом. На облаках это обычно те же деньги, что и с обновлением, но происходит контролируемо и безопасно.
Опять же, говорить что managed лучше, потому что у отдельно взятой команды с определённым коэффициентом прямоты рук что-то не получилось с отдельно взятым инструментом - ошибка выжившего наоборот. Долго юзали Rancher. Ни одной проблемы не возникло подобного рода. А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$. Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.
Managed Kubernetes это про удобство и квалификацию команды, а не про стабильность и отсутствие багов.
Спасибо, что поделились своим опытом! Тоже юзали Rancher и выглядел он довольно неплохо на тот момент, однако с ним также возникало немало других проблем. Возможно, как Вы выразились, у нас был недостаточный коэффициент прямоты рук, но когда строили свой private cloud, мы много где отгребли.
Зачастую обновления кластера проще сделать созданием нового, переносом нагрузки и тестированием с откатом
Мне всегда было интересно почитать материалы на такие темы, особенно когда там описана миграция каких-нибудь сложных stateful сервисов. У меня как-то был опыт перетаскивания cassandra и postgres на другие k8s без простоя, но эти сервисы как бы подразумевают такую возможность. А вообще эта тема интересная, но как по мне это усложнение инфраструктуры. Кстати когда я описывал миграцию с KIAM, то да, это самый простой вариант обновления без простоя в нашей ситуации
А вот в одном облаке не удалось потушить часть нод на время и это вылезло в $$$
Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?
Про обновления вообще молчу - ни разу не удалось качественно обновиться без простоев.
Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?
Managed Kubernetes это про удобство и квалификацию команды
Это имеет место быть. Однако здесь важно еще упомянуть размер команды. Когда команда небольшая, вы скорее всего будете стремиться к максимальному упрощению своей инфраструктуры
Использование stateful считается самым грозным антипаттерном. Вообще не понимаю что может побудить такое использовать в продакшене.
Наверное правильнее писать о том, что использовать нужно managed сервисы вместо stateful. Вот на такую статью надо сразу в карму плюсы кидать. Управляемый облаком кубер проблему миграции таких сервисов точно не решает точно, потому что шанс поломки ровно такой же, как и всех инструментов. За managed решением всегда один или несколько open source проектов или набор самостоятельных костылей, которые пишут ровно такие же специалисты (по квалификации, внимательности и качеству написания ченжлогов), что и у того же kops, rke, k3sup и прочих деплоеров.
Можете поподробнее описать как так получилось, в чем была проблема и какое это было облако?
Не хочется ребятам антирекламу делать, потому что объективно понимаю, что всего усмотреть просто невозможно в таких больших решениях. Да и так в двух словах не опишешь. Всё свелось к тому, что хотели до времени потушить кластер, чтоб деньги не кушал, а ноды остались бодрствовать. Техподдержка просто развела руками и сказала что баг и будут исправлять, а пока только убивать кластер. Благо в тестовом контуре всё было, так что и инсталляция небольшая была. К слову, остальные сервисы тушились хорошо.
Почему-то у меня складывается ощущение, что речь о каком-то конкретном облаке. Можете поделиться?
Нет, это были разные кейсы и даже у разных компаний. Если будет время напишу статью.
Когда команда небольшая, вы скорее всего будете стремиться к максимальному упрощению своей инфраструктуры
Мне скорее интересна мотивация пихать всё в куб. Может изначально облако подобрано не очень? Либо с архитектурой беда, раз на команду обслуживания нет денег. Тут больше вопросов только появляется.
Stateful-сервисы - это не антипаттерн, а один из видов бизнес-сервисов. Некоторые сервисы просто невозможно сделать stateless, а другие нерационально. Речь идет о таких вещах как игровые сервера, потоковые сервисы, биржевые сервисы и так далее - везде, где важно иметь вычисления в большом объеме оперативной памяти и важно соблюдать порядок сигналов. Мне как разработчику и архитектору странно слышать от девопса призыв не делать stateful только потому что в кубере с ним проблемы. В некоторых бизнес-задачах такой опции просто нет. Специалист, который о своем удобстве думает больше, чем о задачах бизнеса у меня вызывает удивление.
Чтобы у вас не подгорало с такой силой, уточню. Имелось в виду stateful в kubernetes. Этот механизм не так давно из альфы и беты вышел. Однако, его появление в кубе такой же костыль, как ansible-pull.
Есть инструмент и спектр задач, который он предназначен покрывать. Многие stateful сервисы не рекомендует работу в контейнерах, потому что контейнер задуман эфимерным.
Не нужно городить огород, в облаках с одним аккаунтом нужно использовать просто Terraform, с мультиаккаунтами Terragrunt, а не kops.
Цена managed k8s cluster'a на AWS - 0.1$ в час, итого за месяц использования выходит - 0.1$ * 730 часов = 73$, то есть 12 k8s кластеров стоят 876$ в месяц.
К чему эти подсчёты? Если ваш k8s не cloud provider managed, то вам вообще-то нужно 3 мастера и всякая обвязка, что не бесплатно. В итоге cloud managed k8s выйдет вам дешевле + не нужно обслуживать некоторые компоненты, а это время команды, т.е. $$$.
использование k8s это уже vendor agnostic
Зачем стремиться быть vendor agnostic, если AWS предоставляет невероятно крутую экосистему сервисов? Не используя всё это, вы просто ограничиваете себя и свою команду в возможностях и тратите кучу $$$ на оплату лишних часов команды.
в случае чего без проблем переехать с одного на другой, если возникает такая необходимость
В случае чего?
В случае необходимости резко сократить бюджет лучше изначально правильно планировать архитектуру именно с учётом специфики использования AWS , а не просто использовать всякие вещи вроде spot instances, Karpenter, keda & etc , хотя и это делают не все.
Или нужно начать оказывать услуги клиентам там, где нет AWS (таких мест, помимо России, в мире всё меньше)? Такое, конечно, бывает, но часто (не всегда) можно обойтись proxy / cdn и т.д.
В остальном, если у вас не какой-то серо чёрный бизнес и сам AWS вас не выгоняет, то смысла переезжать с него почти никогда нет.
Добрый день.
К чему эти подсчёты?
К тому, что managed k8s чаще выходит дешевле, чем использование своего, в статье после этих расчетов я об этом как раз и рассуждаю.
Зачем стремиться быть vendor agnostic, если AWS предоставляет невероятно крутую экосистему сервисов?
Если нужно развернуть свой SaaS в регионе без AWS. ОАЭ например.
с учётом специфики использования AWS , а не просто использовать всякие вещи вроде spot instances, Karpenter, keda & etc
Spot instances можно как раз отнести к специфике использования облака, потому что не все облака это предоставляют
Как хорошо, что все обсуждающие эту тему верят в то, что облако никогда не может отказать в обслуживании без каких-либо причин и затаскивают критически важную для компанию инфраструктуру в мега-надëжное облако.
А потом иногда оказывается, что для получения бана в облаке достаточно иметь "неправильное" гражданство или проживать в "неправильной стране" или просто неверно высказаться про какое-то движение (хз, допустим вовремя не похвалить ЛГБТ, не встать на колено или не сделать какую-то ещё публичную трендовую штуку).
p.s. Если что - это троллинг. В России довольно много компаний очень серьёзно попало с облачными сервисами только из-за того, что "потому, что санкции". И очень странно читать такую статью на русскоязычном ресурсе без упоминания того, что произошло совсем недавно (к примеру, я лишился своего AWS аккаунта из-за блокировки платежей моей карты Visa, но это же мои проблемы, верно?).
Если нужно развернуть свой SaaS в регионе без AWS. ОАЭ например.
Плохой пример и регионов всё больше и больше
https://aws.amazon.com/blogs/aws/now-open-aws-region-in-the-united-arab-emirates-uae/
Но чаще всего необходимости иметь инфру именно в том регионе реально нет.
Без упоминания про необходимость платить за мастеров, lb для них и т.д. в "своём" k8s это как-то странно.
Да, согласен, упустил этот момент, спасибо. Добавил упоминание.
Плохой пример и регионов всё больше и больше
Я лишь описал с каким примером столкнулся на практике. Дело было в 2019-2020 и в ОАЭ балом правил Azure. Сейчас появляется все больше и больше регионов, это не может не радовать. Однако мой главный посыл был не только про AWS, а про любые облака в целом.
Однако мой главный посыл был не только про AWS, а про любые облака в целом.
2019 и 2023 это огромная разница и опубликовав статью в 2023 нужно понимать, что деплоить k8s в AWS не Terraform/Terragrunt, а kops'ом - это дичь. Также касается Azure и GCP.
После нескольких попыток мы так и не смогли начать использовать эту функциональность kops: как оказалось, мигрировать существующие кластера на нее без простоя невозможно.
Потому что не нужно использовать kops :) Хотя он не делает ничего магического и мигрировать существующие кластера с kiam на "IAM roles for service accounts" вам вероятно не удалось всё же не по вине kops или просто не докрутили.
По-хорошему нужно просто написать Terraform/Terragrunt и воспользоваться import или создать новый EKS и мигрировать приложения в него.
Вам не нужен свой Kubernetes