📱 Часть 4/5: CNI-ПЛАГИНЫ И SERVICE MESH — ВЫБОР ПРАВИЛЬНЫХ ИНСТРУМЕНТОВ

🔌CNI-плагины: какой выбрать для вашего кластера?

CNI (Container Network Interface) — это не одна сеть, а стандарт. Разные плагины = разные подходы.

📊Популярные CNI:

🐯Calico — для большинства продакшен-кластеров

# Установка
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# Преимущества:
# ✅ Сетевые политики из коробки
# ✅ Может работать без overlay (BGP режим)
# ✅ Интеграция с Istio
# ✅ Поддержка Windows узлов

BGP режим (для продвинутых):

# Calico конфигурация для BGP с физическими роутерами
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
  name: default
spec:
  logSeverityScreen: Info
  nodeToNodeMeshEnabled: false  # отключаем mesh
  asNumber: 64512  # наш AS номер

🚀Cilium — будущее на eBPF

# Установка через Helm
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set eBPF.hostRouting=true \
  --set kubeProxyReplacement=strict

# Что дает eBPF:
# 🚀 Убирает iptables (много правил = медленно)
# 🔍 L7-политики (блокировать по URL, header)
# 📊 Hubble — observability как в Service Mesh

Пример L7 политики в Cilium:

# Блокировать доступ к /admin
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: web
  egress:
  - toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/admin"  # ← блокируем путь!
          action: Deny

🛌 Flannel — просто работает

# Самая простая установка
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

# Когда выбирать Flannel:
# - Тестовый кластер
# - Демо-окружение
# - Не нужны сетевые политики
# - Маленький кластер (<50 нод)

🌐 Service Mesh: нужен ли он вам?

Service Mesh = сеть микросервисов + управление трафиком + безопасность + observability.

Популярные решения:
1. Istio — самый мощный, но сложный
2. Linkerd — легковесный, проще в освоении
3. Consul Connect — от HashiCorp
4. Open Service Mesh — от Microsoft

⚖️ Istio vs Linkerd:

Istio (для сложных сценариев):

# Canary deployment
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90  # 90% трафика
    - destination:
        host: reviews
        subset: v2
      weight: 10  # 10% трафика

Плюсы Istio:
- Canary, A/B testing
- Трассировка распределенных систем
- mTLS между всеми сервисами
- Политики доступа (кто может вызывать кого)

Минусы Istio:
- +0.5 CPU и 256MB RAM на ноду
- Сложная настройка
- Много moving parts (Pilot, Citadel, Galley, Mixer)

Linkerd (проще и легче):

# Установка в две команды
linkerd install | kubectl apply -f -
linkerd viz install | kubectl apply -f -

# Проверка
linkerd check

Когда НЕ нужен Service Mesh:
- Монолитное приложение
- <10 микросервисов
- Нет требований к canary deployments
- Нет бюджета на дополнительные ресурсы
- Команда не готова к сложности

💡Вывод для части 4:

- Flannel — для простоты
- Calico — для большинства продакшен-сценариев
- Cilium — для максимальной производительности и L7-политик
- Service Mesh — только если реально нужны его фичи

В следующей части: Диагностика проблем и мониторинг!

#Kubernetes #CNI #ServiceMesh #Istio #Cilium #WeDoOps

📱 Часть 5/5: ДИАГНОСТИКА, МОНИТОРИНГ И BEST PRACTICES

🐞Диагностика сетевых проблем в Kubernetes

Когда сеть не работает (а она обязательно сломается), вот пошаговый план действий:

🔍 Шаг 1: Базовые проверки

# 1. Проверяем состояние Pod'ов
kubectl get pods -o wide
# Обращаем внимание на STATUS и READY колонки

# 2. Проверяем Service'ы
kubectl get svc
kubectl describe svc problem-service

# 3. Проверяем Endpoints (самое важное!)
kubectl get endpoints problem-service
# Если пусто — селектор Service'а не совпадает с лейблами Pod'ов

# 4. Проверяем Network Policies
kubectl get networkpolicies --all-namespaces

🎯Шаг 2: Диагностический Pod

Создаем Pod с сетевыми утилитами:

apiVersion: v1
kind: Pod
metadata:
  name: network-tester
spec:
  containers:
  - name: tools
    image: nicolaka/netshoot:latest
    command: ["sleep", "3600"]

# Запускаем диагностику
kubectl exec -it network-tester -- bash

# Внутри контейнера:

# 1. Проверяем DNS
nslookup kubernetes.default.svc.cluster.local
dig @10.96.0.10 google.com +short

# 2. Проверяем подключение к Service'у
curl -v http://service-name.namespace:port/
nc -zv service-name 80
telnet service-name 80

# 3. Смотрим сетевые интерфейсы
ip addr show
ip route show
netstat -tulpn

# 4. Трассировка
traceroute service-name
mtr service-name

# 5. Проверяем iptables правила
iptables -L -n -v | grep service-name
iptables -t nat -L -n -v

📊Шаг 3: Мониторинг ключевых метрик

Что нужно мониторить в Prometheus:

# 1. Ошибки сети
sum(rate(container_network_transmit_errors_total[5m])) by (pod)
sum(rate(container_network_receive_errors_total[5m])) by (pod)

# 2. Пропускная способность
rate(container_network_receive_bytes_total[5m])
rate(container_network_transmit_bytes_total[5m])

# 3. Задержки DNS
histogram_quantile(0.95, rate(coredns_dns_request_duration_seconds_bucket[5m]))

# 4. kube-proxy здоровье
kubeproxy_sync_proxy_rules_duration_seconds_bucket

🚨Распространенные проблемы и решения:

Проблема 1: DNS не работает

# Решение:
# 1. Проверяем CoreDNS Pod'ы
kubectl get pods -n kube-system -l k8s-app=kube-dns

# 2. Проверяем resolv.conf
kubectl exec -it my-pod -- cat /etc/resolv.conf
# Должно быть: nameserver 10.96.0.10

# 3. Если используем Network Policies
# Убедитесь, что разрешен исходящий UDP трафик на порт 53

Проблема 2: Service не доступен снаружи

# Решение:
# 1. Для NodePort: проверяем firewall на нодах
sudo iptables -L -n -v | grep NODEPORT

# 2. Для LoadBalancer: проверяем облачный провайдер
kubectl describe service my-lb-service
# Ищем Events в выводе

# 3. Для Ingress: проверяем Ingress Controller
kubectl get pods -n ingress-nginx
kubectl logs -n ingress-nginx ingress-nginx-controller-xyz

