Открыть список
Как стать автором
Обновить

Комментарии 54

Кроме этого, если в Kubernetes по умолчанию поддерживаются пространства имен (Namespaces), которые можно эффективно использовать для разделения сред разработки, то в Nomad данная функциональность доступна только в Enterprise-версии.

Уже нет. В nomad 1.0 namespaces стали доступны в opensource-версии.

Спасибо, проапдейтим текст
Однако дальнейшее администрирование Apache Mesos сложнее по сравнению с K8s, так как необходимо работать с ZooKeeper, уметь администрировать Java и быть готовым к связанным с этим трудностям: утечкам памяти, Xmx, лимитам и так далее. Kubernetes с Golang в этом плане проще.


Данное утверждение показывает только личные предпочтения автора.

Думаю для восстановления баланса во Вселенной стоит оставить оставить тут такой текст:
К тому же дальнейшее администрирование Kubernetes сложнее по сравнению с Mesos, так как необходимо составлять многостраничные манифесты, работать с etcd, уметь администрировать Golang и быть готовым к связанным с этим трудностям: утечкам памяти, сегфолтам, лимитам и так далее. Mesos с Java в этом плане проще.


Я к тому, что особенности администрирования есть в любой из этих систем, особенно когда их размер достигает десятков тысяч узлов и сводить это к holywar о языках реализации не стоит.
Согласен. И все же я бы сказал, что в среднем при работе с Javа чаще приходится обращаться к настройкам самой Java-машины, лучше понимать внутреннюю структуру работы языка. С Golang в этом плане проще. Хотя, несомненно, и у него есть свои нюансы. И так уж случилось, что в современном мире инженеры эксплуатации чаще знакомы и работают с Golang, чем с Java.
Возможно, вы снова переносите свои предпочтения на весь мир. В мире есть очень много Java, значительно больше Golang.
Вот тут есть рейтинг популярности языков программирования TIOBE Index, Java более 20 лет занимает 1 и 2 позиции. Это значит, что есть множество программ разработанных на этом языке и их кто то эксплуатирует. Golang стал более менее заметен только с 2017 года и до сих пор не дотянул не то что до Java, но даже и до Visual Basic.
Так что нет, Java более знакома в эксплуатации и возможно именно поэтому имеет большое количество средств диагностики, мониторинга и настройки, которых в Golang просто нет — неуспели сделать. Это разнообразие видимо и дает ощущение сложности.
Но я бы предпочел эксплуатировать критическую часть инфраструктуры имея в своем арсенале все эти инструменты.
Можно взять k3s или k0s, добавить kubevirt и это в огромном подавляющем числе упростит и первоначальную настройку и расширит рабочие нагрузки. А в случае роста узлов и подов, можно делать мультикластерные решения и это в любом случае потребует затрат специалистов для обслуживания инфраструктуры. Сейчас нет никаких преимуществ в новых проектах использовать, что-то отличное от k8s.

А как же rancher до версии 2.x?

Остался за рамками этой статьи, все рассмотреть невозможно. И все-таки инженеры, склоняющиеся в пользу использования Rancher, чаще используют >2.0 версии.

Знающие люди, подскажите — чем k8s лучше чем terraform + aws (забудем про eke) с точки зрения администрирования и поддержки? И там и там кластер описывается конфигом, есть автомасштабирование и виртуальные сети.

Очевидно, отсутствием привязки к aws?
Отсутствием привязки к AWS, большим опенсорсным комьюнити и, как следствие, большим количеством всевозможных дополнительных компонентов. Кроме того, K8s реализует паттерн замкнутого контура управления (ЗКУ). Это позволяет приводить ваше приложение к целевому состоянию, пускай даже на это уйдет несколько дней. В случае с Terraform вы ограничены клиент-серверным взаимодействием и небольшим количеством попыток установить целевое состояние для ресурса

Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое. Не думаю чтотв этом нет некого умысла.
Что касается озвученных недостатков nomad. Или авторы не владеют полностью темой или пытаются подыграть k8s. Nomad это один из продуктов в стеке от hashicorp. Другой который ведает секретами это vault и еще есть другие. Так недостаток ли это что функционал разный по своей природе не впихнули в один черный ящик а распределили между разными продуктами стека?
Что касается реальных недостатков nomad это проблема с зависимыми заданиями. Хотя возможно ее уже пофиксили

Так как поднять и главное обслуживать его своими силами просто немыслимо

Почему? В моей практике кубер просто работает и никого ничем не парит. Как по мне, это больше миф, который распространился как вирус, а облачные провайдеры подхватили его и начали толкать managed решения. То, что в нем много компонентов, не является прямым следствием сложности работы с ним. Как правило, эти компоненты живут своей жизнью и никого не трогают.

Но вот когда что-то идёт не так, то даже определить какой компонент надо смотреть пристальней может быть не просто

