Microsoft AZ-204: Azure 容器解決方案 — 學習指南

By Laurynas Brazys · 6 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

屬於 Microsoft Azure Developer Associate AZ-204 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Azure 提供了一系列的容器選項，涵蓋了單一容器執行、經編排的叢集，以及安全、企業級的映像檔供應鏈。Azure Container Instances (ACI) 是執行 Linux 或 Windows 容器最快的方法，無需管理伺服器。Azure Kubernetes Service (AKS) 是一個受控的 Kubernetes 控制平面，可透過進階的排程、網路、安全性和 DevOps 整合來擴展微服務。Azure Container Registry (ACR) 是一個私有、地理複寫的登錄檔中心，用以支撐您的建置、標記、推送/拉取及 Helm 分發流程。精通 Docker 映像檔的建構與生命週期管理，是在任何這些平台上進行可靠部署的基礎。本節從開發人員的實用角度，闡述各個部分如何協同運作，包括由 YAML 驅動的部署、Helm 封裝、服務暴露以及身分識別/安全模式。

Docker 與 Azure Container Registry (ACR)

可靠的容器交付始於扎實的 Docker 基礎。每個映像檔都由 Dockerfile 指令所形成的層 (layer) 組成；層的重複使用和快取命中對於快速建置至關重要。

• 常見的 Dockerfile 指令與指南：
  • FROM 定義基礎映像檔。偏好使用最小化的映像檔 (例如，在適當時使用 distroless、alpine) 以減少攻擊面和大小。
  • RUN 執行指令以安裝相依套件。合併相關指令以減少層數，但避免使用會掩蓋失敗的單一龐大 RUN 行。
  • COPY 和 ADD 放置應用程式成品。使用 .dockerignore 避免內容 (context) 臃腫；將 COPY 鎖定在明確的路徑上。
  • WORKDIR 設定工作目錄；使用它來取代在 RUN 中串接 cd。
  • EXPOSE 記錄預計監聽的連接埠 (這不是防火牆)。
  • ENV 和 ARG 設定環境變數和建置時期變數；透過固定 ARG 預設值或傳遞明確值來提升建置時期的確定性。
  • ENTRYPOINT 定義主要執行檔；使用 CMD 來設定預設參數。偏好使用 exec 格式 (JSON 陣列) 以保留信號處理，實現優雅關機。
  • HEALTHCHECK 啟用存活探測，以便編排器能做出反應。
• 多階段建置 (Multi-stage builds) 將建置階段與執行階段分開，僅將所需成品複製到一個乾淨的執行階段映像檔中，從而大幅減少大小和 CVE 足跡。例如，使用 SDK 進行建置，發布二進位檔，然後複製到執行階段基礎映像檔中。
• 映像檔層是不可變且以內容定址的。重新排序指令會改變快取行為。將經常變動的指令 (例如，COPY 來源) 放在 Dockerfile 的後段，以最大化快取命中率。

透過 ACR，您可以私密地儲存和分發映像檔及 Helm charts：

• 存放庫與標記：將映像檔推送為 <registry>.azurecr.io/<repo>:<tag>。偏好使用語意化或基於 Git 的標籤 (例如，1.4.0、建置 SHA)，並在生產部署中使用不可變的摘要 (digest) 以確保可重複性。
• 推送與拉取：
  • 使用

undefined

或使用帶有 Azure AD 權杖的

undefined

來驗證 ACR。避免在生產環境中啟用 ACR 管理員使用者。

• 標記與推送：

undefined

；

undefined

。使用

undefined

或透過 Kubernetes 映像檔參考來拉取。

• 將上游映像檔匯入 ACR 以控制供應鏈：

undefined

。

• ACR Tasks：在 Azure 中原生建置、測試和修補映像檔。使用

undefined

進行隨選建置；使用

undefined

自動化更新，以從 Git commit 或基礎映像檔更新觸發，從而無需更改應用程式碼即可修復 CVE。

