Здравствуйте, mrTwister, Вы писали:
T>У меня есть теория, кто плачут от кубернетеса обычно либо те, кому он не нужен, а они все равно используют из-за хайпа, либо те, кто не пробовал на голых виртуалках делать пачку разных связанных друг с другом сервисов с автоскейлингом и автоматическим восстановлением. Вот если им дать сначала поиграться в это без кубера, а потом с кубером, вот тут то любовь к кубернетесу и просыпается.
Предыдущий продукт, которым моя команда занималась, был на голых VMSS. Текущий на кубере. Вместо любви к куберу в основном кое что другое просыпается регулярно, особенно у тех кто код пишет и отлаживает.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, vsb, Вы писали:
vsb>>С чего ты взял, что Servo был паровозом? Он мне всегда казался странным проектом, никому особо не нужным. Делать движок, на который никто переходить не собирается и в лучшем случае какие-то его куски будут дёргать в фаерфокс.
KP>А разве не Мозилла была основным спонсором для Rust? Ну а затеяли они Rust вроде потому, что не осилили C++ и движек вечно тёк. Не?
По твоей же ссылке в стартовом сообщении:
В Firefox уже интегрированы такие наработки Servo, как многопоточный CSS-движок и система отрисовки WebRender.
Всё что надо было — успешно обкатали в том движке и забрали/заинтегрили к себе, далее отпустили в свободное плаванье, чтобы продолжать получать свои доходы от ESR + ни в коем виде более не мараться с Сосунгами, помня офигительные истории с Tizen.
НС>Предыдущий продукт, которым моя команда занималась, был на голых VMSS. Текущий на кубере. Вместо любви к куберу в основном кое что другое просыпается регулярно, особенно у тех кто код пишет и отлаживает.
У нас кстати тоже предыдущий был на голых VMSS. Геморроя с ними было на порядок больше, чем с кубером. Точнее не с самими VMSS (хотя и с ними тоже, LB там жесть), сколько с деплоем. Время апгрейда сократилось с нескольких часов до нескольких минут. Для добавления нового сервиса раньше надо было идти на поклон к админам DevOpsам, ждать фиг знает сколько пока они допилят деплоймент, чертыхаться пока они исправят там баги. Сейчас же разработчик сам коммитит новый простенький yaml файлик формат которого описан в любом букваре по кубернетесу и всё, мы имеем новый сервис. Я к тому, что команды разработки стали гораздо более автономные и могут решать практически все свои проблемы и развивать приложения самостоятельно без привлечения админов. При этом всё просто работает. Не понимаю, что там дебажть. Тестирование также значительно упростилось, так как появилась возможность тестировать не только в service provider'е (azure), а где угодно. Например, нам по определённым причинам удобнее проводить тестирование на своём кубернетисе, не в облаке. При этом самому приложению пофиг где его запускают, в ажуре, или у себя: и там и там кубернетис, который с точки зрения приложения работает одинаково.
Здравствуйте, mrTwister, Вы писали:
T>У нас кстати тоже предыдущий был на голых VMSS. Геморроя с ними было на порядок больше, чем с кубером. Точнее не с самими VMSS (хотя и с ними тоже, LB там жесть), сколько с деплоем. Время апгрейда сократилось с нескольких часов до нескольких минут.
У меня прямо обратный экспириенс. На VMSS, после некоторого количества потраченных усилий, релизы проходили как по маслу, а на кубере каждый релиз как в первый раз. Обязательно что то ломается.
T> Для добавления нового сервиса раньше надо было идти на поклон к админам DevOpsам, ждать фиг знает сколько пока они допилят деплоймент
Ну так ошибка в том, что у вас к девопсам надо было идти, хотя девопс должен быть частью команды продукта.
НС>Ну так ошибка в том, что у вас к девопсам надо было идти, хотя девопс должен быть частью команды продукта.
Ну вот как раз с кубером этого достичь гораздо проще, так как он стандартизует высокоуровневое описание инфраструктуры: сервисов, правил масштабирования и пр. Админы про это теперь вообще ничего не знают.
Здравствуйте, mrTwister, Вы писали:
НС>>Ну так ошибка в том, что у вас к девопсам надо было идти, хотя девопс должен быть частью команды продукта. T>Ну вот как раз с кубером этого достичь гораздо проще,
Моя практика показала, что не проще. Экономим на функционале кубера, теряем на борьбе с самим кубером.
T> так как он стандартизует высокоуровневое описание инфраструктуры: сервисов, правил масштабирования и пр.
Не не не. Вот то что он стандартизует — это одно. Именно ради этого и приходится его тащить. Но стандартизация не всегда нужна, а гемороя сам по себе он привносит изрядно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не не не. Вот то что он стандартизует — это одно. Именно ради этого и приходится его тащить. Но стандартизация не всегда нужна, а гемороя сам по себе он привносит изрядно.
А какой именно геморрой ты имеешь ввиду? У вас, я надеюсь, managed kubernetes?
=> k8s & Dev, второе для работы с конкретным модулем в комфорте собственной рабочей станции.
дальше забота DevOps и внешней конфигурации, где уже, централизованно появляются эти самые N environments
— Нету больше вопросов, где мне взять username/pass для БД/Message Broker/..... В кластере он генерируется через Vault. На рабочей станции, точно так же генерируется в кластере и доставляется девелоперу через S3 bucket
— нету больше списка ресурсов, серверов с портами и прочего. Это все доставляется и автоподставляется с консул темплейт. Разраб получает точно так же как credentials
— не будет у них никаких там SSL. А как разрабочики мучаются с SSL я уже насмотрелся. Учитывая, что cross-node траффик должен шифроваться (SOC 2 или местечковые требования). То дальше или мучения разработчиков или mTLS через service mesh. Последнее, шифрование есть, а разработчики занимаются своими делами.
— Разработчики больше не работают с AWS Secrets Manager. Ни с Cloudwatch, ни с кучей другого. Все эти привязки к провайдеру ушли в некий тонкий слой. Что-то тянет секреты, что-то подтягивает данные с (S3/Azure Container/...)? что-то забирает логи из текстовых текстовых файлов/stdout/socket и пишет их туда, куда скажут, централизовано. Неразрешимая задача продаванов "Клиент XYZ подпишет с нами, если мы не будем на AWS" решается элементарно, сменой этого слоя. На Azure, GCP или тот же Digital Ocean с минус ~ 40% инвойсу. Раньше, до меня с кубернетесами, они в самых смелых снах не представляли, как смогут оторваться от AWS
Теперь ты: расскажи, тогда, конкретно, отчего у вас не в восторге? Что, конкретно, ломается, что не работает. Какие мучения разрабов, diff(мучения-до-кубернетес, мучения-после)
Здравствуйте, kaa.python, Вы писали:
AA>>Я уж не говорю про clojure который имеет только один недостаток — jvm. KP>Может, главное достоинство?
Та не. ))
Еще на первом дотнете нарисовал как-то упрощённый интерпретатор Схемы...
В общем, оно вело себя отвратительно, дотнетный сборщик мусора для сценария {CAR, CDR} оказался тормозным.
И явовский тогда был не лучше.
Т.е. лисповские графы требуют в разы более шустрого GC.
Там пустые ячейки просто складываются в список и переиспользуются.
Попробовал так же в дотнете — опять не подходит — язык Схема является чистым, иммутабельным, это надо прописывать полям readonly, но тогда невозможно уже выделенные объекты складывать в пул...
В итоге, на технике начала 2000-х это было чушью, годилось только для относительно небольших "скриптов".
Не зря Кложура появилась на слуху только где-то к 2010-м годам, когда техника чуть подросла...
Здравствуйте, mrTwister, Вы писали:
НС>>Не не не. Вот то что он стандартизует — это одно. Именно ради этого и приходится его тащить. Но стандартизация не всегда нужна, а гемороя сам по себе он привносит изрядно. T>А какой именно геморрой ты имеешь ввиду?
Куча инструментария, которым его приходится обвешивать, потому что сам он чего то не совсем. Хелмы, приблуды для хелмов, консул, Ленз и т.п.
И я еще могу понять Виталика из Канады, который в основном использует готовые решения. Но когда ты сам эти решения делаешь, то количество танцев с бубном чтобы поднять новый кластер совсем не радует, я не говорю уж о том чтобы поднять часть сервисов вне кластера под отладкой.
Здравствуйте, Vetal_ca, Вы писали:
V_>Со своей стороны: V_>- нет больше инстансов и прочего VM-centric
Зато есть ноды и поды.
V_>- нет больше скольки-то там environments, оно, фактически, одно два:
Это уж как повезет.
V_>- Нету больше вопросов, где мне взять username/pass для БД/Message Broker/..... В кластере он генерируется через Vault.
И при чем тут кубер? Тем более что родных Secrets тебе не хватило, раз Vault понадобился.
V_>- нету больше списка ресурсов, серверов с портами и прочего. Это все доставляется и автоподставляется с консул темплейт.
Опять же, кубер тут никаким боком. Консул и без кубера работает, а родные куберовские Config Maps — опять какая то марсианская недоделка.
V_> Разраб получает точно так же как credentials
Ну и? В VMSS ставишь галку, потом просто лезешь в KeyVault напрямую или через App Configuration. И никакого кубера не нужно.
V_>- не будет у них никаких там SSL. А как разрабочики мучаются с SSL я уже насмотрелся.
Правда думаешь что SSL offload в кубере изобрели?
V_>- Разработчики больше не работают с AWS Secrets Manager. Ни с Cloudwatch, ни с кучей другого. Все эти привязки к провайдеру ушли в некий тонкий слой.
Ну вот единственное ради чего кубер имеет смысл. Только восторга от того никакого, увы. Это как с JS — какашка полная, но альтернатив все равно нет.
V_>что-то забирает логи из текстовых текстовых файлов/stdout/socket и пишет их туда, куда скажут, централизовано.
И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает.
V_>Теперь ты: расскажи, тогда, конкретно, отчего у вас не в восторге?
От того что разработка и настройка деплоймента превратилась в задачу для целой команды хронически перегруженных девопсов (при том что написание и подержку хелмов для собственных сервисов они взвалили на разрабов), в то время как раскатка на голых VMSS, пусть и без возможности съехать в другой клауд, занимала, после некоторой первоначальной инвестиции, 20% времени одного разраба.
Ну и как вишенка на торте — продукт на VMSS после первоначального тюнинга уже больше года работает как швейцарские часы вообще без присмотра, а новый продукт на кубере постоянно чудит, все никак потребный зоопарк из десятков сторонних продуктов не срастется.
V_> Что, конкретно, ломается, что не работает. Какие мучения разрабов, diff(мучения-до-кубернетес, мучения-после)
Мне одного того, что разрабы вместо написания хелмов поднимаю кластер в композе, ибо в 100 раз быстрее чем пачку хелмов расписывать и потом ждать когда оно задеплоится, вполне достаточно чтобы считать кубер далеко не идеальным решением.
НС>Куча инструментария, которым его приходится обвешивать, потому что сам он чего то не совсем. Хелмы, приблуды для хелмов, консул, Ленз и т.п.
Не знаю, мы как-то без всего этого обходимся, нет ни хелма, ни консула, ничего. Да, используем стандартные секреты, ConfigMap, при этом нет никаких проблем, работает все как часы.
Здравствуйте, mrTwister, Вы писали:
T>Не знаю, мы как-то без всего этого обходимся, нет ни хелма, ни консула, ничего. Да, используем стандартные секреты, ConfigMap, при этом нет никаких проблем, работает все как часы.
Ну если даже хелмов не используете, то у вас, судя по всему, совсем простой по структуре и настройкам кластер.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зато есть ноды и поды.
И, в чем проблема? Нод, их, вообще не видно. Поды ... Это как процессы -> контейнеры -> поды. Плюс огромное удобство, подготовка тех же credentials в init контейнерах. Или незаметная для основного приложения отправка тех же логов через sidecar контейнер. Тот же, FluentBit
НС>И при чем тут кубер? Тем более что родных Secrets тебе не хватило, раз Vault понадобился.
Секреты Kubernetes это статические вещи, как пароли в KeePass у простых смертных. Эти сredentials имеют совершенно другой принцип. Эти creds создаются по запросу на те же 30 секунд, они одноразовы и "проворачиваемы" (или как оно там, secrets rotation по русски). И ведут они к тем же Mongo, Postgres, AWS AMI и т.п., нигде вне контекста Pod не хранясь, с минимальным периодом жизни. С Kubernetes secrets это не сравнимо. Но, надо заметить, Kubrentes (и Hashicorp Vault) дает такую возможность совершенно "бесшовно", что есть признак гибкой и удобной системы.
V_>>- нету больше списка ресурсов, серверов с портами и прочего. Это все доставляется и автоподставляется с консул темплейт.
НС>Опять же, кубер тут никаким боком. Консул и без кубера работает, а родные куберовские Config Maps — опять какая то марсианская недоделка.
Работает. И без косула работает. Разница только во времени внедрения. так сказать, день-неделя-месяц-год, никакой разницы, ага.
НС>Ну и? В VMSS ставишь галку, потом просто лезешь в KeyVault напрямую или через App Configuration. И никакого кубера не нужно.
VMSS это типа instance profile на EC2 ? Переносим на GCP и это уже не работает. Ох уж этот отдел маркетинга провайдеров с попыткой привязать к своим технологиям.
В общем, в топку, что VMSS что EC2 Instance profile, все эти скрытые неявные привязки должны быть явны и видимы.
НС>Правда думаешь что SSL offload в кубере изобрели?
Что ты здесь имеешь в виду под SSL Offloading? Наиболее употребимый вариант, что приходит на ум, это SSL Offloading на reverse proxy, что к моему примеру никак не относится и задач для внутри-кластерной SSL не подходит.
НС>Ну вот единственное ради чего кубер имеет смысл. Только восторга от того никакого, увы. Это как с JS — какашка полная, но альтернатив все равно нет.
Не скажу за JS — но про какашку требует четкого обоснования. Пока какашки не видел, только восторг и рабочий environment. Как на работе, так и в личных проектах, где меня уж точно никто не заставляет пользоваться неудобными инструментами.
НС>И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает.
И что у тебя в приложении "зашито"? Прямо так, к ELK завязано на уровне приложения?
V_>>Теперь ты: расскажи, тогда, конкретно, отчего у вас не в восторге?
НС>От того что разработка и настройка деплоймента превратилась в задачу для целой команды хронически перегруженных девопсов (при том что написание и подержку хелмов для собственных сервисов они взвалили на разрабов), в то время как раскатка на голых VMSS, пусть и без возможности съехать в другой клауд, занимала, после некоторой первоначальной инвестиции, 20% времени одного разраба. НС>Ну и как вишенка на торте — продукт на VMSS после первоначального тюнинга уже больше года работает как швейцарские часы вообще без присмотра, а новый продукт на кубере постоянно чудит, все никак потребный зоопарк из десятков сторонних продуктов не срастется.
ХЗ, тут надо по месту смотреть. У нас срастается, как сторонние так и внутренние приложения.
НС>Мне одного того, что разрабы вместо написания хелмов поднимаю кластер в композе, ибо в 100 раз быстрее чем пачку хелмов расписывать и потом ждать когда оно задеплоится, вполне достаточно чтобы считать кубер далеко не идеальным решением.
КМК, кто-то Helm charts у вас увлекся. Впрочем, выбор правильного баланса для конкретного случая тут достаточно сложная задача. Kustomize vs Helm vs Terraform vs Spinnaker vs .... На предыдущем месте один пришлый DevOps за Helm Charts "топил". В смысле, написания этих Helm charts для собственных приложений. Даже juniorа ему выдали под эксперименты, замучил он этого junior-а. Меня не переубедил, мне кажется, что Helm больше для создателей компонентов. Типа VLC компонентов для Delphi. Хотя, как пользователь, с точки зрения потребления этих сторонних компонентов, все замечательно. Тот же Bitnami, просто супер
Тут, главное, не прикипать, мыслить широко и, если видно что закопался (типа как вы с Helm) "переобуваться" под более подходящую технологию. Ничего страшного в переобувании и адаптации нет.
В настоящий момент больше склоняюсь к Terraform/Terragrunt + Kubernetes, и их Kubernetes-Alpha. Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
Здравствуйте, Vetal_ca, Вы писали:
НС>>Зато есть ноды и поды. V_>И, в чем проблема?
А в чем проблема с VM?
НС>>И при чем тут кубер? Тем более что родных Secrets тебе не хватило, раз Vault понадобился. V_>Секреты Kubernetes это статические вещи, как пароли в KeePass у простых смертных.
О чем и речь. Вроде функционал есть, но применим только в простых случаях. И так везде. Вроде есть service discovery с DNS, но обычно ставят consult. Вроде есть автоскейлинг, но на практике еще и KEDA нужна. И т.п.
V_>Работает. И без косула работает. Разница только во времени внедрения. так сказать, день-неделя-месяц-год, никакой разницы, ага.
Внезапно перепрыгнули от разработчиков к внедрению?
НС>>Ну и? В VMSS ставишь галку, потом просто лезешь в KeyVault напрямую или через App Configuration. И никакого кубера не нужно. V_>VMSS это типа instance profile на EC2 ?
Нет, это что то типа AWS Auto Scaling
V_>Переносим на GCP и это уже не работает.
А если не переносим?
НС>>Ну вот единственное ради чего кубер имеет смысл. Только восторга от того никакого, увы. Это как с JS — какашка полная, но альтернатив все равно нет. V_>Не скажу за JS — но про какашку требует четкого обоснования.
Того что я уже привел вполне достаточно.
V_> Пока какашки не видел, только восторг и рабочий environment.
Восторг внедренцев? Охотно верю. Но ты с разработчиков начал.
НС>>И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает. V_>И что у тебя в приложении "зашито"? Прямо так, к ELK завязано на уровне приложения?
Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком.
V_>КМК, кто-то Helm charts у вас увлекся.
Остальные варианты еще хуже.
V_>Меня не переубедил, мне кажется, что Helm больше для создателей компонентов.
Бинго!
V_> Типа VLC компонентов для Delphi. Хотя, как пользователь, с точки зрения потребления этих сторонних компонентов, все замечательно.
Даже не сомневаюсь. Только мне как раз эти хелмы писать и править приходится постоянно.
V_>В настоящий момент больше склоняюсь к Terraform/Terragrunt + Kubernetes, и их Kubernetes-Alpha.
Terraform немного из другой оперы. А Kustomize соседняя команда решила использовать, и теперь долго и больно стараются на хелмы переползти.
V_> Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну если даже хелмов не используете, то у вас, судя по всему, совсем простой по структуре и настройкам кластер.
Система и правда не сложная, но я, тем не менее не очень понимаю, для чего сложным системам нужен хелм. Насколько я понимаю, хелм нужен разработчикам компонент под кубернетес, когда заранее неизвестно в каком окружении и в каких условиях будет использоваться компонент. Но ведь при разработке некоробочных приложений это не так, мы заранее точно знаем в каких окружениях будет запускаться приложение и можем еще на этапе сборки сервиса сгенерировать отдельный yaml под каждое окружение, который не потребует никакой дальнейшей кастомизации. Причем в этом же yaml'е будут и все необходимые для работы ConfigMap'ы. В результате весь деплоймент сводится к выполнению одной команды "kubectl apply"
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А в чем проблема с VM?
Микроменеджмент. Кубернетес сам разбрасывает. Добавить ресурсов, убрать ресурсы, гранулярность использования (заполнение проплаченного). Вплоть до гибких способов исчпользования spot instances
НС>О чем и речь. Вроде функционал есть, но применим только в простых случаях. И так везде. Вроде есть service discovery с DNS, но обычно ставят consult. Вроде есть автоскейлинг, но на практике еще и KEDA нужна. И т.п.
C++ тоже не имеет операторов для отрисовки окна. И, тем не менее, используется
Короче, не аргумент.
НС>Внезапно перепрыгнули от разработчиков к внедрению?
Если "без кубернетес можно" выливается в месяц работы и вагон гемора, то это, внезапно, не вариант. Отклонено. Теоретически — можно, практически — нет.
V_>>Переносим на GCP и это уже не работает.
НС>А если не переносим?
Вот так прямо к сейлзам идешь и говоришь, "У нас тут VMSS, мы "поженены" на Azure, потому обойдемся без этих клиентов — отдавайте их конкурентам"
НС>Того что я уже привел вполне достаточно.
Ничего ты не сказал. Все что ты сказал, что у тебя что-то там не получается. Пока, все что понятно, это Helm Charts и его identations. И, наверняка, закономерное неприятие написания Charts разработчиками.
НС>>>И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает. V_>>И что у тебя в приложении "зашито"? Прямо так, к ELK завязано на уровне приложения?
НС>Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком.
Все эти варианты "вне кубернетес", как правило, вторичны. Выбор узок. Интеграция растянута во времени. Что, в реальном мире называется "не выдерживает конкуренции". Вариант есть, но его нет
Да,что там у нас с mTLS вне кубернетес? Не вижу твоих предложений. Напоминаю:
Клиент: "Подпишем, если будет SOC 2" -> "Data-in-transit-encryption".
Разработчики меняют свои endpoints и мучаются с SSL ?
НС>Остальные варианты еще хуже.
Отклонено как недоказательное.
V_>>Меня не переубедил, мне кажется, что Helm больше для создателей компонентов.
НС>Даже не сомневаюсь. Только мне как раз эти хелмы писать и править приходится постоянно.
Ну так не правь. Ты же не юниор, чтобы следовать приказаниям, не взирая ни на что. Меняй, внедряй предлагай более правильное и соответствующее задаче.
НС>Terraform немного из другой оперы. А Kustomize соседняя команда решила использовать, и теперь долго и больно стараются на хелмы переползти.
