eBPF давно перестал быть узкоспециализированной игрушкой для kernel-энтузиастов и исследователей внутренностей Linux. Сегодня с ним, так или иначе, сталкиваются не только SRE, но вообще все, кто разрабатывает системы, близкие к сети, производительности или безопасности: от авторов сетевых плагинов (CNI) и прокси, до разработчиков кастомных агентских решений, observability-инструментов и low-level инфраструктурных компонентов. Даже если вы никогда не писали eBPF-код руками, есть хороший шанс, что он уже работает в вашей системе — тихо, незаметно и с довольно широкими полномочиями.
Чаще всего eBPF проявляется через удобные CLI, библиотеки и дашборды: установили агент, включили, и внезапно система знает о происходящем больше, чем strace, tcpdump и половина метрик вместе взятых. Но за этим комфортом скрывается нетривиальный механизм исполнения пользовательского кода прямо внутри ядра Linux — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.
В этой статье заглядываем под капот eBPF и разбираемся, как именно eBPF-программы попадают в ядро, что с ними происходит до и во время выполнения, и почему одни сценарии применения действительно оправданы, а другие выглядят впечатляюще только на слайдах.