Azure Local 为什么需要 AKS：构建企业内部 Azure Region 的关键能力

未经同意，请勿转载！

TL;DR：Azure Local 上的 AKS 真正价值，不是"在本地跑 Kubernetes"，而是把企业本地基础设施升级为Azure 云原生应用平台能力——本文从架构定位、能力边界、企业责任、业务价值与现实限制五个维度展开。

之所以强调"应用平台能力"，是因为AKS 在严格意义上不是 PaaS。它仍然是企业需要持续运维的 Kubernetes 容器编排平台，但通过 Azure Arc 把生命周期与治理能力纳入了 Azure 管理闭环。

术语约定：本文首次使用AKS enabled by Azure Arc这一微软官方命名，后续统一简称为"Azure Local AKS"——全文不再混用 "AKS Arc" / "AKS on Azure Local" 等变体。

引言：被反复追问的一个问题

很多企业在评估 Azure Local（原 Azure Stack HCI）时，会反复问一个问题：

既然 Azure Local 已经可以运行虚拟机，为什么还需要在上面部署 AKS？直接部署 Docker 或 Kubernetes 不行吗？

这个问题的关键不在于"能不能跑 Kubernetes"，而在于：

Azure Local + AKS 的真正价值，是把企业本地基础设施升级为具备 Azure 云原生管理模式的应用平台能力。

微软将AKS enabled by Azure Arc（以下简称Azure Local AKS）定义为Azure Kubernetes Service 向本地 / 边缘环境的延伸形态——企业可以通过 Azure 控制平面统一管理本地 Kubernetes 集群的生命周期、API 与集成，但控制平面仍运行在企业环境中。

这一点与"AKS 是 PaaS"的常见印象有本质区别，本文先把这层关系讲清楚。

第〇章：架构总览——从 Azure Region 到本地 AKS

为了让后续章节的局部图都能挂在同一张总图上，先给出整篇文章的核心视觉：

flowchart TD subgraph Cloud["Azure Cloud"] A1[Azure Region] A2[Azure Resource Manager<br/>ARM 控制平面] A3[Azure Arc<br/>混合云管理] A1 --> A2 --> A3 end subgraph Bridge["本地扩展层"] B1[Custom Location<br/>ARM 逻辑扩展点] B2[Arc Resource Bridge<br/>本地桥接组件] A3 --> B1 --> B2 end subgraph OnPrem["============== Azure Local =============="] C1[计算 / 存储 / 网络<br/>Hyper-V + S2D] C2[Virtual Machines<br/>通用 VM] C3[AKS Cluster<br/>Kubernetes 平台] B2 --> C1 C1 --> C2 C1 --> C3 C3 --> D[Kubernetes Control Plane<br/>本地 VM] C3 --> E[Worker Nodes<br/>本地 VM 池] E --> F1[AI / 推理 / RAG] E --> F2[ERP / 数据库] E --> F3[Edge / 微服务] end

这张图概括了全部要点：Azure ARM 通过 Azure Arc → Custom Location → Arc Resource Bridge 延伸到企业本地 Azure Local，Azure Local AKS 是这条延伸链上的"云原生应用平台层"。

一、首先明确：Azure Local 上的 AKS 是什么、不是什么

1.1 不是普通 Kubernetes

Azure Local 上部署的 AKS，不是企业自己安装的：

• kubeadm
• Rancher
• K3s
• OpenShift
• 上游 Kubernetes

也不是一个能用 Install-AKS.ps1 一键安装的软件包。

1.2 不是"完全托管生命周期"——是"生命周期管理能力"

这是本文必须澄清的另一关键点。

Azure Local AKS 是微软提供的 Kubernetes 生命周期管理能力，由微软通过 Azure Arc 集成提供：

• Kubernetes API Server / etcd 的部署与升级编排
• 节点池（Node Pool）的生命周期
• 与 Azure 服务（Azure Monitor、Azure Policy、Defender 等）的集成入口
• Kubernetes 各组件版本兼容性协调、证书轮换、控制面 HA 等平台工程问题