Проблема 3: Network Policies блокируют трафик

# Быстрое решение (только для тестов!):
kubectl delete networkpolicies --all-namespaces --all

# Поиск проблемной политики:
# 1. Удаляем все политики
# 2. Добавляем по одной, проверяем
# 3. Нашли проблемную — анализируем

🏆Best Practices для продакшена:

1. Планирование сети:

# Золотое правило: считайте заранее!
# Pod CIDR: минимум /16 (65,534 Pod'а)
# Service CIDR: минимум /20 (4,094 Service'а)
# Пример для кластера на 100 нод:
POD_CIDR: 10.244.0.0/16
SERVICE_CIDR: 10.96.0.0/20

2. Безопасность:
- Всегда начинайте с политики "deny-all"
- Используйте namespace для изоляции окружений
- Регулярно аудитируйте Network Policies
- Шифруйте трафик между нодами (IPsec, WireGuard)

3. Производительность:

# Используйте IPVS вместо iptables для больших кластеров
# В kube-proxy конфигурации:
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  scheduler: "wrr"  # weighted round-robin

4. Ограничение трафика на Pod:

apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      limits:
        kubernetes.io/ingress-bandwidth: 10M  # входящий
        kubernetes.io/egress-bandwidth: 5M    # исходящий

#Kubernetes #DevOps #SRE #Networking #BestPractices #WeDoOps

🚀 DevOps 2025-2026: Куда катится мир автоматизации? в сторону ИИ

Привет! Год только начался, а тренды уже бьют ключом. Держите выжимку главных нововведений в DevOps, которые меняют правила игры прямо сейчас.

1. GitOps — это новый стандарт. Точка.
Git — теперь «единый источник истины» для всей инфраструктуры. ArgoCD и FluxCD правят балом. Результат? Развёртывания стали предсказуемыми, а откаты — моментальными. Кто ещё не въехал — самое время!

2. Безопасность — это не этап, а процесс (DevSecOps)
Теперь защищают не только код, а всю цепочку поставок (Supply Chain): от библиотеки до пайплайна сборки. SBOM (список компонентов) и подпись артефактов — must have. Иначе рискуете стать героем хакерской сводки.

3. Платформенная инженерия 2.0: Self-service для девелоперов
Разработчики хотят окружение «в один клик», а не писать 10 тикетов. Решение — Внутренние платформы разработки (Internal Developer Platform). Теперь это ещё и "AI-ready": платформа сама подсказывает, как исправить пайплайн или применить политику.

4. Агентный ИИ: не просто чат-бот, а коллега-автомат
Новое слово — Agentic AI. Это ИИ-агенты, которые сами могут: пофиксить сломанный тест, отреагировать на инцидент или собрать PR. Главный тренд 2026 — "агенты с ограничителями", чтобы не наломали дров.

5. Событийно-Ориентированный DevOps (Event-Driven DevOps) и "взрослый" Serverless
Пайплайны по расписанию — прошлый век. Теперь всё запускается событиями: коммит, новая версия, алерт. В связке с serverless (который наконец стал enterprise-ready) это даёт супергибкость и экономию.

6. Observability + FinOps = Видимость и контроль
Логи, метрики и трассировки сливаются в единую картину. Цель — не просто показать проблему, а намекнуть на причину. Параллельно FinOps учит команды балансировать между скоростью и облачными счетами. Деньги любят счёт.

7. Что нового под капотом?

Kubernetes 1.33+: Меняем CPU/память у Pod’ов на лету, без перезапуска.

OpenSearch 3.1+: GPU-ускорение для AI-поиска и векторных операций.

Итог: DevOps становится стратегической интеллектуальной платформой. Скорость, безопасность и AI — три кита, на которых всё держится.


#devops #gitops #devsecops #ai #platformengineering #kubernetes #observability #finops #technews #NY2026 #WeDoOps

Очереди в Kubernetes: Какой брокер выбрать? 📡

Запускаете микросервисы в k8s и ломаете голову над асинхронным общением? Разбираемся с брокерами сообщений — от классики до хайпа.

🤔 Зачем вообще это нужно?
- Развязка сервисов (один упал — другие работают)
- Буфер против всплесков нагрузки
- Гарантии доставки сообщений
- Фоновая обработка задач

🏆 ТОП-5 кандидатов:

1️⃣ Apache Kafka — мастодонт
✅Миллионы сообщений в секунду
✅ Exactly-once доставка
✅Сохраняет историю
❌ Сложный в настройке и "прожорливый"

2️⃣ RabbitMQ — классика
✅ Простая установка и управление
✅Гибкая маршрутизация
✅ Отличная документация
❌ Масштабируется хуже конкурентов

3️⃣ NATS — снайпер
✅Супер-низкая задержка (<1 мс)
✅Простая архитектура
✅Автомасштабирование
❌ Меньше фич из коробки

4️⃣ Apache Pulsar — современник
✅Лучшее из Kafka + RabbitMQ
✅ Встроенная мультитенантность
✅Отделение хранилища от обработки
❌ Молодая экосистема

5️⃣ Redis Streams — минимализм
✅Бешеная производительность
✅ Проще некуда
✅Универсальный инструмент
❌ Всё в памяти → ограничения

📊 Быстрое сравнение:
- Производительность: NATS > Redis > Kafka > Pulsar > RabbitMQ
- Простота: Redis > NATS > RabbitMQ > Pulsar > Kafka
- Функциональность: Kafka > Pulsar > RabbitMQ > NATS > Redis

🎯 Что выбрать?
- Стартап/небольшой проект → RabbitMQ или Redis
- High-load с гарантиями → Kafka или Pulsar
- Low-latency системы → NATS
- Уже используете Redis → Redis Streams
- Облачный проект → managed-сервисы (AWS MSK, Google Pub/Sub)

💡 Важный лайфхак:
В k8s используйте StatefulSet + Persistent Volumes для stateful-брокеров и операторы (Strimzi для Kafka, RabbitMQ Operator) для упрощения жизни.

📈 Тренд:
Многие переходят от монолитных брокеров к cloud-native решениям вроде NATS и Pulsar, но Kafka пока держит корону enterprise-сегмента.


#kubernetes #devops #microservices #architecture #tech #WeDoOps

🚀 RabbitMQ в Kubernetes: Полное руководство по настройке через операторы

Сегодня разберем настройку RabbitMQ в k8s через два ключевых оператора:

🐇 Cluster Operator - развертывание и управление кластерами
📡 Messaging Topology Operator - управление ресурсами (vhost, очереди, политики)


