Cilium и Istio в 2026: сравнительный анализ архитектур, производительности и миграции

Cilium и Istio часто противопоставляют как «два service mesh». На практике это продукты с разной исходной функцией: Cilium — eBPF-based CNI (Container Network Interface) с нарастающими возможностями L7 и mesh-подобной безопасностью; Istio — service mesh с зрелым L7-управлением трафиком, где dataplane historically строился на sidecar Envoy, а с 2024–2026 гг. — также на ambient-режиме без sidecar. Корректный выбор в 2026 году опирается не на маркетинговые ярлыки, а на слой OSI, модель идентичности и измеренный overhead.

Оба проекта — выпускники CNCF. Ниже — сверка версий, терминологии, независимых и вендорских бенчмарков 2025–2026, а также практический контур миграции с Istio Sidecar на Cilium.

1. Терминология (краткий глоссарий)

Путаница WireGuard ↔ mTLS — типичная ошибка обзоров 2024–2025 гг. Их следует описывать как дополняющие, а не взаимозаменяемые механизмы.

2. Версии и зрелость (актуально на сентябрь 2026)

Cilium

Cilium поддерживает три последних minor. «LTS» в классическом смысле (как у Kubernetes) у проекта нет.

Ключевые возможности 1.20: поддержка Gateway API v1.6.1 (в т.ч. HTTPRoute ExternalAuth / GEP-1494), расширяемый datapath для облачных провайдеров, автоматический выбор netkit vs veth, IPv6 ENI IPAM (beta).

Istio

Ошибка исходного текста: «Ambient развивается с 1.18» — слишком ранний ориентир для production-нарратива; для продакшена следует указывать GA в 1.24. Sidecar не deprecate.

Control plane: сегодня это Istiod (историческое объединение Pilot / Citadel / Galley); отдельно перечислять три компонента как текущую архитектуру некорректно.

3. Архитектуры dataplane

3.1. Cilium: eBPF в ядре

Пакеты обрабатываются eBPF-программами на узле. Это снижает число context switch относительно userspace-прокси и делает Cilium естественным выбором как единый CNI (замена kube-proxy, NetworkPolicy, базовая observability).

Компоненты: Cilium Agent (DaemonSet), eBPF datapath, Hubble (flows/DNS/HTTP observability), Tetragon (runtime security на syscalls), опционально Envoy для L7 policy / Gateway API, опционально ztunnel для L4 mTLS.

3.2. Istio: Sidecar и Ambient

Sidecar: Envoy в каждом поде → полный L7 на каждом hop, высокая изоляция политик, предсказуемая модель, выше CPU/RAM.

Ambient:

1. Namespace/pod в mesh → L4 через ztunnel (mTLS + L4 authz + telemetry по HBONE).
2. При необходимости L7 → waypoint (Envoy), обычно один на namespace/service, а не на каждый pod.

Согласно документации Istio (сводка dataplane modes), ориентиры latency (p90/p99): ambient L4 порядка 0.16–0.20 ms, waypoint 0.40–0.50 ms, sidecar 0.63–0.88 ms (лабораторные условия; не абсолют для любого кластера).

4. Производительность: что говорят измерения 2024–2026

Бенчмарки service mesh нельзя сводить к одной таблице без указания: L3/L4 vs L7, наличие ли mTLS, encrypt on/off, железо, и кто автор теста.

4.1. Независимый бенчмарк (OCI ARM64, Kubernetes 1.32, Fortio; публичный отчёт 2025)

Сценарии относительно baseline без mesh (service-mesh-benchmark):

Вывод: на L3/L4 Cilium практически совпадает с «голым» ядром. Ambient существенно легче sidecar, но тяжелее чистого eBPF. Cilium L7 на слабых single-core узлах может дать катастрофический overhead — это не опровержение Cilium как CNI, а предупреждение против «включить HTTP policy везде» без capacity planning.

4.2. mTLS overhead (исследование DEEPNESS Lab / arXiv:2411.02267, 2024–2025)

При целевой нагрузке 3 200 RPS рост latency относительно режима без mTLS:

Важно: в этом тесте Cilium не показал минимальный mTLS-overhead; Ambient оказался лучшим по приросту latency. Cilium выигрывал по CPU scalability (нет sidecar на каждый pod). Авторы также отмечают, что Cilium по дизайну может не шифровать intra-node трафик в ряде режимов — это снижает latency, но меняет threat model.

