r3tam blog

Kubernetes в 2026: Sidecarless mesh, eBPF и эволюция оркестрации

11 мин. чтения

Kubernetes в 2026: Sidecarless mesh, eBPF и эволюция оркестрации

2026 год стал поворотным для экосистемы Kubernetes. Три фундаментальных тренда — отказ от sidecar-прокси, переход на eBPF как основной сетевой механизм и AI-ориентированная оркестрация — окончательно сформировали новый ландшафт платформенной инженерии. Если ещё два года назад sidecarless mesh был экспериментальной технологией, eBPF — «перспективным направлением», а DRA — альфой, то сегодня это продакшн-стандарты, которые меняют архитектуру решений.

Эта статья — обзор ключевых изменений 2026 года: сравнение Istio Ambient Mesh и Cilium Service Mesh, влияние eBPF на производительность и наблюдаемость, а также новые возможности оркестрации в Kubernetes 1.36 и 1.37. Вы узнаете, какие решения принимать при выборе service mesh, как eBPF заменяет iptables и почему AI-нагрузки диктуют развитие планировщика.

Смерть sidecar-прокси: Sidecarless mesh как новый стандарт

Эпоха per-pod sidecar-прокси завершилась. Istio Ambient Mesh стал общедоступным (GA) в версии 1.24 ещё в ноябре 2024 года, а Cilium Service Mesh довёл eBPF-нативный подход до зрелости в релизах 1.16–1.19. В 2026 году выбор стоит уже не между sidecar и sidecarless, а между двумя архитектурами без sidecar: Istio Ambient и Cilium Service Mesh.

Оба решения устраняют главный недостаток классического Istio — ~50–70 МБ RAM на под и ~1–3 мс дополнительной латентности на каждый hop через Envoy-прокси. Но они принципиально расходятся в том, где и как обрабатывать трафик.

Istio Ambient: двухуровневая архитектура

Ambient-режим Istio использует два компонента вместо одного per-pod Envoy. Ztunnel — легковесный Rust-процесс (DaemonSet на每一 ноде), который обрабатывает L4-трафик: mTLS, шифрование, маршрутизация по протоколу HBONE (HTTP/2 CONNECT over mTLS). Waypoint proxy — опциональный per-namespace или per-service Envoy, который включается только тогда, когда нужны L7-политики, HTTP-маршрутизация, JWT-валидация или ретраи.

По данным Solo.io, ztunnel добавляет ~0.4 ms p50 латентности к трафику без mesh, обеспечивая 60–70% экономии ресурсов по сравнению с классическим sidecar-режимом.

Миграция с sidecar на ambient происходит постепенно и обратимо: namespace-ы переключаются через лейбл istio.io/dataplane-mode: ambient, а sidecar и ambient-нагрузки могут сосуществовать в одном кластере. Это позволяет платформенным командам мигрировать сервис за сервисом без downtime.

Cilium Service Mesh: eBPF-native подход

Cilium изначально строился вокруг eBPF и не нуждался в sidecar-модели. В его архитектуре L3/L4-политики выполняются целиком в ядре — программами eBPF, которые cilium-agent программирует на hooks tc, XDP и cgroup/connect4. L7-обработка включается через per-node Envoy, который активируется только для потоков, требующих HTTP-инспекции.

Это даёт радикальный выигрыш в производительности: Cilium eBPF (L3/L4) показывает overhead менее 1% по сравнению с bare-metal сетью, а P99 латентность увеличивается всего на ~0.4 ms. Для сравнения, классический Istio sidecar добавляет +4–5 ms P99.

Сравнение производительности

Свежие бенчмарки 2026 года (тестирование на OCI Ampere Altra, ARM64, 1 OCPU на ноду) дают следующие результаты:

| Сценарий | QPS (50 соединений) | vs Baseline | P50 латентность |

|---|---|---|---|

| Baseline (без mesh) | 1 235 | — | 42 ms |

| Cilium eBPF (L3/L4) | 1 218 | –1.3% | 43 ms |

