Kubernetes *

Обеспечение безопасности инфраструктуры является неотъемлемой частью процессов DevSecOps. На сегодняшний день для работы различных приложений используются контейнеры, а для управления ими применяется Kubernetes. Когда речь заходит о безопасности контейнеров, то обычно все вспоминают о сканировании образов и поиске в них уязвимостей. Но при этом не стоит забывать и о безопасности самой среды оркестрации Kubernetes, которая управляет всеми нашими контейнерами.

О безопасной настройке Kubernetes написано немало статей, однако важно понимать, что недостаточно один раз безопасно настроить. Необходимо периодически проверять уровень защищенности K8s, а в этом лучше всего помогут сканеры безопасности, некоторые из которых мы сегодня и рассмотрим.

В рамках этой статьи мы рассмотрим, как работает Garbage Collector в Kubernetes. Данная статья была написана, когда мне пришлось разбираться в производительности Garbage Collector, а чтобы понять как его можно ускорить, сначала надо понять, как он работает. Для точного понимания мы будем запускать Garbage Collector локально в дебаг режиме, чтобы максимально ясно видеть как он работает и что делает.

Зомби-слои в Docker — это не просто технический термин, а реальная угроза для ваших секретов. Мы перевели статью, автор которой рассказывает, что это такое и как избежать потенциальных утечек данных.

Однажды поздним воскресным вечером ничто не предвещало неприятностей, пока не поступило сообщение о проблемах с репликацией в продуктовом кластере ClickHouse. В статье поделились опытом восстановления сервиса после сбоя и разобрали  репликацию материализованных представлений.

Ситуация. Вы сидите в высокой башне Фуфелшмерц Пакостин Корпорейшн, и вдруг во всем мире случается зомби‑апокалипсис. Очевидно, что у гениального ученого где‑то есть «инатор» для борьбы и выживания в таком случае.

Порывшись немного в кладовке, вы случайно находите главный сервер здания, где страшными буквами написано КуБеРнЕтИс СИ/СД Пипелайн (разумеется на русском). Слава Богу, что вас когда‑то в универе пытались научить чему‑то, и вы, вроде, что‑то начинаете вспоминать...

Осталось только придумать, как с помощью этого сервера раскатить защиту башни на распознавание зомби, а не Перри...

Вспомнив наставления своего мастера (и английский алфавит) вы вспомнили, что КуБерНеТиС на самом деле отлично подходит для настройки непрерывной интеграции и доставке (CI/CD), чтобы автоматически обновлять защиту башни и мочить защищаться от зомби.

Привет, Хабр!

Сегодня я расскажу, как создать кастомный контроллер для Kubernetes на Rust. Кастомные контроллеры нужны, чтобы автоматизировать действия, которые Kubernetes сам по себе не умеет.

В статье рассматриваем, как RabbitMQ интегрирован в dBrain, какие операторы использовались для управления кластерами, а также с какими проблемами разработчики столкнулись в процессе внедрения.

Статья посвящена Istio — платформе для создания service mesh. Она объясняет ключевые функции инструмента: управление трафиком, защита коммуникаций через mTLS и сбор метрик для мониторинга. Также рассматриваются примеры конфигурации: как Istio помогает в управлении сетевыми взаимодействиями и повышает устойчивость систем. Узнайте, помогает ли Istio в работе с распределёнными системами.

Как погубить кластер, действуя во благо? Подборка вредных советов из реальных кейсов и опыта от специалиста по безопасности контейнеров и Kubernetes. Вместе установим антивирус на ноды, просканируем хостовую ОС и заблокируем выкатки образов с чувствительной информацией.

Привет, Хабр! Меня зовут Дмитрий Евдокимов. Я — Founder & CTO Luntry в компании по созданию решений для безопасности контейнеров и Kubernetes, CFP конференций DevOpsConf и Highload, автор курса «Cloud-Native безопасность в Kubernetes» и телеграм-канала k8s (in) security. Эта статья написана по мотивам моего доклада для DevOpsConf 2024. Так как я проработал в сфере информационной безопасности больше 15 лет и специализируюсь именно на безопасности контейнеров и кластеров, дам несколько «вредных» советов, как сделать Kubernetes-кластер «безопасным».

Представьте, что вы строите город для ваших приложений. Каждому из них нужно собственное пространство, где оно будет хранить свои данные и жить своей жизнью. На первый взгляд, кажется логичным для каждого приложения построить отдельный коттедж – выделить свой кластер. На первых порах, когда у нас всего несколько приложений, этот подход кажется вполне приемлемым: у каждого приложения свой уютный домик, все изолировано и работает независимо друг от друга. 

В обзоре узнаете, как графический интерфейс PG Back Web значительно облегчает управление резервными копиями PostgreSQL. Мы покажем, как настраивать резервные копии всего за несколько кликов.

Привет, Хабр! Меня зовут Антон, я DevOps-инженер в YADRO, работаю с платформой машинного обучения. Недавно столкнулся с интересным случаем, над которым мне пришлось поломать голову. Одной из задач нашей команды стало развертывание helm-чарта для Airflow с использованием ArgoCD. Это потребовалось для реализации DAG-пайплайнов, необходимых для обработки данных и автоматизации процессов в проектах машинного обучения.

В статье расскажу о сложностях при расшифровке секретов с использованием плагина ArgoCD Vault, о паттерне App of Apps для обхода этих сложностей и небольшом погружении в детали установки плагина в кластер, из-за которых возможно неочевидное поведение ArgoCD Applications.

В статье разбирается модель claims и её ценность для управления ресурсами в Kubernetes. Узнайте, как она помогает разделять желаемое и наблюдаемое состояния ресурсов.

Развитие методологий CI и CD не стоит на месте. Тем не менее, проверенные практики, вероятно, останутся актуальными и в 2025 году. В этой статье покажем некоторые из таких в действии.

С переходом на кластерные решения платформа 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.