« Rev
@kubernetes_ru   1382
Fwd »


G72K
Для удобства пользования + можно киллер фичи замутить когда состояния кластера инжектится в jsonnet чтобы принимать решения, навроде генерировать ли случайный пароль в секрете или оставить старый потому что он там уже есть
Rainbow
думаю стоит заменить все unix команды на dowell my-deployment.jsonnet
Rainbow
Поттеринг вас не кусал? 😂
Rainbow
(нужно было пошутить)
G72K
Ну и плюс поддержка языка в стандартной тулзе позволяет всем проектам использовать его в своих howto без лишних трений
G72K
Я за systemd с первых его дней :)
Rainbow
я бы выкинул yml из k8s. Для тех кому нужно cat template.yml | yaml2json | kubectl apply -f -
Rainbow
Потому что json есть в go стандартной либе, а yaml нет
Rainbow
jsonnet на выходе json. Т.е. было бы норм
Etki
да вообще любой дополнительный функционал не нужен
G72K
думаю стоит заменить все unix команды на dowell my-deployment.jsonnet
Я очень хочу git clone + kubectl apply и чтобы работало ) к сожалению пока не так, запилив jsonnet в kubectl я как минимум сэкономлю себе время потому что мне не придется переделывать всякие сторонние проекты
Rainbow
скачайте https://github.com/linux/сделатьзашибись/archive/v0.0.1.zip
G72K
Потому что json есть в go стандартной либе, а yaml нет
Странная логика. Какое значение имеет язык к пользовательской утилите? Фичи языка уж точно не должны диктовать фичи утилиты
Rainbow
Вы в курсе, что json - это один видов yml, верно?
да и в курсе, что в стандартной либе нет yml
Vadim
golang
Окей, это какой-то серьезный минус?
G72K
nodejs отлично показывает как бездумные deps вываливаются в черные дыры node_modules.
Я их не вижу, у меня бинарник на руках который делает примерно что мне нужно, какая польщователю разница сколько там было файлов в node_modules или vendor или 3rdparty
Rainbow
Окей, это какой-то серьезный минус?
это раздутие. Не критичное, но по unix way было бы лучше cat templates.yml | yaml2json | kubectl apply
Rainbow
Иначе где грань? Можно сувать в kubectl ещё xml, hcl и кучу всего другого.
Etki
Сколько истребителей?
Vadim
Кому от этого лучше?
Тем кто боятся node_modules спокойно спится. От ямла одни CVE потом, ага
Rainbow
Весь мир ПО сейчас страдает от раздутия. Можно хотя бы уме держать, что хорошо бы меньше раздутия. Я не бегу переделывать kubectl, но в своих проектах просто стараюсь делать меньше зависимостей. Если все целиком понемного будут двигать своё делов в этом направлении - думаю мир станет чуть чище.
Vadim
Сильно сомневаюсь что раздутие - хоть сколько-нибудь значимая проблема для кубеней
Vadim
И вырезанием yml из kubectl сильно не поможешь
Rainbow
Тогда вопрос остаётся, где грань? Почему я *мой любимый формат* не могу использовать? Сильно kubectl он не помешает
G72K
Проблемное раздутие идёт не ввысь, а вширь. Все популярные проекты вроде сфокусированы на своей задаче и втягивают те зависимости (растут ввысь) , которые помогают ее решать, при это в голове ничего нового держать не надо, а значит такое раздутие одобрено ассоциацией психотерапевтов аляски
Etki
Тем кто боятся node_modules спокойно спится. От ямла одни CVE потом, ага
Я полностью спеку ямла не читал, но на самом деле если там есть что-то вроде XXE - жди беды
Rainbow
Ок, мои заморочки. Я скажу нет, если кто-то из команды с json кофигами захочет использовать yml, потому что сильно не помешает, всего один импорт.
Rainbow
можешь
$ kubectl get service metabase -o xml error: output format "xml" not recognized Я ж доверчивый
G72K
Тогда вопрос остаётся, где грань? Почему я *мой любимый формат* не могу использовать? Сильно kubectl он не помешает
Можно. Любой формат можно и хорошо. kubectl сфокусирован на CRUD операциях, значит любая помощь в формировании ямла/JSON который заслать будет полезной. А вот скажем контроллер для red-blue деплоев будет уже более проблемно добавить, т.к. расширяет область ответственности kubectl
Etki
А, ты про "почему Х не был добавлен"? Ну, потому что пока деманд не превысил пороговые значения
Rainbow
Потому что я надеюсь, что его не примут
Vadim
Верно, тогда просто имплементацию, без отправки в апстрим
Rainbow
- мне не нравится эта идея, я не буду так делать - отправь pull request конструктивный диалог
Etki
- почему я не могу использовать Х? - только потому что пока не хватило рук заимплементировать его, но ты можешь сделать это сам
Rainbow
Нахождения edge cases одна из основных задач в IT, в остальном задачи простые. "когда хватит добавлять форматы?" один из таких случаев. Я возвожу проблему в абсолют и смотрю что выходит. Херня выходит, поэтому 1+ тоже выглядит не выгодно.
Etki
так а в чем проблема с дополнительными форматами?
Etki
Есть N девелоперских ресурсов, они просто сейчас распределяются на олее актуальные задачи. Но никакой проблемы с тем, что в один день они начнут писать адаптеры под любой формат, нет.
Rainbow
абсолютный вариант - добавить все форматы. добавить все форматы - раздутие. раздутие - зло
Rainbow
И я спрашивал где грань? Типа 2 норм, 20 не норм или норм? а 100? Сложно. Гораздо проще выбрать 1 и все.
Etki
нет никаких проблем и с сотней
Rainbow
Сочувствую. Вопрос закрыт.
Etki
хочешь использовать только жсон - твой выбор, но от разнообразия никаких негативных последствий не будет
Rainbow
Желаю вам в ваших проектах больше форматов
Etki
больше форматов в оба ваших дома
Rainbow
фундаментальный вопрос: три - это куча или не куча?
Это сложно. На порядок проще 1. Я за 1. Вот смысл всего диалога с моей стороны.
Rainbow
Сложно выбрать "три - это куча или не куча"
Etki
Я понимаю позицию "на кучу форматов может требоваться O(N) девелоперского времени", но ведь библиотеки ровно для этого и существуют
Vadim
Сложно выбрать "три - это куча или не куча"
самое забавное, что хотя позиция имеет смысл, вас распнут и обвинят в гном3поклонничестве - мол, только фичи вырезать умеете
G72K
абсолютный вариант - добавить все форматы. добавить все форматы - раздутие. раздутие - зло
Абсолютный вариант - добавить 100000 нод в кластер, аписервер надрывается, etcd взрывается, scheduler обрабатывает поды по десятку минут на цикл. Вывод - kubernetes непригоден
G72K
Будь я по-образованнее я б назвал как идея возведения в абсолют в философии называется, кто ее исследовал и к каким выводам пришел. Но я не такой.
Rainbow
Есть такая штука - ТРИЗ. Я не фанат, даже времени нет почитать книгу, которую 3 года назад купил. Но с первых строчек идет идея "шаблонность мышления приводит к раздутости". Ещё сверху идея "проблема может уйти, если перенести её на другой уровень", unix way и yaml2json как раз другой уровень.
Etki
мы пока не видим проблемы :(
Etki
ну и все равно получается, что ты ямл юзаешь
Rainbow
вам нужен custom формат - берёшь custom2json и все. А основная утилита не раздувается.
Rainbow
Т.е. я против того, чтобы тащить deps в проект, если это решает 1+ бинарник, который даже не всегда нужен.
Rainbow
Конкретно сейчас думаю для половины пофиг, что есть yaml. Потому что jsonnet и тп утилиты.
Rainbow
а что за книжка?
https://www.alpinabook.ru/upload/resize_cache/iblock/087/380_567_1/08781f1f0f10bd0de0021d5cc7cccf40.jpg
G72K
вам нужен custom формат - берёшь custom2json и все. А основная утилита не раздувается.
С custom2json гитлаб не может выложить у себя репу "устанавливай меня так" и вынужден корячить неработающие хелм чарты с инструкциями на 3 экрана
Etki
ну и по поводу транзакционных издержек - если внедрить новый формат в уже работающий тулчейн, то никому не придется еще возиться с установкой всех нужных x2json
Tema
Alexey зачем вообще тогда kubectl?
Anton
Товарисчи у кого работает top + metrics-server?
Tema
можно использовать api напрямую
Tema
а зачем api вообще? и k8s? можно руками всё развернуть на машинах
Tema
а зачем операционка? и GUI для осей?
Tema
можно и в консоли
Tema
а можно и без консоли вовсе
Rainbow
Alexey зачем вообще тогда kubectl?
мы говорим про "N однотипные вещей в утилите", а не зачем утилита.
Tema
(ответ: кто-то не такой умный как ты, и не умеет в unix way)
Tema
кому-то проще иначе
« Rev
@kubernetes_ru   1382
Fwd »