8.3 Контейнеры, оркестрация и облачные технологии

Обзор и мотивация

Контейнер упаковывает приложение вместе с его зависимостями в единую переносимую изолированную единицу. Он работает одинаково на ноутбуке, в тестовой среде и в производстве. Платформы оркестрации, прежде всего Kubernetes, планируют и обслуживают большое число контейнеров на парках машин. Они управляют размещением, масштабированием, здоровьем, сетью и восстановлением. Облачные технологии (cloud-native) это более широкий архитектурный стиль, построенный на этих основаниях: приложения, спроектированные как слабо связанные, независимо развёртываемые, горизонтально масштабируемые сервисы, предполагающие динамическую самовосстанавливающуюся инфраструктуру.

Для больших команд контейнеры и оркестрация решают одну трудную проблему. Нужно надёжно и эффективно запускать много сервисов, построенных многими командами, на общей инфраструктуре. Контейнеры дают каждой команде согласованный контракт упаковки и среды выполнения, что упраздняет класс отказов «работает на моей машине». Оркестрация прячет отдельные машины за общим субстратом, так что команды развёртывают на платформу, а не на серверы. Эта стандартизация позволяет эксплуатировать сотни или тысячи сервисов, не заставляя каждую команду заново изобретать развёртывание, масштабирование и устойчивость.

Корпоративные и государственные пользователи получают переносимость, устойчивость и путь прочь от привязки. Взамен они наследуют реальную сложность и новые обязанности по безопасности. Платформа контейнеров мощна именно потому, что программируема и динамична, а значит, ею нужно тщательно управлять. Происхождение образов, изоляция многоарендности, сетевая политика и цена становятся заботами уровня платформы. Принимающие в государственном секторе всё чаще добавляют требования суверенитета: контроль над тем, где находятся данные и кто может к ним обращаться. Это делает способность запускать согласованные нагрузки в выбранных средах стратегической возможностью, а не просто технической деталью.

Ключевые принципы

• Упаковывайте приложения как малые, узкоцелевые, неизменяемые образы контейнеров.
• Практикуйте гигиену образов: минимальные базовые образы, закреплённые версии, сканирование на уязвимости и подпись.
• Проектируйте приложения без состояния и горизонтально масштабируемыми, где возможно, выводя состояние наружу.
• Воспринимайте модель желаемого состояния платформы оркестрации как источник истины и позвольте ей самолечиться.
• Принуждайте изоляцию и наименьшие привилегии между арендаторами, нагрузками и пространствами имён.
• Следуйте принципам двенадцати факторов, методологии построения одноразовых приложений с вынесенной конфигурацией и горизонтальным масштабированием, и расширяйте их под реальности распределённых систем.
• Делайте цену первоклассной видимой инженерной заботой, а не запоздалой мыслью.
• Предпочитайте переносимые абстракции на основе стандартов, чтобы сохранить стратегическую гибкость.

Рекомендации

Практикуйте строгую гигиену образов

Образ контейнера ваша основная единица доверия и развёртывания, так и воспринимайте его. Начинайте с минимальных доверенных базовых образов, чтобы сократить поверхность атаки. Закрепляйте версии зависимостей и базовых образов для воспроизводимости. Сканируйте каждый образ на известные уязвимости в конвейере сборки и блокируйте образы с критичными находками. Подписывайте образы и проверяйте подписи при развёртывании, так что работают только утверждённые, неизменённые образы. Держите курируемый внутренний реестр укреплённых базовых образов, из которых строят команды. Это автоматически распространяет хорошие умолчания безопасности.

Используйте шаблоны Kubernetes, а не изобретайте их заново

Kubernetes вознаграждает команды, принимающие его устоявшиеся шаблоны, и наказывает тех, кто борется с его моделью. Используйте декларативные манифесты для желаемого состояния. Добавляйте пробы здоровья, чтобы платформа могла обнаруживать и заменять нездоровые экземпляры. Задавайте запросы и пределы ресурсов, чтобы планировщик мог безопасно упаковывать нагрузки. Используйте горизонтальное автомасштабирование для эластичного спроса. Для операционной логики, которая должна работать непрерывно, такой как управление базой данных, ротация сертификатов или согласование пользовательских ресурсов, используйте шаблон оператора, кодирующий человеческое операционное знание в программное обеспечение, следящее за состоянием и действующее. Сопротивляйтесь желанию строить заказную оркестрацию поверх платформы. Предпочитайте нативные конструкции.

