Комментарии 6
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
А разве готовые платформы это не делают? Упрощение и улучшение пользовательского опыта и фич (для конечных пользователей). А то, что там внутри этой платформы, остаётся на откуп вендорам. Это стоит денег, но не согласен, что дешевле получать "граблями в лоб". Точнее, свои грабли могут быть дешевле до определенной точки размеров/зрелости бизнеса, при достижении которой каждый простой обходится сильно дороже готового продукта/его поддержки.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Особенно в стоимости оперативного решения проблем.
Почему? Почему с платформой (я больше про всякие OpenShift, а не облачные KaaS'ы) и поддержкой от вендора проблемы решать дольше/дороже, чем в самодельных инсталляциях Kubernetes?
Стоимость миграции — более очевидный, но всё-таки тоже спорный вопрос. Мигрировать с кастомных инсталляций, когда они разрослись (обросли кучей своих автоматизаций и удобств), на что угодно другое — это вовсе не простая (не дешёвая) операция :-)
чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках
По нашему опыту, обслуживание KaaS'ов вовсе не является таким простым и дешёвым, как в случае зрелой платформы. А чем дольше проект их использует, тем больше завязывается на специфику того, с чего потом больно уходить…
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
И "чем дальше в лес, тем толще волки".
Стандарты безопасности в Kubernetes (обзор и видео доклада)