Azure Local 离线模式：AKS Arc 管理（Preview）

文档体例说明：本节采用三栏组织——

• ✅官方要求（Official Requirement）—— 微软 Learn 原文明确说明的事实
• 🔍技术分析（Technical Analysis）—— 根据 Azure Local / AKS Arc 架构推导出的技术原理
• 💡企业最佳实践（Best Practice）—— 企业生产环境建议、风险控制、扩展性考量

重要 Preview 风险声明：本文描述的功能属于Microsoft Azure Previews，使用前必须阅读 Supplemental Terms of Use for Microsoft Azure Previews——Preview 功能可能发生 API、CLI、资源模型及部署行为变化，升级路径和兼容性可能调整，应以每个版本 Release Notes 为准。

本文三类内容边界声明：

• 标注为 ✅官方要求（Official Requirement）的内容均来源于 Microsoft Learn 或其他微软官方文档
• 标注为 🔍技术分析（Technical Analysis）的内容基于 Azure Local、Azure Arc 与 AKS Arc 的公开架构推导
• 标注为 💡企业最佳实践（Best Practice）的内容属于工程实践建议，并非微软官方强制要求

1. 支持状态

✅ 官方要求

微软官方说明：

"Support for disconnected operations begins with the Azure Local 2408 release."

• 起点版本：Azure Local 2408
• 当前状态：Preview
• 因此使用前必须阅读： Supplemental Terms of Use for Microsoft Azure Previews

Preview 功能在 GA 前可能发生：

• API 调整
• CLI 参数变化
• 功能限制更新
• 升级路径变化
• 回滚支持变更

🔍 技术分析

2408 是 Disconnected Operations 的起始版本。这意味着：

• Azure Local2408 开始支持本地控制平面的离线管理能力（Local Control Plane for Disconnected Operations）
• AKS Arc 可以通过离线控制平面管理
• 不再要求管理节点持续连接 Azure 公有云

但：

• 这并不意味着 AKS Arc 全部功能均已支持
• 当前 Preview仅开放部分能力
• 与 connected 模式相比，identity / network / GPU 等维度仍有显著缺口（详见 §2）

💡 企业最佳实践

Preview 期间必须执行：

2. 当前 Preview 限制

✅ 官方要求

微软当前列出的限制如下：

🔍 技术分析

(1) Kubernetes 版本——"supported and validated" 范围

• 1.33.4 / 1.33.5 是当前受支持并经过验证（supported and validated）的 Kubernetes 版本
• 表示的是Preview 当前验证范围，并不意味着未来仅支持这两个 Patch
• 随 Azure Local 后续版本发布，支持的 Patch 版本可能扩展

⚠️常见误读：

• ❌ 误读："AKS Arc 只支持 1.33.4 / 1.33.5"
• ✔ 正确："Preview 当前仅在 1.33.4 / 1.33.5 上验证，其他 Patch 等待后续 release"

(2) Microsoft Entra ID——Preview 限制，非长期架构限制

Disconnected 模式下：

• ❌ 不支持通过 Microsoft Entra ID 完成 Kubernetes 身份认证
• ✔ 只能依赖：
  • Active Directory
  • AD FS（Active Directory Federation Services）

进行身份验证。

关键 nuance：

• 这是Preview 当前限制
• 并非AKS Arc 长期架构限制
• 未来 GA 阶段很可能恢复Entra 统一身份集成（具体以官方 release notes 为准）

(3) GPU——AKS 层不开放，底层能力可能有

当前 Preview 限制：

• ❌ Kubernetes无法调度GPU Workload
• ❌所有依赖 Kubernetes GPU Device Plugin 的工作负载目前均无法运行—— 例如：
  • AI 推理
  • AI 训练
  • CUDA HPC
  • GPU 加速应用

关键 nuance：

• Azure Local底层基础设施未来仍可能支持GPU 硬件
• 当前 Preview仅AKS 层没有 expose GPU scheduling capability
• 不能简单理解为 "Azure Local 无 GPU 能力"

(4) Arc Gateway / Outbound URL——架构上不走该模式

• ❌ disconnected 模式不依赖Arc Gateway outbound endpoint
• ✔ disconnected 模式通过本地控制平面完成资源管理，不依赖 Arc Gateway 对 Azure 公有云的持续连接
• 这是该模式的架构选择，而非参数配置限制

(5) Portal 部分能力缺失——根因

某些资源只能通过 Azure CLI 创建（Logical Network、SSH Key 等）：

