Microsoft AZ-400: Контейнеризация и Kubernetes — Руководство по подготовке

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Часть Microsoft DevOps Engineer Expert AZ-400 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Контейнеризация и Kubernetes лежат в основе современных практик DevOps в Azure, объединяя воспроизводимые сборки, безопасное распространение и декларативную, самовосстанавливающуюся оркестрацию среды выполнения. Для их освоения необходимо понимать, как собираются и оптимизируются образы, как реестры реплицируют и удостоверяют содержимое, как проектируется и обновляется AKS без прерывания работы, как реализуется прогрессивная доставка и как обеспечивается сквозная безопасность рабочих нагрузок. Помимо «чистого» Kubernetes, вы будете использовать Helm для упаковки, GitOps для согласования состояния, а в бессерверной среде — Azure Container Apps с Dapr и KEDA для упрощения шаблонов микросервисов и масштабирования на основе событий. В следующих разделах кратко изложены ключевые решения по выбору платформы и операционные практики, необходимые для реализации надежных, соответствующих требованиям конвейеров и отказоустойчивых производственных кластеров.

Основы сборки и реестров: Docker и ACR

Создание производительного образа контейнера начинается с детерминированного Dockerfile и грамотно организованного контекста сборки. Многоэтапные сборки (multi-stage builds) позволяют отделить этапы компиляции, требующие большого набора инструментов, от компактных образов среды выполнения. Например, можно скомпилировать бинарный файл .NET или Go на этапе сборщика (builder stage), а затем скопировать только скомпилированный артефакт в минимальный или distroless базовый образ (например, mcr.microsoft.com/dotnet/runtime-deps или gcr.io/distroless/base), что уменьшает поверхность атаки и ускоряет загрузку образа. Каждая команда RUN, COPY и ADD создает слой; реструктурируйте Dockerfile, чтобы максимизировать попадания в кэш слоев, размещая редко изменяемые шаги в конце и объединяя команды с логической группировкой, сохраняя при этом читаемость. Всегда включайте файл .dockerignore для исключения каталогов bin/obj, node_modules, тестов, документации и секретов; слишком большой контекст сборки замедляет загрузку и снижает эффективность удаленного кэша. Используйте детерминированную установку пакетов (с фиксацией версий, lock-файлы) и аккуратно применяйте аргументы сборки; файлы, специфичные для окружения, должны передаваться через конфигурацию во время выполнения, а не встраиваться в неизменяемые образы.

Azure Container Registry (ACR) — это основа для хранения и распространения образов. Используйте ACR Tasks, чтобы перенести сборки в Azure: быстрые задачи для сборок по требованию (az acr run), автоматизированные задачи, запускаемые по коммитам в Git, обновлениям базового образа или расписанию, а также многошаговые задачи в формате Task YAML для создания мультиархитектурных образов с помощью Buildx. Георепликация (SKU «Премиум») зеркалирует артефакты между регионами, минимизируя задержку при загрузке (pull latency) и затраты на исходящий трафик для развертываний AKS/ACA в нескольких регионах; сочетайте ее с приватными конечными точками (private endpoints) и RBAC на уровне репозитория для соблюдения принципа наименьших привилегий. Включите доверие к содержимому (content trust) для подписи образов и проверки их происхождения: Docker Content Trust/Notary и развивающиеся экосистемы подписей OCI (например, cosign) можно принудительно применять на этапе приема (admission) с помощью ограничений OPA Gatekeeper, требующих наличия подписей для защищенных пространств имен. Интегрируйте сканирование уязвимостей: Microsoft Defender for Cloud сканирует образы при отправке (push) и в состоянии покоя, выявляет CVE с рекомендациями по исправлению и может блокировать развертывания с помощью Azure Policy и проверок в CI; внедрите автоматизацию обновления базовых образов, чтобы уменьшить количество слоев с известными уязвимостями.

Платформа AKS и доставка рабочих нагрузок

Создавайте кластеры AKS с безопасными по умолчанию настройками: управляемое удостоверение, интеграция с Azure AD для RBAC, Azure CNI для интеграции с VNET, сетевая политика (Azure или Calico), провайдер Azure Key Vault (Secrets Store CSI) для использования секретов и приватные кластеры с авторизованными диапазонами IP-адресов. Выбирайте пулы узлов, соответствующие рабочей нагрузке: системные пулы для критически важных компонентов плоскости управления; пользовательские пулы для приложений; пулы с GPU для ML; spot-пулы для экономичных задач без состояния; пулы узлов Windows для контейнеров Windows. Используйте taints/tolerations и topology spread constraints для управления расписанием и отказоустойчивостью. Автоматически масштабируйте с помощью cluster autoscaler и Horizontal Pod Autoscaler для каждого развертывания; рассмотрите использование эфемерных дисков ОС и зон доступности для повышения производительности и отказоустойчивости.