🔧 Быстрая установка операторов:

1️⃣ Cluster Operator:

kubectl apply -f "https://github.com/rabbitmq/cluster-operator/releases/latest/download/cluster-operator.yml"


2️⃣ Messaging Topology Operator:

kubectl apply -f https://github.com/rabbitmq/messaging-topology-operator/releases/latest/download/messaging-topology-operator-with-certmanager.yaml


📦 Базовый кластер RabbitMQ:


apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbitmq-cluster
spec:
  replicas: 3
  image: rabbitmq:3.12-management
  persistence:
    storage: "10Gi"



🎯 Основные конфигурации Messaging Topology:

1️⃣ Vhost:

apiVersion: rabbitmq.com/v1beta1
kind: Vhost
metadata:
  name: payments-vhost
spec:
  name: devops
  defaultQueueType: classic
  deletionPolicy: retain
  rabbitmqClusterReference:
    name: rabbitmq-cluster
    namespace: rabbitmq-system 


2️⃣ Policy для Dead Letter:

apiVersion: rabbitmq.com/v1beta1
kind: Policy
metadata:
  name: dlq-policy
spec:
  name: "dead-letter-policy"
  vhost: "payments"
  pattern: "^order\."
  applyTo: "queues"
  definition:
    dead-letter-exchange: "dlx.exchange"



💡 Практические советы:

✅ Используйте минимум 3 ноды для production
✅ Всегда настраивайте anti-affinity для распределения по нодам
✅ Настройте мониторинг очередей и соединений
✅ Используйте политики для автоматического управления TTL и DLQ
✅ Храните манифесты в Git для версионирования


🚨 Чего избегать:

❌ Не используйте guest/guest в production
❌ Не отключайте persistent storage
❌ Не забывайте про лимиты памяти
❌ Не запускайте single-node в production

💎 Итог:

1. Операторы автоматизируют 90% рутинных задач
2. GitOps подход для управления конфигурацией
3. Встроенная отказоустойчивость через k8s механизмы
4. Единая точка управления для всех окружений


#MessageBroker #CloudNative #InfrastructureAsCode #WeDoOps

🚀 Частые проблемы при запуске FalkorDB в Kubernetes и как их решать

Разворачиваете графовую БД FalkorDB в k8s через Helm? Сталкиваетесь с непонятными падениями подов? Собрал топ проблем, которые возникают и готовые способы их решения! 🛠


❌ Проблема 1: Redis не стартует → падает вся FalkorDB

Симптомы: Pod с Redis в CrashLoopBackOff, логи показывают ошибки инициализации.

Что делать:
- Проверьте kubectl describe pod - часто проблема в недостатке ресурсов или проблемах с PVC
- Убедитесь, что в values.yaml включена загрузка модуля:

extraFlags: ["--loadmodule /var/lib/falkordb/bin/falkordb.so"]

- Если используете кастомный дистрибутив - обновите containerd/runc


🔌 Проблема 2: Модуль falkordb.so не загружается

Симптомы: Redis запущен, но Cypher-запросы не работают.

Решение: Для разных типов установки нужна разная конфигурация:

Для Sentinel-режима:

master:
  extraFlags: ["--loadmodule /var/lib/falkordb/bin/falkordb.so"]

Для Redis Cluster режима ищите в values.yaml блок с initContainers - он должен копировать модуль в общий volume.


🛡 Проблема 3: Заблокировано политиками безопасности PodSecurity

Ошибка: Pod запрещён из-за небезопасного образа.

Быстрое решение:

global:
  security:
    allowInsecureImages: true

Внимание: В продакшене лучше использовать свой registry с проверенными образами!


💾 Проблема 4: Данные исчезают после перезапуска

Важно: По умолчанию данные хранятся только в памяти Pod'а!

Решение для продакшена:

persistence:
  enabled: true
  storageClass: "fast-ssd"
  size: 50Gi

Проверьте, что ваш StorageClass поддерживает ReadWriteOnce.


🌐 Проблема 5: Не могу подключиться извне кластера

Шаг за шагом:
1. Проверьте сервисы: kubectl get svc | grep falkordb
2. Для теста используйте port-forward:

kubectl port-forward svc/falkordb-redis-master 6379:6379

3. Для продакшена настройте Ingress или LoadBalancer

Не забудьте: Пароль лежит в Secret, получайте так:

kubectl get secret falkordb-secret -o jsonpath='{.data.password}' | base64 -d

⚡️ Проблема 6: Низкая производительность при нагрузке

Чек-лист:
✅ Достаточно ли RAM? FalkorDB хранит граф в памяти
✅ Используете ли реплики для чтения?
✅ Проверьте логи на медленные запросы
✅ Рассмотрите шардирование через Redis Cluster режим

Мониторинг - ваше всё: Настройте Prometheus + Grafana для отслеживания метрик.


🔄 Проблема 7: Сломали всё при обновлении Helm

Золотые правила:
1. Всегда тестируйте обновления в staging
2. Читайте changelog чарта
3. Знайте команду для отката:

helm rollback falkordb 1

📊 Проблема 8: Нет понимания что происходит внутри

Решение: Включаем логи и мониторинг:

master:
  extraFlags:
    - "--loadmodule /var/lib/falkordb/bin/falkordb.so"
    - "--loglevel verbose"  # или debug для отладки

🎯 Выводы:

1. Всегда проверяйте ресурсы (RAM особенно критична)
2. Не забывайте про persistence в продакшене
3. Мониторинг > гадание по кофейной гуще
4. Тестируйте обновления перед продакшеном

Полезные ссылки:
- Документация: https://falkordb.com/docs


#FalkorDB #Kubernetes #DevOps #БазыДанных #Helm #ГрафовыеБазы

🛑 Не убивай меня сразу! Настраиваем Graceful Shutdown

Коллеги, бывало такое? Вы делаете kubectl rollout restart, Kubernetes обещает бесшовное обновление, но в момент переключения подов пару юзеров все равно ловят 502 Bad Gateway или обрывы соединений.

Проблема часто не в балансировщике, а в том, что ваше приложение не умеет "красиво уходить" (Graceful Shutdown).

Когда Kubernetes хочет остановить под, происходит следующий танец:

1. K8s посылает процессу сигнал SIGTERM.
2. K8s ждет terminationGracePeriodSeconds (по дефолту 30 сек).
3. Если процесс еще жив -прилетает SIGKILL (выстрел в голову).

❌ Как делают новички

Приложение получает SIGTERM и... мгновенно закрывается.

