Azure Kubernetes Service (AKS) 基线集群

这个参考实现展示了一个通用 AKS 集群的推荐起点（基线）基础架构。本实现和文档旨在指导跨学科团队或多个不同团队（如网络、安全和开发团队）完成部署这个通用基线基础架构的过程，并理解其组成部分。

我们以相当详细的方式逐步介绍部署过程，以帮助您理解这个集群的每个组件，理想情况下，教会您每一层的知识，并为您提供必要的知识以应用到您的工作负载中。

Azure 架构中心指南

本项目有一系列配套文章，描述了安全 AKS 集群的挑战、设计模式和最佳实践。您可以在 Azure 架构中心找到这篇文章：Azure Kubernetes Service (AKS) 基线集群。如果您还没有阅读过，我们建议您阅读它，因为它将为本实现中应用的考虑因素提供额外的背景。最终，这是该特定架构指南的直接实现。

架构

这个架构更注重基础设施，而不是工作负载。它集中在 AKS 集群本身，包括身份、部署后配置、秘密管理和网络拓扑等问题。

这里呈现的实现是大多数 AKS 集群的最低推荐基线。这个实现集成了 Azure 服务，提供可观察性，提供支持多区域增长的网络拓扑，并保持集群内流量的安全。这个架构应被视为您在预生产和生产阶段的起点。

这里的材料相对密集。我们强烈建议您花时间仔细阅读这些说明，以学习为目的。因此，我们不提供任何"一键"部署。为了理解部署资源之间的关系，我们建议您在探索部署时参考详细的架构概览。一旦您理解了涉及的组件，并确定了您的团队和您的优秀组织之间的共同责任，我们鼓励您围绕最终的基础架构构建合适的、可审核的部署流程。

在整个参考实现中，您会看到对Contoso Bicycle的引用。它是一家虚构的小型且快速成长的初创公司，为北美西海岸的客户提供在线网络服务。他们没有本地数据中心，所有容器化的业务应用程序现在都将由安全、企业级的 AKS 集群进行编排。您可以阅读更多关于他们的需求和 IT 团队组成的信息。这个叙述为一些实现细节、命名约定等提供了基础。您应该根据需要进行调整。

最后，这个实现使用 ASP.NET Core Docker 示例 Web 应用作为示例工作负载。这个工作负载故意设计得不那么有趣，因为它仅用于帮助您体验基线基础架构。

核心架构组件

Azure 平台

AKS v1.30
- 系统和用户节点池分离
- AKS 托管的 Microsoft Entra ID 集成
- 基于 Microsoft Entra ID 的 Kubernetes RBAC（禁用本地用户帐户）
- 托管身份
- Azure CNI
- Azure Monitor for containers
Azure 虚拟网络（中枢-辐射型）
- Azure 防火墙管理的出口
Azure 应用程序网关（WAF）
AKS 托管的内部负载均衡器

集群内开源组件

Azure 工作负载身份 [AKS 托管插件]
Flux GitOps 操作员 [AKS 托管扩展]
ImageCleaner (Eraser) [AKS 托管插件]
Kubernetes 重启守护程序
Kubernetes 的 Secrets Store CSI 驱动程序 [AKS 托管插件]
Traefik 入口控制器

描绘具有两个对等 VNet 和架构中使用的主要 Azure 资源的中枢-辐射型网络的网络图。

同时不要忘记查看详细的架构图，以了解部署的资源如何在此参考架构中协同工作。

部署参考实现

AKS 托管工作负载的部署通常涉及先决条件、主机网络、集群基础架构和最终工作负载这些领域的职责分离和生命周期管理。不同的团队通常负责这些组件中的每一个。这个参考实现遵循类似的方法。此外，请注意我们的主要目的是说明基线集群的拓扑和决策。我们认为"逐步"流程将帮助您了解解决方案的各个部分，并让您深入了解它们之间的关系。最终，集群及其依赖项的生命周期/SDLC 管理将取决于您的情况（团队角色、组织标准等），并将根据您的需求进行适当实施。

请从准备集群部分开始这个学习旅程。 如果您一直跟随到最后，您将安装我们推荐的基线集群，并运行一个端到端的示例工作负载，供您在自己的 Azure 订阅中参考。

1. :rocket: 准备集群

在开始部署集群之前，必须解决一些考虑因素。我在订阅和 AD 租户中是否有足够的权限进行这么大规模的部署？有多少部分将由我的团队直接处理，而有多少部分将由另一个团队负责？

2. :electric_plug: 构建目标网络

Microsoft 建议将 AKS 部署到经过精心规划的网络中；根据您的需求适当调整大小，并具备适当的网络可观察性。组织通常倾向于传统的中枢-辐射模型，这在本实现中得到了体现。虽然这是一个标准的中枢-辐射模型，但其中包含了一些应该理解的基本规模和分配考虑因素。

构建中枢-辐射网络

3. :package: 部署集群

这是本参考实现指南的核心部分；与之前的网络拓扑指南配套。在这里，您将为集群部署 Azure 资源，以及相邻的服务，如 Azure 应用程序网关 WAF、Azure Monitor、Azure 容器注册表和 Azure Key Vault。这也是您将验证集群引导的地方。

我们在这里手动执行前面的步骤，以便您了解涉及的组件，但我们提倡使用自动化的 DevOps 流程。因此，将前面的步骤纳入您的 CI/CD 流水线中，就像您对待任何基础架构即代码（IaC）一样。有关更多详细信息，请参阅专门的 AKS 基线自动化指南。

4. :package: 部署您的工作负载

如果没有部署工作负载到集群，很难看出这些决策如何共同作用，成为您业务的可靠应用平台。这个工作负载的部署通常会遵循 CI/CD 模式，甚至可能涉及更高级的部署策略（如蓝/绿部署）。以下步骤代表了一个手动部署，适合用于说明此基础架构的目的。

5. :checkered_flag: 验证

现在集群和示例工作负载已经部署；是时候看看集群如何运作了。

执行端到端部署验证

:broom: 清理资源

在前面步骤中部署的大多数 Azure 资源将产生持续的费用，除非被移除。

清理所有资源

预览和附加功能

Kubernetes 及其扩展 AKS 是快速发展的产品。AKS 路线图展示了该产品变化之快。此参考实现确实依赖于 AKS 团队描述为"已发布并持续改进"的部分预览功能。其背后的理由是，许多预览功能仅在几个月内就会进入正式发布状态。如果你现在才开始设计集群，那么等到你准备投入生产时，很可能许多预览功能已经接近或已经正式发布。

此实现不会包含每个预览功能，而只包含那些为通用集群带来显著价值的功能。你可能希望在预生产集群中评估一些额外的预览功能，以增强安全性、可管理性等方面的能力。随着这些功能退出预览状态，本参考实现可能会更新以incorporatethem。考虑尝试并提供以下功能的反馈：

高级主题

本参考实现有意不涉及更高级的场景。例如，以下主题未被涉及：

关于 SDLC 和 GitOps 的集群生命周期管理
工作负载 SDLC 集成（包括 Bridge to Kubernetes、高级部署技术、Draft 等概念）
容器安全性
同一团队拥有的多个（相关或无关的）工作负载
不同团队拥有的多个工作负载（AKS 作为组织中的共享平台）
集群内状态（PV 和 PVC）
Windows 节点池
缩放到零的节点池和基于事件的缩放（KEDA）
Terraform
dapr

请继续关注，我们将提供这些主题的参考实现指南。未来提供的指南将以此基线 AKS 实现为起点。如果你想贡献或建议基于此基线的模式，请联系我们。

最后的想法

Kubernetes 是一个非常灵活的平台，为基础设施和应用程序运营者提供了多种选择，以实现其业务和技术目标。在你的journey中，你需要考虑何时依赖 Azure 平台功能、开源解决方案、支持渠道、法规遵从性和运营流程。我们鼓励将此参考实现作为你在自己团队内部开始架构对话的起点；根据你的具体要求进行调整，最终提供一个让客户满意的解决方案。