| Istio Ambient | 883 | –28.5% | 54 ms |

| Istio Sidecar | 531 | –57.0% | 88 ms |

| Cilium L7 (Envoy) | 192 | –84.5% | 249 ms |

Главный вывод: Cilium eBPF на L3/L4 практически не добавляет overhead. Istio Ambient проигрывает ~28% пропускной способности, но это кардинально лучше, чем –57% у sidecar-режима. Cilium L7 оказался худшим на однопроцессорных нодах, но это проблема CPU-бюджета, а не архитектуры — на multi-core системах общий Envoy эффективнее per-pod sidecar.

Когда что выбирать

  • Cilium Service Mesh — если вы уже планируете замену CNI, хотите eBPF-native производительность и единый стек (CNI + mesh + observability). Идеален для greenfield-проектов.
  • Istio Ambient — если у вас существующие Istio CRD, нужна поддержка multi-cluster federation или вы цените более богатый L7-функционал и большое сообщество.
  • Без mesh — если вам достаточно Kubernetes NetworkPolicy и application-level mTLS. Этот путь по-прежнему валиден для небольших кластеров.

eBPF как фундамент: от iptables к in-kernel networking

В 2026 году eBPF перестал быть «экспериментальной технологией» и стал основой для сетевого стека Kubernetes. Cilium, проект, который уже почти десять лет развивает eBPF-нативный CNI, стал де-факто стандартом для новых кластеров.

Конец эпохи iptables

Традиционный kube-proxy с iptables использовал линейные цепочки правил — O(n) по количеству правил. При тысячах сервисов каждое новое соединение проходило через тысячи правил, что создавало значительную нагрузку на CPU и conntrack. Бенчмарки показывают: при 1 000+ сервисов Cilium (eBPF kube-proxy replacement) даёт на 30–60% ниже P99 латентность и на ~50% меньшее потребление CPU по сравнению с iptables-режимом.

На тестах с 100+ сетевыми политиками Cilium держит ~8.9 Gbps, в то время как Calico с iptables «проседает» до ~3.2 Gbps. Разрыв — 64%, и он растёт с увеличением числа политик.

Upstream Kubernetes тоже движется в эту сторону:

  • kube-proxy с nftables ожидает GA в Kubernetes 1.33 (замена iptables)
  • IPVS-режим деприкейтится в 1.35
  • Все три major облачных провайдера (EKS, GKE, AKS) предлагают eBPF-датаплейны как first-class option

Cilium 1.19: зрелость, безопасность, масштабирование

Релиз Cilium 1.19, вышедший в начале 2026 года, сфокусирован на трёх направлениях: encryption hardening, scalability для крупных кластеров и Gateway API. Среди ключевых возможностей:

  • Kube-proxy replacement c constant-time lookup сервисов через eBPF maps
  • Identity-based network policy — привязка политик к identity (label pod), а не к эфемерным IP
  • Gateway API production-grade (L7-роутинг в data plane)
  • ClusterMesh — multi-cluster networking без централизованного management-plane

Производительность Cilium на современном оборудовании впечатляет: pod-to-service throughput достигает ~28.5 Gbps против ~22.1 Gbps у Calico на iptables — прирост ~25%. А при 100 Gbps нагрузке Cilium использует менее 10% CPU (против 15–20% у Calico с nftables и 25–30% у Flannel).

Hubble и Tetragon: наблюдаемость и безопасность без sidecar

Cilium поставляется с двумя инструментами, которые делают eBPF-стек законченным.

Hubble — слой сетевой наблюдаемости, который генерирует structured flow events для каждого пакета, обогащённые Kubernetes-контекстом: имена подов, namespace, labels, сервисы, вердикты политик. Без sidecar, без проброса пакетов, без сэмплирования.

Tetragon — runtime security-инструмент, который через eBPF-хуки на syscall-ы, file access и process exec не только наблюдает, но и блокирует угрозы на уровне ядра, до того как syscall вернётся в userspace. В отличие от Falco, который только сообщает о подозрительной активности, Tetragon может убить процесс inline.

