Здравствуйте, Vetal_ca, Вы писали:
НС>>А в чем проблема с VM? V_>Микроменеджмент. Кубернетес сам разбрасывает.
Поды — да. А ноды ты сам резервируешь. И далеко не всегда нужно на одной ноде несколько подов.
НС>>Внезапно перепрыгнули от разработчиков к внедрению? V_>Если "без кубернетес можно" выливается в месяц работы и вагон гемора, то это, внезапно, не вариант. Отклонено. Теоретически — можно, практически — нет.
Практически настройка кубера занимает порой времени больше, чем без него.
V_>>>Переносим на GCP и это уже не работает. НС>>А если не переносим? V_>Вот так прямо к сейлзам идешь и говоришь, "У нас тут VMSS, мы "поженены" на Azure, потому обойдемся без этих клиентов — отдавайте их конкурентам"
Ну а сейлзы тебе говорят, что им пофиг, и все равно кроме азура нам ничего не нужно.
НС>>Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком. V_>Все эти варианты "вне кубернетес", как правило, вторичны.
Нет. ELK появился задолго до кубера.
V_>Да,что там у нас с mTLS вне кубернетес?
Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2.
НС>>Даже не сомневаюсь. Только мне как раз эти хелмы писать и править приходится постоянно. V_>Ну так не правь.
V_> Ты же не юниор, чтобы следовать приказаниям, не взирая ни на что. Меняй, внедряй предлагай более правильное и соответствующее задаче.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Поды — да. А ноды ты сам резервируешь. И далеко не всегда нужно на одной ноде несколько подов.
Да, и тут все гибко в отличие от ручного прибивания гвоздями сервиса к ноду.
НС>Практически настройка кубера занимает порой времени больше, чем без него.
cd tf/deplyment/aws/prod/us-east1/core-cluster/01-insall && terragrunt apply
Минут 20 занимает времени, полностью автоматически
Точно так же с AKS, GCP или DO
V_>>Вот так прямо к сейлзам идешь и говоришь, "У нас тут VMSS, мы "поженены" на Azure, потому обойдемся без этих клиентов — отдавайте их конкурентам"
НС>Ну а сейлзы тебе говорят, что им пофиг, и все равно кроме азура нам ничего не нужно.
Ну вот, == никак. "Не шмогла", слив зафиксирован.
НС>>>Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком. V_>>Все эти варианты "вне кубернетес", как правило, вторичны.
НС>Нет. ELK появился задолго до кубера.
Опять съехал Если аргумент неудобен, то можно съехать? В реальном мире 2-3 съезда и перестанут воспринимать как серъезного человека.
Вопрос был о централизованной logging системой и возможностью переключать logging backends: ELK/PaperTrail/CloudWatch и т.д. и т.п.
В кубернетес логгирование легко абстрагируется. Так что приложения пишут в файлы/stdout а на уровне кластера уже перенаправляется в тот или иной logging backend. Где запущен тот-же ELK — дело десятое
НС>Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2.
И как вы, конкретно, data-in-transit encryption решали? Сколько людей было задействовано, сколько усилий. Кто это шифрование внедрял и как, конкретно подключал?
И, главное, почему это быстрее/лучше/надежнее чем тот же "LinkerD 2/Consul Service Mesh" и прочих, "mTLS автоматом" ?
НС>И какое решение более правильное?
Все что выше обсуждалось — пока мусор. Теперь мы переходим к сути вопроса.
Вот это и есть главный вопрос. Не переубедить. А узнать, где именно у вас проблемы и соотносятся ли они с моей ситуацией. Чтобы эти конкретные проблемы у себя обойти.
Пока тобой описанное никак не соотносится, кроме как эпизодических обсуждений на тему "А давайте сами писать Helm Charts"
По моему опыту, использовать Terraform с его HCL описаниями и связующими переменными показало себя намного лучше в моей практике, чем написание Helm Charts.
Даже решение mrTwister + Kustomize, добавляющий image tag от CI/CD выглядит проще этих Helm Charts
С другой стороны, Terraform c его state не совсем подходит для случая Кластер-на-девелоперской-машине. Или для деплойментов-на-раз, типа прогона тестов из Jenkins и создания/уничтожения mockup DB.
Здравствуйте, Vetal_ca, Вы писали:
НС>>Поды — да. А ноды ты сам резервируешь. И далеко не всегда нужно на одной ноде несколько подов. V_>Да, и тут все гибко в отличие от ручного прибивания гвоздями сервиса к ноду.
Serverless, опять же, ортогонален куберу.
V_>Минут 20 занимает времени, полностью автоматически
Да, если есть готовые отлаженные скрипты деплоя. Речь же про разработку.
НС>>Нет. ELK появился задолго до кубера. V_>Опять съехал
Куда я съехал? Централизованный сбор и индексация логов абсолютно ортогональны куберу, сам кубер ничего в этом плане не предоставляет.
V_>В кубернетес логгирование легко абстрагируется. Так что приложения пишут в файлы/stdout а на уровне кластера уже перенаправляется в тот или иной logging backend.
При чем тут кубер? Без кубера нет stdout и файлов? Или fluentd, внезапно, без кубера перестал работать? Ты бы разобрался как оно устроено, а не просто тыкал в готовые решения.
НС>>Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2. V_>И как вы, конкретно, data-in-transit encryption решали?
Там есть оговорки, позволяющие для внутрикластера это требование обойти. В подробности не вникал.
V_> Сколько людей было задействовано, сколько усилий. Кто это шифрование внедрял и как, конкретно подключал?
Тебе список фамилий что ли нужен? Вся команда почти была задействована в той или иной мере. Это требование SOC.
V_>И, главное, почему это быстрее/лучше/надежнее чем тот же "LinkerD 2/Consul Service Mesh" и прочих, "mTLS автоматом" ?
Почему отсутствие SSL там где он не нужен быстрее и проще чем его наличие? Странный вопрос.
НС>>И какое решение более правильное? V_>Все что выше обсуждалось — пока мусор. Теперь мы переходим к сути вопроса.
V_>Вот это и есть главный вопрос.
Это совсем не главный вопрос, потому что главный вопрос это сам кубер, а не какой то очередной отдельный тул.
SD>Задают тренды и историю единицы. SD>Ленин, Джобс, Маск.
SD>А миллионы просто ей следуют.
А ты к какой из этих двух категорий относишься?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vetal_ca, Вы писали:
НС>Serverless, опять же, ортогонален куберу.
Привязан к провайдеру. Как и Fargate для AWS
НС>Да, если есть готовые отлаженные скрипты деплоя. Речь же про разработку.
Отмазка девопса?
НС>Куда я съехал? Централизованный сбор и индексация логов абсолютно ортогональны куберу, сам кубер ничего в этом плане не предоставляет.
V_>>В кубернетес логгирование легко абстрагируется. Так что приложения пишут в файлы/stdout а на уровне кластера уже перенаправляется в тот или иной logging backend.
НС>При чем тут кубер? Без кубера нет stdout и файлов? Или fluentd, внезапно, без кубера перестал работать? Ты бы разобрался как оно устроено, а не просто тыкал в готовые решения.
Там еще есть более удобные варианты, можешь почитать на досуге.
НС>>>Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2.
НС>Тебе список фамилий что ли нужен? Вся команда почти была задействована в той или иной мере. Это требование SOC.
То есть, не делали. А если бы делали, то увидели бы, что SSL/TLS "вручную", L7 требует вникания каждого члена команды. Адаптации и обучения. Включая сопутствующие минусы этого ручного и непрозрачного случая. Пример минуса "а какая версия OpenSSL в контейнере питона какого-то далекого компонента?"
В кубернетес можно единовременно добавить service mesh со сквозным шифорованием так, что приложение ни в коей степени не задействовано. Плюс сохранено много-много часов разработчиков. Не говоря уже о плюсах централизованного менеджмента всего это in-cluster шифрования, см пример выше.
Конечно, ты напишешь, чтобы выкрутиться "Можно и без" или чпрез старый "LinkerD 1.0" — ответ уже дан и закрыт — оптимально нельзя. Неоптимально — пускай наши конкуренты делают.
НС>Это совсем не главный вопрос, потому что главный вопрос это сам кубер, а не какой то очередной отдельный тул.
У меня лично, кубер не вопрос. Ни разворачивание, ни поды ни ноды — под моим руководством оно не вызывает вопросов. Преподавать с важным видом или пропагандировать кубернетес — не есть моя цель.
Вопрос только в частных случаях, где можно улучшить мои знания за счет опыта других. Что есть непосредственная цель моего тут участия. И, как ты уже, наверное, заметил, выхлоп данной ветки приближается к нулю, посему откланяюсь.
Здравствуйте, Pzz, Вы писали:
Pzz>Что есть ниша системного программирования?
Возможность работать без GC, большого рантайма и боксинга. Ниша C/C++ — вычислительный и железячный софт, где Go вообще никаким боком.
Pzz>Понятно, что ядерные драйвера вряд ли кто-то будет писать на Go (да и на Rust'е тоже).
На Rust'e можно. Поблемы не технические, а легаси и политика.
Pzz>Но почему бы на Go не быть написанным какому-нибудь почтовому демону, мне непонятно.
Почтовый доме можно написать на чем угодно, включая Питон.
Здравствуйте, Vetal_ca, Вы писали:
НС>>Serverless, опять же, ортогонален куберу. V_>Привязан к провайдеру. Как и Fargate для AWS
Т.е. вернулись к тому же самому — единственное неоспоримое преимущество кубера — некоторая стандартизация инфраструктуры — облака, PowerShift etc.
V_>Ты описываешь частный случай, Exposing logs directly from the application
Нет.
V_>Там еще есть более удобные варианты, можешь почитать на досуге.
Ты сам почитай на досуге
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: Stackdriver Logging for use with Google Cloud Platform, and Elasticsearch. You can find more information and instructions in the dedicated documents. Both use fluentd with custom configuration as an agent on the node.
НС>>Тебе список фамилий что ли нужен? Вся команда почти была задействована в той или иной мере. Это требование SOC. V_>То есть, не делали.
Если факты не подходят под теорию ...
НС>>Это совсем не главный вопрос, потому что главный вопрос это сам кубер, а не какой то очередной отдельный тул. V_>У меня лично, кубер не вопрос.
Ну так ты и не разработчик. И выводы, судя по всему, делаешь на основании своих личных задач, в кои поставки того или иного вида коробки не входят.
К примеру, если взять коробочные сервисы, то практически в 100% случаев там есть хелм, чуть реже есть еще docker-compose.yml. А вот терраформ ты будещь поддерживать сам.
Болтология проскипана. Полезной информации у тебя нет, а бесполезную преподносишь так, что красивее будет продолжать вариться тебе в собственном соку.
НС>Ну так ты и не разработчик. И выводы, судя по всему, делаешь на основании своих личных задач, в кои поставки того или иного вида коробки не входят. НС>К примеру, если взять коробочные сервисы, то практически в 100% случаев там есть хелм, чуть реже есть еще docker-compose.yml. А вот терраформ ты будещь поддерживать сам.
Чисто по "реальной" части:
1. Helm Charts я не пишу
2. 3D party компоненты прекрасно интегрируются и параметризуются с Terraform:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Внезапно перепрыгнули от разработчиков к внедрению? V_>>Если "без кубернетес можно" выливается в месяц работы и вагон гемора, то это, внезапно, не вариант. Отклонено. Теоретически — можно, практически — нет. НС>Практически настройка кубера занимает порой времени больше, чем без него.
В AWS сейчас это выглядит так: запускаем EKS, настраиваем роли и всё. EKS запускает контейнеры на Fargate-узлах по требованию: https://medium.com/better-programming/serverless-kubernetes-cluster-on-aws-with-eks-on-fargate-a7545cf179be
Я не про то как это в облака вывесить, а про то как собрать из кучи сервисов единый продукт. А то что EKS или AKS под готовое решение поднять не сложно я как бы в курсе.
Если аргумент неудобен, то можно съехать? В реальном мире 2-3 съезда и перестанут воспринимать как серъезного человека.