Проектируйте многоарендность намеренно

Когда много команд делят кластер, изоляция требование безопасности и надёжности, а не любезность. Используйте пространства имён как границы аренды. Принуждайте квоты ресурсов, чтобы ни один арендатор не мог обездолить остальных. Применяйте сетевые политики, ограничивающие трафик явно разрешённым. Используйте управление доступом на основе ролей (RBAC), чтобы ограничить то, что может делать каждая команда. Для нагрузок с более сильными нуждами в изоляции рассмотрите отдельные кластеры или более сильную песочницу. Решите рано, какова ваша модель: мягкая многоарендность (доверенные внутренние команды) или жёсткая (взаимно недоверяющие нагрузки), потому что они требуют очень разных средств контроля.

Стройте облачные технологии: двенадцать факторов и дальше

Методология двенадцати факторов с её явными зависимостями, конфигурацией в среде, процессами без состояния, одноразовостью и так далее остаётся отличной основой для сервисов, процветающих на динамической платформе. Расширяйте её под добавочные реальности распределённых систем. Проектируйте для частичного отказа. Делайте операции идемпотентными и повторяемыми. Открывайте здоровье и телеметрию. Воспринимайте наблюдаемость как встроенную функцию, а не дополнение. Выводите всё состояние в управляемые сервисы данных, чтобы экземпляры приложений оставались одноразовыми и горизонтально масштабируемыми.

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

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

Сделайте цену видимой с FinOps

В эластичных облачных средах цена прямое следствие инженерных решений, поэтому дайте инженерам видимость и подотчётность. Размечайте ресурсы тегами для распределения затрат. Относите расходы на команды и сервисы. Показывайте данные о цене рядом с метриками производительности. Подбирайте размер нагрузок, используйте автомасштабирование под спрос и возвращайте простаивающие ресурсы. Установите практику FinOps, сводящую инженерию, финансы и продукт, так что облачные расходы становятся общей непрерывной ответственностью, а не квартальным сюрпризом.

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы	Лучше всего подходит
Kubernetes	Мощно, переносимо, огромная экосистема	Крутая сложность; эксплуатационное бремя	Много сервисов в масштабе
Управляемый сервис контейнеров	Меньше бремя эксплуатации; быстрый старт	Некоторая привязка; меньше контроля	Команды, желающие простоты
Единый общий кластер	Эффективное использование ресурсов	Труднее изоляция; радиус поражения	Доверенные внутренние арендаторы
Кластер на арендатора	Сильная изоляция	Выше цена и накладные расходы	Недоверяющие или регулируемые нагрузки
Переносимость мультиоблака	Гибкость; избегает привязки	Сервисы наименьшего общего знаменателя	Снижение стратегического риска
Глубокие управляемые сервисы одного облака	Максимальная продуктивность	Зависимость от поставщика	Команды, нацеленные на скорость

Всеобъемлющий компромисс возможности против сложности. Kubernetes и облачные архитектуры дают эластичность, устойчивость и скорость. Но они налагают существенное эксплуатационное и когнитивное бремя, которое малые команды регулярно недооценивают. Подобным образом погоня за полной переносимостью мультиоблака меняет продуктивность на опциональность. Правильный ответ зависит от масштаба и риска. Большие организации со многими командами и сильными потребностями управления обычно оправдывают вложение. Меньшим усилиям нередко лучше служат управляемые сервисы, скрывающие сложность.

Вопросы для обсуждения с командой

1. Подписываете ли вы образы и проверяете подписи при развёртывании и блокирует ли критичная уязвимость сборку на самом деле? Образ ваша единица доверия, поэтому цепочка поставок вокруг него заслуживает жёстких барьеров, а не предупреждений. Решите, могут ли работать только подписанные проверенные образы, блокирует ли сканирование критичные находки или только журналирует их и кто сопровождает курируемый реестр укреплённых базовых образов, из которых строят команды. Для корпоративных и государственных нагрузок это нередко требование соответствия, а также ваша лучшая защита от отравленной зависимости, достигающей производства. Принесите текущее состояние: какая доля работающих образов происходит из вашей укреплённой базы, сколько несёт неисправленные критичные CVE и можно ли сейчас запланировать любой неподписанный образ. Если критичная находка не останавливает развёртывание, ваш сканер декорация.