4.3. Вендорский large-scale тест Istio («Scaling in the Clouds», AKS до ~1000 узлов / ~11 000 ядер)

Публикация Istio (сравнение Ambient vs Cilium при включённых сопоставимых security/L7-фичах):

• Istio обработал на ~56% больше запросов при ~20% меньшей tail latency;
• CPU у Cilium был ~на 30% ниже, но измерение не включало ядра, занятые kernel-side encryption;
• нормировка: ~2178 QPS/core (Istio) vs ~1815 QPS/core (Cilium) (~+20% в пользу Istio).

Интерпретация: при «feature parity» (шифрование + L7) преимущество «лёгкого eBPF» частично нивелируется. Тест не независим (автор — Istio), но полезен как stress-test на тысячах узлов.

4.4. Gateway API throughput

Таблицы вида «Istio 99 994 QPS / 0.097 ms vs Cilium 20 049 QPS» без методички сравнивают ingress/Gateway, а не east-west mesh. Их нельзя экстраполировать на «Cilium медленнее Istio в service mesh». В обзорах 2026 их следует помечать как Gateway-specific.

4.5. Ресурсы (ориентиры порядка величины)

Утверждения вида «95 MB vs 15 GB на 50 узлов» допустимы только с явной методикой суммирования (включая все waypoints). Без источника — как иллюстрация порядка, не как норматив.

5. Безопасность и Zero Trust

Cilium

1. Identity-based NetworkPolicy (L3–L7) по Kubernetes labels / CiliumIdentity.
2. WireGuard / IPsec — transparent encryption между узлами.
3. Ztunnel (beta) — L4 mTLS между enrolled namespaces (TCP); enrollment через label namespace.
4. Tetragon — detection на уровне процессов (exec, network syscalls).
5. Legacy Mutual Authentication (SPIRE) — с 1.19 disabled by default; для mTLS рекомендуют пробовать ztunnel.

Istio

1. mTLS (STRICT / PERMISSIVE) — зрелая модель; в ambient mTLS обеспечивается ztunnel по умолчанию для mesh traffic.
2. SPIFFE workload identity.
3. AuthorizationPolicy L4/L7 (методы, paths, JWT).
4. Интеграции: SPIRE, cert-manager, внешние CA.

Практический вывод: для «Zero Trust L4 + минимальный overhead» в экосистеме Istio рационален Ambient; для «CNI + network policy + kernel visibility» — Cilium. Для строгого L7 Zero Trust с богатыми HTTP-политиками Istio (sidecar или ambient+waypoint) по-прежнему зрелее.

6. Управление трафиком и наблюдаемость

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

Cilium как основа, если:

• нужен единый высокопроизводительный CNI и NetworkPolicy;
• критична east-west latency на L3/L4;
• крупные кластеры (часто рекомендуют managed Cilium на сотнях узлов);
• важны Hubble/Tetragon без sidecar tax.

Istio Ambient, если:

• нужен mesh mTLS и L4 Zero Trust с низким overhead (+8% latency в mTLS-тесте);
• L7 нужен выборочно (waypoints);
• команда уже в экосистеме Istio.

Istio Sidecar, если:

• нужны зрелый multi-cluster и функции, ещё не паритетные в ambient;
• требуется per-pod L7 isolation и привычная операционная модель.

Гибрид Cilium CNI + Istio mesh — распространённый и поддерживаемый паттерн (в т.ч. в AKS-сценариях): сеть и policy на eBPF, service identity и L7 — на Istio. Требует аккуратной совместимости CNI chaining / datapath.

8. Миграция: Istio Sidecar → Cilium

Ниже — практический алгоритм смены dataplane/mesh-стека на Cilium, а не только переход sidecar→ambient внутри Istio. Параллельно указан «мягкий» путь остаться в Istio.

8.1. Целевые варианты

Большинство команд, говорящих «уходим с sidecar на Cilium», имеют в виду A или B.

8.2. Фаза 0 — инвентаризация (1–3 дня)

1. Каталог зависимостей от Istio:

• VirtualService, DestinationRule, Gateway, EnvoyFilter, WasmPlugin;
• PeerAuthentication, RequestAuthentication, AuthorizationPolicy (отдельно L4 vs L7);
• mTLS STRICT между namespace;
• multi-cluster / east-west gateways;
• retry/timeout/outlier, canary, fault injection.

