Cloud Native: принципы CNCF и практика без облака

Что такое Cloud Native

Cloud Native — это не про где, а про как.

CNCF определяет cloud native как подход к созданию и запуску масштабируемых приложений в динамических средах: public, private и hybrid cloud. Контейнеры, service mesh, микросервисы, immutable infrastructure и declarative APIs — примеры, а не обязательный чеклист.

Главные свойства: loosely coupled systems, resilience, manageability, observability и robust automation. Без этих свойств Kubernetes сам по себе не делает систему cloud native.

Принципы и технологии

Cloud Native ортогонально микросервисам: монолит в контейнере с CI/CD, Helm и Prometheus — это всё ещё cloud native.

Cloud Native на bare-metal: полный стек без AWS

Типичный вопрос: «мы не можем идти в облако — у нас госзаказчик / банк / свой ДЦ. Cloud Native нам недоступен?» Нет.

Пример рабочего on-premises стека:

# Установить кластер Kubernetes на физических серверах
kubeadm init --pod-network-cidr=10.244.0.0/16

# Деплой через Helm
helm upgrade --install my-app ./charts/my-app \
  --namespace production \
  --set image.tag=v1.4.2

# GitOps-синхронизация через ArgoCD
kubectl apply -f argocd-app.yaml

# Проверить статус rollout
kubectl rollout status deployment/my-app -n production

Стек:

Kubernetes (bare-metal, kubeadm или Talos)
Harbor — приватный container registry вместо Docker Hub
GitLab CI/CD — сборка образов, прогон тестов, деплой через Helm
ArgoCD — GitOps: кластер синхронизируется с Git-репозиторием, не с руками
Prometheus + Grafana + Loki — метрики, алерты, логи

Это полноценный cloud native без единого запроса к AWS/GCP/Azure.

12-Factor App: фундамент для cloud native приложений

Методология 12factor.net описывает, как писать приложения, которые хорошо работают в cloud native среде. Ключевые факторы:

Приложение, нарушающее эти принципы (хранит состояние на диске, читает конфиг из файла рядом с бинарником, не умеет в graceful shutdown), будет работать в Kubernetes плохо — rolling deploy сломает сессии, канарейка потеряет данные.

Сравнение архитектурных подходов

CAP-теорема в контексте распределённых систем

В распределённых системах сетевые разрывы нужно считать нормальным отказом, поэтому проектируют поведение при partition. Выбор остаётся между:

CP (consistency + partition): etcd, ZooKeeper — лидер-элекция, данные консистентны, но при разрыве часть узлов недоступна
AP (availability + partition): Cassandra-style системы продолжают обслуживать часть операций, но допускают расхождение реплик и последующее схождение

При проектировании микросервисов это определяет стратегию согласованности данных и паттерны: Saga (распределённые транзакции), CQRS (разделение чтения и записи), Event Sourcing.

Trade-offs: что получаешь и за что платишь

Что получаешь:

Горизонтальное масштабирование без остановки сервиса
Self-healing: Kubernetes перезапускает упавшие поды автоматически
Независимые релизы: команда фронтенда деплоит без синхронизации с бэкендом
Скорость: от merge в main до production — минуты, не дни
Утилизацию: ресурсы можно выделять ближе к фактической нагрузке, если есть метрики и автоматизация

За что платишь:

Крутая кривая обучения: Kubernetes, Helm, CI/CD, observability — это недели, не дни
Больше движущих частей: ingress-контроллер, CNI-плагин, cert-manager, external-dns
Большая поверхность атаки: container escape, RBAC misconfiguration, exposed API server
Vendor lock-in при использовании managed services (EKS, GKE) — переход дорог

Platform Engineering: следующий уровень

После того как cloud native инфраструктура выстроена, следующий шаг — снижение когнитивной нагрузки на команды разработки через Internal Developer Platform (IDP).

Backstage (Spotify, open source) — портал для самообслуживания: каталог сервисов, шаблоны для создания новых репозиториев, документация, интеграция с CI/CD
Developer self-service — разработчик сам деплоит, создаёт feature-окружения, управляет зависимостями без DevOps-тикета

IDP не заменяет cloud native инфраструктуру — он строится поверх неё.

Гибридный подход

Часть сервисов в облаке, часть on-premises — рабочая архитектура для банков, госструктур, телекома:

Данные пользователей — on-premises (требование регулятора)
ML-обучение — в облаке (нужны GPU по требованию)
Edge-нагрузка — on-premises рядом с пользователем

Принципы cloud native одинаковы в обоих окружениях. Terraform/Pulumi описывают инфраструктуру и там, и там.