🎯 AIOps — это эволюция ответственности, а не магия

1. Сначала данные: без OpenTelemetry нет разговора.
2. Итеративно растите от baselin'ов к автопоиску причин.
3. Замыкайте обратную связь с инженерами.
4. Доверяйте, но проверяйте: даже самый умный AI требует человеческого контроля.


#AIOps #DevOps #SRE #MachineLearning

🔗 Cilium Cluster Mesh между двумя RKE2 – quick guide

📦 Исходные данные:
Кластеры msk-1 и spb-1 с Cilium (rke2-cilium), cilium-cli установлен.

⚠️ Важно:
- Pod-подсети кластеров не должны пересекаться.
- Между кластерами открыт порт 2379 (или другой, заданный у clustermesh-apiserver).


1️⃣ Переменные

export CLUSTER1=msk-1 CLUSTER2=spb-1

2️⃣ Сброс старых секретов (опционально)

kubectl --context=$CLUSTER1 delete secret -n kube-system cilium-ca --ignore-not-found
kubectl --context=$CLUSTER2 delete secret -n kube-system cilium-ca --ignore-not-found

3️⃣ Включаем mesh на первом кластере

cilium --helm-release-name rke2-cilium clustermesh enable \
  --context $CLUSTER1 --service-type LoadBalancer

🔍 Если нет LB, используй NodePort и укажи IP вручную позже.

4️⃣ Копируем корневой CA во второй кластер

kubectl --context=$CLUSTER1 get secret -n kube-system cilium-ca -o yaml | \
  kubectl --context=$CLUSTER2 create -f -

5️⃣ Защищаем секрет от удаления Helm-ом
(выполнить в обоих кластерах)

kubectl --context=$CLUSTER1 label secret -n kube-system cilium-ca \
  app.kubernetes.io/managed-by="Helm"
kubectl --context=$CLUSTER1 annotate secret -n kube-system cilium-ca \
  meta.helm.sh/release-name="rke2-cilium" \
  meta.helm.sh/release-namespace="kube-system"

Аналогично для $CLUSTER2.

6️⃣ Включаем mesh на втором кластере

cilium --helm-release-name rke2-cilium clustermesh enable \
  --context $CLUSTER2 --service-type LoadBalancer

7️⃣ Проверяем поднятие apiserver

cilium clustermesh status --context $CLUSTER1 --wait
cilium clustermesh status --context $CLUSTER2 --wait

8️⃣ Соединяем кластеры

cilium --helm-release-name rke2-cilium clustermesh connect \
  --context $CLUSTER1 --destination-context $CLUSTER2

📌 При использовании NodePort или нестандартного IP:

cilium ... connect --context $CLUSTER1 \
  --destination-endpoint <IP>:<Port>

9️⃣ Финальная проверка

cilium clustermesh status --context $CLUSTER1
kubectl exec -it -n kube-system ds/cilium -- cilium-dbg node list

Видишь оба кластера? ✅

🔟 Тест связности

cilium connectivity test --helm-release-name rke2-cilium \
  --context $CLUSTER1 --multi-cluster $CLUSTER2

или пинг вручную:
kubectl --context=$CLUSTER1 exec test-tools -- ping -c 4 <pod-IP-во-втором-кластере>

🛑 Разрыв mesh

cilium --helm-release-name rke2-cilium clustermesh disconnect \
  --context $CLUSTER1 --destination-context $CLUSTER2

🧠 Как это работает
В каждом кластере поднимается clustermesh-apiserver, агенты Cilium устанавливают к нему mTLS-соединения, используя общий корневой сертификат (cilium-ca). Метаданные узлов и сервисов синхронизируются через эти каналы.

💡 Не забыть:
- Секрет cilium-ca должен быть одинаковым во всех кластерах mesh.
- Лейблы Helm — обязательны, иначе при helm upgrade секрет удалится → mesh сломается.
- Порт 2379 (по умолчанию) должен быть доступен с нод одного кластера до apiserver другого.

Готово! Твои поды теперь видят друг друга напрямую. 🌐

🤖 AI в DevOps: Как Cursor, Claude, Copilot и Amazon Q меняют работу инженера

