Комментарии 56
Кроме этого, если в Kubernetes по умолчанию поддерживаются пространства имен (Namespaces), которые можно эффективно использовать для разделения сред разработки, то в Nomad данная функциональность доступна только в Enterprise-версии.
Уже нет. В nomad 1.0 namespaces стали доступны в opensource-версии.
Однако дальнейшее администрирование Apache Mesos сложнее по сравнению с K8s, так как необходимо работать с ZooKeeper, уметь администрировать Java и быть готовым к связанным с этим трудностям: утечкам памяти, Xmx, лимитам и так далее. Kubernetes с Golang в этом плане проще.
Данное утверждение показывает только личные предпочтения автора.
Думаю для восстановления баланса во Вселенной стоит оставить оставить тут такой текст:
К тому же дальнейшее администрирование Kubernetes сложнее по сравнению с Mesos, так как необходимо составлять многостраничные манифесты, работать с etcd, уметь администрировать Golang и быть готовым к связанным с этим трудностям: утечкам памяти, сегфолтам, лимитам и так далее. Mesos с Java в этом плане проще.
Я к тому, что особенности администрирования есть в любой из этих систем, особенно когда их размер достигает десятков тысяч узлов и сводить это к holywar о языках реализации не стоит.
Вот тут есть рейтинг популярности языков программирования TIOBE Index, Java более 20 лет занимает 1 и 2 позиции. Это значит, что есть множество программ разработанных на этом языке и их кто то эксплуатирует. Golang стал более менее заметен только с 2017 года и до сих пор не дотянул не то что до Java, но даже и до Visual Basic.
Так что нет, Java более знакома в эксплуатации и возможно именно поэтому имеет большое количество средств диагностики, мониторинга и настройки, которых в Golang просто нет — неуспели сделать. Это разнообразие видимо и дает ощущение сложности.
Но я бы предпочел эксплуатировать критическую часть инфраструктуры имея в своем арсенале все эти инструменты.
А как же rancher до версии 2.x?
Знающие люди, подскажите — чем k8s лучше чем terraform + aws (забудем про eke) с точки зрения администрирования и поддержки? И там и там кластер описывается конфигом, есть автомасштабирование и виртуальные сети.
Ничем
Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое. Не думаю чтотв этом нет некого умысла.
Что касается озвученных недостатков nomad. Или авторы не владеют полностью темой или пытаются подыграть k8s. Nomad это один из продуктов в стеке от hashicorp. Другой который ведает секретами это vault и еще есть другие. Так недостаток ли это что функционал разный по своей природе не впихнули в один черный ящик а распределили между разными продуктами стека?
Что касается реальных недостатков nomad это проблема с зависимыми заданиями. Хотя возможно ее уже пофиксили
Так как поднять и главное обслуживать его своими силами просто немыслимо
Почему? В моей практике кубер просто работает и никого ничем не парит. Как по мне, это больше миф, который распространился как вирус, а облачные провайдеры подхватили его и начали толкать managed решения. То, что в нем много компонентов, не является прямым следствием сложности работы с ним. Как правило, эти компоненты живут своей жизнью и никого не трогают.
Но вот когда что-то идёт не так, то даже определить какой компонент надо смотреть пристальней может быть не просто
Поднять просто. Тем боле сейчас есть несколько решений например от canonical. Сложности начинаются когда оно начинает включить и куда бежать не х известно черный ящик
Ну вот вы хотя бы знали про etcd и смогли локализовать проблему
Не ставил сам никогда вот и не знаешь, досталось так сказать в наследство внезапно.
Есть уже по крайней мере 2 решения которые кажутся удобными и в установке и в поддержке https://k3s.io/ и microk8s
Значит у Вас все еще впереди.
Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое.
В таком случае можно взять managed-решение с Kubernetes от стороннего поставщика (не облачного провайдера), которое позволяет [одновременно] использовать и bare metal, и разные облака (и даже мигрировать между ними). Такие решения уже существуют. С ними вы сохраняете независимость от поставщика инфраструктуры (один из главных бонусов Kubernetes, который незаметно убили те самые облака в своих интересах), но при этом уже не нуждаетесь в трудоёмком обслуживании кластеров своими руками.
Что касается Nomad — да, действительно Vault, так же, как Consul, Consul Template и ряд других продуктов, фактически являются компонентами одного стека компании Hashicorp. Но если говорить конкретно о секретах, то у Kubernetes это реализовано из коробки и не требует дополнительных настроек или компонентов. То что секреты хранятся в закодированном, а не зашифрованном виде, в Kubernetes решается через разграничение прав. И также не требует дополнительных компонентов.
Совместимость это увы не всегда переносимость. Контрпример. Вы реализуете базовый функционал + даете клиентам еще что-то в виде бонуса например липкие контейнеры для баз данных, ssl сертификаты, PROXY-PROTOCOL и всепереносимости уже нет.
Совместимость это увы не всегда переносимость. Контрпример. Вы реализуете базовый функционал + даете клиентам еще что-то в виде бонуса например липкие контейнеры для баз данных, ssl сертификаты, PROXY-PROTOCOL и всепереносимости уже нет.
Все так. А как только ты расширяешь функционал кубернетеса теми же операторами — прибиваешь себя гвоздями к ним и к версии куба. Наверное, это не так уж и плохо ) но нужно понимать, что хоть базовый API и структура манифестов одинаковая, но специфика будет в каждой установке.
Так как поднять и главное обслуживать его своими силами просто немыслимо.
Мыслимо, но это нужно иметь целую команду инженеров. Вот давайте возьмём способ развёртывания кубера. Их есть с десяток и каждый из них имеет свои особенности и нюансы. А ведь это только установка! Потом кластер ещё и поддерживать и обновлять придётся! И не факт, что условный kubespray будет в конкретной инфраструктуре делать это гладко! А если мы ещё и хранилище тащим в кубернетес… вах. Боль и тлен.
Поэтому managed решения срезают часть проблем и сложности. И люди в них идут
В рекламной статье продвигающий сервис компании на базе кубера победил… барабанная дробь… кубернетис!!! Сюрприз-сюрприз!!!
Отдельно доставило про "безопасность в кубернетесе из коробки". Отличная безопасность когда все секреты лежат в base64 — прям непрошибаемая!
А уж кубер — победитель в категории "самое легкое управление кластером" — это вообще за гранью.
А вообще сложно сравнивать что-то с кубером, ибо сейчас вокруг него крутиться такое сообщество, которое компенсирует практически все недостатки.
P.S. ну и в целом маил.ру во всей своей красе =\
Победил только в случае managed кластера, самим поднимать и обслуживать не рекомендуется ;) Тогда он легкий в управлении )
Отличная безопасность когда все секреты лежат в base64 — прям непрошибаемая!
Эм, это все равно что сказать: секреты в vault хранятся в открытом тексте, потому что я могу их прочитать когда у меня есть к ним доступ: vault kv get secret
. Или пароль небезопасный, потому что мне его сообщили.
Мы можем прочитать base64 секрета в кубе, когда мы имеем к нему доступ, ровно также как и в vault. base64 очевидно там для удобства хранения бинарных данных. Секреты в кубе в etcd хранятся в шифрованном виде, при монтировании в pod'ы как файлов, секреты всегда хранятся в памяти, и монтируются в tmpfs и никогда не сохраняются на диске узла. Многим этого достаточно, а кому недостаточно и нужно централизованное хранение секретов, используют vault и интегрируют его с кластерами k8s.
Единственное место, где можно несанкционированно почитать секреты в vault — это память запущенного vault (ну ок, можно еще посередине попробовать стырить атакой MiTM).
Теперь сравните это с тем, в скольких местах мы можем у кубера это все дело прочитать.
Ну так это другой вопрос. Вопрос безопасного хранения секретов в k8s vs хранения их в vault. Понятно что в vault с этим лучше, поскольку это ПО которое именно для этого предназначено.
Теперь сравните это с тем, в скольких местах мы можем у кубера это все дело прочитать
А давайте сравним, эта информация будет полезна многим. Раз уж утверждаете, то давайте по существу и с аргументами. В каких местах можно несанкционированно прочитать секреты куба, не имея к ним доступ по RBAC?
Но я так и не понял, как к этому относится формат хранения секретов куба(base64). По этой логике, когда я сохраняю секрет в vault в строке формата base64, то он становится небезопасным?
Если вы попали на хост с etcd
Вот с этого места подробнее. Попадание на хост (да еще с рут правами) почти в любой системе это, как правило, уже катастрофа. Я бы сказал, что и до взлома волта тут рукой подать — я могу банально подсунуть свою форк волта вместо родного, который, условно, всю базу сдампит в темп. Надо определиться все таки, какая модель угроз. Потому как подавляющему большинству хватит защит, которые попадание на хост как раз затрудняют.
Попадание на хост (да еще с рут правами) почти в любой системе это, как правило, уже катастрофа.
В случае кубера это не запредельно сложно.
Примеры https://habr.com/ru/company/southbridge/blog/540216/
Но в статье то сказано что у кубера все лучше, а у nomad у которого все секреты как правило хранятся в vault с защитой все плохо
Мы этот момент его об уждаем в связи с заявлением что у курьера есть защита а у nomad нет. Хотя все совершенно наоборот. То есть у nomad нет необходимости иметь защиту так как для этого используют vault. А nomad плюс vault защищен не хуже кубера
Но тем не менее с точки зрения безопасности — кубер — дырявое решето. Любая ошибка в настройке конфигов — и приплыли. Да даже сами cveшик намекают на то, что не все хорошо.
Какое решение? Ну, или не складывать все яйца в один кубер и разделять нагрузки по разным кластерам — в этом облако очень помогает — или смотреть в сторону специализированных решений, которые будут кластер защищать — те же stackrox, Aqua, twistlock и прочие. Опеншифт тоже из коробки идёт немножко более защищённый, чем обычный ванильный кубер, но ценой менее удобной эксплуатации
По всем пунктам согласны, там про это подробно. Действительно, часто выбора, K8s или нет, уже нет. Но мы не думаем, что это так плохо.
По поводу этого сравнения, что бы вы поставили в победителя по легкости администрирования и безопасности?
Всерьез конкурировать с aws/azure/etc?
Единственное преимущество (недостаток) это цоды в рф.
Если говорить про секреты, то — да, они хранятся в закодированном виде, но разграничение прав на секреты решается с помощью прав доступа, а не шифрования.
Kubernetes сложно установить и настроить по сравнению с другими оркестраторами, это отражено в статье.
docker stack deploy --orchestrator=kubernetes ...
ещё может помочь перейти со swarm на k8s
Придется доделать метки, аннотации, указать дополнительные параметры безопасности на подах, создать дополнительные абстракции (Network Policies, PDB и тд).
Я больше не про docker-compose, а про docker swarm, а его логика к куберовской ближе.
А насчёт придётся доделывать, указывать и создавать — от задач зависит. Если в кубер переехали потому что "сворм умер" или "нам надо в облако, а там только кубер", а не за его фичами, то "придётся доделывать" плавно трансформируется в "захочется доделывать, но придётся бизнес убедить выделить на это дополнительные ресурсы"
Я больше не про docker-compose, а про docker swarm, а его логика к куберовской ближе.
Да не особо-то и ближе. Кубер — все-таки комбайн, который прекрасно смотрится в качестве основы для своего PaaS. В нем и шедюлинг, и сеть, и хранение данных и многое другое. С другой стороны, возможно подход Номада был бы более жизненноспособен, потому что каждая функциональность куба как будто недоделанная — и секреты, и сервис Дискавери и прочее. В целом, жить можно, если разработка своя — это идеальный кейс заезда в кубернетес. Но если разработка заказная или требуется внедрение коробочных решений — начинается костылестрление.
Для задач миграции достаточно близки они — сущности сворма хорошо ложатся на сущности кубернетеса. Может не 1:1 и обратное неверно, но перенести в кубер приложения, уже работающие в сворме с соблюдением лучших практик последнего, достаточно просто и необходимости что-то серьёзно допиливать нет, если нет необходимости использовать фичи кубера, которых нет в сворме, как это часто бывает когда кубер выбирается просто как стандарт де-факто в оркестрации контейнеров, а не как средство добавить в систему что-то чего нет в сворме принципиально нет или делается внешними решениями разной степени костыльности.
Kubernetes, и Nomad могут быть развернуты в различных ОС: Linux, macOS, Windows.
Неоднократно указано, что кубернетес можно развернуть на мак и винде. Как? Винду в качестве воркер узлов завезли буквально недавно. В качестве мастеров — винду вообще нельзя использовать. А варианты типа миникьюб на маке или винде всерьёз рассматривать нельзя, т.к. это по сути виртуальная машина с линуксом будет
Предназначен только для контейнерных приложений.
Выше уже писали, что теоретически кубернетес может управлять чем угодно. Если повторить семантику кубелета — можно управлять виртуалками. Через оператора и OBSAPI — можно управлять любыми managed ресурсами
2. Теоретически да, но задача весьма не тривиальная. А в Nomad эта возможность встроена по умолчанию.
2. Тула для темплейтинга номад джоб Levant. Официально поддерживается хашикорпом.
3. В кубе секреты из коробки это плейнтекст в бейс64. Для куба точно также нужно подтягивать или vault или firefox sops или какой-то дополнительный инструмент чтобы делать секреты.
Куб это круто и определенно маркет лидер, но говорить про то как все в кубе работает из коробки это откровенное лукавство не в лучшем смысле этого слова.
Как жили до Kubernetes: сравниваем самый популярный оркестратор с другими решениями