但是，AKS 不替代企业对 Kubernetes 工作负载、应用生命周期与资源规划的责任。企业仍然需要：

• 规划 Kubernetes 版本升级窗口（哪些版本受支持、何时升级）
• 选择节点池规模与节点 VM 规格
• 管理工作负载兼容性（应用是否能在新 Kubernetes 版本上运行）
• 管理应用自身的升级与回滚
• 自行负责 Kubernetes 节点 VM 的 OS 镜像、GPU 驱动栈（NVIDIA Driver / CUDA / Container Runtime）、CNI / NetworkPolicy、StorageClass 等基础设施层（详见 §2.3）

因此准确表述应当是：

Azure Local AKS 通过 Azure Arc 集成 Kubernetes 集群创建、版本管理、升级编排以及 Azure 服务集成能力，降低企业构建 Kubernetes 平台工程的复杂度，但并不替代企业对 Kubernetes 工作负载、应用生命周期和资源规划的责任。

把 Azure Local AKS 等同于"完全托管"或"PaaS"是被挑战最多的两个表述。

1.3 Azure Local AKS 与 Azure 公有云 AKS 的关键差异

与 Azure 公有云 AKS 不同，Azure Local AKS 的 Kubernetes Control Plane 运行在客户 Azure Local 环境内的 VM 中，由 Arc Resource Bridge 与 Azure 控制平面协同管理。这是 Azure Local AKS 架构的最关键差异点，专业读者最容易在此处追问。

1.4 Custom Location：被忽视的关键 ARM 扩展点

Custom Location 是Azure Resource Manager 的逻辑扩展点（logical extension point）——它将 Azure Local 等本地资源映射为 Azure 可管理的位置，使 Azure Portal 和 ARM API 可以像管理 Azure Region 资源一样管理本地 Kubernetes 服务。

强调三点：

1. Custom Location不是物理位置，是 ARM 中的逻辑对象
2. Custom Location代表"一个本地 Azure 位置"，使 Azure Portal 在创建 AKS 时不必切换到独立管理界面
3. Custom Location解耦了"在哪里创建"与"由谁管理"——Azure 控制面发起请求，落到具体的本地 Arc Resource Bridge 上执行

1.5 各层职责

微软官方文档明确：本地 AKS 的管理流程基于Arc Resource Bridge + Custom Location作为核心管理组件。

二、核心价值 1：从基础设施云到云原生应用平台能力

这一节澄清 Azure Local AKS真正的价值落点——强调组合能力，而非 Azure Local 自身。

2.1 传统 Azure Local 的运维形态

flowchart TD A[Azure Local] --> B[Hyper-V] B --> C[Virtual Machine] C --> D[OS] D --> E[Middleware] E --> F[Runtime] F --> G[Application]

企业自己负责：OS / Middleware / Runtime / Application Deployment。

2.2 Azure Local + AKS + Azure Arc 后的形态

注意，这里强调的是"组合能力"——单独看 Azure Local 是基础设施，单独看 AKS 是容器平台，只有三者结合才形成云原生应用平台能力：

flowchart TD A[Azure Local] --> B[Azure Local AKS<br/>Container Orchestration] A1[Azure Arc<br/>统一控制面] -.-> B B --> C1[Container Pod 1<br/>AI Service] B --> C2[Container Pod 2<br/>Web Service] B --> C3[Container Pod 3<br/>Batch Job]

2.3 但 Azure Local AKS 仍不是"无运维"

这是必须明确的一点——Azure Local AKS 降低的是企业级 Kubernetes 平台工程的复杂度，而不是消除所有运维工作。

在 Azure Local AKS 上，企业依然需要处理：

• Kubernetes 节点 VM 的 OS 镜像与节点池生命周期
• GPU 工作负载的驱动栈（NVIDIA Driver / CUDA / Container Runtime 的版本对齐）
• CNI / NetworkPolicy / StorageClass等 Kubernetes 原生能力
• 应用层的 Deployment / Service / Ingress / RBAC等 YAML 编排

