Calico — хорошее решение! Но нам нужно что-то выбирать. Идея Deckhouse не в том, чтобы собрать в одном месте все возможные реализации каких-то задач, потому что кто-то предпочитает что-то по своим причинам, а предоставить пользователям решение каждой задачи надёжным, проверенным способом, который будет закрывать необходимые потребности, всегда работать, делать это одинаково в разных кейсах (в разных облаках и т.п.), всегда поддерживаться в актуальном состоянии.
Если же «по верхам» сравнивать с Calico, то Cilium:
Технически хорош. И по своей производительности (например), и по своим фичам (observability с Hubble, крутые политики).
Был раньше и очень популярен сегодня. 12,4k vs 3,7k звёзд на GitHub, 438 vs 261 contributors и т.п.
Имеет поддержку индустрии: это выбор крупных провайдеров (AWS и GCP), это проект CNCF.
Поэтому при необходимости что-то выбрать наш выбор пал именно на него.
Давайте рассмотрим фантастический пример, что некто решил отказаться от услуг Фланта и хочет удалить всех фланто-пользователей?
Так ведь отобрать всех пользователей по почте с доменом flant (других мы не добавляем) — это же стандартная операция. Да, это не так изящно, как с отключением отдельного каталога, но и сложности ведь здесь нет.
О какой "привязке" вы говорите? У клиента в любом случае (и с glaball, и без него) полноценный инстанс GitLab со всеми фичами. Никаких "новых" фич решение не приносит, оно использует уже существующие - просто делает это на множестве инсталляций.
Перечисленные дистрибутивы - это компактные инсталляции для задач типа тестирования, локальной разработки и т.п. Deckhouse - это полноценная платформа для production, расширяющая возможности ванильного K8s; ближайшие аналоги - это OpenShift и Tanzu.
На первый вопрос логичным ответом звучит то, что еще тогда сразу требовалось managed-решение:
У ИТ-команды robota.ua не было опыта работы с Kubernetes, поэтому managed-сервис стал самым рациональным способом кубернетизировать приложения.
А из чего было выбирать в самой Украине?..
По третьему вопросу: график хорошо показывает, что с ростом кластера затраты на текущий вариант Kubernetes'а становятся только выгоднее (по сравнению с managed-решением от крупного провайдера). Если говорить про сравнение с зарплатой, то ведь логично (раз сейчас всё устраивает), что и инженер из-за растущей инфраструктуры: а) понадобится позже, б) будет решать более высокоуровневые задачи по инфре, оставив низкий уровень платформе Deckhouse (об этом был такой наш доклад).
В реестр вносится весь продукт, а не его инсталлятор или его отдельные фрагменты. Для лучшего понимания достаточно взять пример с любым дистрибутивом Linux в реестре (Альт, Astra и т.п.). Deckhouse — это не просто инсталлятор, а дистрибутив с модулями.
Добавили в статью уточнение про внутренний трафик между регионами AWS. В старой схеме по факту функционировал full mesh (между API, PgBouncer и СУБД). Но эта схема была сделана на этапе быстрого запуска проекта. С ростом проекта стала заметна проблема неэффективности такого подхода (этот излишний трафик привел к растущим дополнительным расходам). При переезде в новую инфраструктуру проблема решилась сама собой, т.к. взаимодействие между сервисами приложения стало более оптимальным.
P.S. Попутно ещё уточнили про IOPS: платить перестали за provisioned IOPS, а нужную производительность (для СУБД) получили благодаря большим SSD-дискам.
Calico — хорошее решение! Но нам нужно что-то выбирать. Идея Deckhouse не в том, чтобы собрать в одном месте все возможные реализации каких-то задач, потому что кто-то предпочитает что-то по своим причинам, а предоставить пользователям решение каждой задачи надёжным, проверенным способом, который будет закрывать необходимые потребности, всегда работать, делать это одинаково в разных кейсах (в разных облаках и т.п.), всегда поддерживаться в актуальном состоянии.
Если же «по верхам» сравнивать с Calico, то Cilium:
Технически хорош. И по своей производительности (например), и по своим фичам (observability с Hubble, крутые политики).
Был раньше и очень популярен сегодня. 12,4k vs 3,7k звёзд на GitHub, 438 vs 261 contributors и т.п.
Имеет поддержку индустрии: это выбор крупных провайдеров (AWS и GCP), это проект CNCF.
Поэтому при необходимости что-то выбрать наш выбор пал именно на него.
Так ведь отобрать всех пользователей по почте с доменом flant (других мы не добавляем) — это же стандартная операция. Да, это не так изящно, как с отключением отдельного каталога, но и сложности ведь здесь нет.
О какой "привязке" вы говорите? У клиента в любом случае (и с glaball, и без него) полноценный инстанс GitLab со всеми фичами. Никаких "новых" фич решение не приносит, оно использует уже существующие - просто делает это на множестве инсталляций.
Отдельная заметка про айсберг из этого доклада (и его успех в сообществе :-)): Kubernetes is an iceberg.
Время такое…
Обсудили в kubernetes_ru со статистикой и прочим: потому что Argo популярнее ;-)
Совсем не вижу «форсинга» в этой статье ;-)
Опубликовали на английском.
Перечисленные дистрибутивы - это компактные инсталляции для задач типа тестирования, локальной разработки и т.п. Deckhouse - это полноценная платформа для production, расширяющая возможности ванильного K8s; ближайшие аналоги - это OpenShift и Tanzu.
А как померить, что проблем больше, чем пользы? Растущее сообщество и количество внедрений разве не является доказательством большей пользы?
Для сети у нас в планах cilium (issue).
На первый вопрос логичным ответом звучит то, что еще тогда сразу требовалось managed-решение:
А из чего было выбирать в самой Украине?..
По третьему вопросу: график хорошо показывает, что с ростом кластера затраты на текущий вариант Kubernetes'а становятся только выгоднее (по сравнению с managed-решением от крупного провайдера). Если говорить про сравнение с зарплатой, то ведь логично (раз сейчас всё устраивает), что и инженер из-за растущей инфраструктуры: а) понадобится позже, б) будет решать более высокоуровневые задачи по инфре, оставив низкий уровень платформе Deckhouse (об этом был такой наш доклад).
В реестр вносится весь продукт, а не его инсталлятор или его отдельные фрагменты. Для лучшего понимания достаточно взять пример с любым дистрибутивом Linux в реестре (Альт, Astra и т.п.). Deckhouse — это не просто инсталлятор, а дистрибутив с модулями.
В блоге Kubernetes появился официальный анонс этого релиза. В качестве его главной темы авторы выбрали стабилизацию IPv4/IPv6 dual-stack.
Хорошо, что есть разные инструменты. Но игнорировать Helm невозможно.
Здесь есть очень подробное объяснение.
Добавили в статью уточнение про внутренний трафик между регионами AWS. В старой схеме по факту функционировал full mesh (между API, PgBouncer и СУБД). Но эта схема была сделана на этапе быстрого запуска проекта. С ростом проекта стала заметна проблема неэффективности такого подхода (этот излишний трафик привел к растущим дополнительным расходам). При переезде в новую инфраструктуру проблема решилась сама собой, т.к. взаимодействие между сервисами приложения стало более оптимальным.
P.S. Попутно ещё уточнили про IOPS: платить перестали за provisioned IOPS, а нужную производительность (для СУБД) получили благодаря большим SSD-дискам.
… но в статье осталось :-)