Главная мысль
Учитывайте разные границы изоляции контейнеров и VM. Отдельно защищайте узел, гипервизор, образы, учётные записи сервисов и сетевые границы.
Гипервизор распределяет физические ресурсы между VM
Гипервизор, или монитор виртуальных машин, распределяет процессорное время, память, диски и сетевые ресурсы между несколькими VM; каждая VM запускает собственную ОС и процессы. Гипервизор типа 1 работает непосредственно на оборудовании, типа 2 — поверх основной операционной системы. Тип 1 часто выбирают для рабочих систем в центрах обработки данных, а тип 2 удобен для локальной разработки и тестирования. Совместное использование ресурсов помогает консолидировать серверы и быстро создавать среды, но сам гипервизор остаётся критичным уровнем управления.
| Тип | Слой работы | Типичное применение |
|---|---|---|
| Type 1 | Непосредственно на физическом оборудовании | Серверы, центры обработки данных, облачные узлы |
| Type 2 | Поверх основной операционной системы | Разработка, тестирование, виртуализация на рабочем компьютере |
VM и контейнер обеспечивают разную изоляцию
VM получает виртуальное оборудование через гипервизор и запускает полноценную гостевую ОС. Обычный контейнер упаковывает приложение и зависимости, использует общее с узлом ядро и изолируется средствами ОС, например пространствами имён и группами управления ресурсами в Linux. Это уменьшает накладные расходы, но не устраняет риски ядра и среды выполнения. Разные образы контейнеров не создают отдельных границ операционной системы. VM может подойти для задач со специальным ядром, устаревшими зависимостями или более строгими требованиями к изоляции арендаторов; контейнер удобен для быстрого переноса совместимых компонентов.
Микросервис — независимо развертываемая бизнес-функция
Микросервис — компонент, который выполняет узкую бизнес-функцию в отдельном процессе и взаимодействует с другими компонентами через API или сообщения. Оплата, аутентификация и уведомления могут быть отдельными сервисами; каждая команда тестирует и развертывает свой компонент. Монолит может упростить развертывание и работу с общей кодовой базой, а микросервис позволяет отдельно масштабировать и обновлять выбранную часть. Взамен требуется управлять большим количеством сетевых связей, развёртываний, учётных записей сервисов, журналов и потоков данных. Не дробите архитектуру только из-за моды: оцените операционные возможности команды и реальную пользу границ.
| Критерий | Монолит | Микросервис |
|---|---|---|
| Выпуск | Всё приложение как единое целое | Отдельно по сервисам |
| Масштабирование | Масштабируется всё приложение | Нагруженный сервис можно масштабировать отдельно |
| Операционная сложность | Изначально меньше компонентов | Требует наблюдения за большим числом связей |
Явно задавайте доверие между сервисами
Нахождение в одной сети не должно автоматически означать доверие к сервису. Для запросов между сервисами используйте взаимную аутентификацию и шифрование, краткоживущие учётные данные и минимальные разрешения. Проверяйте образы контейнеров и зависимости при сборке, защищайте источник доверенных образов, обновляйте узлы и гипервизоры. Сетевыми политиками разрешайте только необходимые соединения pod и портов; проверьте поддержку этих политик сетевым модулем кластера. Собирайте журналы и метрики среды выполнения и сервисов, чтобы замечать подозрительные связи и потоки данных при компрометации компонента.
Выбирайте размещение вместе с моделью наблюдения
Контейнеры можно переносить между совместимыми средами, но сервисам с состоянием, особыми требованиями к оборудованию или постоянному хранилищу нужен отдельный проект. При росте числа микросервисов должны быть известны ответственный, версия, зависимости и границы данных каждого сервиса. Централизованные журналы, метрики и трассировки помогают восстановить путь запроса между сервисами; не помещайте чувствительные данные в журналы и метки метрик. Через CI/CD отслеживайте изменение кода и проверки, из которых получен каждый образ, и отрабатывайте возврат к прежней версии.