以 AI 场景中部署 vLLM 为例，真实的运维栈是这样的：

AKS ├── GPU Node Pool │ ├── NVIDIA Driver（与企业 GPU 型号对齐） │ ├── CUDA（与 vGPU 版本匹配） │ └── Container Runtime（containerd） ├── vLLM Pod └── Model（外部存储挂载） Azure Local AKS 负责：节点池生命周期、升级编排、Azure 集成 企业负责：GPU 驱动栈、容器镜像、Helm Chart / Kustomize、模型文件管理

Azure Local AKS 降低的是应用交付复杂度，而不是消除基础设施运维。这是 Azure Local AKS 定位的关键认知边界。

2.4 价值跃迁的核心

• 运维心智模型：从"机器 + 系统"下沉到"应用 + 镜像"
• 平台能力：Kubernetes API、节点池、升级编排交给微软生命周期管理
• 应用现代化：与企业容器化 / 微服务 / AI 现代化路径同步

但要清楚：这是 Container Platform 能力的升级，不是从 IaaS 跃迁到 PaaS。把这条路径叫 "Infrastructure Cloud → Cloud Native Application Platform" 更准确。

三、核心价值 2：统一 Azure 公有云与本地的云原生模型

这是组合能力（Azure Local + Azure Arc + AKS）战略层面最大的价值。

3.1 企业未来的多环境现实

flowchart LR A[Azure Region] --> B[Azure Arc<br/>统一控制平面] B --> C1[Azure AKS<br/>公有云] B --> C2[Azure Local AKS<br/>本地] B --> C3[Arc-enabled Kubernetes<br/>边缘 / 第三方]

关于 C3：本图 C3 不使用 "Edge-类 AKS" 这一类非正式名称——它并非微软正式产品。Azure Arc 管理的 Kubernetes 集群在边缘 / 第三方场景下，统一称为Arc-enabled Kubernetes。

3.2 开发者视角的体验统一

开发人员面对的是：

• kubectl
• Helm / Kustomize
• GitOps（Flux / ArgoCD）
• Azure DevOps / GitHub Actions
• Terraform / Bicep

不再区分：这是生产环境 / 这是边缘环境 / 这是数据中心环境。

3.3 统一管理控制面的能力清单

微软通过 Azure Arc 建立统一控制面，跨地点 Kubernetes 管理能力包括：

• Azure Portal（一站式可视化）
• Azure Policy（策略合规下发）
• Azure Monitor（监控告警）
• GitOps（配置同步）
• RBAC（统一权限模型）

四、核心价值 3：满足"数据不出域"的强约束场景

这是 Azure Local AKS最重要的商业场景。

4.1 行业驱动力

许多行业无法把所有数据放在 Azure，但希望使用现代云原生能力：

这些行业希望保留数据治理边界，但同时希望获取：

• Kubernetes
• 微服务
• AI 推理
• MLOps
• DevOps

4.2 工业制造示例（增强版）

真正的工业场景中，从设备到 AI 视觉的价值链远比"摄像头 + AI"更复杂。一个更贴近现实的形态：

flowchart LR A1[PLC<br/>可编程逻辑控制器] --> A2[OPC UA Gateway<br/>工业协议网关] A3[IoT Sensor<br/>MQTT] --> A2 A2 --> B[Azure Local Edge<br/>工厂机房] B --> C[Azure Local AKS] C --> D[Time Series DB<br/>InfluxDB / Timescale] C --> E[AI Vision Pod] C --> F[Digital Twin Service] D --> G[工厂运营数据中台] E --> G F --> G

这条链包含：

• 工业协议层：OPC UA / MQTT 等工业协议接入
• 边缘采集：Edge Gateway 处理采集与初步清洗
• Azure Local：本地算力底座与存储
• Azure Local AKS：编排 AI Vision / 时序库 / Digital Twin 等微服务
• 数据中台：向上对接工厂运营与企业 IT 系统