2. Классифицировать сервисы:

• L4-only (достаточно NetworkPolicy + encryption);
• L7-light (path routing, простой JWT);
• L7-heavy (сложные canary, custom EnvoyFilter) — кандидаты остаться на Istio или на Ambient+waypoint.

3. Зафиксировать SLO: p99 latency, error budget, RPS. Снять baseline до миграции (Prometheus / Fortio).

8.3. Фаза 1 — Cilium как CNI (без отключения Istio)

Если кластер ещё на другом CNI:

1. Подготовить maintenance window / blue-green node pool (для managed K8s — новый node pool с Cilium).
2. Установить Cilium (версия из поддерживаемых: 1.18–1.20 на сентябрь 2026).
3. Проверить: cilium status, connectivity test, Hubble flows.
4. Не удалять Istio на этом шаге: sidecar продолжают работать поверх нового CNI после drain/пересоздания pod.

Критерий готовности: east-west и ingress зелёные; нет роста 5xx; Hubble видит flows.

8.4. Фаза 2 — замещение функций Istio эквивалентами Cilium

Рекомендуемый порядок отключения Istio-фич:

1. Убрать custom EnvoyFilter / переписать.
2. Перевести canary на Rollouts/Gateway API.
3. Переписать L7 authz.
4. Включить Cilium encryption (сначала WireGuard в lab, затем ztunnel на пилотных namespace).
5. Перевести PeerAuthentication STRICT → соответствующая политика Cilium.
6. Снять sidecar injection по namespace.

8.5. Фаза 3 — поэтапный вывод sidecar

На namespace payments (пример):

# 1) Политики Cilium уже применены и проверены в shadow/report режиме
kubectl apply -f cilium-policies/payments/

# 2) Включить encryption/ztunnel enrollment при необходимости
kubectl label namespace payments io.cilium/mtls-enabled=true  # уточняйте актуальный label по docs вашей версии

# 3) Отключить injection
kubectl label namespace payments istio-injection- \
  istio.io/dataplane-mode-

# 4) Перезапуск workload (sidecar исчезнет)
kubectl rollout restart deploy -n payments

# 5) Проверка
cilium connectivity test
# Hubble: нет DROPPED на легитимных flows

Делайте один namespace за раз. После каждого — сравнение p99/error rate с baseline (± бюджет).

8.6. Фаза 4 — удаление control plane Istio

Только когда:

• нет pod с sidecar;
• нет критичных CRD Istio в runtime path;
• мониторинг и on-call runbook обновлены.

Затем uninstall Istio, очистка CRD (осознанно: бэкап istioctl dump), ревизия RBAC.

8.7. Типичные риски

8.8. Альтернатива: Sidecar → Ambient (остаёмся на Istio)

Если цель — снизить стоимость sidecar, а не внедрить Cilium:

1. Установить ambient components (ztunnel, CNI ambient).
2. Перезапустить sidecar с HBONE для совместимости.
3. Мигрировать политики (VirtualService→HTTPRoute, L7 AuthorizationPolicy→targetRefs на waypoint).
4. Label istio.io/dataplane-mode=ambient, снять injection, restart.
5. Учесть окно без L7 enforcement при миграции (документированный gap Istio).

Официальный гайд: Migrate from Sidecar to Ambient.

9. Итоговая матрица

Практическая рекомендация 2026: начинайте с вопроса «нужен ли нам service mesh или достаточно CNI + policy + encryption?». Часто ответ — Cilium как CNI, а Istio (лучше Ambient) — только там, где доказана потребность в L7 mesh. При уже установленном sidecar оценивайте сначала ambient migration, и лишь затем полный уход на Cilium mesh-стек — если L7-зависимости Istio можно заменить.

Источники

• Cilium releases / 1.20
• Cilium WireGuard / Ztunnel encryption
• Istio Ambient GA (1.24)
• Istio 1.30 announcement
• Istio: Sidecar or ambient?
• Istio: Migrate Sidecar → Ambient
• Istio blog: Scaling in the Clouds (Ambient vs Cilium)
• arXiv:2411.02267 — mTLS performance comparison
• Independent Fortio/eBPF benchmark report

Обновлено: 17 сентября 2026. WeDoOps.