Результат: Все запросы, которые обрабатывались в эту миллисекунду (транзакция в БД, загрузка файла), обрываются. Клиент получает ошибку.

✅ Как надо (Уровень Code)

Приложение должно перехватывать SIGTERM.
Получив сигнал, оно должно:

1. Перестать принимать новые соединения.
2. Дождаться завершения текущих запросов.
3. Закрыть коннекты к БД/очередям.
4. Выйти (exit 0).

💀 Скрытая проблема Kubernetes (Race Condition)

Даже если ваш код идеален, вы все равно можете словить 502.
Почему?
В тот момент, когда K8s посылает SIGTERM, он параллельно начинает удалять IP пода из Endpoints (Service).
Это асинхронный процесс. Может случиться так, что Ingress Controller все еще шлет трафик на под, а приложение уже получило SIGTERM и закрыло порт.

💊 Решение: "The Sleep Hack"
Как бы глупо это ни звучало, но best practice в мире K8s - это вставить небольшую паузу перед остановкой.

Мы используем preStop хук. Он выполняется ДО отправки SIGTERM.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 5"]

Что это дает?

1. K8s запускает хук: sleep 5.
2. Под помечается как Terminating.
3. За эти 5 секунд Ingress/Service успевают обновить свои таблицы маршрутизации и перестают слать новый трафик на этот под.
4. sleep заканчивается -> летит SIGTERM -> приложение спокойно доделывает старые запросы -> Profit! 🚀

⚙️ Чек-лист для идеального деплоя:

1. В коде обработан SIGTERM.
2. В K8s добавлен preStop хук со слипом (5-10 сек).
3. terminationGracePeriodSeconds выставлен с запасом (напр. 60 сек, если у вас долгие запросы), чтобы SIGKILL не прилетел слишком рано.


#k8s #devops #architecture #bestpractices #WeDoOps

🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу?

Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s).

Казалось бы, что сложного? Написал curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская.

Разберем две крайности и как делать правильно.

❌ Ошибка №1: "Зомби-апокалипсис" (Слишком слабый чек)

Вы проверяете только то, что процесс веб-сервера запущен и порт слушается.

🔘Сценарий: У приложения отвалился коннект к БД (pool exhaustion), или случился дедлок внутри кода.

🔘Итог: Хелсчек проходит (порт-то открыт!), балансировщик продолжает лить трафик на под, а пользователи получают 500-ки.

🔘Лечение: Чек должен проверять работоспособность логики, а не просто наличие процесса.

❌ Ошибка №2: "Эффект Домино" (Слишком жадный чек)

Вы решили быть умными и в /health эндпоинт засунули проверку коннекта к Базе, Редису и S3.

🔘Сценарий: База данных немного приуныла (медленные запросы).

🔘Итог: Хелсчеки всех 50 подов начинают тайм-аутить. Kubernetes думает: "Ага, поды сдохли!" и начинает их перезагружать.

🔘Финал: Все поды рестартуют одновременно, ломятся устанавливать соединения к и так лежащей базе и добивают её окончательно. Congratulations, you played yourself.

✅ Как делать правильно: Liveness vs Readiness

В Kubernetes (да и в грамотном Docker Compose) эти понятия разделены. Это фундамент.

1. Liveness Probe (Я жив?)

🔘Цель: Понять, не завис ли процесс намертво.
🔘Действие при сбое: РЕСТАРТ контейнера.
🔘Что проверять: Очень легкий запрос. "Я могу отвечать на HTTP?". Не трогайте тут базу данных! Если база лежит, рестарт бэкенда не поможет ей подняться.


2. Readiness Probe (Я готов работать?)

🔘Цель: Понять, можно ли пускать на меня трафик.
🔘Действие при сбое: УБРАТЬ из балансировки (не убивать!).
🔘Что проверять: Вот тут проверяем зависимости. Есть коннект к БД? Прогрелся кэш? Если нет, просто временно не шлите на меня юзеров.



📝 Пример (K8s Manifest):

livenessProbe:
  httpGet:
    path: /health/live # Максимально тупой ответ 200 OK
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready # Проверка БД, очередей и т.д.
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

💡 Главный совет

Никогда не делайте зависимость Liveness-пробы от внешних сервисов. Если у вас упал сторонний API, ваш сервис не должен уходить в циклическую перезагрузку. Он должен просто перестать говорить, что он Ready, или отдавать ошибку юзеру, оставаясь "живым".

#k8s #devops #fails #stability #bestpractices #WeDoOps@WeDoOps

⚖️ Requests vs Limits: Почему твой под тормозит на пустой ноде?

Всем привет! 👋 Сегодня о наболевшем - о ресурсах в Kubernetes.

Я часто вижу манифесты, где секция resources либо отсутствует вовсе ("пусть берет сколько надо"), либо настроена "на глаз". А потом начинаются вопросы: "Почему приложение тупит, хотя CPU загружен на 5%?" или "Почему мой под постоянно убивает OOMKilled?"

Давайте разберем главную ловушку новичка.

1. Requests (Запросы) - Это про "Обещание" 🤝

requests - это то, что Kubernetes гарантирует вашему поду.
Шедулер смотрит на реквесты и ищет ноду, где есть свободное место. Если вы не указали реквесты - K8s считает, что поду ничего не нужно, и может запихнуть его на перегруженную ноду, где он будет страдать.

2. Limits (Лимиты) - это про "Наказание" 👮‍♂️

limits - это верхняя планка. И тут поведение CPU и RAM кардинально отличается.

💀 RAM Limit (Жесткая смерть)
Память - ресурс не сжимаемый. Если приложение съело больше лимита - приходит OOMKiller (Out Of Memory Killer) и пристреливает процесс. Под рестартится.

• Ошибка: Ставить лимит памяти впритык к потреблению Java-хипа. Дайте запас на оверхед!

🐌 CPU Limit (Тормоза / Троттлинг)
CPU - ресурс сжимаемый. Если приложение хочет больше лимита, его не убивают. Его троттлят.
Шедулер просто перестает давать процессу процессорное время на определенные кванты времени.

• Результат: Ваше приложение начинает отвечать не за 50мс, а за 500мс. Ошибок нет, логов нет, но все тормозит.

🔥 QoS Classes: Битва за приоритет

Kubernetes делит все поды на 3 касты (Quality of Service):

1. Guaranteed (Элита) 👑
• requests = limits (и по CPU, и по RAM).
• Эти поды убиваются последними, если на ноде кончается место. Идеально для Баз Данных и критичного прода.