Давайте без воды: AI-инструменты уже не игрушки, а полноценные члены команды. Расскажу про четвёрку лидеров.

⚙️ Кто есть кто
• Cursor — AI-first IDE на базе VS Code. Видит весь ваш репозиторий с Terraform, Helm, Ansible и даёт советы, а в агентном режиме сам создаёт и правит файлы.
• Claude (Claude Code) — языковая модель с терминальным агентом. Запускаете прямо на сервере: читает логи, находит ошибки и выполняет команды для восстановления.
• GitHub Copilot — AI, встроенный в GitHub. Чатится в Issues и PR, генерирует код, анализирует пайплайны Actions и экономит кучу времени на ревью.
• Amazon Q Developer — облачный помощник от AWS. Заточен под CloudFormation, CDK, Terraform. Сканирует уязвимости и выдаёт минимальные IAM-политики.

🔥 Фишки, ради которых стоит пробовать

Cursor: агентный режим
Пишете в чате «сделай модуль EKS с IRSA и мониторингом» — агент создаёт всю структуру, правит security-группы и генерирует README. По нашему style guide, который описан в .cursorrules.

Claude Code: ночной инцидент
Упал Kafka Strimzi. Вместо гугления я дал агенту доступ к логам — он нашёл проблему с сертификатами и выдал готовые kubectl annotate. Восстановились за 5 минут вместо 40.

Copilot: AI в пайплайнах
Упал GitHub Actions? Задаёте вопрос прямо в логе — Copilot объясняет ошибку и предлагает правку. В Copilot Workspace можно создать Issue «добавь автомасштабирование для ECS» и получить готовый PR с кодом.

Amazon Q: безопасность на автомате
Пишете CDK-конструкт, а Q подсвечивает: «S3-бакет публичный!» — и предлагает исправление. Сканер секретов не даёт запушить ключи в репозиторий. И генерация IAM-политик по описанию — экономия часа времени.

🚀 Новые реалии
1. Мульти-агентность: Copilot генерирует черновик модуля → Amazon Q проверяет на AWS-уязвимости → Cursor доводит до ума → Claude Code применяет.
2. Инфраструктура как промпт: системные промпты и правила версионируются вместе с кодом. CI/CD включает этапы AI-генерации и автоматической валидации.
3. Без человека пока никуда: галлюцинации случаются, поэтому финальный approve и OPA/Checkov обязательны.

🧰 Шпаргалка: что для чего
— Создать Terraform-модуль → Cursor Agent / Copilot Workspace
— Отладить CI/CD → Copilot Chat / Claude Code
— Написать Kubernetes манифесты → Cursor / Copilot
— Проверить безопасность AWS → Amazon Q Developer
— Автоматизировать инциденты в консоли → Claude Code
— Сгенерировать мониторинг-правила → Claude / Copilot Chat

🏁 Вывод
Мы становимся не просто DevOps-инженерами, а AI-операторами: ставим задачи, проектируем цепочки валидации и фокусируемся на архитектуре. Рутина уходит агентам. Но важно помнить золотое правило: всегда понимать, что именно генерирует AI, и уметь написать это руками.

Какие инструменты используете вы? Делитесь в комментариях 👇

#DevOps #AI #Cursor #Claude #Copilot #AmazonQ #автоматизация #IaC

📱 Cursor для DevOps: Полный гайд

Последний год Cursor — мой основной инструмент для инфраструктуры. Это не просто редактор, а AI-напарник, который понимает Terraform, Helm, K8s и умеет выполнять команды. Делюсь опытом.

🚀 Почему Cursor круче VS Code + Copilot
• Видит весь репозиторий, а не только открытый файл
• Агентный режим сам создаёт файлы и запускает terraform plan, kubectl get
• Глубокая кастомизация через .cursorrules и MCP

⚙️ Быстрый старт
1. Скачайте с cursor.com, импортируйте настройки VS Code
2. Откройте папку с инфраструктурным репозиторием
3. Освойте 3 элемента: Tab (автодополнение), Chat (Ctrl+L), Composer (Ctrl+I)