2. Как запросы, пределы и квоты ресурсов не дают одной нагрузке обездолить соседей, не оставляя дорогую мощность простаивать? На общем кластере нагрузка без пределов может обрушить или затормозить всё вокруг, а слишком щедрые квоты тратят впустую выигрыши в использовании, оправдывающие платформу. Решите разумные умолчания, кто их настраивает и как вы ловите нагрузки, у которых запросы вообще не заданы. В масштабе это одновременно средство контроля надёжности и средство контроля цены, потому что подбор размера то место, где живёт значительная часть экономии FinOps. Принесите данные: нынешнее использование кластера, как часто нагрузки вытесняются или тормозятся и в каких пространствах имён нет квот. Цель плотная безопасная упаковка, поэтому воспринимайте отсутствующие пределы как дефект, который платформа отвергает.

3. Какому состоянию позволено жить внутри контейнера и куда идёт всё остальное? Облачная устойчивость зависит от одноразовых экземпляров, которые платформа может перепланировать по желанию, а это держится, только если важное состояние живёт в управляемых сервисах данных, а не на локальном диске контейнера. Решите правило явно, потому что состояние, случайно сохранённое в контейнере, становится потерей данных при следующем перепланировании. Для команд, мигрирующих старые приложения, это нередко самая трудная часть, поскольку унаследованные сервисы предполагают стабильную локальную файловую систему. Принесите опись: какие сервисы пишут локальное состояние, какие полагаются на липкие сеансы или привязку к узлу и что потребовалось бы, чтобы вынести каждое наружу. Пока состояние не вынесено, у вас контейнеры, которые выглядят эластичными, но на деле не могут быть перемещены.

4. Когда много команд делят кластер, выбрана ли ваша модель изоляции намеренно как мягкая или жёсткая многоарендность и соответствуют ли средства контроля этому выбору? Пространства имён разделяют доверенные внутренние команды, но не сдерживают нагрузку, активно враждебную или скомпрометированную, а воспринимание мягкой аренды как жёсткой инцидент безопасности, ждущий своего часа. Решите для каждой нагрузки, нужно ли арендаторам просто справедливое разделение или следует предполагать, что они не доверяют друг другу, затем подберите средства контроля: пространства имён, квоты, сетевые политики и RBAC для мягкого случая, отдельные кластеры или более сильная песочница для жёсткого. Для большой организации это решение напрямую определяет цену, потому что кластер на арендатора намного дороже общих пространств имён, поэтому вы хотите тратить бюджет изоляции только там, где модель угроз этого требует. Принесите опись арендаторов: какие нагрузки делят кластер сегодня, какие обрабатывают регулируемый или внешний трафик и где сетевая политика всё ещё разрешает всё по умолчанию. В корпоративной и государственной среде смешение недоверяющих нагрузок под мягкой арендой именно та находка, которую пометит аудитор, поэтому назовите границу раньше него.

5. Сколько вы платите за переносимость мультиоблака и будете ли вы когда-нибудь ею пользоваться? Стандартизация на контейнерах, Kubernetes и открытых API держит нагрузки перемещаемыми, но отказ от каждого управляемого сервиса ради сохранения этой опции меняет реальную ежедневную продуктивность на переносимость, которой организация может никогда не воспользоваться. Решите, где переносимость подлинное требование, например обязательство суверенитета или выхода, которое вы подписали, а где утешительное одеяло, замедляющее каждую команду. Конкурирующее соображение скорость: глубокие управляемые сервисы быстрее выпускают функции, а архитектура наименьшего общего знаменателя постоянный налог на каждую команду. Принесите свидетельства: каких управляемых сервисов вы избегали и чего это стоило в инженерном времени, перемещали ли вы когда-нибудь нагрузку между провайдерами и что на самом деле обязывают ваши контракты. Для государственных и регулируемых пользователей правила местонахождения данных и суверенного облака могут делать переносимость непреложной, поэтому проектируйте так, чтобы те же манифесты и конвейеры работали в суверенном регионе и частном анклаве, но будьте честны, что это цена соответствия, а не бесплатная страховка.