• ❌ Portal 在 disconnected 模式下不支持这些 resource type
• 🔍根因：
  • 当前 Portal尚未覆盖所有离线 Resource Provider
  • 因此部分资源只能通过 Azure CLI 调用本地 Resource Provider 创建
  • 这是当前 Preview 范围内 Resource Provider 的覆盖差异

💡 企业最佳实践

Kubernetes 版本管理

• 不自行升级Kubernetes Patch
• 不跨版本跳版本（如 1.33.4 直接升 1.34.x）
• 等微软发布对应 Azure Local release 的支持版本再升

Identity 设计（最重要）

• AD FS高可用部署（≥2 节点）
• Token Signing 证书生命周期管理
• Kerberos / LDAP fallback 设计
• 时间同步强制一致（NTP）——否则 token failure

Workload 选型约束

3. Azure CLI 扩展版本

✅ 官方要求

微软要求安装指定 Azure CLI 扩展：

示例：

az extension add --name aksarc --version 1.2.23 az extension add --name stack-hci-vm --version 1.11.1 # 关键：关闭 CLI instance discovery（断网必需） az config set core.instance_discovery=false --only-show-errors

🔍 技术分析

(1)stack-hci-vm版本 1.11.1 vs VM 页 1.3.0

⚠️常见误读：1.11.1 高于"Azure Local VM 管理文档"的 1.3.0 → "VM 功能版本跃迁"

✔正确解读：

• Azure CLI extension version不一定跨 feature parity
• "Azure Local VM 管理文档版本" vs "AKS Arc dependency version" 是不同 release train
• AKS Arc 可能 pin 一个较新的stack-hci-vmextension，用于网络 / 计算资源 API 兼容性
• 这是AKS Arc 的 dependency，不等于VM 功能版本变化

判断准则：

• AKS Arc 部署：以本文档（AKS 文档）指定的1.11.1为准
• VM 单独部署：以"Azure Local VM 管理文档"指定的版本为准
• 两边要分开看，不要交叉推断

(2)core.instance_discovery=false——断网环境的关键开关

Azure CLI 默认会：

• discovery ARM endpoints（自动发现 ARM endpoint）
• login metadata refresh（登录元数据刷新）

在断网环境中，保持默认配置会导致：

• DNS hang
• timeout retry
• login latency exponential backoff
• 命令长时间无响应

✔关闭该配置的工程意义：

• bypass AAD instance metadata discovery pipeline
• 避免 CLI 尝试访问公共云身份元数据终结点
• 减少离线环境中的超时和重试
• 大幅提高 CLI 响应速度

这是高质量的工程洞察——必须在所有 disconnected 操作的客户端上设置。

💡 企业最佳实践

Version Pinning（版本锁定）

三方一致性原则（操作前必查）

任意一项不匹配：先把版本对齐，再继续操作。

优先级：Microsoft Release Notes > OEM 驱动/Firmware Matrix。因为兼容性最终由微软 release train 决定，OEM 主要负责驱动层。

4. 部署流程

✅ 官方要求

典型部署流程：

4.1 登录

az login

4.2 创建 Logical Network（AKS 用）