🤖 Какую модель выбрать
• Claude 3.5/3.7 Sonnet — лучший для Terraform, HCL, YAML. Меньше галлюцинаций, точный код.
• GPT-4o — хорош для Python/Bash скриптов и документации.
• Gemini 1.5 Pro — длинный контекст, полезен для анализа больших логов.

👉 Мой совет: для IaC берите Claude, для скриптов — GPT-4o.

#Cursor #DevOps #AI #Terraform #Kubernetes

📱 Cursor для DevOps: Настройка под себя

🔧 Шаг 1: Создайте `.cursorrules`
Это файл в корне репозитория, который превращает общий AI в эксперта по вашим стандартам. Пример:

You are a senior DevOps engineer.
Rules:
- AWS provider >= 5.0
- Never hardcode secrets
- Tags: Environment, Project, Owner
- Never allow public S3 or 0.0.0.0/0
- Always set k8s resources and probes
- Avoid wildcard IAM

Положите его в корень, и Cursor будет автоматически следовать правилам.

🧠 Шаг 2: Включите индексацию кодовой базы
Settings → Features → Codebase Indexing. Для больших монорепо критично: AI видит связи между модулями.

📚 Шаг 3: Notepads и Project Knowledge
• Notepads — встроенные заметки (Runbooks, Architecture, Gotchas). Упоминайте через @Notepad:Runbooks
• Project Knowledge — загрузите PDF/Markdown с документацией. AI будет искать ответы там, снижая галлюцинации.

🤖 Шаг 4: Режимы агента в Composer
• Normal — предлагает изменения, вы применяете
• Auto — сам правит файлы и выполняет команды, но спрашивает для опасных
• YOLO — всё без спроса. ⛔️ Никогда не используйте в проде!

Я использую Auto, но запрещаю автовыполнение terraform apply и kubectl delete.

#Cursor #DevOps #AI #Настройка

📱 Cursor для DevOps: Продвинутая интеграция

🔌 Подключаем MCP-серверы
Model Context Protocol позволяет Cursor работать с живыми системами: kubectl, terraform, AWS CLI, GitHub.

Пример: через kubernetes-mcp агент сам проверит статус подов, а через terraform-mcp выполнит plan и покажет diff.

Как подключить:
1. Установите MCP-сервер (npm или Docker)
2. Settings → Features → MCP → Add MCP Server
3. Укажите команду запуска

🔒 Безопасность
• Никогда не храните секреты в .cursorrules или Notepads
• Используйте отдельные AWS профили с ограниченными правами
• Разрешайте только безопасные команды: terraform fmt, kubectl get, helm lint
• Всегда смотрите git diff перед коммитом

⚡️ Где использовать (часть 1)
1. Генерация Terraform-модулей: «Создай модуль RDS с multi-AZ, шифрованием, тегами» — агент создаст все файлы.
2. Отладка ошибок: вставьте вывод terraform plan в Chat, он найдёт причину.
3. Написание Helm-чартов: «Сгенерируй чарт для веб-приложения с probes, HPA, ingress».
4. CI/CD пайплайны: «Напиши GitHub Actions workflow для сборки, Trivy, деплоя в EKS».

#Cursor #DevOps #MCP #Безопасность

📱 Cursor для DevOps: Сценарии и советы

🛠 Где использовать (часть 2)
5. Рефакторинг Ansible: «Вынеси повторяющиеся задачи в роли, добавь обработку ошибок».
6. Скрипты автоматизации: «Создай Python-скрипт для бэкапа RDS в S3 с шифрованием».
7. Анализ безопасности: «Найди открытые порты, широкие IAM, отсутствие шифрования» — AI выдаст список с рекомендациями.

💡 8 советов для максимальной эффективности
1. Пишите чёткие промпты: контекст, результат, ограничения
2. Используйте @-упоминания файлов
3. Проверяйте версии API (terraform validate)
4. Интегрируйте линтеры: tflint, checkov, hadolint
5. Сохраняйте удачные промпты в git
6. Просите AI объяснить изменения перед применением
7. Добавляйте в .cursorrules типичные ошибки вашей инфраструктуры
8. Для прод-операций всегда проверяйте diff вручную

