Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене CNPE. Читайте сверху вниз или переходите к нужному разделу.
Предоставление и управление мультиоблачной инфраструктурой с использованием декларативных API, нативных для Kubernetes.
Используйте Crossplane. Установите CRD облачных провайдеров (например, provider-aws). Определите абстракции платформы с помощью Composition и CompositeResourceDefinition (XRD).
Почему: Объединяет управление приложениями и инфраструктурой под единой плоскостью управления и рабочим процессом GitOps, абстрагируя специфику провайдеров от разработчиков.
Декларативное управление жизненным циклом (создание, обновление, удаление) нескольких кластеров Kubernetes у разных провайдеров.
Внедрите Cluster API (CAPI) с соответствующими поставщиками инфраструктуры (например, CAPA для AWS, CAPZ для Azure). Определите кластеры как ресурсы Kubernetes в кластере управления.
Почему: Рассматривает жизненный цикл кластера как код, обеспечивая GitOps для самих кластеров. CAPI MachineHealthChecks предоставляют автоматическое восстановление узлов.
Обеспечение сильной изоляции между рабочими нагрузками арендаторов на общей платформе Kubernetes.
Объедините выделенные пулы узлов (вычисления), NetworkPolicies (сеть), RBAC (API), ResourceQuotas (ресурсы) и Pod Security Standards (безопасность). Рассмотрите виртуальные кластеры (vCluster) для изоляции плоскости управления.
Почему: Требуется стратегия многоуровневой защиты. Ни одна функция не обеспечивает полной изоляции. Каждый уровень затрагивает различные аспекты многопользовательской среды.
Управление конфигурациями и рабочими нагрузками для большого количества нижестоящих кластеров из центральной точки.
Назначьте "hub" кластер для размещения инструментов плоскости управления платформы (ArgoCD, Flux, Crossplane, механизмы политик). "Spoke" кластеры запускают рабочие нагрузки и управляются из хаба.
Почему: Централизует управление, применение политик и наблюдаемость, упрощая операции с несколькими кластерами и обеспечивая согласованность.
Предоставление командам разработчиков изолированных сред, похожих на кластер-администратор, без накладных расходов физических кластеров.
Используйте vCluster. Каждый vCluster запускает отдельную плоскость управления K8s в виде подов в пространстве имен хост-кластера, используя общие рабочие узлы хоста.
Почему: Предлагает сильную изоляцию на уровне API по более низкой цене, чем полноценные кластеры. Синхронизатор vCluster материализует необходимые ресурсы на хост-кластере.
Обеспечение аварийного восстановления для stateful рабочих нагрузок с низким RPO/RTO.
Используйте драйвер CSI, который поддерживает синхронную или асинхронную репликацию данных между регионами/кластерами (например, Rook-Ceph, Portworx).
Почему: Репликация критически важна для доступности данных в случае регионального сбоя. Локальные снимки или высокопроизводительные уровни не решают проблему DR между сайтами.
Повышение доступности приложения путем распределения реплик по доменам отказа.
Используйте Pod Topology Spread Constraints в спецификациях рабочих нагрузок. Определите `topologyKey` (например, `topology.kubernetes.io/zone`) и `whenUnsatisfiable: ScheduleAnyway` или `DoNotSchedule`.
Почему: Предотвращает планирование всех реплик сервиса в одной зоне или на одном узле, смягчая воздействие локализованных сбоев инфраструктуры.
Управление политиками и RBAC для команд с иерархическими организационными структурами.
Внедрите Hierarchical Namespace Controller (HNC). Создайте отношения родитель-потомок для пространств имен, чтобы распространять RBAC, NetworkPolicies и ResourceQuotas.
Почему: HNC упрощает управление, позволяя администраторам платформы устанавливать политики на уровне команды/организации (родительское пространство имен), которые автоматически наследуются всеми подпространствами имен.
Внедрение продвинутых автоматизированных стратегий развертывания, таких как canary или blue-green, с анализом на основе метрик и откатом.
Используйте Argo Rollouts. Определите ресурс Rollout со стратегией (например, canary), которая включает конфигурацию маршрутизации трафика (для service mesh) и AnalysisTemplate, ссылающийся на поставщика метрик, такого как Prometheus.
Почему: Отделяет развертывание от логики приложения. Автоматизирует переключение трафика и анализ, безопасно продвигая релизы и автоматически откатываясь при сбое, снижая риск развертывания.
Управление секретами в рабочем процессе GitOps без хранения учетных данных в открытом виде в Git.
Используйте Sealed Secrets (шифрует секреты для конкретного кластера) или External Secrets Operator (синхронизирует из Vault, менеджеров секретов AWS/GCP/Azure). Коммитьте только зашифрованный секрет или ссылочный ресурс в Git.
Почему: Хранит конфиденциальные данные вне Git, позволяя управлять секретами декларативно как частью рабочего процесса GitOps, поддерживая единый источник истины.
Автоматизация создания и управления приложениями ArgoCD для нескольких кластеров, сред или микросервисов.
Используйте ApplicationSet. Определите шаблон для приложения и используйте генератор (например, cluster, git, matrix) для динамического создания приложений на основе списков кластеров, каталогов Git или других источников.
Почему: Исключает ручное создание приложений, обеспечивая масштабируемое управление сотнями приложений или кластеров из одной определения.
Предоставление разработчикам эфемерных сред предварительного просмотра для тестирования изменений в pull request.
Используйте ArgoCD ApplicationSet с генератором Pull Request. Он автоматически создает приложение при открытии PR и удаляет его при закрытии/слиянии PR.
Почему: Позволяет разработчикам проверять изменения в живой среде перед слиянием, улучшая качество кода и уменьшая проблемы интеграции, без ручного управления средой.
Управление большим, сложным набором приложений и компонентов платформы с помощью ArgoCD структурированным образом.
Внедрите шаблон App-of-Apps. Корневое приложение управляет другими дочерними приложениями, которые, в свою очередь, могут управлять другими приложениями, создавая иерархическую структуру.
Почему: Предоставляет единую точку входа для начальной загрузки кластера или среды, одновременно позволяя модульное, командное управление отдельными наборами приложений.
Обеспечение развертывания ресурсов в правильном порядке (например, CRD перед CR, инфраструктура перед приложениями).
В ArgoCD используйте Sync Waves и проверки состояния ресурсов. В Flux используйте `dependsOn` в ресурсах Kustomization или HelmRelease.
Почему: Декларативные системы по умолчанию применяют ресурсы параллельно. Для управления зависимостями между ресурсами требуются явные механизмы упорядочивания.
Реализация полного конвейера GitOps с использованием Flux.
Объедините контроллеры Flux: Source Controller (для источников Git/Helm/OCI), Kustomize Controller (для применения манифестов) и Helm Controller (для HelmReleases). Используйте Notification Controller для оповещений.
Почему: Flux - это компонуемый набор специализированных контроллеров. Понимание роли каждого из них является ключом к созданию и устранению неполадок непрерывной доставки на основе Flux.
Обеспечение постоянного соответствия текущего состояния кластера желаемому состоянию в Git, отменяя любые ручные изменения.
Настройте приложение ArgoCD с `syncPolicy.automated.selfHeal: true`. ArgoCD обнаружит расхождение и автоматически синхронизируется, чтобы отменить несанкционированные изменения.
Почему: Самовосстановление является основным принципом GitOps, который обеспечивает Git как единый источник истины и предотвращает дрейф конфигурации, что критически важно для соответствия требованиям и стабильности.
Продвижение версий приложений между средами (dev -> staging -> prod) с надлежащим аудитом и этапами утверждения.
Используйте отдельные каталоги или ветки для каждой среды в Git. Продвигайте изменения, создавая pull-запросы (например, из ветки/каталога staging в prod). Применяйте проверку PR.
Почему: Использует Git для аудита и утверждений. Процесс PR становится формальным этапом продвижения, гарантируя проверку изменений перед достижением продакшена.
Реализация многопользовательской среды в общем экземпляре ArgoCD, ограничивая команды их собственными ресурсами.
Создайте проекты ArgoCD для каждой команды. Настройте проекты для ограничения исходных репозиториев Git, целевых кластеров/пространств имен и разрешенных типов ресурсов. Интегрируйте с SSO и сопоставьте группы с ролями проекта.
Почему: Проекты являются основным механизмом для многопользовательской изоляции и RBAC в ArgoCD, обеспечивая безопасное развертывание приложений самообслуживания.
Разработка API самообслуживания для разработчиков для предоставления инфраструктуры без необходимости облачных знаний.
Определите высокоуровневый API с помощью CompositeResourceDefinition (XRD). Реализуйте API с помощью Composition, которая сопоставляет высокоуровневые поля с базовыми управляемыми ресурсами. Разработчики взаимодействуют с простым Composite Resource Claim (XRC).
Почему: Эта трехслойная модель (Claim -> Composition -> Managed Resource) отделяет пользовательский API от реализации, обеспечивая чистую абстракцию и позволяя управлять платформой.
Предоставление разработчикам возможности декларативно запускать новые проекты, микросервисы или инфраструктуру в соответствии с организационными стандартами.
Создавайте шаблоны программного обеспечения Backstage. Шаблон определяет входные параметры (пользовательский интерфейс формы) и серию действий по созданию каркаса (например, получение скелета, создание репозитория Git, регистрация в каталоге).
Почему: Автоматизирует рабочие процессы "золотого пути", снижая когнитивную нагрузку разработчиков, обеспечивая согласованность и ускоряя настройку проекта с минут до секунд.
Создание единого централизованного места для обнаружения всего программного обеспечения, сервисов, API и их владельцев в организации.
Внедрите каталог программного обеспечения Backstage. Импортируйте дескрипторы сущностей `catalog-info.yaml` из репозиториев Git для построения графа программных компонентов и их взаимосвязей с возможностью поиска.
Почему: Каталог является ядром IDP, обеспечивая обнаруживаемость и основу для других функций, таких как TechDocs, документация API и видимость статуса CI/CD.
Оператору Kubernetes необходимо очищать внешние ресурсы (например, облачное хранилище, записи DNS) при удалении Custom Resource.
Используйте финализаторы. В контроллере добавьте финализатор к CR при создании. В цикле согласования, если установлен `deletionTimestamp`, выполните логику очистки, а затем удалите финализатор.
Почему: Финализаторы предотвращают удаление ресурса Kubernetes до тех пор, пока контроллер не завершит свои задачи очистки, предотвращая появление потерянных внешних ресурсов.
Предоставление рабочим нагрузкам Kubernetes безопасного, кратковременного доступа к API облачных провайдеров без управления статическими учетными данными.
Используйте решения Workload Identity облачных провайдеров (AWS IRSA, GCP Workload Identity, Azure Workload Identity). Это связывает ServiceAccount Kubernetes с облачной ролью IAM, позволяя подам получать временные учетные данные.
Почему: Устраняет риск долгоживущих статических учетных данных. Это самый безопасный шаблон для предоставления облачных разрешений подам.
Передача состояния и прогресса согласования пользовательского ресурса обратно пользователям и средствам автоматизации.
Включите подресурс статуса в определении CRD. Контроллер должен обновлять статус условиями (например, `Type: Ready`, `Status: True`) и наблюдаемым состоянием.
Почему: Отделяет желаемое состояние (spec) от наблюдаемого состояния (status). Предоставляет стандартный, наблюдаемый механизм для клиентов для понимания работоспособности и готовности ресурса.
Развитие API платформы (CRD) без нарушения работы существующих клиентов или пользователей.
Следуйте соглашениям о версионировании API Kubernetes (v1alpha1 -> v1beta1 -> v1). При внесении ломающих изменений создайте новую версию и реализуйте вебхук преобразования для трансляции между хранимыми и обслуживаемыми версиями.
Почему: Вебхуки преобразования позволяют серверу API одновременно обслуживать несколько версий ресурса, сохраняя при этом единую версию хранения, что обеспечивает плавное развитие API.
Создание действенных оповещений на основе целевых показателей надежности сервиса, которые балансируют чувствительность с предотвращением усталости от оповещений.
Определите SLO и рассчитайте бюджеты ошибок. Внедрите многооконное оповещение с несколькими скоростями сжигания, которое срабатывает, когда скорость потребления бюджета ошибок угрожает SLO.
Почему: Оповещение о сжигании бюджета ошибок более значимо, чем простые пороговые оповещения. Оно напрямую связывает оповещения с влиянием на пользователей и нарушениями SLO.
Внедрение независимого от поставщика, унифицированного конвейера для сбора, обработки и экспорта сигналов наблюдаемости (трассировок, метрик, логов).
Разверните OpenTelemetry Collector. Настройте конвейеры с ресиверами (например, OTLP, Jaeger), процессорами (например, batch, attributes) и экспортерами (например, Prometheus, Loki, Tempo, серверные части поставщиков).
Почему: Отделяет инструментирование от серверной части наблюдаемости, позволяя платформе переключать или добавлять серверные части без повторного инструментирования приложений. Предоставляет центральную точку для обработки и обогащения.
Декларативная настройка Prometheus для обнаружения и сбора метрик из рабочих нагрузок Kubernetes.
Используйте Prometheus Operator. Создайте пользовательские ресурсы `ServiceMonitor` или `PodMonitor`, которые используют селекторы меток для определения того, какие сервисы или поды Prometheus должен опрашивать.
Почему: Предоставляет нативный для Kubernetes способ управления конфигурациями опроса, легко интегрируясь с развертываниями приложений и рабочими процессами GitOps.
Во время расследования инцидента быстро переходить от аномальной метрики (например, всплеска задержки) к конкретным запросам, которые ее вызвали.
Используйте Prometheus exemplars. Инструментируйте приложения для прикрепления идентификаторов трассировки к наблюдениям метрик. Настройте Prometheus и Grafana для отображения exemplars, обеспечивая прямые ссылки от метрик к трассировкам в бэкенде трассировки, таком как Tempo или Jaeger.
Почему: Резко сокращает MTTR, напрямую связывая "что" (метрика) с "почему" (трассировка), исключая ручные усилия по корреляции.
Создание базовой линии для мониторинга работоспособности любого пользовательского или критически важного сервиса.
Мониторинг четырех "Золотых Сигналов": Latency (время отклика), Traffic (запросы в секунду), Errors (частота неудачных запросов) и Saturation (использование ресурсов).
Почему: Эти четыре сигнала предоставляют всесторонний, высокоуровневый обзор работоспособности сервиса и пользовательского опыта, применимый практически к любому виду сервиса.
Предоставление командам информации о стоимости их рабочих нагрузок Kubernetes для возмещения затрат или отображения затрат.
Разверните инструмент с открытым исходным кодом, такой как OpenCost или Kubecost. Эти инструменты распределяют облачные затраты по ресурсам Kubernetes (поды, пространства имен, метки) на основе их запросов и использования ресурсов.
Почему: Преобразует счета за инфраструктуру в значимые, ориентированные на приложения данные о затратах, позволяя командам понимать и оптимизировать потребление ресурсов.
Уменьшение шума оповещений во время крупномасштабных сбоев путем подавления симптоматических оповещений.
Настройте `inhibit_rules` в Alertmanager. Например, подавляйте все оповещения для конкретного кластера, если уже срабатывает оповещение "ClusterUnreachable".
Почему: Предотвращает "шторм оповещений" путем подавления низкоприоритетных оповещений, которые являются симптомами высокоприоритетного оповещения о первопричине, позволяя дежурным сосредоточиться на реальной проблеме.
Проактивное тестирование отказоустойчивости платформы и приложений путем контролируемого внедрения сбоев.
Используйте инструмент хаос-инжиниринга, такой как Chaos Mesh или Litmus. Определите эксперименты с ограниченным радиусом поражения (например, конкретные пространства имен или метки) и автоматическими условиями остановки на основе SLO или критических метрик.
Почему: Выходит за рамки реактивного реагирования на инциденты, проактивно находя слабые места в системе до того, как они вызовут сбои в производстве.
Выбор механизма политик для обеспечения защитных мер на платформе Kubernetes.
Выберите Kyverno для нативных для Kubernetes политик на основе YAML или OPA/Gatekeeper для более мощного, универсального языка политик (Rego).
Почему: Kyverno имеет более низкий порог входа для инженеров Kubernetes. OPA/Gatekeeper более гибок и может использоваться вне Kubernetes, но имеет более крутую кривую обучения.
Реализация политик платформы, которые могут блокировать несоответствующие ресурсы, добавлять значения по умолчанию или автоматически создавать связанные ресурсы.
Используйте механизм политик, такой как Kyverno. Используйте правила `validate` для блокировки/аудита, правила `mutate` для добавления значений по умолчанию (например, securityContext, labels) и правила `generate` для создания ресурсов (например, NetworkPolicy по умолчанию).
Почему: Различные типы политик служат разным целям. Их объединение позволяет разработать надежную, многогранную стратегию управления, которая как принуждает, так и помогает пользователям соблюдать требования.
Обеспечение базовой защиты для всех подов, работающих на платформе.
Используйте Pod Security Standards (PSS) через встроенный контроллер Pod Security Admission. Помечайте пространства имен метками `pod-security.kubernetes.io/enforce=baseline` или `restricted`.
Почему: PSS предоставляет стандартизированный, встроенный механизм для предотвращения распространенных проблем безопасности, таких как повышение привилегий и доступ к пространству имен хоста, формируя базовый уровень безопасности.
Обеспечение того, что только доверенные образы контейнеров, созданные официальным конвейером CI/CD, могут быть развернуты в кластере.
Реализуйте подписание образов в CI с использованием Sigstore/Cosign. Используйте механизм политик (Kyverno, Gatekeeper) в качестве контроллера допуска для проверки подписей образов по доверенному ключу, прежде чем разрешить создание пода.
Почему: Криптографическая проверка обеспечивает надежные гарантии происхождения и целостности образов, предотвращая развертывание поддельных или несанкционированных образов.
Реализация модели безопасности с нулевым доверием, где связь между сервисами аутентифицируется криптографической идентификацией рабочей нагрузки, а не сетевым местоположением.
Используйте SPIFFE/SPIRE для выдачи кратковременных, ротируемых криптографических идентификаторов (SVID) рабочим нагрузкам. Примените взаимный TLS (mTLS) с использованием service mesh, который проверяет SVID при каждом запросе.
Почему: Переносит безопасность с контроля периметра сети на идентификацию, ориентированную на рабочую нагрузку, обеспечивая сильную аутентификацию даже для внутреннего трафика и ограничивая радиус поражения скомпрометированного узла или пода.
Изоляция рабочих нагрузок на сетевом уровне, принудительное применение политики "запрета по умолчанию" и разрешение только необходимых путей связи.
Внедрите Kubernetes NetworkPolicies. Примените политику "запрета по умолчанию" к каждому пространству имен, затем добавьте специфические политики ingress/egress, которые разрешают трафик на основе меток подов/пространств имен.
Почему: Уменьшает поверхность атаки бокового перемещения. Компрометация одного пода не автоматически предоставляет сетевой доступ ко всем другим сервисам в кластере.
Создание всеобъемлющего и защищенного от подделки аудиторского следа всех действий, выполненных на сервере API Kubernetes, для обеспечения безопасности и соответствия требованиям.
Включите аудит логирования Kubernetes на сервере API. Настройте политику аудита для логирования соответствующих событий (например, всех запросов на запись). Отправляйте аудиторские логи в безопасное, неизменяемое хранилище или SIEM.
Почему: Аудиторские логи необходимы для расследования инцидентов, отчетности о соответствии требованиям (например, PCI-DSS, SOC2) и обнаружения аномальной активности API.