Терминальная панель для Docker, которая отслеживает несколько хостов в реальном времени.

Нужно проверить обязательную метку или ограничить число реплик? Прежде чем поднимать отдельный webhook-сервер, посмотрите на CEL-политики Kubernetes. ValidatingAdmissionPolicy выполняет проверку внутри API-сервера, без сетевого обращения к вашему сервису. Эта возможность стабильна с Kubernetes 1.30.

Webhook остаётся полезным для сложной логики, например вызова внешнего API. Но к нему добавляются доступность сервера, тайм-ауты и задержка admission. Mutating webhooks вызываются последовательно, иногда повторно. Validating webhooks работают параллельно.

Для CustomResource базовую валидацию и значения по умолчанию лучше задавать в самой CRD. Выбирать механизм стоит по задаче и версии кластера, а не по привычному шаблону с ещё одним Deployment.

Управление в кластере для ИИ-агентов на Kubernetes. Независимые от среды выполнения контракты рабочих нагрузок, изоляция и конфигурация исходящего трафика, доказательства затрат на модели и примитивы аудита, верифицируемые в автономном режиме.

Attune — это оператор Kubernetes, который автоматически подгоняет запросы и лимиты ресурсов подов с помощью функции In-Place Pod Resize (изменение размера пода на месте).

OpenTelemetry eBPF Instrumentation — OBI — научился автоматически добавлять trace_id и span_id в существующие логи контейнеров. Не нужно подключать SDK, настраивать библиотеку логирования, пересобирать или повторно развёртывать приложение.

OBI через eBPF определяет, какой запрос в данный момент обрабатывает поток, и дополняет связанные с ним записи. Это работает с JSON, NDJSON и обычным текстом: из трейса можно сразу перейти к нужным логам, а из подозрительной записи — найти соответствующий трейс.

Но есть ограничения: обогащаются только логи из stdout и stderr, необходим активный trace-контекст, CAP_SYS_ADMIN и подходящая версия ядра.

В статье в блоге OpenTelemetry показаны принцип работы, конфигурация OBI и схема внедрения.

Jarvis — это веб-фронтенд с открытым исходным кодом для Prometheus Alertmanager — интерактивный, в реальном времени и с возможностью самостоятельного хостинга.

kern это не другой способ изоляции вместо контейнеров. Это тоже Linux-контейнеры, но с другой архитектурой runtime, настройками безопасности и интерфейсами для разработчика. Большинство соответствующих ограничений можно организовать и в Docker/Podman. Разница — в том, насколько готовым и удобным получается этот сценарий без собственной обвязки.

Но самое интересное в проекте (по крайней мере для нас) — три документа: SECURITY.md, THREAT_MODEL.md и CVE-POSTURE.md. Эти документs честно и прямолинейно отвечают на вопросы: что именно защищает песочница и где защита заканчивается?

На пример, в CVE-POSTURE описывается 25 способов побега из контейнера и как с этим справляется данный проект. А так как проект базируется на классических механизмах контейнеризации (а не microVM, sandbox и т.д.), то это все очень просто перенести для понимания картины в классических контейнерах Docker/Podman.

В статье разобран практический переход к распределённой архитектуре для инфраструктуры из 250+ узлов и 3000+ подов: Grafana Alloy собирает телеметрию локально на каждом узле, а Mimir, Loki, Tempo и Pyroscope работают в отдельном observability-кластере.

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

Gateway API предлагает более расширяемую модель с разделением ответственности между инфраструктурными и прикладными командами. Он поддерживает сложные правила маршрутизации и позволяет обходиться без привязки к специфичным аннотациям отдельных контроллеров.

Gateway API — перспективный выбор для новых Kubernetes кластеров и сложных сценариев маршрутизации, тогда как Ingress остаётся рабочим вариантом для простых конфигураций.

Три Ready-реплики, minAvailable: 2. При добровольном выселении через Eviction API бюджет не позволит опустить число доступных Pod ниже двух. На этом механизме основан и обычный kubectl drain.

А прямое удаление Pod или Deployment обходит PDB. Если удалить две реплики вручную, бюджет не превратит этот запрос в отказ. PDB также не предотвращает аппаратный сбой: он ограничивает определённые добровольные disruption, а не гарантирует доступность приложения.

При обслуживании проверяйте не только YAML с minAvailable, но и путь, которым инструмент убирает Pod. Eviction и DELETE похожи по результату, но разные по защите. Контроллер восстановит реплики, однако это не означает, что перерыва не было.