6. Видит ли каждая команда, что она тратит, и владеет ли кто-нибудь счётом, прежде чем он станет сюрпризом? В эластичной платформе цена прямой выход инженерных решений, однако без тегов распределения затрат и видимых панелей расходы копятся в общем пуле, за который никто не чувствует ответственности, пока финансы не поднимут тревогу. Решите, как вы относите цену на команды и сервисы, кто её рецензирует и видят ли инженеры цену рядом с метриками производительности или слышат о ней раз в квартал. Напряжение между подотчётностью и трением: давите на цену слишком сильно, и каждое решение становится бюджетным торгом, игнорируйте её, и простаивающие, избыточные нагрузки тихо накапливаются. Принесите числа: нынешние расходы по командам, сколько мощности простаивает или избыточно и как быстро была бы замечена убегающая нагрузка. Для корпоративных и государственных бюджетов неотнесённые облачные расходы и сбой управления, и реальный финансовый риск, поэтому поднимите практику FinOps, ставящую инженерию, финансы и продукт в один разговор, а не сверяющую постфактум.

Взгляд по секторам

Стартап. Тянитесь к управляемому сервису контейнеров, а не к самостоятельно размещаемому кластеру Kubernetes: с парой сервисов и без платформенного инженера плоскости управления отвлечение, которое вы не можете себе позволить. Упаковывайте малые образы из минимальной базы, закрепляйте версии, добавьте одно сканирование уязвимостей в сборку и перенесите всё состояние в управляемую базу данных, чтобы экземпляры оставались одноразовыми. Пропустите пространства имён, операторы и переносимость мультиоблака, пока у вас действительно нет сервисов и людей, чтобы это оправдать.

Малый бизнес. Без выделенного платформенного специалиста и при ограниченном бюджете сильно опирайтесь на управляемые сервисы и позвольте провайдеру вести оркестрацию, которую иначе пришлось бы комплектовать персоналом. Воспринимайте основы контейнеров как ваш пол безопасности: минимальные образы, закрепление версий и сканирование в конвейере дают большую часть защиты при малых усилиях. Предпочитайте покупку поддерживаемой платформы её построению и сохраняйте достаточно переносимости, стандартные контейнеры и открытые API, чтобы не оказаться в ловушке, если цены или условия изменятся.

Крупная организация. Задача платформенное управление по многим командам: центральная платформенная команда, поставляющая укреплённые базовые образы, барьеры подписи и сканирования, аренду по пространствам имён с квотами, сетевую политику и RBAC, плюс теги распределения затрат и панель FinOps. Стандартизируйте контракт развёртывания, чтобы сотни сервисов работали одинаково, и управляйте безопасностью, многоарендностью и ценой централизованно, пока команды обслуживают развёртывание сами. Финансируйте платформенную команду должным образом, потому что недоукомплектованная платформа становится узким местом, которого ждёт вся организация.

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

Примеры

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

Крупная организация. Телекоммуникационная компания ведёт несколько сотен микросервисов на общих кластерах Kubernetes. Платформенная команда предоставляет укреплённые базовые образы, принуждает подпись образов и барьеры уязвимостей и изолирует бизнес-подразделения по пространствам имён с квотами, сетевыми политиками и RBAC. Теги распределения затрат и панель FinOps относят расходы на каждую продуктовую линию, а автомасштабирование подбирает мощность под спрос. Продуктовые команды развёртывают десятки раз в день на согласованную платформу, не управляя серверами. Компания сохраняет центральный контроль над безопасностью и ценой.

Государственный сектор. Национальная служба здравоохранения должна держать данные граждан внутри национальных границ и под национальным правовым контролем. Она ведёт нагрузки в суверенном облачном регионе на стандартных контейнерах и Kubernetes, так что те же конвейеры и манифесты работают также в локальной аккредитованной среде для самых чувствительных данных. Границы местонахождения данных и доступа закодированы как политика, образы берутся из внутреннего укреплённого реестра, а жёсткая многоарендность изолирует чувствительные нагрузки. Переносимость между суверенным регионом и частным анклавом даёт службе устойчивость и рычаг в переговорах без жертв в соответствии.

Бизнес-обоснование: мотивы, ROI и TCO

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

Анализ TCO должен быть честен об эксплуатационном бремени. Цены принятия включают платформенный инженерный персонал, обучение, инструменты безопасности для образов и кластеров и постоянные усилия по эксплуатации самой платформы. Цена непринятия включает несогласованное заказное развёртывание по командам, плохое использование дорогой инфраструктуры, хрупкое ручное масштабирование и трудность в выполнении требований устойчивости и суверенитета. Для руководства довод опирается на масштаб. Ниже определённого числа сервисов сложность может не окупаться, и управляемый сервис мудрее. Но в корпоративном и государственном масштабе управляемая облачная платформа обычно самый экономически эффективный и устойчивый фундамент при условии, что вы финансируете платформенную команду для её должной эксплуатации.

Антипаттерны и ловушки