4.3 工业场景的三大特点

1. 数据留在工厂
2. 延迟低（本地 AI 推理）
3. 网络环境受限时仍可运行（见第七节 Disconnected Operations 严谨表述）

微软也将 Azure Local AKS 的典型场景定位于Hybrid Cloud / Edge Computing / Regulatory Compliance——这与企业 IT 实际诉求高度吻合。

五、核心价值 4：成为企业 AI 平台的基础底座

这是当前 Azure Local AKS最重要的新方向。

5.1 未来企业 AI 架构范式

flowchart TD A[Azure Local<br/>本地算力底座] --> B[GPU Enabled Node Pool] B --> C[NVIDIA GPU Operator<br/>驱动 + Runtime 编排] C --> D[AI Workloads] D --> E1[LLM Service] D --> E2[RAG Service] D --> E3[Agent Service]

5.2 GPU 资源池化：底层能力栈

企业 AI 场景的关键不是"部署一个 vLLM"，而是把 GPU 算力、模型服务、应用工作负载纳入统一调度体系。

完整的 GPU 资源栈由以下组件构成：

flowchart TD A1[NVIDIA Driver<br/>GPU 硬件驱动] --> A2[NVIDIA Container Toolkit<br/>使容器内可调用 GPU] A2 --> A3[NVIDIA GPU Operator<br/>统一管理 Driver / Runtime 生命周期] A3 --> A4[Device Plugin<br/>向 K8s 注册 GPU 资源] A4 --> A5[MIG / Time-Slicing<br/>多 Pod 共享一张 GPU] A5 --> A6[Kubernetes Scheduler<br/>统一调度 + 多租户隔离] A6 --> B1[LLM Inference Pod] A6 --> B2[Embedding Pod] A6 --> B3[RAG Pod] A6 --> B4[Agent Pod] B1 & B2 & B3 & B4 --> C[多租户隔离<br/>Namespace + RBAC + ResourceQuota]

每一层的价值：

关于"多 Pod 共享一张卡"必须严谨表述：是否支持 GPU 共享取决于 GPU 型号、NVIDIA 软件栈、以及 Kubernetes GPU 调度策略——例如 MIG（硬件级隔离，限 Ampere 及更新架构）或 Time-Slicing（软件级时间分片）——本文不预设特定卡型支持的 partition 数，实际可用形态以 NVIDIA vGPU Manager 当期版本与 OEM 公开 Support Matrix 为准。

业务层的能力叠加（与底层解耦）：

5.3 一个具体的 LLM 推理部署示例

flowchart LR A[DeepSeek / Qwen / Llama / GPT OSS<br/>开源 / 私有模型] --> B[AKS Deployment] B --> C[vLLM Pod<br/>推理引擎] C --> D[NVIDIA GPU<br/>硬件加速] D --> E[对外推理 API] F[RAG 服务] --> G[Vector DB<br/>Milvus / pgvector] G --> E

注意驱动栈：这一形态的"基础设施栈"包括 NVIDIA GPU Operator / Driver / CUDA / Container Toolkit / Container Runtime——这正是 §2.3 强调的"Azure Local AKS 不是消除运维"的真实成本。

5.4 VM 模式 vs Azure Local AKS 模式（多维度务实对比）

Azure Local AKS 的价值在 AI 场景不是简单运行模型，而是将 GPU 算力、模型服务和应用工作负载纳入统一调度体系。

5.5 Azure Local AI 落地的现实起点：硬件与软件栈支持

虽然本章主要讲 Kubernetes 调度层，但在企业 AI 场景中，Azure Local AKS 只是 GPU 调度层之一——实际部署仍依赖：