Планируйте обновления так, чтобы минимизировать сбои. AKS сначала обновляет плоскость управления, а затем пулы узлов. Используйте max-surge при обновлении пулов узлов, чтобы добавить дополнительную емкость, корректно осушать узлы (drain) и соблюдать PodDisruptionBudgets. Используйте каналы автоматического обновления (rapid/stable/patch-only) для предсказуемого ритма; разделяйте обновления системных и пользовательских пулов, чтобы ограничить радиус поражения (blast radius). Регулярно обновляйте образы узлов, чтобы получать исправления ядра/среды выполнения даже без повышения версии Kubernetes, и закрепляйте совместимые версии CNI/CSI. Используйте blue-green пулы узлов для изменений платформы без простоев — выполняйте cordon/drain для «зеленого» пула, перенося нагрузку на «синий», и переключайтесь с помощью nodeSelector/affinity.

Deployments в Kubernetes нативно поддерживают плавающие обновления (rolling updates) с параметрами maxUnavailable и maxSurge для поддержания емкости во время развертывания; используйте их в паре с readiness/liveness и startup probes, чтобы предотвратить преждевременную подачу трафика. Blue-green развертывание в Kubernetes реализуется путем запуска параллельных Deployments («синего» и «зеленого») и переключения селектора стабильного Service или объекта Endpoint на целевую ревизию; это обеспечивает почти мгновенный откат путем смены меток. Канареечное развертывание (canary delivery) лучше всего выполнять на уровне ingress: NGINX Ingress поддерживает взвешенное канареечное развертывание через аннотации; Application Gateway Ingress Controller (AGIC) может разделять трафик между бэкендами; сервисные сетки (service mesh) обеспечивают переключение трафика с гранулярными политиками и телеметрией. Для надежных конвейеров выполняйте проверку с помощью дымовых тестов (smoke tests) и проверок доступности App Insights перед повышением веса.

Helm упаковывает манифесты Kubernetes в чарты (charts), состоящие из Chart.yaml, шаблонов и файла values.yaml по умолчанию. Файлы values накладываются детерминированно; используйте оверлеи вида values.<env>.yaml и блок “global” для настроек, общих для нескольких подчартов. Предпочтительно использовать Helm 3 с хранением чартов в ACR на базе OCI (helm registry login && helm push oci://…), что обеспечивает RBAC и георепликацию наравне с образами. В Azure Pipelines устанавливайте Helm определенной версии (HelmInstaller) и развертывайте (HelmDeploy) через service connection типа Kubernetes/Azure Resource Manager; проверка (linting) шаблонов, а также dry-run и diff (плагин helm diff) должны служить барьером для релизов. Избегайте коммита секретов в файлы values; интегрируйте external-secrets или CSI Key Vault для материализации секретов во время выполнения. Версионируйте чарты семантически и закрепляйте appVersion за дайджестом образа для отслеживаемости.

Эксплуатация, безопасность и управление трафиком

GitOps с использованием Flux или Argo CD обеспечивает непрерывное приведение кластеров к заявленному состоянию. Flux v2 нативно интегрируется с AKS через Azure CLI/расширение, сверяя (reconciling) источники (Sources: Git/OCI/Bucket) и Kustomizations с определенным интервалом, и включает автоматизацию образов для обновления Helm/Kustomize до новых тегов на основе политик. Argo CD отслеживает приложения (Applications) и их состояние, поддерживает SSO с Azure AD и может работать в pull-моделях и по принципу «приложение из приложений» (app-of-apps) для разделения мультиарендных сред. Оба инструмента обнаруживают дрейф конфигурации и могут автоматически его исправлять, генерировать события/оповещения и поддерживать прогрессивную доставку; используйте их в паре с Flagger для автоматизации канареечных развертываний и A/B-тестов с помощью NGINX, Istio или Linkerd, повышая трафик на основе метрик и выполняя откат при нарушении SLO.

Безопасность начинается в цепочке поставок и обеспечивается на этапах admission (приема) и runtime (выполнения). Непрерывно сканируйте образы с помощью Defender for Cloud и встраивайте проверки (gates) в CI/CD. Внедряйте Kubernetes Pod Security Standards (baseline/restricted) с метками Pod Security Admission на пространствах имен, чтобы по умолчанию блокировать привилегированные поды, hostPath и небезопасные sysctls. Применяйте организационные политики с помощью OPA Gatekeeper: шаблоны ограничений (constraint templates) запрещают привилегированные контейнеры, требуют использования одобренных реестров, принудительно устанавливают лимиты ресурсов и требуют наличия подписанных образов или SBOM. Применяйте сетевые политики для определения разрешенного трафика между подами и исходящего трафика; AKS поддерживает Azure Network Policies (с Azure CNI) и Calico. Дополняйте это контролем исходящего трафика через Azure Firewall или NVA и входящего трафика через Application Gateway WAF. Усиливайте безопасность рабочих нагрузок, используя пользователей без прав root, файловые системы только для чтения, профили seccomp и AppArmor, а также регулярно обновляя образы узлов. Включите аудит и обнаружение угроз через Defender for Kubernetes и собирайте телеметрию в Azure Monitor Container Insights; стандартизируйте логи/трассировки с помощью OpenTelemetry.

Сервисная сетка (service mesh), такая как Istio или Linkerd, добавляет унифицированное управление трафиком, шифрование и наблюдаемость (observability). Используйте DestinationRules/VirtualServices (Istio) или ServiceProfiles (Linkerd) для определения повторных попыток, тайм-аутов, размыкания цепи (circuit breaking) и взвешенной маршрутизации. Включите взаимную аутентификацию TLS (mTLS) для шифрования и идентификации между сервисами; применяйте политики, такие как “STRICT” mTLS, чтобы устранить пробелы в безопасности. Экспортируйте метрики в Prometheus и дашборды в Grafana; собирайте распределенные трассировки (Jaeger/Zipkin) и передавайте их в Application Insights или Azure Monitor через коллекторы OpenTelemetry. Канареечные развертывания на основе сетки и внедрение сбоев (fault injection) обеспечивают надежное тестирование и прогрессивную доставку, при этом Flagger автоматизирует анализ на соответствие SLO.

Повышение производительности разработчиков и бессерверные контейнеры в Azure

Инструменты интеграции DevOps в AKS оптимизируют внутренние циклы разработки. Draft определяет языковые фреймворки и создает шаблоны для Dockerfiles, Helm-чартов и конфигураций запуска, ускоряя контейнеризацию. Bridge to Kubernetes перенаправляет вызовы служб из работающего кластера на вашу локальную рабочую станцию, позволяя итерировать и отлаживать один микросервис локально, в то время как остальные работают в кластере с реальными данными и зависимостями. Служба Azure Dev Spaces была упразднена; Bridge to Kubernetes является поддерживаемым решением для локальной разработки и интегрируется с VS Code и Visual Studio.

Azure Container Apps (ACA) предлагает бессерверную, полностью управляемую среду выполнения для микросервисов и заданий без необходимости управлять Kubernetes. Каждое развертывание создает ревизию; вы можете распределять трафик между ревизиями в процентном соотношении для сине-зеленых или канареечных развертываний с помощью одной команды или изменения в YAML. Встроенная интеграция с Dapr обеспечивает вызов сервисов, pub/sub, привязки, хранилища состояний и секретов без написания специального кода; подключаемые компоненты (например, Azure Service Bus, Key Vault, Cosmos DB) ускоряют реализацию согласованных межсервисных возможностей. KEDA обеспечивает автомасштабирование на основе событий, таких как количество одновременных HTTP-запросов, и поддерживает более 60 модулей масштабирования (Azure Queue/Service Bus, Kafka, Prometheus, пользовательские), позволяя масштабироваться до нуля для экономии затрат. Используйте среды ACA Environments для сетевой изоляции и интеграции с VNET, подключайте ACR через управляемое удостоверение и управляйте конфигурацией с помощью YAML-файлов containerapps для поддержания декларативного соответствия практикам GitOps.

Практический сценарий

Компании Adobe необходимо модернизировать многорегиональный сервис аналитики клиентов, снизив риски выпуска релизов и одновременно усилив безопасность цепочки поставок и среды выполнения. Команда должна стандартизировать сборки, автоматизировать безопасные развертывания и обеспечить быструю доставку в соответствии с требованиями в регионах США и ЕС.

Внедрить многоэтапные Dockerfiles и файлы .dockerignore для всех сервисов

Зачем: Минимизирует размер образа и поверхность атаки, улучшает попадания в кэш сборки и предотвращает случайное включение в образ секретов или больших тестовых данных.

Собирать и подписывать образы с помощью ACR Tasks, отправлять в геореплицированный ACR

Зачем: Сборки в облаке устраняют различия локальных сред; триггеры на обновление базового образа снижают риски уязвимостей CVE. Георепликация в Premium ACR размещает артефакты рядом с кластерами AKS, уменьшая задержки и исходящий трафик. Подписи обеспечивают подтверждение происхождения.

Включить сканирование образов в Defender for Cloud и применять политики через шлюзы CI и OPA Gatekeeper

Зачем: Сканирование при отправке и в состоянии покоя позволяет выявлять уязвимости CVE на ранней стадии. Ограничения Gatekeeper обеспечивают соблюдение политик, таких как «только одобренные реестры», «требуются подписанные образы» и лимиты ресурсов, предотвращая допуск небезопасных рабочих нагрузок.

Подготовить приватные кластеры AKS в каждом регионе с Azure CNI, сетевыми политиками и управляемым удостоверением

Зачем: Приватные конечные точки ограничивают доступ к плоскости управления; Azure CNI интегрируется с корпоративными VNET; сетевые политики ограничивают горизонтальное перемещение; управляемое удостоверение устраняет разрастание секретов.

Создать отдельные системные и пользовательские пулы узлов, добавить пулы спотовых узлов для пакетных заданий

Зачем: Изолирует критически важные системные поды, предоставляет экономичную вычислительную мощность для некритичных нагрузок и упрощает обновления и управление SLO.

Использовать Helm для упаковки, хранить чарты в ACR (OCI), развертывать через Azure Pipelines

Зачем: Обеспечивает согласованные, версионированные релизы с отдельными значениями для каждой среды. Конвейеры выполняют helm lint, dry-run и diff перед helm upgrade, используя подключение службы Kubernetes для целевых кластеров.

Развернуть Flux v2 для сверки и обнаружения расхождений в GitOps, интегрировать Flagger для канареечных развертываний

Зачем: Декларативная синхронизация на основе запросов (pull-based) уменьшает количество учетных данных в CI и обеспечивает сходимость состояния. Flagger автоматизирует взвешенные канареечные развертывания на основе SLO, используя метрики NGINX Ingress, и выполняет откат при ошибках или всплесках задержки.

Настроить поэтапные обновления (rolling updates) с PDB и пробами готовности/запуска (readiness/startup probes); использовать сине-зеленое развертывание для рискованных компонентов

Зачем: Поэтапные обновления сохраняют производительность; пробы защищают пользовательский трафик. Сине-зеленое развертывание с переключением меток в Service обеспечивает мгновенный откат для компонентов с высоким риском, таких как API-шлюз.

Внедрить сервисную сетку Istio со строгим mTLS, повторными попытками и таймаутами; экспортировать телеметрию в Application Insights

Зачем: Шифрование в масштабе всей сетки, надежные политики трафика и единая наблюдаемость. Коллекторы OpenTelemetry отправляют трассировки/метрики в центральное хранилище для мониторинга SLO и анализа инцидентов.

Создать контролируемую стратегию обновлений с помощью канала автообновления AKS и обновлений образов узлов

Зачем: Регулярные, предсказуемые обновления платформы снижают риски уязвимостей нулевого дня. Параметр max-surge и PDB обеспечивают минимальные сбои; обновление пользовательских пулов по отдельности ограничивает радиус поражения.

Использовать Bridge to Kubernetes для внутреннего цикла разработки; создавать шаблоны с помощью Draft

Зачем: Разработчики отлаживают код локально, используя зависимости из кластера без необходимости их имитации. Draft ускоряет создание согласованных шаблонов для контейнеризации и Helm в разных командах.

Перенести второстепенные сервисы в Azure Container Apps с использованием Dapr и KEDA

Зачем: Управляемые событиями микросервисы (например, для приема и обогащения данных), масштабируемые до нуля, работают с низкими затратами и имеют встроенное разделение трафика для канареечных развертываний; компоненты Dapr стандартизируют межсервисные вызовы и pub/sub без написания специального кода.

Это комплексное решение сочетает детерминизм сборок с безопасным распространением, декларативными операциями и прогрессивной доставкой, обеспечивая Adobe быстрые релизы с низким риском и защищенную среду выполнения в разных регионах.

← Инфраструктура как код и управление конфигурацией · Все домены · Управление релизами и стратегии развертывания →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →