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

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

Коллеги!
Я очень ценю ваш труд и буду обязательно покупателем этой книги. Но можно попросить хотя бы немного аккуратнее переводить?
Ну, например,
контрольного среза ведущего узла Kubernetes.

Что, простите? Какой контрольный срез? Control plane? Ну, это как бы устоявшийся термин, который можно не переводить. Или может — «управляющий слой» (неуклюже, но по-русски).
Ведущий узел — то же такое себе. Везде они называются «мастерами». Хотя кому-то и может показаться, что это «рабская» и нетолерантная лексика
Приносим свои извинения, «контрольный срез» действительно не отражает сути понятия. Поскольку устоявшегося перевода, к сожалению, нет, остановились на «контрольной плоскости».

«управляющий слой»?
Про плоскость — тоже такое себе.
Я понимаю, что задача формирования русскоязычной терминологии сложная. Нужно, чтобы она была удачной, иначе она не приживется. В этом отношении всегда сложно быть первыми.
Ну, и всё-таки давать табличку соответствия где-то в начале или конце книги (или хотя бы в первый момент ввода термина в оборот). В общем, что-то я опять учу вас жить ))) вам же виднее.
Удачи!
«ДМК», например, согласует черновики перевода с коммьюнити (в частности, так они делали книгу «Scala for impatient». Думаю, это хорошая практика.
Мне кажется, собственный кластер кубика — это когда вы его разворачиваете сами.
А когда арендуете — это облачный кластер.
По поводу самого k8s — все описанное выше можно сделать и без него хотя бы на чистом docker + docker-compose, профит только в более дешевых нодах от гугла, и то я сомневаюсь, что невозможно найти vps по +- той же цене…
По поводу самого k8s — все описанное выше можно сделать и без него хотя бы на чистом docker + docker-compose

А все, что можно сделать на докере, можно сделать на обычном линуксе. Вот только дело в оркестрации.
Я сам не фанат кубернетса (скорее наоборот, из-за того, что имел негативный опыт с ним), но вы не понимаете, что это совсем другой уровень абстракции.
Очень интересно про негативный опыт.
У меня реально есть подозрение, что сейчас куб пихают куда ни попадя (это плохо).
С другой стороны, он проникает везде и это позволяет формировать бест пректис и специалисты по нему будут «на плаву»
отписался ниже про свой небольшой опыт)
таки да, если есть возможность нанять свою фулл тайм команду для поддержания всей среды и конкретно k8s, как это делают те же devops as a service вроде фланта (и кто там еще пишет на харб) — то вопросов нет и все чудесно.
я же лично сталкивался больше с тем, что клиентам просто продают распиаренную технологию ради продажи услуг онли, не заботясь, нужно ли это реально клиенту или нет… и меня такой подход в бизнесе как минимум раздражает
всем своим контактам я всегда говорю две вещи:
1) хорошо подумать, готовы ли они перевести всю свою инфраструктуру в докер контейнеры с соответствующими изменениями в процесс разработки, деплоя и оперирования
2) если готовы, то брать готовый кластер в облаке, от того же гугла, или вот DO подсуетились на днях буквально — и даже не думать о самодельном сетапе, пока не потренируются на готовой среде без большой боли и вложений
Продукт по качеству выглядит крайне сырым. Это тот пункт, который рано или поздно исправят, но все же пока что он есть. Огромное количество косяков, на которые постоянно напарываешься.

Я задаю себе вопрос: «Как описать простыми словами, для чего нужен k8s?»
И в голову приходит такое слово: масштабирование. Все в нем сделано вокруг масштабирования.
Он не решает многие проблемы, например через него нельзя делать релизы, если речь идет о чем-то посложнее замены образов. Поэтому вокруг этого инструмента оркестрации придется иметь внешнюю оркестрацию, например Helm и скрипты вокруг Helm.
Мало того, что масштабирование нужно не всем, но на коленке собранное решение из докера и балансировщиков будет проще и дешевле. В моем случае после ликвидации k8s в продакшене все стало стабильнее и лучше в поддержке и развитии.
Да и после ликвидации docker'а на паре (суб)проектов стало стабильнее работать.
Все-таки — чем больше слоев абстракций, тем сложнее ) но и тем проще разработчикам.
Поэтому вокруг этого инструмента оркестрации придется иметь внешнюю оркестрацию, например Helm и скрипты вокруг Helm.

helm — сырой, пока 3-й версии нет. А тот же redhat рекомендует lifecycle management приложения делать через ansible (фу-фу-фу).
Я как бы devops и с k8s работал))
Я и говорю, что кубик является дополнительным уровнем абстракции, и за нее нужно платить.
И я бы поспорил, что в маленьких проектах она вообще нужна.
У меня был опыт с легаси кластером, и вот список проблем, которые я словил с ним за пару месяцев:
1) рандомно отваливалась виртуальная сеть или dns
2) заэкспайрились сертификаты на мастере и отвалились все ноды с полным шутдауном всех контейнеров
3) при падении ноды кубик ждал дефолтные 5 минут до признания ноды умершей
первые два пункта быстрее и проще всего лечились полным ресетапом кластера с нуля.
Я понимаю, что k8s можно бесконечно долго тюнить под разные задачи, но блин!
Есть вопрос ресурсов бизнеса и вообще уровня компетенции в команде. Не говоря уже о том, что при statefull приложениях куб никак не решает проблему синхронизации данных, а то и усложняет сам менеджемент.
В моем случае, заказчику важнее была доступность приложения, и мы элегантным движением руки превратили кластер кубика в HA сетап приложений на каждом хосте, запущенных в докере с конфигурацией из compose.
И я не согласен с тем, что оркестрация докер контейнеров + yaml конфигов compose намного сложнее докер контейнеров + yaml конфигов k8s
Перешел на подписки от safaribooksonline.com, и в сторону бумажных книг больше не смотрю.
Реально выгоднее получается, чем покупать книги по отдельности.
Главное, чтобы термины не переводили. Пожалуйста, назовите поды подами, а ноды нодами, ну пожаааалуйста. Не надо переводить то, что должно быть на английском. А то. у ДМК вышла книга и это жесть. С таким переводом, кроме как выкинуть книгу, ничего не хочется. Безголовые службы, контрольная плоскость, узел, модуль, вход — почему нельзя headless service, contril plane, node, pode, ingress?
И да, у вас на сайте не работают ссылки на оглавление и на полистать, чтобы оценить качество перевода.
Самым большим открытием этой книги был термин «мотоколсяка» (вместо «sidecar»), docker изображения (вместо образов). Очень тяжелый перевод.
У меня много книг этого издательства, но это первая, в которой терминология меня напрягает.
Я задолбался искать способ купить ее с доставкой в РБ. Неужели сложно удовлетворить спрос, который реально есть?
Большое человеческое спасибо откликнувшимся на комментарий представителям компании. Впечатлен!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.