本文是AKS 基线体系结构的扩展，全面回顾了将 AKS 群集部署到生产环境中的建议配置。 本文的重点是提供有关在 AKS 上部署 Windows 容器的指导。 因此，本文重点介绍特定于在 AKS 上部署 Windows 的配置，可以参考 AKS 基线文档了解此处所述的配置。
请参阅 AKS Windows 基线 GitHub 项目，查看与此参考体系结构关联的参考实现，包括示例部署代码。
网络设计
此体系结构中使用的网络设计基于 AKS 基线体系结构中使用的设计，因此除以下更改外，与该设计共享所有核心组件。
- 添加了 Active Directory 域控制器以支持基于 Windows 的工作负载。
- 此体系结构中的入口解决方案使用 Azure Front Door (AFD) 和 Microsoft Entra 应用程序代理 (AAP)，而不是 AKS 基线体系结构中使用的 Azure 应用网关。
注意
将 Windows 工作负载迁移到 AKS 通常不包括主要重构工作，因此工作负载可能使用在本地相对容易实现但在 Azure 上却难以实现的功能。 例如使用 gMSA 和 Kerberos 身份验证的应用程序。 这是一个常见的用例，因此，此体系结构首先使用满足这些工作负载需求的组件。 具体而言，在入口路径中使用前端为 AFD 的 AAP。 如果工作负载不需要此支持，可以按照 AKS 入口基线中的相同指南进行操作。
入口设计
组件：
- 带有 WAF 的 Azure Front Door：AFD 是 AKS 群集上托管的应用面向公众的入口点。 此设计中使用 AFD 高级版，因为它允许使用专用链接，可以将内部应用流量锁定到专用网络，从而提供最高等级的安全性。 Web 应用程序防火墙 (WAF) 可提供针对常见的 Web 应用程序攻击和漏洞的保护。
- Microsoft Entra 应用程序代理：此组件充当 AKS 管理的内部负载均衡器前面的第二个入口点。 它启用了 Microsoft Entra ID 来预先验证用户身份，并使用条件访问策略来防止未经授权的 IP 范围（AAP 查看原始客户端 IP，并将其与条件访问策略进行比较）和用户访问该站点。 这是在使用支持 WAF 的 Azure 服务时路由 Kerberos 身份验证请求的唯一方法。 有关为受应用程序代理保护的应用提供单一登录访问的详细说明，请参阅使用应用程序代理通过 Kerberos 约束委派实现应用程序的单一登录 (SSO)
- 内部负载均衡器：由 AKS 管理。 此负载均衡器通过专用静态 IP 地址公开入口控制器。 它用作接收入站 HTTP 请求的单一联系点。
- 此体系结构中不使用群集内入口控制器（如 Nginx）。
若要实现此设计，必须将 AFD 配置为使用在该服务中发布应用时创建的应用程序代理 URL。 此配置将入站流量路由到代理，并允许预先进行身份验证。
注意
客户端源 IP 保留不受支持，因此应用程序架构师应计划替代措施，以便为依赖于源 IP 地址的应用在群集外对该逻辑外部化。
网络拓扑
下图显示了此体系结构中使用的中心辐射型网络设计。
下载此体系结构的 Visio 文件。
节点池拓扑
此体系结构使用三个节点池：运行 Linux 的系统节点池、运行 Linux 的用户节点池和运行 Windows 的用户节点池。 Windows 和 Linux 用户节点池用于工作负载，而系统节点池用于所有系统级配置，例如 CoreDNS。
入口流量流
- 客户端将 HTTPS 请求发送到域名：bicycle.contoso.com。 该名称与 Azure Front Door 公共 IP 地址的 DNS A 记录相关联。 此流量经过加密，以确保无法检查或更改客户端浏览器与网关之间的流量。
- Azure Front Door 有一个集成的 Web 应用程序防火墙 (WAF) 并为 bike.contoso.com 协商 TLS 握手，只允许安全密码。 Azure Front Door 网关是 TLS 终止点，因为需要它才能处理 WAF 检查规则，并执行将流量转发到所配置后端的传递规则。 TLS 证书存储在 Azure 密钥保管库中。
- AFD 将用户请求路由到 Azure 应用程序代理。 AFD 配置为仅允许 HTTPS 流量。 如果启用了预先身份验证，用户必须使用 Microsoft Entra ID 进行身份验证。
- 应用代理通过 AKS 负载均衡器将用户路由到后端应用容器。
注意
可以在流中的每个跃点强制实施端到端 TLS 流量，但在做出保护 Pod 到 Pod 流量的决策时，请衡量性能、延迟和操作影响。 对于大多数单租户群集，具有适当的控制平面 RBAC 和成熟的软件开发生命周期做法，强行加密到入口控制器并使用 Web 应用程序防火墙 (WAF) 保护后端就足够了。 此配置将最大限度地减少工作负载管理和网络性能影响的开销。 工作负载和合规性要求将决定执行 TLS 终止的位置。
出口流量流
AKS 基线文章中的所有指导均适用于此处，并针对 Windows 工作负载提供其他建议：为了实现 Windows Server 自动更新，切勿在 Azure 防火墙规则集中阻止所需的 FQDN。
注意
对基于 Linux 和基于 Windows 的工作负载使用单独的节点池需要使用节点选择器，以确保在部署给定工作负载时，根据工作负载类型将其部署到相应的节点池中。
IP 地址规划
与具有 Linux 节点池的 AKS 群集不同，具有 Windows 节点池的 AKS 群集需要 Azure CNI。 使用 Azure CNI 允许从 Azure 虚拟网络为 Pod 分配 IP 地址。 然后，Pod 可以通过 Azure 虚拟网络进行通信，就像任何其他设备一样。 它可以连接到其他 Pod、使用 ExpressRoute 或 VPN 连接到对等互连网络或本地网络，或者使用专用链接连接到其他 Azure 服务。
有关计划 AKS 基线体系结构文章中提供的 IP 地址的所有指导均适用于此处，此外还有一个建议：考虑为域控制器预配专用子网。 对于 Windows 节点池，建议通过单独的子网从逻辑上将其与其他节点池隔离开来。
节点池升级
升级 Windows 节点的过程与 Azure Kubernetes 服务 (AKS) 节点映像升级文档中提供的指导相同，但计划升级节奏时应考虑以下计划差异。
Microsoft 每月为节点提供新的 Windows Server 映像，包括最新的补丁，并且不执行自动修补或更新。 因此，必须根据此计划手动更新节点或以编程方式更新节点。 使用 GitHub Actions 创建按计划运行的 cron 作业，从而以编程方式计划每月升级。 上面链接的文档中提供的指导反映了 Linux 节点进程，但你可以更新 YAML 文件，将 cron 计划设置为每月运行一次，而不是每两周运行一次。 还需要将 YAML 文件中的“runs-on”参数更改为“windows-latest”，以确保升级到最新的 Windows Server 映像。
有关其他指导，请参阅关于工作器节点修补和更新的 AKS 操作员指导。
注意
必须先升级群集，然后才能执行节点和节点池升级。 请按照群集升级指导执行升级。
计算注意事项
与基于 Windows Server 的映像关联的较大映像需要在节点池中部署相应大小的 OS 磁盘。 仍建议对所有节点（包括 Windows 节点）使用临时 OS 磁盘，因此在计划部署时，请确保了解必须遵循的大小要求。
身份管理
Windows 容器无法加入域，因此如果需要 Active Directory 身份验证和授权，可以使用组托管服务帐户 (gMSA)。 若要使用 gMSA，必须在运行 Windows 节点的 AKS 群集上启用 gMSA 配置文件。 请参阅 gMSA AKS 文档，全面查看体系结构和关于启用配置文件的指导。
节点和 Pod 缩放
Windows 容器的群集自动缩放程序指导保持不变。 如需指导，请参阅群集自动缩放程序文档。
基线群集文档介绍了可用于 Pod 缩放的手动和自动缩放方法。 这两种方法都适用于运行 Windows 容器的群集，本文中提供的指导通常也适用于此处。
大多数情况下，Linux 容器和 Windows 容器在 Pod 缩放操作方面的区别在于映像的大小。 Windows 容器的映像大小越大，完成缩放操作的时间可能会越长，因此应该考虑一些有关缩放方法的注意事项。 由于 .NET 运行时的大小，此方案在旧版 .NET 应用程序中很常见。 为了缓解在缩放期间下拉取映像的延迟，可以使用 DaemonSet 将 ACR 中的映像下拉到每个 Windows 节点上的缓存，从而在预先加载映像后再启动 Pod。 此后，Pod 只需在联机之前运行为工作负载定义的应用配置过程。
应执行基准测试练习以了解执行缩放操作的时间影响，并且应根据业务需求权衡此数据。 如果工作负载需要通过自动缩放来更快地执行缩放，建议考虑以下备选的“热备用”解决方案：
首先需要执行基线测试，以确定需要在高峰负载时间和非高峰负载时间运行多少个 Pod。 建立此基线后，可以计划节点计数，以考虑在任何给定时间需要提供的节点总数。 此解决方案涉及对群集使用手动缩放，并将初始节点数设置为所需的非高峰节点数。 接近高峰时段时，需要提前缩放到节点的峰值负载时间数。 随着时间的推移，需要定期重新建立基线，以考虑应用使用情况或其他业务需求的变化。
监视
可以使用 Azure Monitor 和容器见解监视运行 Windows 的容器，这与 Linux 容器非常类似。 因此，AKS 基线文章中的大部分指导也适用于此处。 但是，Windows Server 群集的容器见解监视具有以下限制：
- Windows 没有内存 RSS 指标。 因此它不适用于 Windows 节点和容器。 可使用工作集指标
- 磁盘存储容量信息不适用于 Windows 节点。
还可以通过使用数据收集规则从 Windows Server 系统收集事件和性能计数器来补充容器见解。
注意
Windows Server 2022 操作系统的容器见解目前为公共预览版。
策略管理
AKS 基线文章中的所有策略指导均适用于 Windows 工作负载。 Azure Kubernetes 服务的 Azure Policy 内置定义参考文章中的其他特定于 Windows 的策略有：
- Kubernetes 群集 Windows 容器不应过度使用 CPU 和内存
- Kubernetes 群集 Windows 容器不应按 ContainerAdministrator 运行
- Kubernetes 群集 Windows 容器应仅使用已批准的用户和域用户组运行
群集引导
与 AKS 基线文章中提供的群集引导指导一样，群集操作员还应考虑其针对基于 Windows 的工作负载的引导方法。 AKS 基线文章中提供的相同指导也适用于此处。
成本管理
AKS 基线文章中的所有成本优化指导均适用于 Windows 工作负载。 应考虑的其他成本注意事项包括：
- Windows Server 的许可成本会增加 AKS 群集的节点成本。 此因素的成本优化建议包括保留容量或使用现有许可证（如果已有许可证用于其他业务用途）。
- 请参阅 Windows Server 的 Azure 混合权益 (AHUB) 文档，了解软件保障 (SA) 适用的 Windows Server 许可证的折扣。
- 有关将权益应用于新群集和现有群集的说明，请参阅 Windows Server 容器常见问题解答。
- 由于多个映像所需的存储量、从 ACR 拉取的并发节点数和异地复制要求，Windows 容器映像的大小可能会产生额外的 Azure 容器注册表 (ACR) 成本。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Isabelle Bersano | 云解决方案架构师
- Akshay Nimbalkar | 首席云解决方案架构师
- Clayton Siemens | 首席内容开发员
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
- 了解更多关于 Windows 容器的信息