🏁 Вывод
Потратьте час на настройку — получите AI-ассистента, который знает вашу инфраструктуру и берёт на себя рутину. Начните с малого: создайте .cursorrules, включите Auto-режим, попробуйте сгенерировать модуль.


#Cursor #DevOps #AI #Автоматизация #Советы

Почему DevOps больше не про скрипты

🤖 DevOps 2026: ИИ не заменит, но переопределит

Три года назад DevOps‑инженер = Kubernetes + Terraform + CI/CD + Bash.
Сегодня 83% IT‑специалистов говорят: индустрия меняется из‑за ИИ.

Главный вопрос уже не «заменит ли ИИ DevOps?» – нет.
Вопрос: «заменит ли инженер с ИИ инженера без ИИ?» – да, однозначно.

💡 В этой серии постов разберём:
– какие навыки теперь в цене
– сколько доплачивают за AI‑скиллы
– какие новые ветви профессии появились
– и куда двигаться, чтобы не выпасть из тренда

Рынок труда: спрос и зарплатная премия

📊 Цифры, которые меняют всё

Спрос на DevOps остаётся высоким:
– более 40 000 активных вакансий в США
– рынок растёт на 19,2% в год ($14,95 млрд в 2025‑м)

Анализ 3556 вакансий (май 2026):
🔹 10,3% явно требуют GenAI (агенты, LLM, RAG)
🔹 18,2% – любые AI‑навыки (ML, MLOps)

💰 Зарплатная премия (США, медиана):
– без AI‑скиллов: $114 000
– с AI‑скиллами: $150 000
– +$36 000 в год!

Лидеры по найму AI‑DevOps: Software‑компании (15,7%) и FinTech (14,2%).

Как ИИ меняет рутину DevOps-инженера

⚙️ От «тушения пожаров» к предсказаниям

Раньше: реагируем на инциденты.
Теперь: AI анализирует логи, метрики и историю – и предупреждает сбой ДО его начала.

Что ещё изменилось:

✅ CI/CD – самооптимизация: AI находит flaky‑тесты, ускоряет сборку, прогнозирует риски деплоя.

✅ IaC (Terraform, K8s‑манифесты) – генерируется с помощью копилот. Пример: Pulumi Neo сократил время provisioning с 3 дней до 4 часов.

✅ Облачные затраты – AI автоматически находит аномалии, подбирает дешёвые инстансы и оптимизирует workload в реальном времени.

📌 87% инженеров говорят: ИИ освобождает время для системного проектирования вместо ручного скриптинга.

Это называется shift‑up – переход на уровень выше.

Новые ветви профессии: кем стать сегодня

🧭 4 карьерных трека, которые породил ИИ

1️⃣ MLOps – DevOps для ML‑моделей: пайплайны, мониторинг дрифта, A/B‑тесты. Инструменты: MLflow, Kubeflow.

2️⃣ AIOps – интеллектуальная эксплуатация. 73% предприятий внедряют к концу 2026. Обещает ускорение разрешения инцидентов на 25%+.

3️⃣ Platform Engineering + AI‑агенты – строим внутренние платформы со встроенными агентами. К 2030 году 80% разработчиков будут работать с автономными AI‑агентами (IDC).

4️⃣ DevSecOps с AI‑безопасностью – AI сканирует код, контейнеры и облачные конфиги, выявляя уязвимости до продакшена.

Каждый трек – это +20–45% к зарплате по сравнению с классическим DevOps.

Новый стек навыков: что учить, а что забыть

📚 Must‑have 2026

🔹 Фундамент – Linux, сеть, Kubernetes, один язык (Python/Go). Без него вы не поймёте, куда вас ведёт модель.

🔹 AI‑грамотность – умение настраивать агентов, писать промпты, понимать ограничения LLM.

🔹 Policy‑as‑Code – декларативная безопасность, встроенная в CI/CD.

🔹 Review как навык – проверять код, сгенерированный AI, теперь ценнее, чем писать его самому. Требует более глубокого контекста.

🔹 Multi‑LLM‑стратегии – Claude для сложных рассуждений, AWS Q для облака, локальные модели для приватных данных.