az stack-hci-vm network lnet create ` --subscription $subscription ` --resource-group $resource_group ` --custom-location $customLocationID ` --name $lnetName ` --vm-switch-name $vmSwitchName ` --ip-allocation-method "Static" ` --address-prefixes $addressPrefixes ` --gateway $gateway ` --dns-servers $dnsServers ` --ip-pool-start $ipPoolStart ` --ip-pool-end $ipPoolEnd

4.3 创建 AKS Arc Cluster

参见原文：Create an AKS cluster through CLI

🔍 技术分析

Logical Network 是 AKS Arc 的网络基础。其负责：

• Pod 网络
• Service 网络
• VM 网络接口
• IP 地址池管理

Disconnected 模式下：

• 网络资源全部由本地控制平面管理
• Pod CIDR / Service CIDR 必须预先规划——后期修改成本极高

💡 企业最佳实践

部署前必须规划（避免后期重建）

⚠️关键原则：logical network ≠ physical network。logical network 是 SDN 抽象，必须在底层 physical network 之上设计。

5. 部署前置条件

✅ 官方要求

部署前需完成：

🔍 技术分析

上述准备工作不仅影响部署是否成功，还决定后续：

• 集群升级路径
• 身份认证
• 网络连通性

特别是Identity / PKI / Network——一旦投入使用，后期调整成本极高，应在部署前完成设计评审。

💡 企业最佳实践

将以下内容纳入企业上线检查清单（Deployment Readiness Checklist）：

Identity 维度

• Identity 方案评审（AD FS 高可用 / AD 集成）
• PKI 生命周期规划（证书轮换 / CRL 维护）
• 时间同步验证（NTP 一致性 → token 验证前提）

Network 维度

• IP 地址容量规划
• DNS split horizon 设计
• MTU 一致性验证（跨 HCI 节点）
• Static IP pool exhaustion strategy

Operations 维度

• CLI / Extension 版本锁定
• 镜像仓库（container image registry mirror）同步验证
• Local container registry governance 策略
• 离线 audit log export 方案
• Extension repo source 冻结

Storage 维度（AKS 比 VM 更依赖存储）

• CSV 容量规划（含增长预留）
• Storage Path设计（避免后期重建）
• Image Volume容量（container image 占空间）
• Snapshot 空间预留（升级/回滚都需要）

Container Image Lifecycle 维度（disconnected 的核心难点）

• Image mirror strategy—— 如何从公云镜像库同步到本地
• Image vulnerability scanning—— 离线场景下的镜像漏洞扫描
• Image retention—— 保留策略与清理
• Image signing—— 镜像签名校验（防止内部篡改）

6. 架构级补充（官方未明确说明）

6.1core.instance_discovery=false是否恢复默认？

🔍 技术分析

• 官方文档说明了离线环境需要关闭instance discovery
• 但未明确说明何时恢复默认配置

💡 企业最佳实践

• 仅在离线环境中使用该设置
• 如需重新连接公共 Azure，应恢复默认并验证 CLI 登录流程
• 建议建立脚本式切换：

# 进入 disconnected 模式 az config set core.instance_discovery=false --only-show-errors # 退出 disconnected 模式 az config set core.instance_discovery=true --only-show-errors

6.2 AKS Arc 是否消耗管理集群资源？

🔍 技术分析

官方未明确说明AKS Arc 是否额外占用管理集群资源。

从 Azure Local 架构合理推断：

┌─────────────────────────────────────┐ │ Azure Local Management Cluster │ │ (HCI 底层物理基础设施) │ ├─────────────────────────────────────┤ │ Arc Control Plane │ │ ├─ Appliance VM │ │ ├─ Operations Module │ │ └─ Arc Resource Bridge │ ├─────────────────────────────────────┤ │ AKS Arc Workload Cluster │ │ ├─ Control Plane (Pods) │ │ ├─ Worker Nodes │ │ └─ Networking / Storage │ └─────────────────────────────────────┘

✔真实架构：

• 管理控制组件运行于 Azure Local 管理平面
• AKS 工作负载共享底层物理计算资源（CPU / Memory / Storage）
• 控制平面与业务工作负载通过逻辑隔离实现资源管理（compute is shared, control plane is logically separated）

该推断符合 Azure Local 控制平面设计，但目前官方文档尚未对此进行明确说明，应视为架构分析而非官方结论。

6.3 Preview 升级风险

⚠️ Preview 期间可能出现

💡 企业最佳实践

• 充分验证升级影响后再进入生产部署
• 保留升级前的 snapshot / backup
• 建立 Preview 退出策略：GA 后如何平滑切到 GA 版本
• 不要 auto-upgradePreview extension

6.4 已知未覆盖 / Open Questions

7. 企业级最佳实践总结

🔐 Preview 风险控制

🆔 Identity 设计

• AD FS高可用（≥2 节点）
• Token signing 证书生命周期管理
• Kerberos / LDAP fallback 设计
• NTP 时间同步强制一致（≤5 秒漂移）
• 不能依赖 Entra ID（Preview 限制）

🌐 Networking 设计

📊 Operations

• CLI + Extension统一版本管理
• Local container registry（harbor / 自建）
• 离线 audit log→ 本地 SIEM
• Cluster snapshot / backup策略
• 升级演练→ 在测试集群先行验证

🔄 升级策略

• 不跨 version jump——按 release train 顺序
• Preview 不升级——等 GA
• 回滚方案——必须先验证
• 三方一致性——CLI / extension / Appliance 版本对齐

8. 与相关文档的衔接

本节与同目录其他文档的边界说明：

9. 官方要求 vs 企业建议 对照表

企业读者一眼就知道哪些是必须的、哪些是建议的——本页价值最高。