Comments 16
Коллеги!
Я очень ценю ваш труд и буду обязательно покупателем этой книги. Но можно попросить хотя бы немного аккуратнее переводить?
Ну, например,
Что, простите? Какой контрольный срез? Control plane? Ну, это как бы устоявшийся термин, который можно не переводить. Или может — «управляющий слой» (неуклюже, но по-русски).
Ведущий узел — то же такое себе. Везде они называются «мастерами». Хотя кому-то и может показаться, что это «рабская» и нетолерантная лексика
Я очень ценю ваш труд и буду обязательно покупателем этой книги. Но можно попросить хотя бы немного аккуратнее переводить?
Ну, например,
контрольного среза ведущего узла Kubernetes.
Что, простите? Какой контрольный срез? Control plane? Ну, это как бы устоявшийся термин, который можно не переводить. Или может — «управляющий слой» (неуклюже, но по-русски).
Ведущий узел — то же такое себе. Везде они называются «мастерами». Хотя кому-то и может показаться, что это «рабская» и нетолерантная лексика
Приносим свои извинения, «контрольный срез» действительно не отражает сути понятия. Поскольку устоявшегося перевода, к сожалению, нет, остановились на «контрольной плоскости».
«управляющий слой»?
Про плоскость — тоже такое себе.
Я понимаю, что задача формирования русскоязычной терминологии сложная. Нужно, чтобы она была удачной, иначе она не приживется. В этом отношении всегда сложно быть первыми.
Ну, и всё-таки давать табличку соответствия где-то в начале или конце книги (или хотя бы в первый момент ввода термина в оборот). В общем, что-то я опять учу вас жить ))) вам же виднее.
Удачи!
Про плоскость — тоже такое себе.
Я понимаю, что задача формирования русскоязычной терминологии сложная. Нужно, чтобы она была удачной, иначе она не приживется. В этом отношении всегда сложно быть первыми.
Ну, и всё-таки давать табличку соответствия где-то в начале или конце книги (или хотя бы в первый момент ввода термина в оборот). В общем, что-то я опять учу вас жить ))) вам же виднее.
Удачи!
«ДМК», например, согласует черновики перевода с коммьюнити (в частности, так они делали книгу «Scala for impatient». Думаю, это хорошая практика.
Мне кажется, собственный кластер кубика — это когда вы его разворачиваете сами.
А когда арендуете — это облачный кластер.
По поводу самого k8s — все описанное выше можно сделать и без него хотя бы на чистом docker + docker-compose, профит только в более дешевых нодах от гугла, и то я сомневаюсь, что невозможно найти vps по +- той же цене…
А когда арендуете — это облачный кластер.
По поводу самого k8s — все описанное выше можно сделать и без него хотя бы на чистом docker + docker-compose, профит только в более дешевых нодах от гугла, и то я сомневаюсь, что невозможно найти vps по +- той же цене…
UFO just landed and posted this here
Очень интересно про негативный опыт.
У меня реально есть подозрение, что сейчас куб пихают куда ни попадя (это плохо).
С другой стороны, он проникает везде и это позволяет формировать бест пректис и специалисты по нему будут «на плаву»
У меня реально есть подозрение, что сейчас куб пихают куда ни попадя (это плохо).
С другой стороны, он проникает везде и это позволяет формировать бест пректис и специалисты по нему будут «на плаву»
отписался ниже про свой небольшой опыт)
таки да, если есть возможность нанять свою фулл тайм команду для поддержания всей среды и конкретно k8s, как это делают те же devops as a service вроде фланта (и кто там еще пишет на харб) — то вопросов нет и все чудесно.
я же лично сталкивался больше с тем, что клиентам просто продают распиаренную технологию ради продажи услуг онли, не заботясь, нужно ли это реально клиенту или нет… и меня такой подход в бизнесе как минимум раздражает
всем своим контактам я всегда говорю две вещи:
1) хорошо подумать, готовы ли они перевести всю свою инфраструктуру в докер контейнеры с соответствующими изменениями в процесс разработки, деплоя и оперирования
2) если готовы, то брать готовый кластер в облаке, от того же гугла, или вот DO подсуетились на днях буквально — и даже не думать о самодельном сетапе, пока не потренируются на готовой среде без большой боли и вложений
таки да, если есть возможность нанять свою фулл тайм команду для поддержания всей среды и конкретно k8s, как это делают те же devops as a service вроде фланта (и кто там еще пишет на харб) — то вопросов нет и все чудесно.
я же лично сталкивался больше с тем, что клиентам просто продают распиаренную технологию ради продажи услуг онли, не заботясь, нужно ли это реально клиенту или нет… и меня такой подход в бизнесе как минимум раздражает
всем своим контактам я всегда говорю две вещи:
1) хорошо подумать, готовы ли они перевести всю свою инфраструктуру в докер контейнеры с соответствующими изменениями в процесс разработки, деплоя и оперирования
2) если готовы, то брать готовый кластер в облаке, от того же гугла, или вот DO подсуетились на днях буквально — и даже не думать о самодельном сетапе, пока не потренируются на готовой среде без большой боли и вложений
UFO just landed and posted this here
Да и после ликвидации docker'а на паре (суб)проектов стало стабильнее работать.
Все-таки — чем больше слоев абстракций, тем сложнее ) но и тем проще разработчикам.
helm — сырой, пока 3-й версии нет. А тот же redhat рекомендует lifecycle management приложения делать через ansible (фу-фу-фу).
Все-таки — чем больше слоев абстракций, тем сложнее ) но и тем проще разработчикам.
Поэтому вокруг этого инструмента оркестрации придется иметь внешнюю оркестрацию, например Helm и скрипты вокруг Helm.
helm — сырой, пока 3-й версии нет. А тот же redhat рекомендует lifecycle management приложения делать через ansible (фу-фу-фу).
Я как бы devops и с k8s работал))
Я и говорю, что кубик является дополнительным уровнем абстракции, и за нее нужно платить.
И я бы поспорил, что в маленьких проектах она вообще нужна.
У меня был опыт с легаси кластером, и вот список проблем, которые я словил с ним за пару месяцев:
1) рандомно отваливалась виртуальная сеть или dns
2) заэкспайрились сертификаты на мастере и отвалились все ноды с полным шутдауном всех контейнеров
3) при падении ноды кубик ждал дефолтные 5 минут до признания ноды умершей
первые два пункта быстрее и проще всего лечились полным ресетапом кластера с нуля.
Я понимаю, что k8s можно бесконечно долго тюнить под разные задачи, но блин!
Есть вопрос ресурсов бизнеса и вообще уровня компетенции в команде. Не говоря уже о том, что при statefull приложениях куб никак не решает проблему синхронизации данных, а то и усложняет сам менеджемент.
В моем случае, заказчику важнее была доступность приложения, и мы элегантным движением руки превратили кластер кубика в HA сетап приложений на каждом хосте, запущенных в докере с конфигурацией из compose.
И я не согласен с тем, что оркестрация докер контейнеров + yaml конфигов compose намного сложнее докер контейнеров + yaml конфигов k8s
Я и говорю, что кубик является дополнительным уровнем абстракции, и за нее нужно платить.
И я бы поспорил, что в маленьких проектах она вообще нужна.
У меня был опыт с легаси кластером, и вот список проблем, которые я словил с ним за пару месяцев:
1) рандомно отваливалась виртуальная сеть или dns
2) заэкспайрились сертификаты на мастере и отвалились все ноды с полным шутдауном всех контейнеров
3) при падении ноды кубик ждал дефолтные 5 минут до признания ноды умершей
первые два пункта быстрее и проще всего лечились полным ресетапом кластера с нуля.
Я понимаю, что k8s можно бесконечно долго тюнить под разные задачи, но блин!
Есть вопрос ресурсов бизнеса и вообще уровня компетенции в команде. Не говоря уже о том, что при statefull приложениях куб никак не решает проблему синхронизации данных, а то и усложняет сам менеджемент.
В моем случае, заказчику важнее была доступность приложения, и мы элегантным движением руки превратили кластер кубика в HA сетап приложений на каждом хосте, запущенных в докере с конфигурацией из compose.
И я не согласен с тем, что оркестрация докер контейнеров + yaml конфигов compose намного сложнее докер контейнеров + yaml конфигов k8s
Перешел на подписки от safaribooksonline.com, и в сторону бумажных книг больше не смотрю.
Реально выгоднее получается, чем покупать книги по отдельности.
Реально выгоднее получается, чем покупать книги по отдельности.
Главное, чтобы термины не переводили. Пожалуйста, назовите поды подами, а ноды нодами, ну пожаааалуйста. Не надо переводить то, что должно быть на английском. А то. у ДМК вышла книга и это жесть. С таким переводом, кроме как выкинуть книгу, ничего не хочется. Безголовые службы, контрольная плоскость, узел, модуль, вход — почему нельзя headless service, contril plane, node, pode, ingress?
И да, у вас на сайте не работают ссылки на оглавление и на полистать, чтобы оценить качество перевода.
И да, у вас на сайте не работают ссылки на оглавление и на полистать, чтобы оценить качество перевода.
UFO just landed and posted this here
Sign up to leave a comment.
Kubernetes: поразительно доступное решение для персональных проектов