❌ Что уходит – фиксированные скрипты. Harness уже предлагает агентов, которые делают их ненужными.

💡 «Junior + AI = Middle» – но только при твёрдом фундаменте.

Риски, будущее и главный вывод

⚠️ Теневая сторона AI‑трансформации

🔸 «Теневой ИИ» – агенты, используемые без одобрения и мониторинга. Когда AI начинает действовать (менять ресурсы), риски взлетают.

🔸 Скорость – главная угроза – изменения попадают в продакшен быстрее, чем их проверяют.

🔸 Governance – только 39% компаний имеют полные audit‑треки для AI‑операций.

Уже были реальные кейсы: Replit «уронил» базу, сервис аренды машин «ушатал» продакшен.

🚀 Будущее: Agentic DevOps

Оркестр AI‑агентов сам развернёт сервис, настроит observability, проверит безопасность и затраты. Инженер – архитектор и оркестратор, а не исполнитель.

💎 Итог

DevOps не исчезает – он трансформируется.
Спрос растёт, зарплаты – тоже, но требования меняются.

«Инженер с ИИ заменит инженера без ИИ» – это уже реальность.

Фундамент + AI‑навыки + умение работать с агентами = ваше будущее.

#DevOps #AI #AIOps #MLOps #PlatformEngineering #Карьера

Я наконец закончил строить из себя фронтенд разработчика

И наконец запустил свой сайт блог где буду писать развернутые статьи с заметками

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

Https://we-do-ops.ru

P.s. прошу сильно не судить, осталось только перенести все статьи в этот сайт) ну и это первая версия)

🔥 DevSecOps: безопасность, встроенная в разработку

Киберпреступность в РФ выросла примерно в 2,3 раза за 5 лет: с ~294 тыс. (2019) до ~677 тыс. (2023). В 2024-м — уже около 765 тыс. (МВД).

Утечки тоже бьют по объёму: по Роскомнадзору, в 2024 году 135 инцидентов — в сумме 710+ млн записей о россиянах (это строки в базах, не уникальные люди; большая часть — один крупный кейс).

«Пентест в конце» под ежедневные деплои уже не тянет. Ответ — DevSecOps.

🔐 Что это
Безопасность на каждом этапе: от кода до прода. Главный принцип — Shift Left: ловим дыры как можно раньше, пока фикс дешёвый.

Не «два сканера в пайплайне», а:
• Security as Code — политики в Git
• Автоматические проверки в CI/CD
• Гейты на CRITICAL перед продом
• Мониторинг после деплоя
• Общая ответственность dev + ops + ИБ

📊 State of DevOps Russia 2025
(«Экспресс 42» / Флант + партнёры, в т.ч. Positive Technologies)
• ~77% используют инструменты ИБ / выстраивают процессы безопасной разработки
• ~67% уже встроили ИБ в CI/CD
• ~40% — защита проходит через весь цикл
• ~75% собирают метрики ИБ

🛠 Базовый стек
• SAST — Semgrep / SonarQube / GitLab SAST
• SCA — Trivy / Snyk / Dependency-Check
• Образы — Trivy (+ SBOM)
• DAST — OWASP ZAP (на staging)
• Секреты — Vault / External Secrets
• IaC / K8s policy — Checkov, Kyverno

Как внедрять без саботажа команды:
1) пилот на одном сервисе
2) сначала report-only, потом fail на CRITICAL
3) понятные отчёты: сервис / env / что делать

⚠️ Типичные барьеры (тот же отчёт)
• ~46% — нехватка экспертизы
• ~42% — совместимость со стеком
• ~41% — стоимость
• ~27% — непонятные результаты сканов

📌 ГОСТ Р 56939-2024
С 20.12.2024 в силе (взамен 2016). Это стандарт безопасной разработки. Сам по себе он не делает DevSecOps обязательным для всех — но для КИИ, госконтуров и сертификации ориентир жёстче. Уточняйте у ИБ/юристов.

Итог: DevSecOps — не про набор гаджетов, а про культуру и гейты в пайплайне. Быстрее релизы + дешевле чинить дыры.