В 2026 году набор Cilium + Hubble + Tetragon — это рекомендуемый baseline для eBPF-наблюдаемости и безопасности, с экспортом телеметрии через OpenTelemetry Collector.

AI-ориентированная оркестрация: Kubernetes 1.36 и 1.37

Последние релизы Kubernetes отчётливо демонстрируют сдвиг в сторону AI/ML-нагрузок. Если раньше Kubernetes был платформой «в первую очередь для микросервисов, а во вторую — для batch-задач», то в 2026 баланс изменился.

Workload-Aware Scheduling (v1.35–1.36)

Kubernetes 1.35 и 1.36 ввели концепцию workload-aware scheduling — планировщик научился работать не с отдельными подам, а с группами (PodGroup).

Ключевые нововведения:

  • PodGroup API — группа подов как единый объект для Gang Scheduling (all-or-nothing)
  • Topology-aware scheduling — ко-локация подов группы в рамках одного NUMA-узла или физического домена
  • Workload-aware preemption — вытеснение подов для целой PodGroup, а не для одного пода
  • DRA ResourceClaim для PodGroup — одна ResourceClaim на всю группу, а не на каждый под (решает проблему лимита в 256 reservedFor entry)

Для AI-тренировок gang scheduling критичен: если распределённый training job не может запустить все свои поды одновременно, запуск части подов приводит к deadlock и пустой трате ресурсов.

v1.36 также интегрирует Job controller с Workload API — теперь Job-ы могут автоматически создавать PodGroup и Workload-объекты без дополнительного tooling.

Dynamic Resource Allocation (DRA): зрелость и partitionable devices

DRA стал GA в Kubernetes 1.34 и продолжает развиваться. В 1.36 и 1.37 добавились критически важные функции:

  • Partitionable devices (alpha в 1.36, продолжение в 1.37) — один физический GPU делится на логические slices, которые планируются независимо на разные поды. Это меняет экономику GPU-вычислений: дорогой акселератор перестаёт простаивать, когда одному inference-ворклоаду нужна только его часть.
  • DRA Extended Resources — мост между старыми extended resources и новым DRA API, позволяющий мигрировать постепенно
  • Resource pool status — возможность запросить снэпшот доступности устройств в пуле (total, allocated, available, unavailable) через ResourcePoolStatusRequest
  • DRA для CPU и memory — использование DRA API для управления стандартными вычислительными ресурсами, с NUMA-aware аллокацией

In-Place Vertical Scaling (v1.35–1.36)

In-Place Pod Vertical Scaling стал GA в 1.35, а расширение на Pod-Level Resources — Beta в 1.36. Теперь можно менять ресурсы пода без перезапуска, через cgroup v2. Kubelet обновляет cgroup limits динамически через CRI:

  • При увеличении — расширяется pod-level cgroup, затем индивидуальные container cgroups
  • При уменьшении — сначала сужаются container cgroups, затем pod-level

Это особенно полезно для VPA (Vertical Pod Autoscaler): он теперь может выдавать рекомендации по ресурсам и применять их in-place, без рестарта подов.

Kubernetes 1.37: консолидация и очистка

Релиз 1.37, ожидаемый 26 августа 2026 года, выглядит как консолидационный: без революций, но с важными operational-изменениями:

  • cgroup v1 — hard fail: kubelet откажется стартовать на нодах с cgroup v1
  • containerd 2.0 required: containerd 1.x больше не поддерживается
  • Удаление legacy manual driver flags: определение cgroup driver только через CRI

Для платформенных команд это означает, что аудит нод на cgroup v2 и containerd 2.0+ — задача №1 перед августовским апгрейдом.

Наблюдаемость и безопасность на уровне ядра

Когда sidecar-прокси уходят, а eBPF берёт на себя сеть, встаёт вопрос: как наблюдать и защищать кластер без sidecar?

Ответ — eBPF-based observability, которая в 2026 году стала мейнстримом. Опрос CNCF TAG Observability показывает: 67% команд, управляющих Kubernetes на масштабе, уже используют хотя бы один eBPF-инструмент для наблюдаемости.

OpenTelemetry eBPF Instrumentation

Grafana Beyla, проект с нуль-кодовой инструментацией приложений через eBPF, был передан в OpenTelemetry и теперь развивается как OpenTelemetry eBPF Instrumentation (OBI). На KubeCon EU 2026 Splunk объявил о поддержке OBI в бета-версии.

OBI мониторит сетевой трафик через eBPF и автоматически генерирует distributed traces и RED-метрики (Rate, Errors, Duration) для языков Go, Java, Python, Node.js, .NET, Ruby, C/C++ и Rust — без единого изменения кода приложения.

Стек наблюдаемости 2026

Рекомендуемый production-стек в 2026 выглядит так:

  1. Cilium + Hubble — сетевая наблюдаемость и политики на уровне ядра
  2. Tetragon — runtime security с inline-блокировкой на уровне syscall
  3. OBI / Beyla — нуль-кодовая APM и distributed tracing
  4. OpenTelemetry Collector — унифицированный хаб для фильтрации, трансформации и маршрутизации телеметрии во все бэкенды (Grafana, Prometheus, Tempo)

Перспективы: AI-driven threat detection

Во второй половине 2026 года ожидается внедрение ML-детекции угроз на основе данных Hubble network flow. Также анонсирован tetragon-python SDK, который позволит писать eBPF-политики безопасности на Python с транспиляцией в байткод. Это снижает порог входа для security-инженеров, не знакомых с C и eBPF.

Заключение

Kubernetes в 2026 году — это зрелая, но быстро эволюционирующая платформа. Три главных тренда определяют её будущее:

Sidecarless mesh становится стандартом. Istio Ambient и Cilium Service Mesh предлагают разные подходы, но оба избавляют от главного источника оверхэда — per-pod прокси. Выбор между ними — это выбор между богатством L7-функций и максимальной производительностью.

eBPF побеждает iptables на всех фронтах. Cilium де-факто стал стандартным CNI, а Hubble и Tetragon дают наблюдаемость и безопасность без sidecar. Это снижает операционную сложность и радикально улучшает производительность.

Kubernetes становится AI-first платформой. DRA, PodGroup-шелдулинг и partitionable devices делают кластер полноценным планировщиком для AI/ML-нагрузок. Gang scheduling больше не требует внешних операторов.

Что делать платформенной команде прямо сейчас:

  • Для новых кластеров — используйте Cilium как CNI, рассмотрите Cilium Service Mesh или Istio Ambient как mesh
  • Для существующих Istio — мигрируйте на ambient mode, это снизит resource footprint на 60–70%
  • Подготовьтесь к K8s 1.37 — проверьте ноды на cgroup v2 и containerd 2.0+
  • Внедрите eBPF-observability — Hubble + Tetragon уже сегодня дают больше, чем legacy sidecar-инструментация

Часто задаваемые вопросы

Нужен ли вообще service mesh в 2026 году?

Если в вашем кластере нет требований к mTLS, L7-маршрутизации и zero-trust политикам — Kubernetes NetworkPolicy и application-level mTLS может быть достаточно. Service mesh стоит внедрять только когда эти требования действительно есть.

Что выбрать: Istio Ambient или Cilium?

Для greenfield-проектов с фокусом на производительность — Cilium. Для существующих инвестиций в Istio CRD и multi-cluster — Istio Ambient. На малых кластерах (до 10 нод) mesh может быть избыточен.

Когда переходить на eBPF?

Если ваш минимальный kernel — 5.10+ (рекомендуется 6.1+), то eBPF-стек (Cilium) уже сегодня даёт измеримые преимущества. Единственная причина откладывать — legacy kernel или специфические требования к iptables.

Как eBPF влияет на безопасность?

Tetragon позволяет блокировать угрозы на уровне ядра до того, как они затронут userspace, а CiliumNetworkPolicy даёт identity-based контроль на L3/L4/L7. Это более эффективная модель, чем legacy sidecar с EnvoyFilter.