Рубрика «kubernetes» - 2

Мечта: systemd как execution plane

Все мы знаем старый прикол — заказ пиццы через Kubernetes (это, кстати, реальный проект)… Смешно, потому что показывает, до какой степени создатели Kubernetes оторвались от простого «запустить процесс»: между декларативным состоянием в API-сервере и реальным процессом на хосте у него почти ещё одна целая ОС — CRI, containerd, runc. Но на любом Linux-хосте уже есть менеджер выполнения с cgroups, namespaces, зависимостями, журналом и D-Bus API — systemd… Вас ничего не смущает?

Читать полностью »

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

Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять.

Читать полностью »

Изначально идея была грубее: взять логовую строку, посчитать энтропию у подозрительных кусков и скрывать всё, что похоже на случайный секрет.

PII здесь — это personally identifiable information, то есть персонально идентифицируемая информация: email, телефон, адрес, паспортные данные, номера карт, токены доступа и другие значения, которые не должны свободно гулять по логам.

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

x9VdQp2Mz_La77kPq0
sk_live_51Nx...
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Но быстро выяснилось, что одной энтропией нормальный фильтр не собрать.

Читать полностью »

Горизонтальное автоскалирование в Kubernetes обычно начинается с HPA. Это понятный и практичный механизм: контроллер смотрит на метрику, например CPU, и меняет число реплик Deployment. Для многих сервисов этого достаточно.

Проблема начинается там, где нагрузка меняется быстрее, чем контур успевает на неё отреагировать. Метрика должна быть собрана, решение должно быть принято, новые Pod’ы должны запуститься и пройти readiness. Пока всё это происходит, старые Pod’ы уже могут работать на пределе, а хвостовые задержки p95/p99 — расти.

Читать полностью »

Предисловие

Статья получилась большой: практик много, и каждая из них важна по-своему. Я собрал её как набор best practices: не все пункты нужны каждому проекту, но почти каждый пункт однажды всплывает на ревью, в CI или после неприятного инцидента.

Я старался писать для разных грейдов: от базовых ошибок вроде COPY . ., latest и root-пользователя до продовых тем вроде BuildKit, секретов, SBOM, подписи образов и защиты цепочки поставки ПО.
Читать полностью »

Предыстория

Когда изучаешь DevOps по курсам — всё выглядит просто. Запустил minikube, поднял pod, посмотрел на kubectl get pods — красота. А потом пытаешься сделать что-то настоящее и понимаешь: между “hello world в Kubernetes” и реальной инфраструктурой — пропасть.

Я решил эту пропасть пройти. Взял 5 виртуальных машин на VMware Workstation и построил на них production-ready кластер с нуля. С CI/CD, GitOps, мониторингом, высокой доступностью и реальным приложением.

Расскажу что получилось, как именно это работает — и главное, какие грабли я собрал по дороге. Их было немало.

Окружение:Читать полностью »

Если коротко — плохо живут.

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

С чего всё началось

В 2022–2024 западные CNAPP-платформы закрыли доступ для российских компаний. Wiz, Prisma Cloud, Lacework, Orca — все они либо ушли сами, либо отвалились после санкций. Кто работал с этими инструментами, тот помнит — это была основная рабочая лошадка для аудита Kubernetes в облаке.

Читать полностью »

Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.

Есть очень узнаваемая картина. Новый релиз выкатывается нормально на staging, а в production внезапно «висит». kubectl get podsЧитать полностью »

Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения. 

Читать полностью »

Дисклеймер: самая большая ошибка в этой истории даже не выбор Dart, порядок действий. Вместо того чтобы в первый же день сделать честный raw benchmark на нашем production-like сценарии, я поверил в AOT, в статическую типизацию и в обещания ready for cloud - и сразу начал переносить сервис. Поэтому этот текст не только про Dart, но и про очень дорогой инженерный урок: сначала валидируй runtime-гипотезу, потом строй архитектуру вокруг неё. Чтобы не превращать текст в войну микрооптимизаций — все raw results, k8s manifests, CPU profiles, Dockerfiles и исходники рантаймов вынесены в репозиторийЧитать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js