Поднять просто. Тем боле сейчас есть несколько решений например от canonical. Сложности начинаются когда оно начинает включить и куда бежать не х известно черный ящик

У нас пока не было таких проблем. У нас два кластера ща работают под постоянно нагрузкой, где тысячами поды убиваются и запускаются в сотнях деплойментов. Единственный, кто нас беспокоил, это etcd, когда он жил на HDD. При повышении нагрузки кубер банально тормозил. Перекинули его на ssd и с тех пор живет себе. Переживает падение и зависание нод, кончившееся на дисках место и т.д. и т.п. Из всего нашего стека наверное наименее проблемный это именно кубер.

Ну вот вы хотя бы знали про etcd и смогли локализовать проблему

Да хз как про него можно не знать. Он ставится отдельно, в логи постоянно жалуется, что задержки из-за диска высокие. Хранит все данные кубер именно в нем. Само собой разумеется, что смотреть надо в его сторону для начала. Попробовали — помогло. Это никак не тянет на «обслуживать его своими силами просто немыслимо». Это просто будничная проблема.

Не ставил сам никогда вот и не знаешь, досталось так сказать в наследство внезапно.

Есть уже по крайней мере 2 решения которые кажутся удобными и в установке и в поддержке https://k3s.io/ и microk8s

k3s отличается разве что тем, что там все упаковано в один бинарник — coredns, local path provisioner, api server, metrics server, nginx, etcd и все остальное. Т.е. сложность системы никак не меняется. При этом за счет того, что проект это все таки другой, глюков своих у них хватает. Мы k3s пробовали, наелись всякой ерунды с ним (чето вроде с конфигами по дефолту была фигня, что нельзя было перенастроить все эти встроенные компоненты. etcd не работал), что подумали ну его нафиг. Лучше кубспреем разольем ванильный кубер. Теже яйца только в профиль.

Охотно Вам верю. Однако после таких слов мне кажется что ваша команда скорее специализируется на поддержек к8с чем мимо проходила и все работает.

Значит у Вас все еще впереди.

Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое.

В таком случае можно взять managed-решение с Kubernetes от стороннего поставщика (не облачного провайдера), которое позволяет [одновременно] использовать и bare metal, и разные облака (и даже мигрировать между ними). Такие решения уже существуют. С ними вы сохраняете независимость от поставщика инфраструктуры (один из главных бонусов Kubernetes, который незаметно убили те самые облака в своих интересах), но при этом уже не нуждаетесь в трудоёмком обслуживании кластеров своими руками.
По поводу необходимости обращаться к облачным провайдерам для разворачивания Kubernetes — это нельзя назвать необходимостью, Kubernetes многие используют как самостоятельный продукт. По поводу несовместимости при миграции — например, наш KaaS сертифицирован CNCF и полностью совместим со всеми другими CNCF-сертифицированными облаками или установщиками, такими как kubeadm, kubespray и kops.

Что касается 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 вы уже получили доступ к секретам кубера, если не включено шифрование секретов через какой-то из поддерживаемых kms провайдеров. Попав на хост с Vault — получить доступ к данным на много сложнее, ну разве что, админ в motd не впихнул рутовый токен и унсейл ключи, а я такое тоже видел)))))
Если вы попали на хост с etcd

Вот с этого места подробнее. Попадание на хост (да еще с рут правами) почти в любой системе это, как правило, уже катастрофа. Я бы сказал, что и до взлома волта тут рукой подать — я могу банально подсунуть свою форк волта вместо родного, который, условно, всю базу сдампит в темп. Надо определиться все таки, какая модель угроз. Потому как подавляющему большинству хватит защит, которые попадание на хост как раз затрудняют.
Попадание на хост (да еще с рут правами) почти в любой системе это, как правило, уже катастрофа.

В случае кубера это не запредельно сложно.
Примеры https://habr.com/ru/company/southbridge/blog/540216/

в куче дефолтных инсталяций кубера смаунтить файловую систему мастера вообще не представляет каких либо проблем, получив серты к etcd вы уже получили туда доступ, с волтом такая песня не пройдет.

Но в статье то сказано что у кубера все лучше, а у nomad у которого все секреты как правило хранятся в vault с защитой все плохо

Не всем требуется шифровать секреты. У всех разные требования к безопасности и то, что кубер не дает читать секреты средствами RBAC, вполне может быть достаточно. Недостаточно — кубер позволяет все это шифровать, интегрируясь с другими решениями. Люди же хранят на диске приватные ключи без шифрования, полагаясь только на права файловой системы, и ничего, живут как-то все. Странно предъявлять претензии к этому, не указав, какая конкретно модель угроз и зачем нужно что-то более серьезное.

Мы этот момент его об уждаем в связи с заявлением что у курьера есть защита а у nomad нет. Хотя все совершенно наоборот. То есть у nomad нет необходимости иметь защиту так как для этого используют vault. А nomad плюс vault защищен не хуже кубера