2. Burstable (Средний класс) 💼
• requests < limits.
• Они могут "бурстить" (потреблять больше реквеста), если есть свободные ресурсы. Но если на ноде начнется давка, их начнут выселять первыми. Подходит для большинства веб-сервисов.


3. BestEffort (Бомжи) 🗑
• Ресурсы не указаны вообще.
• Живут "на птичьих правах". При любой нехватке ресурсов на ноде эти поды улетают в небытие первыми. Используйте только для неважных тестовых джобов.


💡Золотое правило настройки

1. Memory: Всегда ставьте Requests == Limits.
• Почему? Чтобы K8s гарантировал вам эту память и не пытался выселить под при нехватке ресурсов на ноде. Это дает класс Guaranteed (по памяти).


2. CPU:
• Requests: Обязательно ставьте честные значения (сколько реально надо при средней нагрузке).
• Limits: Осторожно! Некоторые инженеры вообще не ставят CPU лимиты (или ставят их очень высокими), чтобы избежать троттлинга при резких всплесках трафика. Если нода свободна - пусть приложение забирает всё!


📝 Пример "Надежного" конфига:

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"  # 0.25 ядра
  limits:
    memory: "512Mi" # Равно реквесту!
    # cpu: "1000m"  # Можно не ставить или ставить с запасом

Не бойтесь давать памяти с запасом, но бойтесь зажать CPU в тиски.


#k8s #performance #cpu #ram #bestpractices #troubleshooting

🤖 AI-агенты в DevOps: конец автоматизации, который вы не ждали

DevOps всегда был про скорость и автоматизацию. Мы перетащили тестирование влево, обвешались CI/CD пайплайнами и даже подружили разработку с эксплуатацией. Но сейчас индустрию ждёт тектонический сдвиг.

🚀 Речь не про очередной Copilot, а про Agentic AI — автономных ИИ-агентов, которые становятся полноправными участниками процесса. Они не подсказывают код, а сами его пишут, тестируют, деплоят и мониторят.

Чем это меняет DevOps?

🔄 От инструментов — к коллегам
Раньше мы «сдвигали влево» задачи, чтобы разработчики думали о безопасности и тестах. Теперь агенты берут на себя рутину:
— анализируют требования,
— генерируют IaC,
— проверяют политики,
— и даже согласовывают изменения с другими агентами.

Это уже не просто автоматизация — это виртуальная команда с иерархией:
1️⃣ Стратег (платформенный менеджер) — получает запрос на естественном языке.
2️⃣ Тактики (менеджеры по инфраструктуре, безопасности) — координируют.
3️⃣ Исполнители — пишут код, валидируют, деплоят.

Результат: задача, на которую раньше уходило 40 часов, теперь выполняется за 11 минут с минимальным участием человека.

🛡 Безопасность: AgentSecOps и новые угрозы
Когда у агентов есть доступ к инфраструктуре, они становятся целью номер один для хакеров. Взломанный агент — это не утечка данных, а прямой доступ к вашим серверам.

OWASP уже обновляет топ-10 для агентных приложений. Главная опасность — Goal Hijacking (перехват цели). Злоумышленник маскирует вредоносную инструкцию под легитимные данные (например, в комментарии к коду), и агент её выполняет, думая, что помогает.

Появляется новое понятие — нечеловеческие идентичности. У агентов есть широкие права, но их поведение непредсказуемо. AgentSecOps теперь должен учитывать:
— инъекции промптов,
— отравление контекста,
— и контроль над автономными действиями.

👨💻 А что с человеком?
Инженеры не останутся без работы, их роль станет стратегической:
— проектировать системы, где работают агенты,
— задавать границы (guardrails),
— утверждать рискованные изменения,
— расследовать инциденты, которые агенты не смогли решить.

Уже есть инструменты (например, Harness), которые оценивают риск изменения и запрашивают одобрение человека только в сложных случаях. В остальном — полная автономия в рамках политик.

💡 Итог
По данным IBM, 86% руководителей считают, что к 2027 году именно агенты сделают автоматизацию по-настоящему эффективной. Мы переходим от «сдвига влево» к «сдвигу повсюду» — непрерывному сканированию, упреждающему тестированию и интеграции легаси.

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

#WeDoOps #AI #AgenticAI

⚡️ Автоскейлинг в Kubernetes: как не переплачивать и выдерживать нагрузки?

Автомасштабирование — это магия, которая позволяет вашему кластеру расти и сжиматься под реальную нагрузку. Вместо ручного расчёта серверов вы просто описываете правила, а Kubernetes делает всё сам. Рассказываем про основные инструменты: от классики до самых современных решений.

📦 Уровень 1: Масштабирование подов (приложений)

Если нагрузка растёт — добавляем копии приложения. Если падает — убираем лишние.

🔹 Horizontal Pod Autoscaler (HPA)
Самый популярный инструмент. HPA следит за потреблением CPU/RAM подами и меняет количество реплик. Например, если средняя загрузка CPU превышает 80%, HPA создаст новые поды. При снижении — уберёт. Работает на основе метрик с Metrics Server.

🔹 Vertical Pod Autoscaler (VPA)
А это уже про «размер» подов. VPA анализирует реальное потребление ресурсов и автоматически корректирует requests/limits. Идеально для монолитов или stateful-приложений, которые сложно горизонтально масштабировать. Может работать в режиме рекомендаций или самостоятельно перезапускать поды с новыми параметрами.

🔹 KEDA (Kubernetes Event-driven Autoscaler)
Киллер-фича для event-driven архитектур. KEDA умеет масштабировать поды на основе длины очереди сообщений (Kafka, RabbitMQ), количества запросов к БД или даже по расписанию. Может держать реплики на нуле, пока не появится событие, — экономия ресурсов колоссальная.

⚙️ Уровень 2: Масштабирование инфраструктуры (нод)

Когда подов становится слишком много и они не помещаются на существующие серверы, нужны новые ноды. Здесь два основных игрока.

🔹 Cluster Autoscaler (CA)
Классика. CA следит за подами в статусе Pending (которым не хватило ресурсов) и добавляет ноды через API облачного провайдера. Если ноды простаивают — удаляет. Работает с заранее созданными группами нод (Node Groups). Надёжно, но есть нюансы: нужно заранее определять типы машин, удаление нод происходит с задержкой.