• Azure Local OEM 集成系统的硬件认证矩阵（Dell / HPE / Lenovo 等厂商各自有 Support Matrix）
• GPU 驱动兼容矩阵（NVIDIA vGPU Manager / 数据中心驱动版本与 GPU 型号对齐）
• NVIDIA 软件栈（CUDA / GPU Operator / Container Toolkit 的版本对齐与时序要求）
• CPU-内存-存储-GPU-网络的资源池规划（GPU 调度不能孤立看待）

因此，"买几个 GPU 服务器 + AKS" 这种思路在 Azure Local AI 落地时不充分——必须先确认 OEM 认证 SKU 与 GPU 型号在 Support Matrix 内，再规划 GPU 池化与 Kubernetes 调度。

六、核心价值 5：DevOps / GitOps 企业模式落地

6.1 传统企业发布路径

代码 → 测试 → 人工部署

6.2 GitOps 形态

flowchart TD A[Git Repository<br/>应用代码 + K8s 清单] --> B[Flux / ArgoCD<br/>GitOps 控制器] B --> C[AKS Cluster] C --> D[Application Workloads] D --> E[监控 / 策略反馈] E --> A

6.3 Flux vs ArgoCD：微软官方推荐路径

Azure Arc 在 Kubernetes 集群上提供GitOps 能力，其中两条主要路径：

微软在Azure Arc-enabled Kubernetes 文档中明确推荐使用Flux Extension（基于 Flux v2），用户可以在 Portal 上为已接入 Arc 的 Kubernetes 集群一键启用 Flux GitOps 能力。

ArgoCD 在 Azure Arc 体系中也可使用，但需要企业自行安装、配置与维护生命周期。

如果你计划在 Azure Local AKS 上落地 GitOps，优先考虑 Azure Arc Flux Extension 路径。

七、Disconnected Operations：严谨表述

7.1 不能说的说法

❌ "Azure Local AKS 在断网情况下完全正常运行。"

❌ "Azure Local AKS 在断网时所有功能可用。"

这两种说法都不准确。

7.2 比较严谨的表述

✅Azure Local 提供 Disconnected Operations 能力——在受限网络或断网环境下，Azure Local 的本地基础设施（计算 / 存储 / 网络 / VM）和部分平台能力仍可持续运行，包括本地 Azure Local AKS 控制面与容器工作负载的核心运行。

具体细节随 Azure Local 版本演进变化，本节强调的是三点：

1. 本地基础设施层（计算 / 存储 / 网络）不依赖 Azure 公有云
2. 本地 AKS 控制面部署在本地 Azure Local 上的 VM 中
3. Azure 公有云依赖——Portal 治理 / 监控 / GitOps 同步 / 某些 Azure 集成特性在断网时无法访问，需要 Disconnected Operations 部署模式并提供本地等价能力

完整 Disconnected Operations 部署要求、限制与支持的 Azure 服务范围，请以当期 Azure Local 官方文档为准。

八、不是所有 Azure Local 客户都需要 AKS

这一节是本文最容易被忽略、也最重要的部分。

8.1 不适合 AKS 的三种典型场景

场景 1：传统虚拟化负载

例如：Exchange / SQL Server / 文件服务器 / ERP 老系统。

这些系统的迁移路径是 VM，不是容器。继续以 VM 形式运行更合适。

场景 2：普通企业 IT

例如 100 人公司：AD / File Server / ERP / OA。

没有云原生团队，Azure Local AKS 会显著增加复杂度。

场景 3：纯基础设施云

如果 Azure Local 只是：

• VMware 替代
• Hyper-V 替代
• 服务器整合

那么 AKS 不是核心价值点，重点应当是 Azure Local 的基础设施能力本身。

九、真正适合 Azure Local AKS 的企业类型

十、Azure Local AKS 与其他 Kubernetes 平台的对比

读者一定会有疑问——"为什么不用 K3s？或者 OpenShift？"。这一节给出简明定位对比。

10.1 微型对比表

把"治理模型"作为一行加入对比表，是因为它比"生态归属"更能说明 Azure Local AKS 的真正不可替代价值——详见 §12.3。

