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 是 Azure 上现代 DevOps 的基石，它们结合了可复现的构建、安全的分发以及声明式的、自愈的运行时编排。要精通这些技术，需要理解镜像是如何组装和优化的，注册表是如何复制和验证内容的，AKS 是如何设计和无中断升级的，渐进式交付是如何实现的，以及如何端到端地保护工作负载。除了原生的 Kubernetes，您还将利用 Helm 进行打包，利用 GitOps 进行对账，并在无服务器领域利用带有 Dapr 和 KEDA 的 Azure Container Apps 来简化微服务模式和事件驱动的扩展。以下各节提炼了您在实现健壮、合规的流水线和有弹性的生产集群时所需的平台决策和运维实践。

构建与注册表基础：Docker 和 ACR

一个高性能的容器镜像始于一个确定性的 Dockerfile 和一个规范的构建上下文。多阶段构建让您可以将包含繁重工具链的编译阶段与小巧的运行时镜像分离开来。例如，在一个构建器阶段编译 .NET 或 Go 二进制文件，然后仅将编译后的产物复制到一个 distroless 或最小化的基础镜像中（例如，mcr.microsoft.com/dotnet/runtime-deps 或 gcr.io/distroless/base），从而产生更小的攻击面和更快的拉取速度。每一个 RUN、COPY 和 ADD 都会创建一个层；通过将不经常变化的步骤放在后面，并在保持可读性的同时通过逻辑分组聚合命令，来重构 Dockerfile 以最大化利用层缓存。始终包含一个 .dockerignore 文件来排除 bin/obj、node_modules、测试、文档和密钥；过大的构建上下文会减慢上传速度并降低远程缓存的有效性。谨慎使用确定性的包安装（版本锁定、锁文件）和构建参数；特定于环境的文件应该通过运行时配置注入，而不是固化在不可变的镜像中。

Azure Container Registry (ACR) 是镜像存储和分发的支柱。利用 ACR Tasks 将构建任务卸载到 Azure：用于按需构建的快速任务 (az acr run)、由 Git 提交、基础镜像更新或计划任务触发的自动化任务，以及使用 Buildx 构建多架构镜像的多步骤任务 YAML。异地复制（Premium SKU）可在多个区域间镜像产物，为多区域的 AKS/ACA 部署最大限度地减少拉取延迟和出口成本；结合使用私有终结点和存储库范围的 RBAC 以实现最小权限原则。启用内容信任来签署镜像并验证其来源：可以通过 OPA Gatekeeper 的约束策略来强制执行 Docker Content Trust/Notary 和不断发展的 OCI 签名生态系统（例如 cosign），要求受保护的命名空间中的镜像必须带有签名。集成漏洞扫描：Microsoft Defender for Cloud 会在镜像推送时和静态存储时对其进行扫描，揭示 CVE 并提供修复指导，并且可以通过 Azure Policy 和 CI 检查来控制部署；引入基础镜像刷新自动化，以减少已知的易受攻击的层。

AKS 平台与工作负载交付

创建具有默认安全设置的 AKS 集群：托管身份、用于 RBAC 的 Azure AD 集成、用于 VNET 集成的 Azure CNI、网络策略（Azure 或 Calico）、用于使用 Secret 的 Azure Key Vault 提供程序 (Secrets Store CSI)，以及具有授权 IP 范围的私有集群。选择适合工作负载的节点池：系统池用于控制平面关键组件；用户池用于应用程序；GPU 池用于机器学习；Spot 池用于节省成本的无状态作业；Windows 节点池用于 Windows 容器。使用污点/容忍 (taints/tolerations) 和拓扑分布约束来控制调度和弹性。使用集群自动伸缩器和每个部署的 Horizontal Pod Autoscaler 进行自动伸缩；考虑使用临时操作系统磁盘和可用区来提升性能和弹性。

规划升级以最大限度地减少中断。AKS 首先升级控制平面，然后升级节点池。在节点池升级时使用 max-surge 来增加激增容量，优雅地排空节点，并遵循 PodDisruptionBudgets。采用自动升级通道（快速/稳定/仅补丁）以获得可预测的节奏；分开升级系统池和用户池以限制爆炸半径。即使没有 Kubernetes 版本升级，也要定期执行节点镜像升级以获取内核/运行时修复，并固定兼容的 CNI/CSI 版本。使用蓝绿节点池实现零停机平台变更——将绿色节点池设置为不可调度 (cordon) 并排空 (drain) 到蓝色节点池，然后通过 nodeSelector/affinity 进行切换。

Kubernetes 中的 Deployment 原生支持带有 maxUnavailable 和 maxSurge 的滚动更新，以在发布期间保持容量；与就绪/存活探针 (readiness/liveness probes) 和启动探针 (startup probes) 配合使用，以防止流量过早进入。Kubernetes 上的蓝绿交付是通过运行并行的 Deployment（蓝色和绿色）并将一个稳定的 Service 选择器或 Endpoint 对象切换到目标版本来实现的；这通过翻转标签实现了近乎即时的回滚。金丝雀交付最好通过 Ingress 在边缘完成：NGINX Ingress 通过注解支持加权金丝雀发布；Application Gateway Ingress Controller (AGIC) 可以在后端之间拆分流量；服务网格提供具有精细策略和遥测的流量转移功能。为构建健壮的流水线，在提升权重之前，使用冒烟测试和 App Insights 可用性检查进行验证。

Helm 将 Kubernetes 清单打包成 chart，chart 由 Chart.yaml、模板和默认的 values.yaml 组成。Values 文件以确定性的方式分层；使用 values.<env>.yaml 覆盖和一个 “global” 块来进行跨子 chart 的设置。推荐使用 Helm 3，并将 chart 存储在由 OCI 支持的 ACR 中 (helm registry login && helm push oci://…)，从而实现与镜像同等的 RBAC 和地理复制能力。在 Azure Pipelines 中，安装一个固定版本的 Helm (HelmInstaller)，并通过 Kubernetes/Azure Resource Manager 服务连接进行部署 (HelmDeploy)；模板检查 (linting) 加上 dry-run 和 diff (helm diff 插件) 应作为发布的门禁。避免将 secret 提交到 values 文件中；集成 external-secrets 或 CSI Key Vault 以在运行时实例化 secret。对 chart 进行语义化版本控制，并将 appVersion 固定到镜像摘要以实现可追溯性。

运维、安全与流量控制

使用 Flux 或 Argo CD 的 GitOps 确保集群持续收敛到声明的状态。Flux v2 通过 Azure CLI/扩展与 AKS 原生集成，按一定间隔协调 Sources (Git/OCI/Bucket) 和 Kustomizations，并包含镜像自动化功能，可根据策略将 Helm/Kustomize 更新到新的标签。Argo CD 跟踪应用程序及其健康状况，支持与 Azure AD 的单点登录 (SSO)，并能以基于拉取 (pull-based) 的 app-of-apps 模型运行，以实现多租户隔离。两者都能检测漂移并自动纠正，发出事件/警报，并支持渐进式交付；与 Flagger 配对以自动化金丝雀发布和 A/B 测试，使用 NGINX、Istio 或 Linkerd，根据指标进行升级，在违反 SLO 时进行回滚。

安全始于供应链，并在准入和运行时强制执行。使用 Defender for Cloud 持续扫描镜像，并在 CI/CD 中设置门禁。采用 Kubernetes Pod 安全标准（基线/受限），并在命名空间上使用 Pod 安全准入标签，以默认阻止特权/hostPath/不安全的 sysctl。使用 OPA Gatekeeper 强制执行组织策略：约束模板禁止特权容器、要求使用经批准的镜像仓库、强制执行资源限制，并要求签名的镜像或 SBOM 的存在。应用网络策略来定义允许的 Pod 到 Pod 以及出口流量；AKS 支持 Azure 网络策略（与 Azure CNI 一起使用）和 Calico。通过 Azure Firewall 或 NVA 出口控制以及 Application Gateway WAF 入口进行补充。通过非 root 用户、只读根文件系统、seccomp 和 AppArmor 配置文件以及定期的节点镜像升级来加固工作负载。通过 Defender for Kubernetes 启用审计和威胁检测，并在 Azure Monitor Container Insights 中聚合遥测数据；使用 OpenTelemetry 标准化日志/跟踪。

服务网格（Istio 或 Linkerd）增加了统一的流量管理、加密和可观察性。使用 DestinationRules/VirtualServices (Istio) 或 ServiceProfiles (Linkerd) 来定义重试、超时、熔断和加权路由。启用双向 TLS (mTLS) 以实现服务到服务的加密和身份认证；强制执行如“严格” (STRICT) mTLS 的策略以弥补安全漏洞。将指标导出到 Prometheus，将仪表板导出到 Grafana；捕获分布式跟踪 (Jaeger/Zipkin)，并通过 OpenTelemetry 收集器将其提供给 Application Insights 或 Azure Monitor。基于网格的金丝雀发布和故障注入为可靠的测试和渐进式交付提供支持，并由 Flagger 根据 SLO 自动进行分析。

Azure 上的开发人员生产力与无服务器容器

AKS DevOps 集成工具可简化开发内循环。Draft 能够检测语言框架并搭建 Dockerfile、Helm chart 和启动配置的脚手架，从而加速容器化进程。Bridge to Kubernetes 将来自线上集群的服务调用重定向到您的本地工作站，让您可以在本地迭代和调试单个微服务，而其余部分则在集群中与真实数据和依赖项一起运行。Azure Dev Spaces 已被弃用；Bridge to Kubernetes 是受支持的本地开发体验，并与 VS Code 和 Visual Studio 集成。

Azure Container Apps (ACA) 为微服务和作业提供了一个无服务器、完全托管的运行时，无需管理 Kubernetes。每次部署都会创建一个修订版本；您可以通过一个命令或 YAML 变更，按百分比在不同修订版本之间路由流量，以实现蓝绿部署或金丝雀式发布。原生的 Dapr 集成支持服务调用、发布/订阅、绑定、状态存储和密钥管理，无需定制化的底层代码；可插拔组件（例如 Azure Service Bus、Key Vault、Cosmos DB）可加速实现一致的跨服务能力。KEDA 支持基于 HTTP 并发和超过 60 种伸缩器（Azure Queue/Service Bus、Kafka、Prometheus、自定义）的事件驱动自动扩缩，并可缩容至零以实现成本效益。使用 ACA Environments 实现网络隔离和 VNET 集成，通过托管身份连接 ACR，并通过 containerapps YAML 管理配置，以保持与 GitOps 实践的声明式对等。

实际问题场景

Adobe 需要对一个多区域的客户分析服务进行现代化改造，在降低发布风险的同时，加强供应链和运行时安全。团队必须标准化构建，自动化安全发布，并确保在美国和欧盟的快速、合规交付。

为所有服务实施多阶段 Dockerfile 和 .dockerignore

原因：最大限度地减小镜像体积和攻击面，提高构建缓存命中率，并防止意外将密钥或大型测试资产包含在镜像中。

使用 ACR Tasks 构建和签署镜像，并推送到地理复制的 ACR

原因：云端构建消除了本地环境差异；基础镜像更新触发器可减少 CVE 风险暴露。高级版 ACR 的地理复制功能可将构件与 AKS 集群部署在同一位置，从而降低延迟和出口流量成本。签名可实现来源验证。

启用 Defender for Cloud 镜像扫描，并通过 CI 门禁和 OPA Gatekeeper 强制执行

原因：在推送时和静态存储时进行扫描，可及早发现 CVE。Gatekeeper 约束强制执行“仅限批准的镜像仓库”、“需要已签名的镜像”和资源限制等策略，防止不安全的工作负载被准入。

为每个区域预配带有 Azure CNI、网络策略和托管身份的私有 AKS 集群

原因：私有端点限制了控制平面的暴露；Azure CNI 与企业 VNET 集成；网络策略限制了横向移动；托管身份消除了密钥蔓延。

创建独立的系统和用户节点池，为批处理作业添加 Spot 节点池

原因：隔离关键的平台 Pod，为非关键工作负载提供经济高效的容量，并简化升级和 SLO 管理。

采用 Helm 进行打包，将 Chart 存储在 ACR (OCI) 中，通过 Azure Pipelines 进行部署

原因：通过为每个环境设置不同的 values，实现一致的、版本化的发布。Pipelines 在执行 helm upgrade 之前会运行 helm lint、dry-run 和 diff，并使用 Kubernetes 服务连接来指定目标集群。

部署 Flux v2 以实现 GitOps 对账和漂移检测，并集成 Flagger 实现金丝雀发布

原因：声明式的、基于拉取（pull-based）的同步减少了 CI 中的凭证，并确保状态收敛。Flagger 根据 SLO 自动执行加权金丝雀发布，并使用 NGINX Ingress 指标，在出现错误或延迟峰值时进行回滚。

配置带 PDBs 和就绪/启动探针的滚动更新；对高风险组件使用蓝绿部署

原因：滚动更新可保持容量；探针可保护用户流量。对于 API 网关等高风险组件，通过切换 Service 上的标签实现蓝绿部署，可支持即时回滚。

引入 Istio 服务网格，实施严格的 mTLS、重试和超时策略；将遥测数据导出到 Application Insights

原因：实现网格范围的加密、健壮的流量策略和统一的可观测性。OpenTelemetry 收集器将追踪/指标发送到中央存储，用于 SLO 监控和事件分类处理。

建立受控的升级策略，包括 AKS 自动升级通道和节点镜像升级

原因：定期、可预测的平台更新可减少零日漏洞风险。Max-surge 和 PDBs 确保干扰最小化；升级独立的用户节点池可限制爆炸半径。

使用 Bridge to Kubernetes 进行内循环开发；使用 Draft 搭建脚手架

原因：开发人员可以在本地针对集群内的依赖项进行调试，无需模拟（mocking）。Draft 可加速跨团队实现一致的容器化和 Helm 脚手架搭建。

将长尾服务迁移到 Azure Container Apps，并使用 Dapr 和 KEDA

原因：事件驱动、可缩容至零的微服务（例如数据提取和丰富）能够以低成本运行，其内置的流量切分功能支持金丝雀发布；Dapr 组件无需定制代码即可标准化服务间调用和发布/订阅。

这个端到端的设计将构建的确定性与安全分发、声明式运维和渐进式交付结合在一起，为 Adobe 提供了跨区域的快速、低风险的发布能力和强化的运行时环境。

← 基础架构即代码与配置管理 · 所有领域 · 发布管理与部署策略 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通过考试 →

浏览 Microsoft →