🔹 Karpenter
Современная альтернатива от AWS (open source). Karpenter не привязан к группам нод — он сам общается с облаком и создаёт инстансы «на лету», идеально подходящие под требования подов. Выбирает самый оптимальный и дешёвый тип машины из всего каталога.
Фишка: умеет делать консолидацию — перепаковывать поды на меньшее количество нод или заменять дорогие инстансы на более дешёвые без простоя. Экономит деньги гораздо эффективнее CA.

🎯 Как собрать идеальную стратегию?

Комбинируйте инструменты:

- Для подов: HPA под большинство сервисов, VPA для оптимизации ресурсов, KEDA для событийно-управляемых нагрузок.
- Для нод: если у вас классическая инфраструктура — Cluster Autoscaler. Если облако и хотите гибкости + экономии — присмотритесь к Karpenter.

Автоскейлинг в Kubernetes — это не просто модная фишка, а необходимость для production. Правильная связка инструментов даст вам эластичность и контроль над бюджетом.

#kubernetes #devops #autoscaling #karpenter #hpa #keda

Привет! Сегодня поговорим о том, как искать проблемы с PersistentVolumes (PV) и PersistentVolumeClaims (PVC) в Kubernetes, когда за ними стоит Ceph (Rook, ODF и т.п.). Тема объёмная, поэтому разобьём её на несколько постов)

🧭 Часть 1. С чего начинать диагностику?

Прежде чем лезть в дебри Ceph, всегда проверяем то, что видно глазами в Kubernetes.

❗️ Смотрим события пода
Если под не стартует:

kubectl describe pod <problem-pod>

В секции Events ищем FailedMount или FailedAttachVolume. Это даст первую зацепку.

❗️ Статус PVC

kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name>

PVC должен быть Bound. Если висит в Pending — проблема либо в StorageClass, либо в работе CSI-драйвера.

❗️ Логи CSI-драйверов (живут в namespace Rook, обычно `rook-ceph`)
Нас интересуют:
- Provisioner (создание/удаление томов):
csi-cephfsplugin-provisioner-* или csi-rbdplugin-provisioner-*
- Node plugin (монтирование на узлах):
csi-cephfsplugin-* или csi-rbdplugin-*

Просмотр логов провайдера:

kubectl -n rook-ceph logs -l app=csi-rbdplugin-provisioner --tail=50

💡 Вывод: прежде чем грешить на Ceph, убедись, что ошибка не на уровне Kubernetes или CSI.
В следующем посте разберём конкретные проблемы CephFS (RWX).

#k8s #ceph #pvc #troubleshooting #rook

🧭 Часть 2. Типовые проблемы CephFS (ReadWriteMany)

⚠️ Ошибка: mount error: no mds is up
Симптом: В логах пода видим, что нет доступного Metadata Server (MDS).
Причина: Либо MDS действительно не работают, либо клиент (kubelet) не может до них достучаться (сеть, авторизация).

Диагностика:
1. Заходим в тулбокс Rook:

   kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash
   

2. Проверяем статус Ceph:

   ceph status
   

Ищем строчку mds: 1/1 daemons up (или больше). Если MDS не встали — проблема в развёртывании Rook.
3. Проверяем права клиента:

   ceph auth ls | grep client.csi-cephfs-node
   

Должен быть allow rw для CephFS.

Решение:
- Если MDS не стартуют — проверяем ресурсы (CPU/RAM) на нодах MDS.
- В новых версиях Ceph (Squid+) может потребоваться параметр монтирования ms_mode: legacy в StorageClass или в CRD кластера Rook (если версии клиента и сервера не совпадают).

⚠️ Ошибка: NodeResizeError: failed to expand pvc with NodeExpand is not supported
Симптом: PVC расширили, размер в get pvc обновился, но висит эта ошибка.
Причина: Драйвер CephFS не поддерживает расширение файловой системы на узле (NodeExpandVolume), только на стороне хранилища. Ошибка часто косметическая — том работает с новым размером.

Решение: Убедитесь, что в kube-controller-manager включён --feature-gates=RecoverVolumeExpansionFailure=true. Ошибка может игнорироваться, если данные пишутся нормально.


➡️ В следующей части разберём проблемы с RBD (RWO): зависшие блокировки, multi-attach и шифрование.

#k8s #cephfs #pvc #troubleshooting

🧭 Часть 3. Типовые проблемы RBD (ReadWriteOnce)

⚠️ Ошибка: rbd image <pool>/<image> is still being used
Симптом: Под не может смонтировать PVC после пересоздания.
Причина: Старый watcher (клиент Ceph) не отдал диск, образ считается занятым.

Диагностика и решение:
1. В тулбоксе Rook смотрим watcher'ов образа:

   rbd status <pool-name>/csi-vol-<volume-id>
   

Увидим IP-адрес "зависшего" клиента.
2. Самый простой способ разблокировки — перезапустить CSI node plugin на проблемном узле.
Можно также перезагрузить сам узел (если возможно).
3. Если не помогло, можно сбросить блокировку вручную через rbd lock list и rbd lock remove, но осторожно!

⚠️ Multi-Attach error для статических PV
Симптом: Два статических PV, ссылающихся на RBD-образы с одинаковым именем в разных пулах, конфликтуют. Второй под не стартует с ошибкой Multi-Attach error.

Причина: Kubernetes/CSI генерирует volumeHandle на основе имени образа. Если имена совпадают, система думает, что это один и тот же том.

Решение: При создании статического PV обязательно делайте volumeHandle уникальным, например, <pool-name>-<image-name>.

⚠️ Проблемы с шифрованием и OMAP
Редкие ошибки вида internal state inconsistent, omap names mismatch или cannot create encrypted volume from unencrypted volume.
Лечатся проверкой RBAC у CSI-провайдера и, в крайнем случае, ручной зачисткой OMAP-объектов (только для опытных!).


➡️ В следующей части поговорим о сетевых блокировках (blocklist) и дадим универсальный чек-лист.

#k8s #rbd #pvc #troubleshooting

🧭 Часть 4. Сетевые проблемы и чек-лист

⚠️ Blocklist
Симптом: PVC на RBD внезапно становятся ReadOnly, поды в CreateContainerError, в мониторинге видны заблокированные клиенты.
Причина: Ceph забанил клиента за некорректное поведение (например, проблемы сети на узле).

Диагностика:

ceph osd blocklist ls

Решение:
- Перезагрузить проблемный узел — блокировка снимется автоматически.
- Если нужно срочно, можно вручную удалить запись из blocklist, но это временно.


✅ Универсальный чек-лист при проблемах с Ceph PVC

1. Kubernetes уровень
- kubectl describe pod – ищем ошибки монтирования.
- kubectl describe pvc – статус биндинга и события.

