📚 课程目录第1章 AKS平台工程导论

1. AKS平台工程导论

Azure Kubernetes Service（AKS）是Azure上托管的Kubernetes服务。理解AKS，不能只把它当作“云端能跑kubectl的K8s”，而应把它放进Azure云原生体系的整体坐标中：底层是Azure的计算、网络、存储与身份基础设施；中间是AKS控制平面（由Azure托管）与节点池（运行在用户的订阅与虚拟网络中）；上层则接入Azure Container Registry（ACR）、Azure Monitor、Microsoft Entra ID、Azure Policy、Key Vault、Application Gateway、Service Bus等云服务。AKS的价值在于把Kubernetes的控制平面运维责任转移给Azure，同时保留工作负载、网络、身份与策略的自主控制权。

从平台工程视角看，AKS不是终点，而是“平台产品”的运行时底座。平台工程的核心是：把集群、命名空间、网络、身份、策略、可观测性、交付流水线等能力封装成内部开发者平台（IDP），让应用团队通过自助方式获得“生产就绪”的运行环境。SRE则关注服务等级目标（SLO）、错误预算、容量与故障响应；DevOps关注交付流水线、自动化与协作文化。三者关系可以概括为：DevOps提供协作与交付实践，SRE提供可靠性与度量方法，平台工程把二者沉淀为可复用的平台能力，而AKS是这些能力落地的主要载体。

核心判断：AKS平台工程的目标不是“把集群建起来”，而是让应用团队在无需深入Kubernetes细节的前提下，安全、可观测、可审计、可扩展地交付服务。

集群平台的核心能力模型可以拆成六个相互支撑的维度：

计算与弹性：节点池规划、自动扩缩容（HPA、Cluster Autoscaler、KEDA）、节点镜像与升级策略。
网络与入口：Azure CNI或Kubenet、Ingress Controller、Service、Network Policy、私有链接与DNS。
身份与安全：Entra ID集成、Kubernetes RBAC、工作负载身份（Workload Identity）、密钥管理与镜像签名。
交付与配置：GitOps（Flux/Argo CD）、Helm/Kustomize、环境分层与渐进式发布。
可观测性与可靠性：Container Insights、Prometheus/Grafana、日志、追踪、SLO与告警。
治理与成本：Azure Policy、资源配额、命名空间即服务、成本分摊与标签规范。

下面这张图把AKS在Azure云原生体系中的定位、平台工程与SRE/DevOps的关系，以及六项核心能力组织成一张结构关系图，便于建立整体心智模型。

本课程的实战项目将围绕一个“多环境微服务电商平台”展开。项目包含三个环境：dev、staging、prod，分别对应不同的节点池规格、网络策略与发布策略。示例参数如下（属于教学假设，非实测结果）：dev 使用 2 个 Standard_D2s_v5 节点，开启自动扩缩容，最小 1、最大 3；staging 使用 3 个 Standard_D4s_v5 节点，固定规模；prod 使用 3 个可用区分布的 Standard_D8s_v5 节点池，并配置 Cluster Autoscaler 最小 3、最大 12。应用侧包含 frontend、catalog、cart、order 四个服务，通过 Helm Chart 统一交付，使用 Flux 实现 GitOps 同步，使用 Workload Identity 访问 Key Vault 与 Azure SQL，使用 Prometheus + Grafana 观测延迟与错误率。

课程会沿着“平台能力建设”的主线推进：先建立集群与网络基线，再接入身份与安全，随后搭建交付流水线与可观测性，最后完成多环境治理与成本优化。每一章都会给出可操作的配置片段、验证命令与判断依据。例如，验证节点池自动扩缩容是否生效，可以观察以下命令输出中的节点数量变化：

kubectl get nodes -w
# 在另一终端制造负载
kubectl create deployment load --image=busybox --replicas=20 -- sleep 3600
# 观察节点数是否从 3 增加到更多，再删除负载观察缩容
kubectl delete deployment load

判断依据是：节点数在负载增加后上升，在负载删除后经过缩容窗口下降；若节点数不变，应检查 Cluster Autoscaler 日志、节点池最大数量限制以及 Pod 的资源请求是否设置合理。类似地，验证 Workload Identity 是否生效，可以进入 Pod 执行 az login --identity 或直接访问 Key Vault，观察是否返回 403 或成功获取密钥。

学习建议：每章动手前先明确“当前平台能力处于哪一层”，再决定操作对象是 Azure 资源、Kubernetes 对象还是应用配置。把每次变更都当作一次可回滚的实验，记录输入、观察点与结果，形成自己的平台工程笔记。

完成本课程后，你应当能够独立设计一个满足生产要求的 AKS 平台基线：包括网络与身份规划、节点池与弹性策略、GitOps 交付链路、可观测性与告警、策略治理与成本可见性，并能用 SRE 的度量方法判断平台是否真正可靠。AKS 平台工程不是一次性交付，而是一个持续演进的内部产品；它的成功标准是应用团队能否安全、快速、可预期地把服务交付到生产环境。