Но тем не менее с точки зрения безопасности — кубер — дырявое решето. Любая ошибка в настройке конфигов — и приплыли. Да даже сами cveшик намекают на то, что не все хорошо.
Какое решение? Ну, или не складывать все яйца в один кубер и разделять нагрузки по разным кластерам — в этом облако очень помогает — или смотреть в сторону специализированных решений, которые будут кластер защищать — те же stackrox, Aqua, twistlock и прочие. Опеншифт тоже из коробки идёт немножко более защищённый, чем обычный ванильный кубер, но ценой менее удобной эксплуатации

Привет, отдельно про сложности, связанные c Kubernetes, подробно мы писали тут: habr.com/ru/company/mailru/blog/542730

По всем пунктам согласны, там про это подробно. Действительно, часто выбора, K8s или нет, уже нет. Но мы не думаем, что это так плохо.

По поводу этого сравнения, что бы вы поставили в победителя по легкости администрирования и безопасности?
Кстати, зачем вообще маилру делает свой cloud service?
Всерьез конкурировать с aws/azure/etc?
Единственное преимущество (недостаток) это цоды в рф.
Безопасность Kubernetes — это не только секреты. Это еще и управление правами (RBAC), системы авторизации и аутентификации в кластере, политики контроля возможностей подов (PSP), сетевые политики и так далее.

Если говорить про секреты, то — да, они хранятся в закодированном виде, но разграничение прав на секреты решается с помощью прав доступа, а не шифрования.

Kubernetes сложно установить и настроить по сравнению с другими оркестраторами, это отражено в статье.

docker stack deploy --orchestrator=kubernetes ... ещё может помочь перейти со swarm на k8s

Так же как и утилита kompose: kompose.io. Но, скорее всего, их можно использовать только как временное решение или способ быстро перегнать манифесты из одного формата в другой. В последствии все равно придется допиливать кубовые манифесты руками, так как docker-compose все-таки имеет сильно отличающуюся логику работы от Kubernetes.
Придется доделать метки, аннотации, указать дополнительные параметры безопасности на подах, создать дополнительные абстракции (Network Policies, PDB и тд).

Я больше не про docker-compose, а про docker swarm, а его логика к куберовской ближе.


А насчёт придётся доделывать, указывать и создавать — от задач зависит. Если в кубер переехали потому что "сворм умер" или "нам надо в облако, а там только кубер", а не за его фичами, то "придётся доделывать" плавно трансформируется в "захочется доделывать, но придётся бизнес убедить выделить на это дополнительные ресурсы"

Я больше не про docker-compose, а про docker swarm, а его логика к куберовской ближе.

Да не особо-то и ближе. Кубер — все-таки комбайн, который прекрасно смотрится в качестве основы для своего PaaS. В нем и шедюлинг, и сеть, и хранение данных и многое другое. С другой стороны, возможно подход Номада был бы более жизненноспособен, потому что каждая функциональность куба как будто недоделанная — и секреты, и сервис Дискавери и прочее. В целом, жить можно, если разработка своя — это идеальный кейс заезда в кубернетес. Но если разработка заказная или требуется внедрение коробочных решений — начинается костылестрление.

Для задач миграции достаточно близки они — сущности сворма хорошо ложатся на сущности кубернетеса. Может не 1:1 и обратное неверно, но перенести в кубер приложения, уже работающие в сворме с соблюдением лучших практик последнего, достаточно просто и необходимости что-то серьёзно допиливать нет, если нет необходимости использовать фичи кубера, которых нет в сворме, как это часто бывает когда кубер выбирается просто как стандарт де-факто в оркестрации контейнеров, а не как средство добавить в систему что-то чего нет в сворме принципиально нет или делается внешними решениями разной степени костыльности.

Kubernetes, и Nomad могут быть развернуты в различных ОС: Linux, macOS, Windows.

Неоднократно указано, что кубернетес можно развернуть на мак и винде. Как? Винду в качестве воркер узлов завезли буквально недавно. В качестве мастеров — винду вообще нельзя использовать. А варианты типа миникьюб на маке или винде всерьёз рассматривать нельзя, т.к. это по сути виртуальная машина с линуксом будет


Предназначен только для контейнерных приложений.

Выше уже писали, что теоретически кубернетес может управлять чем угодно. Если повторить семантику кубелета — можно управлять виртуалками. Через оператора и OBSAPI — можно управлять любыми managed ресурсами

1. Но все же Kubernetes может управлять Windows-контейнерами на Windows-нодах и поддерживает при этом интеграцию с фичами AD. Что из себя при этом представляют мастера, не принципиально для данной задачи.

2. Теоретически да, но задача весьма не тривиальная. А в Nomad эта возможность встроена по умолчанию.
поддерживает при этом интеграцию с фичами AD

сам кубернетес — нет, конечно.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
team.mail.ru
Численность
5 001–10 000 человек
Дата регистрации
Представитель
Павел Круглов

Блог на Хабре