• 地理複寫 (Premium SKU) 提供多區域的拉取本地性和彈性。在靠近 AKS 叢集的區域設定複本，以減少拉取延遲和跨區傳輸費用。
• 存取控制：
  • 與 Azure AD 整合，並將 AcrPull 等內建角色指派給 AKS kubelet 身分，將 AcrPush 指派給 CI 管線。可透過權杖和範圍對應 (scope map) 實現存放庫範圍的權限，進行精細控制。
  • 使用私有端點、服務端點和防火牆規則來限制網路存取。生產環境中偏好使用私有端點。
  • 使用

undefined

將 ACR 附加到 AKS，以簡化 AcrPull 角色的指派。

Azure Container Instances (ACI)

ACI 依需求執行容器，無需管理叢集。其主要單位是容器群組 (container group)，這是一組共同排程的容器，共享相同的主機作業系統核心、生命週期、IP 和磁碟區。您可以使用容器群組來實作 sidecar 模式 (例如，日誌傳送器、代理伺服器) 或將主要程序與輔助程序結合。

• 多容器群組共享一個網路命名空間，允許容器間透過 localhost 進行通訊。它們也共享掛載的磁碟區 (Azure Files、emptyDir) 和生命週期，使其適合需要緊密耦合的一次性內聚任務。
• 重新啟動原則控制執行語意：
  • Always：當容器退出時重新啟動。最適合長時間執行的服務。
  • OnFailure：僅在非零退出碼時重新啟動。適合應在失敗時重試的批次任務。
  • Never：執行容器一次且永不重新啟動，非常適合冪等 (idempotent) 的作業。
• 網路整合包括帶有 DNS 標籤的公用 IP、在委派的 Azure VNet 子網路中的私有 IP，以及透過 NAT 或防火牆的安全出口流量。注入 VNet 的 ACI 能夠私密地存取服務 (資料庫、儲存體) 而無需公開於公網。
• 維運考量：
  • 使用安全的環境變數或掛載 Azure Files 來注入秘密；若要取得更強的安全性，可在執行時期透過受控識別從 Key Vault 擷取秘密。
  • 使用

undefined

和

undefined

進行觀察；使用

undefined

執行互動式指令。

• 計費方式為 vCPU 和 GiB 記憶體的每秒計費。容器啟動快速，適合突發性工作負載、CI 輔助任務、整合測試，以及不需要 Kubernetes 額外負擔的佇列觸發作業。

Azure Kubernetes Service (AKS)

AKS 提供一個受控管的控制平面，具備節點池、自動擴展以及深度的網路與身分識別選項。

節點池建構了容量和工作負載的放置。系統節點池執行核心服務；使用者節點池執行應用程式 pod。使用多個節點池，可根據 CPU/記憶體/GPU 需求、作業系統 (Linux/Windows)、VM 大小和可用性區域來隔離工作負載。採用污點 (taints)/容忍 (tolerations) 來保護系統節點池，使用標籤 (labels) 進行選擇，並利用叢集自動擴展器 (cluster autoscaler) 根據待處理的 pod 來新增/移除節點。在規劃大小時，需考慮每個節點的 maxPods 和 pod 密度。

Pod 的調度由資源請求 (requests)/限制 (limits)、QoS 等級 (Guaranteed/Burstable/BestEffort) 和約束條件驅動。使用 nodeSelector/親和性 (affinity) 與反親和性 (anti-affinity) 將 pod 推送到適當的節點池，並將複本分散到不同的區域和故障網域。拓撲擴展約束 (Topology spread constraints) 可改善分布的均勻性。對於關鍵服務，定義 PodDisruptionBudgets 和 PriorityClasses 來塑造自願性中斷和搶佔行為。DaemonSets 在每個節點上放置代理程式 (如日誌、監控)，而 CronJobs 則排程容器執行週期性任務。

AKS 中的部署是宣告式的。YAML 清單檔為 Deployments、StatefulSets、Jobs、Services 和 Ingress 定義了 apiVersion、kind、metadata 和 spec。將清單檔保存在原始碼控制中，使用 Kustomize 疊加層為不同環境進行參數化，並透過 kubectl apply -f 來套用。伺服器端套用 (Server-side apply) 和適當的標籤/註解有助於所有權和漂移偵測。對於打包可重複使用的應用程式，Helm 3 將模板 (templates) 和值 (values) 捆綁在一起。將 Helm chart 作為 OCI 成品託管在 ACR 中，並使用 helm upgrade --install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml 進行安裝。為每個環境使用不同的 values 檔案，追蹤 chart 版本，並使用 helm rollback 進行快速恢復。

