Что такое 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.
Принципы и технологии
| Принцип | Технологии |
|---|---|
| Контейнеризация | Docker, Podman, OCI |
| Оркестрация | Kubernetes |
| CI/CD | GitLab CI, GitHub Actions, ArgoCD |
| Observability | Prometheus, Grafana, Loki, OpenTelemetry |
| Неизменяемая инфраструктура | образы пересобираются, не мутируют |
| IaC / декларативные API | Terraform, Pulumi, Helm, Crossplane |
| Service Mesh | Istio, Linkerd, Cilium |
| Serverless / FaaS | Knative, OpenFaaS |
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 среде. Ключевые факторы:
| Фактор | Суть | Почему важно в K8s |
|---|---|---|
| Config in env | Конфигурация через переменные окружения | ConfigMap / Secret → env в поде |
| Stateless processes | Процессы не хранят состояние между запросами | Rolling update без потери сессий |
| Port binding | Сервис сам слушает порт, не зависит от сервера приложений | Любой контейнер — это self-contained HTTP-сервис |
| Disposability | Быстрый старт и graceful shutdown | preStop hook + terminationGracePeriodSeconds |
| Dev/prod parity | Минимальный разрыв между окружениями | Один образ в dev, stage, prod — только env меняется |
Приложение, нарушающее эти принципы (хранит состояние на диске, читает конфиг из файла рядом с бинарником, не умеет в graceful shutdown), будет работать в Kubernetes плохо — rolling deploy сломает сессии, канарейка потеряет данные.
Сравнение архитектурных подходов
| Критерий | Традиционные Ops | Cloud Native монолит | Cloud Native микросервисы |
|---|---|---|---|
| Масштабируемость | Вертикальная (купить сервер побольше) | Горизонтальная (целиком) | Горизонтальная (по сервисам) |
| Обновления | Ручной деплой, даунтайм | CI/CD, rolling update | CI/CD, независимо по сервисам |
| Инфраструктура | Ручная, изменяемая | IaC, неизменяемая | IaC, неизменяемая |
| Гибкость | Минимальная | Средняя | Максимальная |
| Сложность | Простая | Средняя | Высокая |
| Автоматизация | Минимальная | Обязательная | Обязательная |
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 описывают инфраструктуру и там, и там.