
С переходом на кластерные решения платформа dBrain.cloud столкнулась с новыми задачами, требующими пересмотра подхода к выбору операционной системы. Как и что выбирали?
ПО для работы с контейнерными приложениями
С переходом на кластерные решения платформа dBrain.cloud столкнулась с новыми задачами, требующими пересмотра подхода к выбору операционной системы. Как и что выбирали?
Привет, друзья-разработчики и Kubernetes-энтузиасты! Сегодня мы с вами погрузимся в мир KEDA (Kubernetes-based Event Driven Autoscaling) — инструмента, который позволит вашим приложениям масштабироваться как по волшебству.
KEDA позволяет Kubernetes автоматически масштабировать приложения на основе различных внешних событий: сообщений в очередях, метрик из Prometheus, вебхуков и многого другого. Мастхев для некоторых микросервисов.
Привет дорогие Хабровчане! В данной статье хочу поделиться с вами опытом создания сервиса предоставляющего услуги контейнерного хостинга, в процессе работы над которым я узнал много нового, для себя, в этой области. Хочу поделиться с вами и постараюсь сделать так, чтобы вы не были разочарованы если дочитаете до конца.
Изначально, на этапе планирования, была задача строить инфраструктуру вокруг Kubernetes, но сейчас пришли к тому, что сервис работает на Docker, управляется через docker compose файлы и Docker-API. В настоящее время без режима Swarm. Почему так получилось и какие проблемы приходится решать не используя Kubernetes я вам сейчас расскажу.
Во первых, как минимум, сразу напрашивается вопрос, почему без режима Swarm, ведь горизонтальное масштабирование не лишнее? Режим swarm пока не используется, так как в настоящее время мы располагаем только одним сервером и если вдруг сервер перестанет отвечать, то всё равно все реплики перестанут работать, поэтому и смысла от них нет. Однако, естественно (надеюсь) это не постоянная ситуация, поэтому всегда держали в голове режим Swarm и не включали того, что не будет работать в Swarm, чтобы потом было легче мигрировать.
Почему не использовали Kubernetes? Ответ прост, но принять решение было не просто. На момент начала разработки у меня совсем не было опыта работы с ним, да и сейчас пока нет, только в теории. Плюс из интернета я так и не понял, чем он конкретно круче Swarm кроме того, что он может работать с гораздо большим количеством контейнеров. Так как, чтобы это проверить, нужно столько ресурсов скольки у меня пока что нет, я решил двигаться в сторону Swarm, а когда появятся ресурсы и спрос, а главное понимание зачем это нужно, то уже возможно переписывать на Kubernetes.
В этом обзоре мы представляем новые проекты CNCF, которые помогут в разработке и управлении облачными приложениями. Узнайте о последних обновлениях в категориях Runtime и App Definition & Development.
В статье мы рассматриваем новые проекты, добавленные в песочницу CNCF в 2024 году в категории Orchestration & Management. В обзоре расскажем о HAMi, Kmesh и других инициативах, которые меняют подход к оркестрации и управлению контейнерами.
Что делает инженер, если DAG не выполняется? Проверяет Airflow 50 раз, а потом вспоминает, что забыл поставить @dag над функцией.
Развертывание Apache Airflow в промышленной среде — это сложная задача, требующая учета множества аспектов: от обеспечения безопасности конфиденциальных данных до эффективного управления ресурсами. Одной из ключевых проблем, с которыми сталкиваются команды, является безопасное управление секретами, оптимизация конфигураций и наблюдаемость.
В этой статье мы рассмотрим, как использовать инструменты, такие как Sops и YAML-якоря, для упрощения управления конфиденциальными данными и улучшения читаемости конфигураций. А так же как обеспечить полную наблюдаемость инсталляции Apache Airflow.
Подготовили обзор новых проектов, добавленных в песочницу CNCF в 2024 году в категории Provisioning и Observability & Analysis. В статье читайте об инструментах, которые изменят подход к облачным технологиям.
В 2024 году мы не дождались выхода в свет Apache Kafka 4.0, в которой окончательно исчезнет поддержка ZooKeeper, оставив нам для создания кластеров только KRaft. Кто-то давно уже перешёл на эту прекрасную технологию, другие же размышляют, как им жить дальше — оставаться на линейке 3.х или в омут с головой.
Новогодние каникулы самое подходящее время для того, чтобы пощупать новую версию. Хотя код невозбранно доступен в Github проекта Apache Kafka, docker-образов текущих сборок 4.0 мне найти не удалось. Также поддержку 4.0 ещё не добавили в довольно популярный, и с недавних пор мною любимый, k8s-оператор strimzi. Ну что же, придётся устроить себе праздник самому!
Мы все сейчас в предновогоднем марафоне: закрываем хвосты, проводим последние в году дейлики, закупаем подарки на маркетплейсах, ищем трендовые рецепты на стол. Тем не менее, мы не могли оставить вас без традиционного новогоднего дайджеста.
Год был классный и насыщенный. Был и свежий Кубик с S3, и куча новых локаций, и даже два собственных ивента для би-ту-би. Уффф… хочется рассказать вообще обо всем. Но пройдемся только по верхам, чтобы вам не читать до самых курантов.
Итак, рекап за 2024 год. Главные события Клауда. Наши. И ваши.
Представьте, что у вас есть Vault и нужно перенести данные из него в другое хранилище. Например, из одного закрытого контура в другой на обычной флешке. Или из одного backend storage в другой. Причём перенести нужно безопасно, не расшифровывая данные в процессе и не раскрывая секреты. В этой статье мы расскажем, как решаем такие задачи в Deckhouse Stronghold — нашем решении для управления жизненным циклом секретов.
Хабр, привет! Я Максим, технический директор в компании Амвера и в этой статье я хотел бы поделиться опытом развертывания кластера kubernetes у облачного провайдера, который под капотом использует OpenStack. В этой статья я хочу пошагово рассказать про путь развертывания, подсветив те места, которые вызвали у меня затруднения.
Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком.
Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами.
Привет! Меня зовут Даниил Донецков, я DevOps-инженер в KTS.
Аутсорс-разработка цифровых продуктов — одно из ключевых направлений нашей деятельности. Для доступа в собственные внутренние контуры и защищенные среды клиентов нашим сотрудникам приходилось каждый раз использовать разные связки логинов и паролей. С ростом числа клиентов это становилось неудобным, и перед нами встала непростая задача — обеспечить единую точку входа в разные среды.
Мы решили проблему с помощью сервиса Firezone, и в этой статье я хочу поделиться нашим опытом. Сегодня я расскажу о том, как DevOps-юнит KTS:
- внедрил виртуальную сеть в существующую инфраструктуру, состоящую из двух k8s-кластеров и нескольких ВМ в разных облаках;
- обеспечил бесперебойный доступ для более чем 150 сотрудников к веб-сервисам.
Современные распределённые системы требуют надёжных, безопасных и масштабируемых способов управления сетевым взаимодействием между сервисами. Технологии Service Mesh, такие как Istio, предоставляют набор инструментов для решения этих задач. Недавно в экосистеме Istio появилась новая архитектура — Ambient Mesh, предлагающая альтернативный подход к реализации сетевых функций. В данной статье мы рассмотрим, чем отличаются классический Service Mesh и Ambient Mesh в контексте Istio, а также их преимущества и недостатки.
Сложности при работе со stateful-приложениями в Kubernetes знакомы многим. Недавно инженеры LinkedIn поделились своим подходом к их решению: они написали собственный Stateful Workload Operator, который базируется на пяти кастомных ресурсах. На сегодня кластеры компании со stateful-системами полностью переведены на новый оператор. Теперь владельцы систем могут сосредоточиться на управлении ими, не думая о сложностях эксплуатации. Под катом — перевод статьи, которую тепло приняли в сообществе.
Миграция данных в Kubernetes: практическое руководство. Узнайте, как легко и безопасно перемещать данные между различными StorageClass с помощью простых шагов.
Привет всем! В данной статье мы осветим наш опыт внедрения реестра Docker-образов Harbor в CI/CD платформу Gitorion. Расскажем, как настроить внешнюю аутентификацию Harbor в Keycloak по протоколу OIDC. Разграничим права доступа пользователей к реестру на основе ролей RBAC. Настроим дисковые квоты и автоматизируем очистку Harbor от устаревших Docker-образов, используя API Harbor в пайплайне Jenkins.
Популярность Kubernetes в России продолжает расти. О трендах в развитии облачных платформ на 2025 год рассказывает глава разработки платформы контейнеризации dBrain.cloud Дмитрий Головнич.
Привет, Хабр! Сегодня у нас на повестке дня тема кастомизации сетевого стека в Kubernetes с Cilium.
Cilium — это сетевое решение, которое работает прямо в ядре Linux и построено на основе eBPF. Его главная задача — обеспечить эффективное, а главное, безопасное взаимодействие между подами в кластере Kubernetes. И это не просто замена стандартному kube-proxy. Это полноценный инструмент для построения сетевых политик, мониторинга и кастомизации сетевого стека.