您將會每日使用的 kubectl 指令：

• 存取叢集情境：az aks get-credentials -g <rg> -n <cluster> 會合併 kubeconfig；使用已加入 Azure AD 的機器搭配 kubectl 就足夠了——部署清單檔並不需要 Docker。
• 檢查與操作：kubectl get nodes,pods,deploy,svc -A；kubectl describe pod <name>；kubectl logs -f <pod>；kubectl exec -it <pod> -- sh；kubectl rollout status deploy/<name>；kubectl set image deploy/<name> container=<image>:<tag>；kubectl top pods；kubectl cordon/drain nodes 進行維護；kubectl auth can-i 驗證 RBAC。
• 套用/修補：kubectl apply -f k8s/；kubectl patch deploy <name> --type merge -p '{...}'。

AKS 中的網路功能以清晰的職責劃分來暴露 pod 和服務：

• ClusterIP 提供僅限內部、叢集範圍的虛擬 IP 和 DNS，用於服務發現。這是微服務之間東西向流量的預設選項。
• NodePort 在每個節點上開啟相同的埠號；最好在 Ingress 或外部 LB 後方使用，而不是直接使用。
• LoadBalancer 會佈建一個 Azure Load Balancer 前端，該前端以 NodePort 為目標。透過註解 service.beta.kubernetes.io/azure-load-balancer-internal: "true" 將服務標記為內部，或指派一個靜態公用 IP 以獲得穩定的 DNS。
• Ingress 控制器提供 L7 路由、TLS 終止以及路徑/主機規則。NGINX Ingress Controller 是一個功能豐富、具備多樣註解的通用預設選項。Application Gateway Ingress Controller (AGIC) 與 Azure Application Gateway 整合，提供 WAF、自動擴展和企業級 L7 功能，同時保持 Kubernetes 原生的清單檔格式。使用 cert-manager 透過 ACME 自動化 TLS，或使用 CSI Secret Store 將 Key Vault 憑證同步到 Kubernetes secret 中。

身分識別與授權整合了 Azure AD，無需在叢集內儲存 secret：

• AKS 的受控識別包含叢集/控制平面身分識別和 kubelet 身分識別。授予 kubelet 對 ACR 的 AcrPull 權限 (az aks update --attach-acr <acr>)，以便節點可以安全地拉取映像檔。
• 工作負載身分識別 (Workload identity) 使 pod 能夠使用對應到 Kubernetes 服務帳戶的聯邦式 Azure AD 憑證來存取 Azure 資源——無需節點級憑證或 sidecar。在叢集上啟用 OIDC 簽發者，建立一個使用者指派的受控識別，為服務帳戶/命名空間設定一個 FederatedIdentityCredential，並在應用程式中使用 Azure Identity SDK。這取代了舊的 AAD Pod Identity 模型，並與開放標準保持一致。
• RBAC 管理 Kubernetes API 權限。當 AKS 與 Azure AD 整合時，透過 RoleBindings/ClusterRoleBindings 將 Kubernetes Roles/ClusterRoles 綁定到 Azure AD 使用者或群組。或者，啟用 Azure RBAC for Kubernetes Authorization，以使用 Azure RBAC 角色（如 Azure Kubernetes Service RBAC Reader、Writer 和 Admin）來管理存取。遵循最低權限原則，按團隊或工作負載分離命名空間，並透過基於群組的綁定來把關生產環境的存取。

從映像檔到 AKS 的端到端流程直接且安全。建置多階段映像檔，使用不可變的版本進行標記，推送到 ACR，然後使用清單檔或 Helm 部署到 AKS。AKS 使用 kubelet 受控識別從 ACR 拉取映像檔，而 pod 則透過工作負載身分識別來使用 Azure 資源。服務透過 ClusterIP/LoadBalancer 暴露，並由一個集中管理 TLS 和路由的 ingress 控制器進行優化。