• Жирные несканированные образы. Раздутые образы из недоверенных баз несут лишние уязвимости и всё замедляют.
• Kubernetes для всего. Принятие сложного оркестратора для горстки простых сервисов покупает сложность без отдачи.
• Игнорирование пределов ресурсов. Без запросов и пределов одна нагрузка может обездолить или обрушить соседей.
• Мягкая аренда для враждебных нагрузок. Опора на одни пространства имён для изоляции недоверяющих арендаторов инцидент безопасности, ждущий своего часа.
• Случайно имеющие состояние контейнеры. Хранение важного состояния внутри одноразовых контейнеров ведёт к потере данных при перепланировании.
• Слепота к цене. Воспринимание облачных расходов как фиксированных накладных, а не инженерного выхода, ведёт к убегающим счетам.
• Театр переносимости. Отказ от всех управляемых сервисов ради сохранения переносимости, которой организация никогда не воспользуется.

Модель зрелости

Уровень 1: Начальный. Контейнеры используются стихийно, если вообще. Образы собираются вручную и не сканируются, развёртывание ручное и реактивное, и нет ни общей платформы, ни видимости цены, ни модели изоляции.

Уровень 2: Развитие. Команды контейнеризуют приложения и принимают оркестратор, но практики различаются между группами. Сканирование образов, пределы ресурсов и подпись непоследовательны, а цена и многоарендность не управляются систематически.

Уровень 3: Стандартизация. Стандартизированная платформа документирована и принуждается по организации: укреплённые базовые образы, барьеры подписи и сканирования, аренда по пространствам имён с квотами и сетевой политикой, RBAC и распределение затрат. Облачные шаблоны и двенадцать факторов ожидаемая норма, а не локальный выбор.

Уровень 4: Управление. Платформа измеряется и контролируется относительно базовых значений. Вы отслеживаете использование кластера, долю работающих образов, собранных из укреплённой базы, неисправленные критичные уязвимости, частоту развёртываний и долю неудачных изменений, доли вытеснения и торможения и цену на команду и сервис относительно бюджета. Барьеры принуждаются по этим свидетельствам: отсутствующие пределы ресурсов и неподписанные образы отвергаются автоматически, а отклонение от стандарта запускает действие, а не предупреждение.

Уровень 5: Оркестрация. Платформа самообслуживаемая и самолечащаяся, интегрированная по организации и адаптивная. FinOps непрерывно подбирает размеры и возвращает мощность, переносимая архитектура поддерживает гибридные и суверенные требования, а платформа непрерывно улучшается по измеренному использованию, выводя и заменяя компоненты по мере сдвигов нагрузок, цены и картины рисков.

Идеи для обсуждения

• При каком масштабе принятие Kubernetes перестаёт быть сложностью ради сложности и начинает окупаться?
• Где правильная граница между мягкой и жёсткой многоарендностью для ваших нагрузок?
• Сколько вкладывать в переносимость мультиоблака против продуктивности глубоких управляемых сервисов?
• Как дать инженерам реальную подотчётность за цену, не превращая каждое решение в бюджетный торг?
• Какова ваша модель управления базовыми образами и кто сопровождает укреплённый реестр?
• Как требования суверенитета и местонахождения данных формируют архитектуру вашей платформы?

Главные выводы

• Контейнеры стандартизируют упаковку и среду выполнения; оркестрация стандартизирует эксплуатацию в масштабе.
• Гигиена образов, то есть минимальные, закреплённые, сканируемые, подписанные образы, основополагающая безопасность.
• Используйте нативные шаблоны Kubernetes и операторы, а не стройте заказную оркестрацию.
• Выбирайте модель многоарендности намеренно, исходя из того, насколько нагрузки доверяют друг другу.
• Следуйте двенадцати факторам и расширяйте их под реальности распределённых систем вроде частичного отказа и наблюдаемости.
• Воспринимайте цену как инженерный выход и управляйте ею непрерывно через FinOps.

Источники и дополнительное чтение

• Adam Wiggins, The Twelve-Factor App (methodology).
• Brendan Burns, Joe Beda, and Kelsey Hightower, Kubernetes Up & Running.
• Bilgin Ibryam and Roland Huß, Kubernetes Patterns.
• Cornelia Davis, Cloud Native Patterns.
• J.R. Storment and Mike Fuller, Cloud FinOps.
• Liz Rice, Container Security.
• Cloud Native Computing Foundation (CNCF), cloud-native definition and landscape.