2. CSI уровень
- Логи csi-*plugin-provisioner – ошибки создания томов (RBAC, OMAP).
- Логи csi-*plugin (на узле) – ошибки монтирования.

3. Ceph уровень (через toolbox)
- ceph status – здоровье кластера, состояние MDS/MGR/OSD.
- ceph fs status – активность файловых систем.
- rbd status <image> – наблюдатели за RBD-образом.
- ceph osd blocklist ls – не забанен ли узел.

4. Нюансы
- Совместимость версий Ceph и CSI (ms_mode).
- Feature gates в Kubernetes (например, RecoverVolumeExpansionFailure).


📌 Главное: Ceph в Kubernetes — мощная, но сложная система. Всегда начинайте с верха (Kubernetes) и постепенно спускайтесь вглубь (Ceph). И помните: если том не монтируется, проверьте, не "висит" ли где-то старый клиент.


#k8s #ceph #pvc #troubleshooting

⚙️ Движки сборки образов в 2025–2026: разбор

Сборка контейнеров — сердце любого CI/CD. Но чем именно собирать образы сегодня, когда ландшафт инструментов сильно изменился?

Разбираем все актуальные движки: от ветерана Docker BuildKit до новичка Kimia, который пришёл на смену «умершему» Kaniko. Сохраняйте, чтобы не потерять! 👇


🧱 Как это работает

Образ состоит из слоёв. Каждая команда в Dockerfile — новый слой.
- Кэш ускоряет сборку, переиспользуя неизменные слои.
- Современные движки строят граф зависимостей и выполняют этапы параллельно.


🛠 Основные игроки

🐳 Docker BuildKit
Стандарт де-факто. Встроен в Docker. Умеет параллелить независимые стадии, умно кэшировать в S3/Registry, монтировать секреты без сохранения в слоях и собирать multi-arch образы.
👉 *Выбор для большинства команд.*

🦭 Buildah
Инструмент от Red Hat. Работает без демона Docker. Полный rootless из коробки. Тесно дружит с Podman. Отлично подходит для строгих security-политик.
👉 *Максимальная безопасность без компромиссов.*

📦 Podman
Полная замена Docker CLI, но без демона. Для сборки под капотом использует код Buildah.
👉 *Если хочется Docker, но безопаснее.*

☁️ Kaniko (⚠️ Архив)
Google-инструмент для сборки в Kubernetes без демона и root-прав. Важно: проект переведён в архив в июне 2025. Для новых проектов использовать не рекомендуется.
👉 *Пора мигрировать на аналоги.*

🔥 Kimia (НОВИНКА)
Прямая замена Kaniko. Разработан как Kubernetes-native и 100% совместимый по аргументам с Kaniko. Фишка: под капотом использует либо BuildKit, либо Buildah. Обеспечивает полный rootless, сокращает поверхность атаки на 90% и умеет подписывать образы (Cosign).
👉 *Лучший выбор для безопасных сборок в K8s прямо сейчас.*

☕️ Jib
Специалист по Java (Maven/Gradle). Не требует Dockerfile. Сам раскладывает приложение по слоям (зависимости, ресурсы, классы) для супер-быстрых повторных сборок.
👉 *Мастхэв для Java-микросервисов.*

🧩 Cloud Native Buildpacks (CNB)
Сборка из исходников без Dockerfile. Buildpack сам определит язык и соберёт образ по best practices.
👉 *Идеально для платформенных команд, чтобы стандартизировать сборки.*

🧪 Другие
- Makisu (от Uber) — нишевый, почти не развивается.
- Bazel — мощно для монореп, но сложный порог входа.
- werf — CI/CD комбайн на базе Buildah.


💡 Лучшие практики (вне зависимости от движка)

1️⃣ Многоэтапная сборка: собираем в «жирном» образе, копируем только бинарник в минимальный alpine или scratch.
2️⃣ Порядок слоёв: сначала копируем файлы с зависимостями (package.json), потом ставим пакеты, и только в конце — код.
3️⃣ Секреты: никогда не через ENV. Используйте --mount=type=secret.
4️⃣ Безопасность: запускайте контейнер от USER 1000 и сканируйте образы Trivy/Grype.


🚀 Будущее

- BuildKit — король производительности.
- Kaniko уходит в прошлое, его место занимает Kimia.
- Rootless-сборки становятся обязательным стандартом безопасности.
- Все больше команд переходят на CNB, забывая о ручном написании Dockerfile.

🚀 Cilium CNI и Cluster Mesh: единая сеть для всех ваших кластеров

Современный Kubernetes — это часто зоопарк из десятков кластеров. Как заставить их работать как единое целое, не теряя в скорости и безопасности? Ответ — Cilium и его режим Cluster Mesh.

⚡️ Что такое Cilium и при чём тут eBPF?

Cilium — это не просто сетевой плагин. Он основан на eBPF — технологии, которая запускает ваш сетевой код прямо в ядре Linux.

Результат:
* Пропускная способность значительно выше, чем у решений на базе iptables.
* Значительно меньшие задержки по сравнению с традиционными CNI.
* Полноценная замена kube-proxy без потери производительности.
* Глубокая наблюдаемость через Hubble.

🛡 Безопасность на уровнях L3–L7

Cilium понимает не только IP и порты, но и протоколы прикладного уровня: HTTP, Kafka, gRPC, DNS и другие. Можно написать политику: «фронтенду можно GET /api, но только если он из namespace production». И всё это без sidecar-прокси.

🌍 Cluster Mesh: когда один кластер — мало

Cluster Mesh связывает несколько независимых Kubernetes-кластеров в единую сеть. Поды из кластера А могут обращаться к подам в кластере Б так, будто они в одном пространстве имен.

Ключевые сценарии использования:
* Геораспределённые и высокодоступные сервисы
* Разделение stateful / stateless
* Общие сервисы (мониторинг, секреты) для всех команд

🧩 Как это работает

* В каждом кластере разворачивается компонент clustermesh-apiserver. Он отслеживает состояние локального кластера (сервисы, поды, идентификаторы) и синхронизирует его с общим etcd-хранилищем.
* Агенты Cilium на всех узлах читают это хранилище и программируют eBPF-маршруты напрямую к удалённым подам.
* Никаких дополнительных прокси или шлюзов — чистый pod-to-pod через туннели (VXLAN/Geneve) или нативную маршрутизацию.

💡 Ключевые возможности Cluster Mesh