Разбор на сайте → https://we-do-ops.ru/ru/blog/security-in-devops-devsecops
Вопросы / аудит → @WeDoOps

#DevSecOps #InfoSec #Кибербезопасность #DevOps #CI_CD

🔥 Cilium и Istio в 2026: это не «два service mesh»

Часть 1/5

Их часто ставят в один ряд. На практике роли разные.

Cilium — eBPF-CNI: сеть узла, NetworkPolicy, observability, плюс нарастающие L7 и mesh-фичи.

Istio — service mesh: mTLS, маршрутизация, retries, L7-политики. Dataplane: sidecar Envoy или ambient без sidecar.

Выбор в 2026 — не по маркетингу, а по слою OSI, модели идентичности и измеренному overhead.
Оба — выпускники CNCF.

📘 Мини-глоссарий

1. eBPF — программы в ядре Linux: фильтр, маршрутизация, observability без модулей ядра
2. CNI — IP, маршруты, часто NetworkPolicy на уровне ноды
3. Service mesh — mTLS, routing, retries, observability между сервисами без правок кода
4. mTLS — взаимная аутентификация и шифрование между workload
5. SPIFFE — крипто-идентичность (spiffe://…); SPIRE — частая реализация
6. HBONE — туннель поверх HTTP CONNECT в Istio Ambient (ztunnel), несёт mTLS
7. Sidecar — Envoy в каждом поде
8. Ambient — ztunnel (L4 на ноде) плюс waypoint (L7 Envoy по необходимости)
9. WireGuard в Cilium — шифрование между нодами. Это НЕ эквивалент workload mTLS / SPIFFE
10. Cilium ztunnel (beta с ~1.19) — L4 mTLS между enrolled pods (TCP), отдельно от WireGuard

WireGuard и mTLS дополняют друг друга, а не заменяют. Типичная ошибка обзоров 2024–2025.

📦 Версии (сентябрь 2026)

Cilium:
1. 1.20.x — актуальный minor (1.20.0 около 29.07.2026; патчи 1.20.2 — середина сентября)
2. 1.19 и 1.18 — поддерживаются
3. 1.17 и старше — EOL
4. «LTS как у Kubernetes» нет — держат три последних minor
5. В 1.20: Gateway API v1.6.x (в т.ч. ExternalAuth), datapath plugins, bpf.datapathMode=auto (netkit)

Istio:
1. Ambient GA — 1.24 (ноябрь 2024). Не «с 1.18 в проде»
2. Актуальный релиз на момент обзора — 1.30 (май 2026)
3. Ambient multi-network multicluster — beta в 1.29
4. Sidecar — Stable, не deprecated; multi-cluster и ряд фич там всё ещё сильнее
5. Control plane сейчас — Istiod (не Pilot + Citadel + Galley как три текущих компонента)

➡️ Продолжение завтра: как устроен dataplane у обоих.

#Kubernetes #Cilium #Istio #DevOps #eBPF #WeDoOps

⚙️ Dataplane: eBPF vs Sidecar vs Ambient

Часть 2/5 · продолжение серии Cilium / Istio

Вчера: роли и версии. Сегодня — как пакеты реально ходят.

🟢 Cilium: eBPF в ядре

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

Компоненты:
1. Cilium Agent (DaemonSet)
2. eBPF datapath
3. Hubble — flows, DNS, HTTP
4. Tetragon — runtime security на syscalls
5. Опционально Envoy — L7 policy / Gateway API
6. Опционально ztunnel — L4 mTLS

🔵 Istio Sidecar

Envoy в каждом поде → полный L7 на каждом hop, сильная изоляция политик, предсказуемая модель.
Цена: выше CPU и RAM (часто десятки–сотни mCPU и сотни MiB на pod при плотности).

🔵 Istio Ambient (без sidecar)

1. Namespace или pod в mesh → L4 через ztunnel: mTLS, L4 authz, telemetry по HBONE
2. Нужен L7 → waypoint (Envoy), обычно один на namespace или service, а не на каждый pod

📊 Ориентиры latency из документации Istio (лаборатория, p90/p99 — не абсолют для любого кластера):

1. Ambient L4 (ztunnel): примерно 0.16–0.20 ms
2. Waypoint: примерно 0.40–0.50 ms
3. Sidecar: примерно 0.63–0.88 ms

📦 Ресурсы (порядок величины)

1. Cilium CNI (eBPF) — низкий footprint агента на ноду (зависит от Hubble и policy)
2. Ambient только ztunnel — примерно десятки mCPU на узел плюс RAM ztunnel; растёт с числом нод
3. Ambient плюс waypoints — плюс Envoy на namespace или service
4. Sidecar — часто 50–100+ mCPU и сотни MiB на каждый pod → бьёт при высокой плотности

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

➡️ Продолжение: что говорят независимые и вендорские бенчмарки 2024–2026.

#Kubernetes #Cilium #Istio #ServiceMesh #eBPF #WeDoOps

📊 Производительность: цифры без маркетинга

Часть 3/5 · продолжение серии Cilium / Istio

Бенчмарк mesh бессмысленен без контекста: L3/L4 или L7, mTLS on или off, железо, кто автор теста.

🔬 Независимый отчёт 2025

Стенд: OCI ARM64, Kubernetes 1.32, Fortio (service-mesh-benchmark).
Сравнение относительно baseline без mesh:

1. Baseline — p50 около 42 ms (50 соединений), около 202 context switches на запрос
2. Cilium eBPF L3/L4 — QPS минус 0.7%, p50 43 ms (плюс 1.8%), switches 188 (минус 7%)
3. Istio Ambient (ztunnel) — QPS минус 49.7%, p50 54 ms, switches плюс 40%
4. Istio Sidecar — QPS минус 70.5%, p50 88 ms, switches плюс 139%
5. Cilium L7 (per-node Envoy) — QPS минус 87.2%, p50 249 ms, switches плюс 726%

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

🔐 mTLS overhead

Источник: DEEPNESS Lab / arXiv:2411.02267.
Целевая нагрузка 3200 RPS. Рост latency относительно режима без mTLS:

1. Istio Sidecar — плюс 166%
2. Istio Ambient (ztunnel) — плюс 8%
3. Linkerd — плюс 33%
4. Cilium (sidecarless плюс Envoy path в тесте) — плюс 99%

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

☁️ Вендорский large-scale

Источник: Istio, «Scaling in the Clouds», AKS около 1000 узлов / около 11 тысяч ядер.
При сопоставимых security и L7:

1. Istio — примерно на 56% больше запросов при примерно на 20% меньшей tail latency
2. CPU у Cilium примерно на 30% ниже, но без учёта ядер на kernel-side encryption
3. Нормировка: около 2178 QPS на ядро у Istio против около 1815 у Cilium — примерно плюс 20% в пользу Istio

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

⚠️ Про цифры Gateway API вроде «Istio 99 994 QPS против Cilium 20 049»: это ingress/Gateway, не east-west mesh. На «Cilium медленнее в mesh» не экстраполировать.

➡️ Продолжение: Zero Trust и когда что выбирать.

#Kubernetes #Cilium #Istio #Performance #Benchmark #WeDoOps

🔐 Zero Trust и когда что выбирать

Часть 4/5 · продолжение серии Cilium / Istio

🛡 Что даёт Cilium

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

🛡 Что даёт Istio

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

Практично:

1. Zero Trust L4 плюс минимальный overhead → Istio Ambient
2. CNI плюс network policy плюс kernel visibility → Cilium
3. Строгий L7 Zero Trust с богатыми HTTP-политиками → Istio (sidecar или ambient плюс waypoint) зрелее

🚦 Управление трафиком и observability

1. L3/L4 policy — сильная сторона Cilium
2. L7 HTTP и canary — у Istio зрелее (VirtualService, HTTPRoute, DestinationRule); у Cilium растёт через Gateway API
3. Gateway API: у Cilium 1.20 — v1.6.x; у Istio зрело плюс ambient enhancements в 1.30
4. Observability: Hubble (eBPF flows) против Kiali, Envoy metrics, OpenTelemetry
5. Multi-cluster: Cilium Cluster Mesh; Istio sidecar — зрело; ambient multi-network — beta с 1.29

✅ Берите Cilium как основу, если:

1. Нужен единый высокопроизводительный CNI и NetworkPolicy
2. Критична east-west latency на L3/L4
3. Крупные кластеры, Hubble и Tetragon без sidecar tax

✅ Берите Istio Ambient, если:

1. Нужны mesh mTLS и L4 Zero Trust с низким overhead (плюс 8% latency в mTLS-тесте)
2. L7 нужен выборочно (waypoints)
3. Команда уже в экосистеме Istio

✅ Берите Istio Sidecar, если:

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

🔀 Гибрид Cilium CNI плюс Istio mesh — нормальный и поддерживаемый паттерн: сеть и policy на eBPF, identity и L7 — на Istio. Нужна аккуратная совместимость CNI chaining и datapath.

➡️ Финал завтра: миграция sidecar → Cilium по фазам плюс практический вывод.

#Kubernetes #Cilium #Istio #ZeroTrust #DevSecOps #WeDoOps

🚀 Миграция sidecar → Cilium и практический вывод

Часть 5/5 · финал серии Cilium / Istio

Сначала цель. «Уходим с sidecar на Cilium» обычно означает вариант A или B:

1. A — Cilium CNI only: убрать Istio
2. B — Cilium плюс mesh-фичи (L7 CNP, Gateway API, WireGuard / ztunnel)
3. C — Cilium CNI плюс Istio Ambient
4. D — только sidecar → ambient по гайду Istio 1.30+, без смены CNI

📋 Фазы миграции

Фаза 0. Инвентаризация (1–3 дня):
1. VirtualService, DestinationRule, EnvoyFilter
2. PeerAuthentication, AuthorizationPolicy (отдельно L4 и L7)
3. Multi-cluster, canary
4. Класс сервисов: L4-only / L7-light / L7-heavy
5. Baseline p99 и RPS до любых движений

Фаза 1. Cilium как CNI (Istio ещё жив):
1. Версии 1.18–1.20
2. Blue-green node pool
3. Проверки: cilium status, connectivity, Hubble
4. Критерий готовности: нет роста 5xx

Фаза 2. Замещение функций:
1. mTLS → WireGuard и/или ztunnel (beta; проверить intra-node)
2. L3/L4 → CiliumNetworkPolicy
3. L7 → L7CNP или Gateway API плюс ExternalAuth (это не 1:1 с Istio)
4. Canary → HTTPRoute или Argo Rollouts
5. EnvoyFilter часто без аналога — возможный блокер

Порядок отключения Istio-фич:
1. Убрать или переписать EnvoyFilter
2. Перенести canary
3. Переписать L7 authz
4. Включить encryption
5. Закрыть PeerAuthentication
6. Снять injection по namespace

Фаза 3. Один namespace за раз:
1. Политики уже на месте
2. Enrollment при необходимости
3. Снять injection
4. Rollout restart
5. Hubble без DROPPED на легитимных flows
6. Сравнить p99 с baseline

Фаза 4. Uninstall Istiod только когда:
1. Нет pod с sidecar
2. Нет критичных CRD в runtime path
3. Есть бэкап istioctl dump

⚠️ Риски:
1. Окно без L7 authz
2. WireGuard — это не mTLS как в Istio
3. Cilium L7 на слабых узлах
4. Multi-cluster — не one-click

Альтернатива: sidecar → ambient внутри Istio (учесть окно без L7 enforcement в официальном гайде).

📌 Итог 2026

Сначала вопрос: нужен mesh или хватит CNI плюс policy плюс encryption?

Часто ответ — Cilium как CNI; Istio (лучше Ambient) — только там, где доказана потребность в L7 mesh.

Уже на sidecar? Сначала ambient migration, потом полный уход на Cilium — если L7-зависимости Istio можно заменить.

Нужна помощь с выбором стека, аудитом mesh или планом миграции —
👉 we-do-ops.ru
👉 @WeDoOps
расширеная версия статьи: https://we-do-ops.ru/ru/blog/cilium-vs-istio-2026-ru
#Kubernetes #Cilium #Istio #ServiceMesh #DevOps #SRE #eBPF #WeDoOps