Сжатый справочник архитектурных шаблонов, проверяемых на экзамене CNPA. Читайте сверху вниз или переходите к нужному разделу.
Основные принципы платформенной инженерии
Установить основной принцип для команды платформы, чтобы обеспечить внедрение и уменьшить трение разработчиков.
Рассматривать внутреннюю платформу как продукт. Относиться к внутренним разработчикам как к клиентам, проводить пользовательские исследования, собирать обратную связь и итерировать функции, чтобы уменьшить их когнитивную нагрузку.
Почему: Этот подход смещает фокус с создания инфраструктуры на предоставление ценности, гарантируя, что платформа решает реальные проблемы разработчиков и не обходится стороной ("теневое ИТ").
Установить единый источник истины для желаемого состояния всей инфраструктуры и приложений.
Использовать Git-репозитории как единый источник истины. Развернуть агент в кластере (ArgoCD, Flux), который запускает непрерывный цикл согласования для сравнения состояния кластера с Git.
Почему: Это обеспечивает полный журнал аудита, позволяет легко откатывать изменения и предотвращает дрейф конфигурации, автоматически отменяя внештатные изменения.
Предотвратить дрейф конфигурации и обеспечить согласованность развернутых артефактов во всех средах.
Рассматривать инфраструктуру как неизменяемую. Никогда не изменять работающие ресурсы. Вместо этого создавать новые, версионированные артефакты (образы контейнеров, образы ВМ) и заменять старые. Обеспечивать это с помощью файловых систем контейнеров только для чтения (`readOnlyRootFilesystem: true`).
Почему: Неизменяемость устраняет дрейф конфигурации и делает развертывания предсказуемыми и повторяемыми. "Заменяй, а не чини".
Выбрать безопасную GitOps-модель развертывания, особенно в многокластерных или ограниченных сетевых средах.
Реализовать pull-модель. Агент (ArgoCD, Flux), работающий внутри кластера, извлекает манифесты из Git. Избегать push-моделей, где внешняя система CI отправляет данные в API Kubernetes.
Почему: Pull-модели более безопасны, так как они не требуют внешнего раскрытия сервера API Kubernetes или управления учетными данными для нескольких кластеров в CI.
Ускорить разработку и обеспечить лучшие практики, не ограничивая чрезмерно опытные команды.
Определить "золотые пути" (или "мощеные дороги"): предварительно настроенные, хорошо поддерживаемые шаблоны и рабочие процессы для общих задач (например, создание нового микросервиса).
Почему: Золотые пути снижают когнитивную нагрузку и усталость от принятия решений для 80% случаев, но должны по-прежнему предусматривать "выходные люки" для экспертных команд с уникальными требованиями.
Обеспечить многопользовательскую работу на общей платформе Kubernetes с соответствующими уровнями изоляции.
Для максимально сильной изоляции используйте отдельные кластеры. Для баланса сильной изоляции и эффективности используйте виртуальные кластеры (vClusters). Для базовой, "мягкой" многопользовательской работы используйте изоляцию на уровне пространств имен с RBAC, NetworkPolicies и ResourceQuotas.
Почему: Выбор зависит от рисков безопасности и "шумного соседа". Виртуальные кластеры обеспечивают изоляцию плоскости управления без затрат на полноценные физические кластеры.
Определить основной режим взаимодействия между командой платформы и командами, ориентированными на поток (продуктовые команды).
Команда платформы должна работать преимущественно в режиме "X-as-a-Service", предоставляя инструменты самообслуживания, API и документацию.
Почему: В масштабе команда платформы не может использовать модель плотного взаимодействия с каждой командой. Модель "как услуга" обеспечивает масштабирование и автономию разработчиков.
Наблюдаемость, безопасность и соответствие платформы
Реализовать всеобъемлющую стратегию наблюдаемости для распределенной системы.
Собирать и коррелировать три столпа: метрики (числовые временные ряды через Prometheus), логи (структурированные события через Fluent Bit) и трассировки (потоки запросов через OpenTelemetry).
Почему: Ни один из столпов не достаточен сам по себе. Корреляция их (например, встраивание идентификаторов трассировки в логи) необходима для быстрого диагностирования проблем в сложных микросервисных архитектурах.
Автоматически обеспечивать соблюдение политик безопасности и организационных политик во всех кластерах Kubernetes.
Использовать механизм политик, такой как OPA/Gatekeeper или Kyverno, интегрированный как контроллер допуска (validating/mutating admission controller). Хранить политики в Git и синхронизировать их через GitOps.
Почему: Это обеспечивает автоматические, превентивные меры безопасности, предоставляя разработчикам быструю обратную связь в их CI/CD конвейере вместо медленных, ручных этапов проверки.
Выбрать механизм политик для Kubernetes на основе навыков команды и сложности политик.
Использовать Kyverno для политик, которые могут быть выражены в знакомом формате YAML Kubernetes. Использовать OPA/Gatekeeper для сложных политик, требующих более мощного, специально разработанного языка (Rego) и интеграции внешних данных.
Почему: Kyverno имеет более низкий порог входа для специалистов по Kubernetes. OPA/Rego более мощный, но требует изучения нового языка.
Обеспечить целостность и подлинность образов контейнеров, развертываемых в production.
Внедрить подписание образов в CI-конвейере с использованием Sigstore/Cosign. Использовать контроллер политик (Kyverno, Gatekeeper) для создания политики допуска, которая проверяет подписи образов перед разрешением создания пода.
Почему: Это гарантирует, что в кластере могут запускаться только образы, созданные доверенными CI-конвейерами и не подвергавшиеся изменениям, предотвращая несанкционированное выполнение кода.
Защитить все взаимодействия между сервисами внутри кластера с помощью подхода "нулевого доверия".
Развернуть service mesh (например, Istio, Linkerd) и включить строгий взаимный TLS (mTLS) для всего трафика внутри mesh.
Почему: mTLS обеспечивает как шифрование в процессе передачи, так и надежную, криптографически проверяемую идентификацию как для клиента, так и для сервера, предотвращая спуфинг и атаки "человек посередине" внутри кластера.
Обеспечить соблюдение лучших практик безопасности для всех рабочих нагрузок, запущенных в кластере.
Включить встроенный контроллер Pod Security Admission. Настроить пространства имен для принудительного применения профиля `restricted` для рабочих нагрузок и `baseline` для компонентов платформы.
Почему: Профиль `restricted` обеспечивает критическое усиление безопасности (например, запуск от имени непривилегированного пользователя, отказ от всех возможностей, запрет повышения привилегий) и является фундаментальной мерой безопасности.
Обнаруживать аномальное или вредоносное поведение внутри запущенных контейнеров на уровне ОС.
Развернуть инструмент безопасности во время выполнения, использующий eBPF, такой как Falco или Tetragon. Определить правила для обнаружения подозрительных системных вызовов, доступа к файлам и выполнения процессов.
Почему: Традиционные инструменты безопасности не видят активность внутри контейнеров. eBPF обеспечивает глубокую, низкозатратную видимость событий на уровне ядра, позволяя обнаруживать угрозы, которые другие инструменты пропускают.
Создать масштабируемый и отказоустойчивый конвейер данных наблюдаемости.
Использовать OpenTelemetry (OTel) Collector. Последовательно применять обработчики для преобразования данных (например, обработчик `attributes` для удаления PII, обработчик `batch` для эффективности). Использовать обработчик `memory_limiter` в начале конвейера для предотвращения переполнения памяти (OOM).
Почему: Collector разделяет инструментарий и бэкэнды, предоставляя гибкий, независимый от поставщика способ обработки, фильтрации и маршрутизации телеметрических данных перед экспортом.
Развертывать новые версии приложений в production, минимизируя риски и область поражения.
Внедрить автоматизированные canary-развертывания с использованием таких инструментов, как Flagger или Argo Rollouts. Постепенно переводить трафик на новую версию, автоматически анализируя ключевые метрики (процент успешных операций, задержка). Автоматически откатывать при нарушении SLO.
Почему: Автоматический канареечный анализ проверяет новые версии с реальным производственным трафиком, обеспечивая гораздо более высокий уровень безопасности, чем простые скользящие обновления.
Развернуть новую версию приложения с возможностью мгновенного отката.
Поддерживать две идентичные производственные среды ("синяя" и "зеленая"). Развернуть новую версию в неактивной (зеленой) среде. После проверки переключить балансировщик нагрузки, чтобы весь трафик направлялся на зеленую. Держать синюю в режиме ожидания для мгновенного отката.
Почему: Этот шаблон обеспечивает развертывания без простоя и максимально быстрый откат, но обычно требует вдвое больше инфраструктурных ресурсов.
Управлять секретами декларативно в рабочем процессе GitOps без хранения учетных данных в открытом виде в Git.
Использовать специализированный оператор секретов. Либо шифровать секреты перед коммитом (Bitnami Sealed Secrets, Mozilla SOPS), либо ссылаться на секреты из внешнего хранилища (External Secrets Operator).
Почему: Это позволяет хранить конфиденциальные данные вне Git, одновременно управляя секретами декларативно вместе с конфигурацией приложения, поддерживая рабочий процесс GitOps.
Управлять конфигурациями приложений в нескольких средах (dev, staging, prod) без дублирования.
Использовать такой инструмент, как Kustomize, со структурой "база-и-наложения" (base-and-overlay), или Helm с файлами значений для конкретной среды. Продвигать изменения, обновляя теги образов или конфигурацию в файле наложения/значений целевой среды, как правило, через pull request.
Почему: Этот подход "Не повторяйся" (DRY) предотвращает дрейф конфигурации между средами и делает различия явными и поддающимися аудиту.
Управлять развертываниями одного и того же приложения в большом, динамическом парке кластеров.
Использовать ArgoCD ApplicationSets с генератором кластеров. Генератор динамически обнаруживает кластеры на основе меток и использует шаблон для генерации ресурса Application для каждого соответствующего кластера.
Почему: Это автоматизирует начальную загрузку приложений для новых кластеров и управляет конфигурацией в масштабе, избегая необходимости вручную создавать сотни ресурсов Application.
Обеспечить непрерывное развертывание в production, контролируя выпуск новых функций для пользователей.
Интегрировать систему feature flagging. Развертывать новый код в production за отключенным feature flag. Выпускать функцию, активируя флаг для определенных сегментов пользователей, отделяя развертывание от выпуска.
Почему: Это разделяет технический риск (развертывание) и бизнес-риск (выпуск), обеспечивая высокоскоростные развертывания, A/B-тестирование и возможности "аварийного отключения".
Автоматически развертывать новые образы контейнеров, как только они будут отправлены в реестр.
Использовать компоненты автоматизации образов FluxCD. `ImageRepository` сканирует реестр, `ImagePolicy` выбирает новый тег (например, на основе semver), а `ImageUpdateAutomation` фиксирует изменение тега обратно в репозиторий Git.
Почему: Это замыкает цикл от CI (push образа) до CD (развертывание) для полностью автоматизированного рабочего процесса GitOps, при этом система CI не нуждается в доступе к кластеру.
API платформы и предоставление инфраструктуры
Предоставить унифицированный, декларативный API для разработчиков, позволяющий им самостоятельно предоставлять как ресурсы Kubernetes, так и облачной инфраструктуры (например, базы данных, очереди сообщений).
Использовать Crossplane. Установить плагины облачных провайдеров и определить высокоуровневые CompositeResourceDefinitions (XRD) для разработчиков (например, `kind: PostgresSQLInstance`). Сопоставить их с базовыми облачными ресурсами, используя Compositions.
Почему: Это расширяет плоскость управления Kubernetes для управления внешними ресурсами, позволяя разработчикам использовать знакомые рабочие процессы `kubectl` и GitOps для всех зависимостей их приложений, управляемых паттернами, определенными платформой.
Автоматизировать комплексное управление жизненным циклом stateful-приложений (например, установка, обновления, резервное копирование, восстановление после сбоев) Kubernetes-нативным способом.
Создать Kubernetes Operator. Определить Custom Resource Definition (CRD) для вашего приложения и реализовать пользовательский контроллер, который запускает цикл согласования для управления состоянием приложения.
Почему: Операторы кодируют человеческие операционные знания в программное обеспечение, обеспечивая надежную автоматизацию и рассматривая сложные приложения как первоклассные ресурсы Kubernetes.
Обеспечить, чтобы оператор мог выполнять очистку внешних ресурсов (например, облачного балансировщика нагрузки) до того, как связанный с ним Custom Resource будет удален из Kubernetes.
Добавить finalizer к метаданным Custom Resource. Когда пользователь удаляет CR, он переходит в состояние `Terminating`. Логика согласования оператора обнаруживает это, выполняет очистку, а затем удаляет finalizer, позволяя серверу API K8s завершить удаление.
Почему: Без finalizer CR может быть удален до того, как оператор успеет очистить внешние ресурсы, что приведет к появлению "осиротевшей", дорогостоящей инфраструктуры.
Управлять жизненным циклом парка самих кластеров Kubernetes с использованием декларативных, GitOps-дружественных инструментов.
Использовать Cluster API (CAPI). Кластер управления запускает контроллеры CAPI, которые согласовывают ресурсы `Cluster` и `Machine` для предоставления и настройки рабочих кластеров у различных облачных провайдеров.
Почему: CAPI превращает управление кластерами в декларативный рабочий процесс Kubernetes, обеспечивая последовательное, автоматизированное и версионированное предоставление и обновление целых кластеров.
Развивать API платформы (определенные как CRD) без нарушения работы существующих пользователей или необходимости "большого взрывного" перехода.
Поддерживать несколько версий в определении CRD (например, v1beta1, v1). Реализовать веб-хук преобразования для перевода между версиями, позволяя новым клиентам использовать v1, в то время как старые клиенты продолжают использовать v1beta1 для того же хранимого объекта.
Почему: Веб-хуки преобразования - это нативный механизм Kubernetes для обеспечения неразрушающей эволюции API, что критически важно для стабильного продукта платформы.
IDP и опыт разработчиков
Уменьшить когнитивную нагрузку разработчиков и улучшить обнаруживаемость путем централизации инструментов, документации и программных активов.
Внедрить внутренний портал разработчиков (IDP), используя фреймворк, такой как CNCF Backstage. Заполнить его каталог программного обеспечения, предоставить шаблоны программного обеспечения для создания новых сервисов и интегрировать TechDocs для "docs-as-code".
Почему: IDP действует как "единое окно" для разработчиков, предоставляя "золотые пути" и возможности самообслуживания, которые абстрагируют сложность платформы и ускоряют адаптацию и разработку.
Предоставить единый, надежный инвентарь всего программного обеспечения в организации, включая владение, зависимости и операционный статус.
Внедрить каталог программного обеспечения (например, Backstage Software Catalog), заполняемый через файлы `catalog-info.yaml` в Git-репозиториях. Это создает центральный, доступный для поиска реестр сервисов, библиотек, API и т.д.
Почему: Каталог решает проблемы обнаруживаемости ("какие сервисы существуют?") и владения ("с кем мне поговорить об этом сервисе?"), что критически важно для масштабирования микросервисных архитектур.
Позволить разработчикам создавать новые, готовые к production сервисы, соответствующие организационным стандартам, за считанные минуты.
Использовать инструмент для генерации кода, такой как Backstage Software Templates. Определить шаблоны, которые генерируют новый Git-репозиторий со стандартной структурой проекта, конфигурацией CI/CD конвейера, дашбордами наблюдаемости и `catalog-info.yaml`.
Почему: Шаблоны кодифицируют лучшие практики и предоставляют "мощеный путь" для разработчиков, значительно сокращая время до первого коммита и обеспечивая создание новых сервисов со встроенной безопасностью, наблюдаемостью и соответствием требованиям.
Обеспечить актуальность, версионирование и совместное расположение технической документации с описываемым ею программным обеспечением.
Принять подход "документация как код". Хранить документацию в файлах Markdown в Git-репозитории сервиса. Использовать инструмент, такой как Backstage TechDocs, для автоматической сборки и рендеринга этой документации в IDP.
Почему: Эта модель рассматривает документацию как код - ее можно рецензировать в pull requests и она версионируется вместе с функцией, которую описывает, предотвращая устаревшую документацию.
Измерение эффективности вашей платформы
Измерить эффективность платформы и ее влияние на производительность доставки программного обеспечения.
Отслеживать четыре метрики DORA: частота развертывания (скорость), время выполнения изменений (скорость), процент сбоев изменений (стабильность) и время восстановления сервиса (MTTR, стабильность).
Почему: Метрики DORA - это отраслевые, ориентированные на результат показатели, которые доказано коррелируют с производительностью организации. Они обеспечивают сбалансированный взгляд как на скорость, так и на стабильность.
Обеспечить точную, детализированную видимость затрат для команд, использующих общую платформу Kubernetes.
Развернуть инструмент FinOps, такой как OpenCost или Kubecost. Присваивать затраты рабочим нагрузкам на основе их фактического потребления ресурсов с течением времени. Пропорционально распределять общие затраты кластера (например, системные компоненты, накладные расходы узлов).
Почему: Точное распределение затрат/демонстрация затрат стимулирует подотчетность и поощряет команды оптимизировать использование ресурсов. Без этого общие затраты платформы непрозрачны и трудноуправляемы.
Измерить, действительно ли платформа приносит пользу и используется командами разработки.
Отслеживать уровень внедрения ключевых функций платформы, особенно шаблонов "золотого пути" и общих CI/CD конвейеров. Дополнять опросами удовлетворенности разработчиков (в стиле NPS).
Почему: Высокий уровень внедрения опциональных, предустановленных функций платформы является сильным сигналом того, что платформа решает реальные проблемы. Низкий уровень внедрения указывает на несоответствие потребностям разработчиков.
Оценить текущее состояние платформы и создать дорожную карту для улучшений.
Использовать модель зрелости платформы для оценки возможностей по нескольким измерениям: например, самообслуживание, наблюдаемость, безопасность, надежность и управление. Определить уровни от ad-hoc/ручного до полностью автоматизированного и оптимизированного.
Почему: Модель зрелости предоставляет структурированную основу для самооценки, помогает выявить слабые места и согласовывает команду в стратегическом видении эволюции платформы.