Сообщение Re[11]: Rust похоже всё? от 22.11.2020 21:06
Изменено 22.11.2020 21:09 Vetal_ca
Re[11]: Rust похоже всё?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зато есть ноды и поды.
И, в чем проблема? Нод, их, вообще не видно. Поды ... Это как процессы -> контейнеры -> поды. Плюс огромное удобство, подготовка тех же 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. Хотя с точки зрения потребления этих компонентов все замечательно
Тут, главное, не прикипать, мыслить широко и, если видно что закопался (типа как вы с Helm) "переобуваться" под более подходящую технологию. Ничего страшного в переобувании и адаптации нет.
В настоящий момент больше склоняюсь к Terraform/Terragrunt + Kubernetes, и их Kubernetes-Alpha. Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
НС>Зато есть ноды и поды.
И, в чем проблема? Нод, их, вообще не видно. Поды ... Это как процессы -> контейнеры -> поды. Плюс огромное удобство, подготовка тех же 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. Хотя с точки зрения потребления этих компонентов все замечательно
Тут, главное, не прикипать, мыслить широко и, если видно что закопался (типа как вы с Helm) "переобуваться" под более подходящую технологию. Ничего страшного в переобувании и адаптации нет.
В настоящий момент больше склоняюсь к Terraform/Terragrunt + Kubernetes, и их Kubernetes-Alpha. Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
Re[11]: Rust похоже всё?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зато есть ноды и поды.
И, в чем проблема? Нод, их, вообще не видно. Поды ... Это как процессы -> контейнеры -> поды. Плюс огромное удобство, подготовка тех же 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. Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
НС>Зато есть ноды и поды.
И, в чем проблема? Нод, их, вообще не видно. Поды ... Это как процессы -> контейнеры -> поды. Плюс огромное удобство, подготовка тех же 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. Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.