10.2 重要澄清：四者并非简单替代关系

必须明确：这些平台并不是简单替代关系。它们解决的问题不同，匹配的企业 IT 战略也不同：

• K3s强调轻量化与边缘自治——适合资源受限、隔离网络、边缘设备
• Rancher强调Kubernetes 多集群管理——适合纳管多个不同形态的 K8s 集群
• OpenShift强调企业应用平台能力——适合已有 Red Hat 投资、深 PaaS 需求
• Azure Local AKS强调Azure Hybrid Cloud 治理闭环——适合已用 Azure、需要跨 Azure / 本地 / 边缘统一治理

这种差异化定位使针对企业 IT 战略的"哪一种最适合"成为可被理性讨论的问题——本文系列第三篇将就此展开深度对比，包括 K3s + 开源生态栈在工业 / 边缘场景下可能更灵活的视角。

完整深度对比详见：Windows Server HCI + K3s vs Azure Local + AKS 深度对比

十一、Azure Local + AKS 的战略定位总结

11.1 三层定位

为何这里强调"容器应用平台层"：Azure Local AKS 提供 Kubernetes API / Container Orchestration / Lifecycle Management / Azure Integration，但不提供完整的 Runtime 抽象、应用生命周期全托管、纯开发者体验——这些仍是 PaaS 路线（如 Azure Container Apps、Azure App Service）。

11.2 一句话定位

Azure Local 解决的是企业计算资源在哪里运行的问题；AKS 解决的是企业应用如何以云原生方式运行的问题；Azure Arc 则提供跨 Azure、公有云和本地环境的一致管理模型。

11.3 Azure Local 的产品演进方向

如果说 Azure Local 的演进方向有一个核心问题，那就是：

从 Azure Local 的产品演进方向看，微软正在推动 Azure Local 从下一代 HCI 平台，向 Hybrid Cloud Platform 演进，使企业数据中心逐步具备 Azure Region 延伸形态。

这条延伸链的完整形态是：

flowchart TD A[Azure Region] --> B[Azure Resource Manager<br/>统一控制面] B --> C[Azure Arc<br/>混合云治理] C --> D[Azure Local<br/>企业内部 Region 抽象] D --> E[Azure Local AKS<br/>企业内部云原生容器应用层] E --> F[Applications<br/>AI / 微服务 / 数据平台]

11.3a 一个常被遗漏的层次：Arc-enabled Kubernetes Management Plane

需要补充一个容易被遗漏的层次：Arc-enabled Kubernetes。完整延伸链不仅是 ARM → Arc → Custom Location → Arc Resource Bridge → 本地 AKS，还包括Arc-enabled Kubernetes Management Plane——它是 Azure 控制面看 Kubernetes 集群的统一入口，提供：

• Cluster Connect（从 Azure Portal 连入任意 Kubernetes 集群）
• GitOps（Flux Extension）——已在 §6 详述
• Azure Policy for Kubernetes（K8s 资源合规检查）
• Microsoft Defender for Containers（容器运行时威胁检测）
• Azure Monitor Container Insights（K8s 监控与告警）

因此严谨的延伸链表述应当是：

Azure Resource Manager ↓ Azure Arc ↓ Arc-enabled Kubernetes Management Plane ↓ Custom Location ↓ Arc Resource Bridge ↓ Azure Local AKS

Kubernetes 专业读者关心的不仅是"AKS 怎么跑"，还包括"已接入 Arc 的 K8s 集群从哪里获得 Azure 治理能力"——这两个问题在同一篇文章里要分清。

11.4 真正的战略意义

因此，部署 Azure Local AKS 的真正意义不是：

❌ "在本地跑 Kubernetes"

而是：

✅让企业自建云具备类似 Azure 公有云的应用交付能力，使 Azure Local 从传统 HCI 平台升级为企业级云原生应用平台，并通过 Azure Arc / Custom Location 进入 Azure 统一治理闭环。

11.5 与传统 HCI 的本质差异