✅ Глобальные сервисы (Global Services): Один и тот же сервис, распределённый по всем кластерам. Балансировка нагрузки и автоматический фейловер «из коробки»:

metadata:
  annotations:
    service.cilium.io/global: "true"

Для этого сервис с одинаковыми именем и пространством имен должен быть создан во всех кластерах mesh-сети.

✅ Сетевые политики на весь Mesh: Запрещаем доступ из кластера 3 к бекенду в кластере 1. Политики CiliumNetworkPolicy работают глобально, опираясь на криптографические идентификаторы, а не на IP-адреса.

✅ Прозрачное шифрование (Transparent Encryption): Включается одной опцией, и весь трафик между узлами в разных ЦОД защищается с помощью IPsec или WireGuard.

✅ Hubble обеспечивает наблюдаемость не только внутри одного, но и между несколькими кластерами в Cluster Mesh.

⚙️ Быстрый старт за 5 минут

1. Устанавливаем Cilium на каждом кластере с уникальными cluster-name и cluster-id и непересекающимися PodCIDR:

    cilium install \
      --cluster-name eu-cluster \
      --cluster-id 1 \
      --kube-proxy-replacement strict

*Важно: Режим передачи данных (инкапсуляция или нативная маршрутизация) должен быть одинаковым на всех кластерах*.

2. Включаем Cluster Mesh на каждом из кластеров:

    cilium clustermesh enable

3. Соединяем кластеры:

    cilium clustermesh connect \
      --context eu-cluster \
      --destination-context us-cluster

📊 Cilium vs. Istio/Linkerd

Cilium — это подход без sidecar-контейнеров (sidecar-less). В отличие от Istio или Linkerd, которые внедряют дополнительный прокси-контейнер в каждый под, Cilium обрабатывает трафик на уровне ядра. Это даёт лучшую производительность и меньшее потребление ресурсов, особенно в крупных масштабах. При этом Cilium легко интегрируется с классическими Service Mesh, обеспечивая многоуровневую защиту.

🏁 Вывод

Связка Cilium + Cluster Mesh — это одна из самых производительных и безопасных альтернатив для построения мультикластерного Kubernetes. Без sidecar-контейнеров, с «плоской» сетью и сквозными политиками безопасности. Если вы ещё думаете, как объединить свои кластеры — попробуйте, оно того стоит.

Больше деталей и туториалов — на официальном сайте [cilium.io](https://cilium.io)

#kubernetes #cilium #ebpf #devops #networking

🌍 Мультикластер и геораспределёнка: не просто «серверы в разных странах»

Современные сервисы должны работать быстро отовсюду и не падать при отказе целого дата-центра. Но поставить железо в нескольких локациях — лишь первый шаг. Разбираемся, чем отличается мультикластерная архитектура от настоящей геораспределёнки, и какие практики спасают от ночных кошмаров дежурных инженеров.

⚖️ Два понятия, которые часто путают
Мультикластер — несколько независимых кластеров (K8s, базы) под единым управлением. Они могут быть хоть в одной комнате. Задача: изоляция сред, отказоустойчивость, разделение тенантов.
Геораспределённая система — кластеры разнесены на сотни/тысячи км, но решают одну бизнес-задачу как единое целое. На первый план выходят физика сети: задержки, джиттер, партиции.

Реальность — гибрид: географически удалённые площадки, внутри каждой — своя мультикластерная логика.

📌 Три главных архитектурных лекала

1️⃣ Active-Passive
Трафик льётся в один регион, второй в резерве. Просто, но RTO — минуты, часть данных может потеряться. Подходит для начала.

2️⃣ Active-Active
Оба региона работают одновременно. Пользователь из Азии летит в Сингапур, из Европы — во Франкфурт. Требует multi-master БД, разрешения конфликтов (CRDT, Last-Writer-Wins). Почти всегда теряем строгую согласованность ради доступности.

3️⃣ Гео-шардирование
Пользователь «прибит» к своему региону по ID. Домен отказа локален, но кросс-региональные запросы редки и медленны.

⚙️ Практики, оплаченные инцидентами

🔹 Проектируйте под разрывы сети
Сетевая партиция — норма. Каждый межкластерный вызов: таймауты, circuit breaker, деградация. Если соседний сервис не отвечает, продолжаем работать на локальных данных, а не падаем с 500-й ошибкой.

🔹 Состояние — отдельная песня
Старайтесь делать сервисы stateless. Если без распределённых данных никак:
- Асинхронная репликация (PostgreSQL/MySQL) — просто, но смиритесь с возможной потерей последних транзакций.
- Распределённые SQL и NoSQL (CockroachDB, YugabyteDB, Cassandra) — консистентность ценой латентности на запись. Лидеров партиций размещайте рядом с сервисами.
- Объектное хранилище (S3/MinIO) — простейший способ раздать статику глобально.

🔹 Единая наблюдаемость без лавины алертов
Метрики, логи, трейсы — в одну платформу (Grafana Mimir, Loki, Tempo). Алертинг сделайте кластерно-осведомлённым: инцидент в одном регионе не должен взрывать уведомления на дежурном пульте.

🔹 GitOps и канареечные выкатки
Всю конфигурацию — в Git. Развёртываете сначала стейджинг, потом наименее нагруженный продакшен-кластер, проверяете метрики, и только затем катите на остальные. Инструменты: Argo CD, Flux, Kustomize.

🔹 Умный вход пользователя
Сочетайте Anycast, Latency-based DNS и Ingress с GeoIP. При падении региона не ждите протухания DNS — рулите трафиком через HTTP-редирект или мгновенный отвод BGP-маршрута.

🔹 Регулярный «день хаоса»
Ручное переключение по чек-листу раз в год — гарантия фейла в реальной аварии. Отключайте целый регион посреди спринта и смотрите, как система сама восстанавливается. Автоматизируйте failover и тестируйте его в CI/CD.

🔹 Безопасность без иллюзий
Никакого доверия по IP-подсетям. Взаимный TLS между сервисами через Service Mesh (Istio, Consul Connect) — обязательно. Единый IAM должен быть отказоустойчив: OIDC-провайдеры с локальными кешами, чтобы разрыв с центром аутентификации не парализовал все кластеры разом.

💎 Итог
Глобальная инфраструктура — всегда компромисс между доступностью, согласованностью и сложностью. Не гонитесь за хайпом multi-master, если можно начать с асинхронной репликации и stateless-сервисов. Сначала добейтесь идеального восстановления резерва, а потом уже выходите в Active-Active. Тогда ваша геораспределёнка будет активом, а не постоянным источником боли.