Вокруг Kubernetes в VK

🔜 22 апреля нам обещают официальный выход версии Kubernetes v1.36. Когда версия стабилизируется, мы обязательно придем туда, а пока разбираемся в ключевых обновлениях платформы с нашим экспертом Алексеем Волковым, руководителем команды Developer Productivity, VK Tech.

Наш коллега Александр Прохоров, ведущий разработчик Backend, поделился концепциями, которые можно использовать, если вам нужно победить монстра, то есть выполнить оптимизацию ресурсов в K8s. Что внутри • Основы ресурсов Kubernetes. CPU, память и сетевые ресурсы • Управление ресурсами контейнеров. …

Наш коллега Александр Прохоров, ведущий разработчик Backend, поделился концепциями, которые можно использовать, если вам нужно победить монстра, то есть выполнить оптимизацию ресурсов в K8s. Что внутри • Основы ресурсов Kubernetes. CPU, память и сетевые ресурсы • Управление ресурсами контейнеров. Предотвращение OOMKilled • Автоматическая оптимизация с Kubernetes Autoscale • Мониторинг и профилирование нагрузки. Инструменты мониторинга • Оптимизация хранения и сетевых ресурсов. Persistent Volumes А в конце собрали список рекомендаций, на который полезно обратить внимание, даже если вы занимаетесь оптимизацией ресурсов 24/7, но надеемся, что нет, потому что спать же нужно. ➜ Читайте материал в блоге

Привет! У нас на Хабре вышла классная статья от руководителя Core-команды VK Tech Сергея Емельянова. В ней он пошагово расписал процесс построения синтетической платформы для обработки потоковых данных на Kubernetes, а также приложил ссылку на репозиторий, чтобы все могли повторить его путь. Что вн…

Привет! У нас на Хабре вышла классная статья от руководителя Core-команды VK Tech Сергея Емельянова. В ней он пошагово расписал процесс построения синтетической платформы для обработки потоковых данных на Kubernetes, а также приложил ссылку на репозиторий, чтобы все могли повторить его путь. Что внутри 🔷 Разбираем условия для построения платформы: от покупок и агрегации к аналитике и хранению 🔷 Собираем сами: устанавливаем сторадж-классы, операторы и вот это все 🔷 Что там с Gateway? Время для Helm и Kustomize. Разворачиваем тестовую среду 🔷 Как настроить Kafka Cluster, когда добавить ClickHouse 🔷 Что нужно сделать сразу, чтобы масштабирование не стало проблемой Будет много примеров кода для наглядности, поэтому надеемся, что материал будет полезен всем экспериментаторам. Читать полностью

Основы безопасности в Kubernetes состоят из дисциплины, внимания к деталям и отказа от работы по принципу «не трогай, оно же работает». 🕵‍♂️ Контейнер запускается от root — Kubernetes этому не мешает. Но если приложение скомпрометируют, злоумышленник получает root-права внутри пода и возможность эс…

Основы безопасности в Kubernetes состоят из дисциплины, внимания к деталям и отказа от работы по принципу «не трогай, оно же работает». 🕵‍♂️ Контейнер запускается от root — Kubernetes этому не мешает. Но если приложение скомпрометируют, злоумышленник получает root-права внутри пода и возможность эскалации на уровне ноды. Базовая изоляция начинается с Security Context 🔐 Обычно в манифесте задают: • runAsNonRoot: true — контейнер не сможет стартовать от root • allowPrivilegeEscalation: false — запрет повышения привилегий • readOnlyRootFilesystem: true — корневая файловая система только для чтения • capabilities: drop: ALL — сбрасывает лишние Linux capabilities Так под работает с минимальными правами. Следующий уровень — настройка Pod Security Standards (PSS) и механизм Pod Security Admission 🔏 Можно задать требования безопасности для подов на уровне namespace: например, запретить запуск контейнеров от root или использование privileged.

Если бы сейчас снимали ремейк фильма «10 причин моей ненависти», возможно, он был бы про падение подов в Kubernetes. Рассказываем в карточках о неочевидных причинах, которые стоит держать в голове, когда расследуете подобные дела.

Иногда Kubernetes делает ровно то, что вы ему разрешили — и именно в этом проблема 🤯 При плановых операциях в Kubernetes удаление подов считается добровольным вмешательством. В этих сценариях кластер не оценивает бизнес-критичность сервиса, а действует строго в рамках заданных ограничений. 🛠️ PodD…

Иногда Kubernetes делает ровно то, что вы ему разрешили — и именно в этом проблема 🤯 При плановых операциях в Kubernetes удаление подов считается добровольным вмешательством. В этих сценариях кластер не оценивает бизнес-критичность сервиса, а действует строго в рамках заданных ограничений. 🛠️ PodDisruptionBudget (PDB) задает эти ограничения. Он определяет, какое количество подов из выбранной группы может быть одновременно выселено при управляемых действиях. PDB описывается одним из двух параметров: • minAvailable — минимальное количество подов в состоянии Ready • maxUnavailable — максимально допустимое количество недоступных подов Параметры взаимоисключающие и применяются к подам, выбранным через селектор. Если PDB не задан, Kubernetes не ограничивает количество выселяемых подов при плановых операциях. Есть граничные случаи, которые важно учитывать: • сервис с одной репликой и PDB (minAvailable: 1 или maxUnavailable: 0) блокирует выселение пода и делает невозможным kubectl drain • PDB учитывает только поды в состоянии Ready, что влияет на поведение кластера при частично деградированном сервисе ❗️ PDB не обеспечивает доступность и не предотвращает отказ. Его задача — формализовать допустимый уровень доступности при управляемых изменениях в кластере. Ставьте реакцию: 🔥— если используете PDB в продакшене ❤️— если узнали о PDB из этого поста