Azure Local + AKS 与传统 HCI 平台最大的差异之一，是其不仅提供基础设施虚拟化能力，还通过Azure Arc + AKS 延伸 Azure 云原生应用管理模式。这是其面向 AI / 微服务 / DevOps / 多云治理路径上的差异化价值——能否用好这条延伸链，取决于企业 IT 治理成熟度，不仅仅是基础设施选型问题。

十二、Azure Local AKS 的现实边界与反向观点

为了让本文对 Kubernetes 专业读者保持诚实，本节给出三个反向观点。

12.1 为什么不是所有企业都应该上 AKS？

因为Kubernetes 本身是一套复杂平台——不是每个企业都有意愿、有能力去建立可持续的容器平台工程团队。AKS 降低的是构建复杂度，不等于复杂度归零。

评估时应该诚实回答：

• 团队是否有 3 年以上的 K8s 运维积累？
• 业务负载是否真的能从容器化获得收益？
• 是真的需要 AKS，还是只是想要"现代化的容器"？

§8 的三种"不适合 AKS"场景已经更具体地回答了这个问题。

12.2 为什么 K3s 在工业边缘仍然有优势？

这是对 §10 表的强补充——工业 / 边缘 / 隔离网络场景下，K3s + 开源生态栈的实际治理能力可能比 Azure Local AKS 更灵活：

• 更轻量：单二进制、K8s 发行版 < 100MB，适合 IoT / 边缘设备
• 更开放：不受单一厂商生态约束，开源 + CNCF 标准
• 更容易离线自治：无 Azure 控制面依赖也能跑
• 更适合多厂商硬件：不依赖 Azure Local OEM 认证矩阵

本系列第三篇就是 K3s + Azure Local AKS 的深度对比，工业 / 边缘读者强烈建议阅读。

12.3 为什么大型 Azure 客户仍选择 AKS？

反向地——大型 Azure 重度客户选择 Azure Local AKS，看中的不是 K8s 本身，而是 Azure Hybrid Cloud 治理闭环：

• Azure Arc：跨本地 / 公有云 / 边缘的统一控制平面
• Azure Policy for Kubernetes：K8s 资源合规与治理
• Microsoft Defender for Containers：容器运行时威胁检测
• Azure Monitor Container Insights：统一的 K8s 监控与告警
• Entra ID / Azure RBAC：身份与权限统一

这些能力是 K3s + 开源栈在同等时间内很难完全拼出的——这是 Azure Local AKS 真正的不可替代价值。

本章让文章保持平衡：Azure Local AKS 不是银弹，K3s 也不是；选型取决于企业 IT 治理成熟度与具体场景，而不是"哪个更先进"。

附录：开始前的五件事

如果你正在评估 Azure Local AKS，建议在动手前先确认：

1. 业务侧的真实诉求：是"在本地跑 K8s"，还是"建设企业级云原生应用平台"？
2. 团队能力匹配：是否有容器化、K8s、GitOps 基础？Azure Local AKS 不是消除运维——你需要有能力管理驱动栈 / 镜像 / Helm Chart。
3. 多场景考虑：不是所有负载都适合容器化，传统 VM 仍是大量企业核心系统的稳定形态。
4. Azure Local AKS 不是 PaaS 的认知准备：能否接受"Azure Local AKS 仍然需要 Kubernetes 工程师"的现实？如果希望完全 PaaS 体验，Azure App Service / Azure Container Apps 在公有云侧才是更直接选择。
5. 混合云治理闭环的预期：Azure Local AKS 真正的价值不在单个集群，而在 Azure Arc / Custom Location 提供的跨本地 / 公有云 / 边缘统一治理体验——只跑本地的小项目，价值可能被掩盖。

系列文章索引

• 下一篇：Windows Server 与 Azure Local AKS：为什么 AKS 不能装在普通 Windows Server 上
• 对比篇：Windows Server HCI + K3s vs Azure Local + AKS 深度对比