實務問題情境

Adobe 的 Creative Cloud 團隊正在將一個單體式的媒體處理服務分解為微服務，目標是實現低延遲的全球交付和一個強化的供應鏈。

1. 在 CI 中使用多階段 Dockerfile 建置和儲存映像檔

• 使用 Docker 多階段建置來編譯媒體編解碼器，並只將執行時期二進位檔複製到一個輕量級基礎映像檔中，以最小化大小和 CVEs。將映像檔以 <acr>.azurecr.io/processing/encoder:<git-sha> 的格式推送到 ACR。這確保了可重現、安全的成品，並帶有不可變的摘要，可用於部署釘選。

2. 強化登錄庫並自動化修補

• 建立一個 ACR Premium 登錄庫，並在每個託管 AKS 的虛擬網路中設定私有端點。啟用對 North Europe 和 East US 的異地複寫，以保持拉取操作的本地性。設定 ACR Tasks，在上游基礎映像檔更新時觸發重新建置，自動傳播已修補的圖層。這在效能與安全性之間取得了平衡，並減少了出口流量。

3. 建立具備分離節點池和身分識別的 AKS

• 使用 Azure CNI 和系統/使用者節點池來部署 AKS：一個小型的系統節點池用於控制平面附加元件，啟用 GPU 的使用者節點池用於轉碼，以及通用目的的節點池用於 API。啟用 Azure AD 整合、OIDC 簽發者和工作負載身分識別。透過 az aks update --attach-acr 將 AcrPull 權限指派給 kubelet 身分識別。這可以隔離工作負載、有效擴展，並移除基於 secret 的映像檔拉取方式。

4. 定義宣告式部署和打包

• 為 Deployments、需要持久性的 StatefulSets、Services、HorizontalPodAutoscaler 和 PodDisruptionBudgets 編寫 Kubernetes YAML。將編碼器服務和 API 閘道打包成 Helm chart，將它們作為 OCI 成品發布到 ACR，並使用 helm upgrade --install 搭配特定環境的 values 檔案進行部署。這提供了具一致性、版本化的發布和簡單的回滾機制。

5. 暴露服務並強制執行 L7 安全性

• 對於內部微服務使用 ClusterIP，對於公開的 API 則使用帶有 Application Gateway Ingress Controller 的 LoadBalancer 服務。在 Application Gateway 上使用 WAF 策略終止 TLS，使用與 Azure DNS 整合的 cert-manager 進行 ACME 挑戰來管理憑證，並根據主機/路徑將流量路由到後端。這能以 Kubernetes 原生的設定方式，實現企業級的 L7 安全性。

6. 實作工作負載對 Azure 資源的安全存取

• 對於一個需要寫入 Blob Storage 和讀取 secret 的縮圖服務，建立一個使用者指派的受控識別，透過工作負載身分識別將其與服務帳戶進行聯邦，並授予 Storage Blob Data Contributor 和 Key Vault Secrets User 角色。Pod 會向 Azure AD 進行驗證，從而消除了掛載 secret 的需要，並實現了細緻且可稽核的存取控制。

7. 使用 ACI 處理批次處理溢流

• 對於零星、高優先級的批次處理溢流，在一個注入 VNet 的子網路內，觸發 restartPolicy: Never 的 ACI 多容器群組（編碼器 + sidecar 指標收集器）。這可以在不將 AKS 擴展到峰值的情況下吸收流量尖峰，並保留通往儲存體帳戶的私有資料路徑。

每個選擇都直接支持 Adobe 的目標：具有異地複寫和私有端點的 ACR Premium 可保護並加速映像檔拉取；具有專門節點池和工作負載身分識別的 AKS 強制執行隔離和最低權限存取；Helm 和宣告式 YAML 標準化了部署和回滾；帶有 WAF 的 AGIC 提供了具彈性、安全的 L7 ingress；而 ACI 則在沒有持續性叢集成本的情況下處理突發的批次處理。

← Azure Cosmos DB · 所有領域 · Azure 驗證、授權和安全性 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →