你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 架构良好的框架评审 - Azure Kubernetes 服务 (AKS)
本文提供了Azure Kubernetes 服务（AKS）的体系结构最佳做法。 本指南基于体系结构卓越五大支柱：
- 可靠性
- 安全性
- 成本优化
- 卓越运营
- 性能效率
我们假设你了解系统设计原则，了解Azure Kubernetes 服务的工作知识，并熟悉其功能。 有关详细信息，请参阅 Azure Kubernetes 服务。
先决条件
了解精心构建的框架支柱有助于生成高质量、稳定且高效的云体系结构。 建议使用 Azure 架构良好的框架评审评估来评审 工作负荷。
对于上下文，请考虑查看一个参考体系结构，以反映其设计中的这些注意事项。 建议从 Azure Kubernetes 服务 上的 Azure Kubernetes 服务 （AKS） 群集和微服务体系结构的基线体系结构开始。 另请查看 AKS 登陆区域加速器，该加速器提供体系结构方法和参考实现，以便为可缩放的 Azure Kubernetes 服务 （AKS） 群集准备登陆区域订阅。
可靠性
在云端，我们承认故障总会发生。 我们的目标不是试图防止各种故障，而是最大程度地减轻单个组件故障造成的影响。 使用以下信息将失败的实例降到最低。
使用 Azure Kubernetes 服务 讨论可靠性时，必须区分群集可靠性和工作负荷可靠性。 群集可靠性是群集管理员与其资源提供程序之间的共同责任，而工作负荷可靠性是开发人员的域。 Azure Kubernetes 服务针对这两个角色都提供了注意事项和建议。
在下面的设计清单和建议列表中，将发出标注，以指示每个选择是否适用于群集体系结构、工作负荷体系结构或两者。
设计清单
- 群集体系结构： 对于关键工作负荷，请使用 AKS 群集的可用性区域 。
- 群集体系结构： 规划 IP 地址空间，以确保群集能够可靠地缩放，包括处理多群集拓扑中的故障转移流量。
- 群集体系结构： 查看 使用 Azure Monitor 监视 Kubernetes 的最佳做法，以确定工作负荷的最佳监视策略。
- 工作负荷体系结构： 确保构建工作负载以支持水平缩放和报告应用程序准备情况和运行状况。
- 群集和工作负荷体系结构： 确保工作负荷在用户节点池上运行，并选择正确的大小 SKU。 至少包括两个用户节点池的节点，以及系统节点池的三个节点。
- 群集体系结构： 使用 AKS 运行时间 SLA 来满足生产工作负荷的可用性目标。
AKS 配置建议
浏览下表，以优化 AKS 配置的可靠性。
| 建议 | 好处 |
|---|---|
| 群集和工作负荷体系结构： 使用节点选择器和相关性控制 Pod 计划。 | 可让 Kubernetes 计划程序以逻辑方式按节点中的硬件隔离工作负荷。 与容忍不同，没有匹配节点选择器的 Pod 可以在标记的节点上计划，这允许节点上未使用的资源，但优先于定义匹配节点选择器的 Pod。 使用节点相关性可提供更高的灵活性，使你可以定义在 Pod 无法与节点匹配时所发生的情况。 |
| 群集体系结构： 确保根据网络要求和群集大小正确选择网络插件。 | 特定方案（例如基于 Windows 的节点池、特定网络要求和 Kubernetes 网络策略）需要使用 Azure CNI。 有关详细信息，请参阅 Kubenet 与 Azure CNI 。 |
| 群集和工作负荷体系结构： 对生产级群集使用 AKS 运行时间 SLA 。 | AKS 运行时间 SLA 保证： - 99.95%使用 Azure 可用性区域的 AKS 群集的 Kubernetes API 服务器终结点的可用性，或者- 不使用 Azure 可用性区域的 AKS 群集的可用性为 99.9%。 |
| 群集和工作负荷体系结构： 查看 使用 Azure Monitor 监视 Kubernetes 的最佳做法，以确定工作负荷的最佳监视策略。 | 空值 |
| 群集体系结构： 使用 可用性区域 通过跨物理独立数据中心分布 AKS 代理节点，最大程度地提高 Azure 区域中的复原能力。 | 通过将节点池分散到多个区域，即使另一个区域发生故障，一个节点池中的节点也会继续运行。 如果存在共置性要求，则可以使用基于 AKS 的常规虚拟机规模集部署到单个区域或邻近放置组，以最大程度地减少节点间延迟。 |
| 群集体系结构： 通过部署跨不同 Azure 区域部署的 AKS 群集来最大程度地提高可用性并提供业务连续性，从而采用 多区域策略 。 | 面向 Internet 的工作负荷应利用 Azure Front Door 或 Azure 流量管理器在 AKS 群集之间全局路由流量。 |
| 群集和工作负荷体系结构： 在应用程序部署清单中定义 Pod 资源请求和限制，并使用 Azure Policy 强制执行。 | 容器 CPU 和内存资源限制是必需的，以防止 Kubernetes 群集中的资源耗尽。 |
| 群集和工作负荷体系结构： 使系统节点池与应用程序工作负载保持隔离。 | 系统节点池需要至少 2 个 vCPU 和 4 GB 内存的 VM SKU，但建议使用 4 个 vCPU 或更高版本。 请参阅系统和用户节点池，了解详细要求。 |
| 群集和工作负荷体系结构： 根据特定要求将应用程序分开到专用节点池。 | 应用程序可以共享相同的配置，并且需要启用 GPU 的 VM、CPU 或内存优化 VM，或者能够缩放到零。 避免大量节点池，以减少额外的管理开销。 |
| 群集体系结构： 对运行多个并发出站连接的工作负荷的群集使用 NAT 网关。 | 为了避免Azure 负载均衡器并发出站流量限制的可靠性问题，我们改为使用 NAT 网关来支持大规模的可靠出口流量。 |
有关更多建议，请参阅 可靠性支柱的原则。
Azure Policy
Azure Kubernetes 服务提供各种适用于 Azure 资源（例如典型 Azure 策略）的内置 Azure 策略，以及使用适用于 Kubernetes 的 Azure Policy 加载项（也适用于群集中的 Azure Policy 加载项）。 这里总结了许多与此支柱相关的关键政策。 有关更详细的视图，请参阅 Kubernetes 的内置策略定义。
群集和工作负荷体系结构
- 群集已为 Pod 规范配置就绪情况或运行 情况运行状况探测 。
除了内置的 Azure Policy 定义之外，还可以为 AKS 资源和 Kubernetes 的 Azure Policy 加载项创建自定义策略。 这样，可以添加想要在群集和工作负荷体系结构中强制执行的其他可靠性约束。
安全性
安全是体系结构的首要考虑因素之一。 若要了解 AKS 如何增强应用程序工作负荷的安全性，建议查看 安全设计原则。 如果Azure Kubernetes 服务群集需要设计为运行符合支付卡行业数据安全标准（PCI-DSS 3.2.1）法规要求的敏感工作负荷，请查看 PCI-DSS 3.2.1 的 AKS 管控群集。
若要了解 AKS 的 DoD 影响级别 5（IL5）支持和要求，请查看 Azure 政府 IL5 隔离要求。
使用 Azure Kubernetes 服务 讨论安全性时，必须区分群集安全性和工作负荷安全性。 群集安全性是群集管理员与其资源提供程序之间的共同责任，而工作负荷安全性是开发人员的域。 Azure Kubernetes 服务针对这两个角色都提供了注意事项和建议。
在下面的设计清单和建议列表中，将发出标注，以指示每个选择是否适用于群集体系结构、工作负荷体系结构或两者。
设计清单
- 群集体系结构： 使用 托管标识 来避免管理和轮换服务原则。
- 群集体系结构： 将 Kubernetes 基于角色的访问控制 （RBAC） 与 Microsoft Entra ID 配合使用，实现 最低特权 访问，并最大程度地减少授予管理员权限以保护配置和机密访问。
- 群集体系结构：通过 Azure Sentinel 使用 Microsoft Defender for 容器来检测和快速响应群集和上运行的工作负载的威胁。
- 群集体系结构： 部署专用 AKS 群集，以确保将群集管理流量保留在专用网络上。 或使用非专用群集的 API 服务器允许列表。
- 工作负荷体系结构：使用Web 应用程序防火墙来保护 HTTP（S） 流量。
- 工作负荷体系结构： 确保使用容器感知扫描强化 CI/CID 管道。
建议
浏览下表，以优化 AKS 配置的安全性。
| 建议 | 好处 |
|---|---|
| 群集体系结构： 使用 Microsoft Entra 集成。 | 通过使用 Microsoft Entra ID，可以将标识管理组件集中在一起。 访问 AKS 群集时，用户帐户或组状态的任何更改会自动更新。 Kubernetes 群集的开发人员和应用程序所有者需要访问不同的资源。 |
| 群集体系结构：使用 Microsoft Entra ID 进行身份验证以Azure 容器注册表。 | AKS 和 Microsoft Entra ID 允许使用Azure 容器注册表进行身份验证，而无需使用imagePullSecrets机密。 有关详细信息，请查看从Azure Kubernetes 服务使用Azure 容器注册表进行身份验证。 |
| 群集体系结构： 使用 专用 AKS 群集保护到 API 服务器的网络流量。 | 默认情况下，节点池与 API 服务器之间的网络流量会传输Microsoft主干网络;通过使用专用群集，可以确保发到 API 服务器的网络流量仅保留在专用网络上。 |
| 群集体系结构： 对于非专用 AKS 群集，请使用 API 服务器授权 IP 范围。 | 使用公共群集时，仍可以使用授权的 IP 范围功能来限制可以访问群集 API 服务器的流量。 包括部署生成代理的公共 IP、操作管理和节点池出口点（如Azure 防火墙）等源。 |
| 群集体系结构： 使用 Microsoft Entra RBAC 保护 API 服务器。 | 要保护群集的安全，保护对 Kubernetes API 服务器的访问是你能够做的最重要的事情之一。 将 Kubernetes 基于角色的访问控制（RBAC）与 Microsoft Entra ID 集成，以控制对 API 服务器的访问。 禁用本地帐户 ，以使用Microsoft基于 Entra ID 的标识强制实施所有群集访问。 |
| 群集体系结构： 使用 Azure 网络策略 或 Calico。 | 保护和控制群集中 Pod 之间的网络流量。 |
| 群集体系结构： 使用 Azure Policy 保护群集和 Pod。 | Azure Policy 可帮助以集中、一致的方式在群集上大规模实施和保护。 它还可以控制向哪些函数授予 Pod，以及是否针对公司策略运行任何函数。 |
| 群集体系结构： 保护容器对资源的访问。 | 限制对容器可以执行的操作的访问。 提供最少权限数量，并避免使用根或特权提升。 |
| 工作负荷体系结构：使用Web 应用程序防火墙来保护 HTTP（S） 流量。 | 若要扫描传入流量以查找潜在的攻击，请使用 azure Web 应用程序防火墙（WAF）等 Web 应用程序防火墙Azure 应用程序网关或 Azure Front Door。 |
| 群集体系结构： 控制群集出口流量。 | 确保群集的出站流量通过网络安全点（例如Azure 防火墙或 HTTP 代理）传递。 |
| 群集体系结构：将开源Microsoft Entra 工作负荷 ID 和机密存储 CSI 驱动程序与 Azure 密钥库配合使用。 | 使用强加密保护并轮换 Azure 密钥库中的机密、证书和连接字符串。 提供访问审核日志，并将核心机密保留在部署管道中。 |
| 群集体系结构： 使用 Microsoft Defender for Containers。 | 监视和维护群集、容器及其应用程序的安全性。 |
有关更多建议，请参阅 安全支柱的原则。
Azure 顾问可帮助确保和改进 Azure Kubernetes 服务。 它针对以下策略部分中列出的项的子集提出建议，例如未配置 RBAC 的群集、缺少 Microsoft Defender 配置、对 API 服务器的不受限制的网络访问。 同样，它会为某些 Pod 安全计划项提供工作负荷建议。 查看建议。
策略定义
Azure Policy 提供适用于 Azure 资源和 AKS 的各种内置策略定义，例如标准策略定义，以及使用适用于 Kubernetes 的 Azure Policy 加载项（也适用于群集中）。 许多 Azure 资源策略同时出现在审核/拒绝中，但也出现在“部署 If Not Exists”变体中。
这里总结了许多与此支柱相关的关键政策。 有关更详细的视图，请参阅 Kubernetes 的内置策略定义。
群集体系结构
- Microsoft Defender for Cloud 策略
- 身份验证模式和配置策略（Microsoft Entra ID、RBAC、禁用本地身份验证）
- API 服务器网络访问策略，包括专用群集
群集和工作负荷体系结构
- 基于 Linux 的工作负载的 Kubernetes 群集 Pod 安全计划
- 包括 Pod 和容器功能策略，例如 AppArmor、sysctl、安全上限、SELinux、seccomp、特权容器、自动装载群集 API 凭据
- 装载、卷驱动程序和文件系统策略
- Pod/容器网络策略，例如主机网络、端口、允许的外部 IP、HTTP 和内部负载均衡器
Azure Kubernetes 服务部署通常也对 Helm 图表和容器映像使用Azure 容器注册表。 Azure 容器注册表还支持各种跨越网络限制、访问控制和 Microsoft Defender for Cloud 的 Azure 策略，这补充了安全的 AKS 体系结构。
除了内置策略之外，还可以为 AKS 资源和 Kubernetes 的 Azure Policy 加载项创建自定义策略。 这样，可以添加想要在群集和工作负荷体系结构中强制执行的其他安全约束。
有关更多建议，请参阅 AKS 安全概念，并根据 CIS Kubernetes 基准评估安全强化建议。
成本优化
成本优化涉及了解各种配置选项和建议的最佳做法，以减少不必要的支出和提高运营效率。 在遵循本文中的指南之前，建议查看以下资源：
- 成本优化设计原则。
- 与 Amazon Elastic Kubernetes 服务（Amazon EKS）相比，Azure Kubernetes 服务（AKS）中的定价和成本管理的工作原理。
- 如果在本地或边缘运行 AKS，则Azure 混合权益还可用于在这些方案中运行容器化应用程序时进一步降低成本。
在讨论使用 Azure Kubernetes 服务优化成本时，请务必区分群集资源的成本和工作负载资源的成本。 群集资源是群集管理员及其资源提供程序的共同责任，而工作负载资源则属于开发人员的范畴。 Azure Kubernetes 服务针对这两个角色都提供了注意事项和建议。
在 设计清单 和建议 列表中，将发出标注，以指示每个选择是否适用于群集体系结构、工作负荷体系结构或两者。
有关群集成本优化，请转到 Azure 定价计算器，并从可用产品中选择Azure Kubernetes 服务。 可以在计算器中测试不同的配置和付款计划。
设计清单
- 群集体系结构：在需要长期容量的每个节点池和预留实例上使用适当的 VM SKU。
- 群集和工作负载体系结构：使用适当的托管磁盘层和大小。
- 群集体系结构：查看性能指标（首先查看 CPU、内存、存储和网络），按群集、节点和命名空间确定成本优化机会。
- 群集和工作负荷体系结构： 使用自动缩放程序在工作负荷不太活跃时进行缩减。
建议
浏览以下建议表，优化 AKS 配置以降低成本。
| 建议 | 好处 |
|---|---|
| 群集和工作负荷体系结构： 使 SKU 选择和托管磁盘大小与工作负荷要求保持一致。 | 将所选内容与工作负载需求相匹配可确保不为不需要的资源付费。 |
| 群集体系结构： 选择正确的虚拟机实例类型。 | 选择正确的虚拟机实例类型至关重要，因为它直接影响 AKS 上运行应用程序的成本。 选择没有适当利用率的高性能实例可能会导致浪费开支，而选择功能较弱的实例可能会导致性能问题并提高停机时间。 若要确定正确的虚拟机实例类型，请考虑工作负荷特征、资源要求和可用性需求。 |
| 群集体系结构：根据 Arm 体系结构选择虚拟机。 | AKS 支持 创建 Arm64 Ubuntu 代理节点，以及在群集中混合使用 Intel 和 ARM 体系结构节点，从而以更低的成本提高性能。 |
| 群集体系结构：选择 Azure 现成虚拟机。 | 现成虚拟机让你能在大幅折扣充分利用未利用的 Azure 容量（相比即用即付价格，最高可达 90%）。 如果 Azure 需要恢复容量，Azure 基础结构会逐出现场节点。 |
| 群集体系结构： 选择适当的区域。 | 由于许多因素，资源成本因 Azure 中的每个区域而异。 评估成本、延迟和符合性要求，以确保以经济高效方式运行工作负荷，并且不会影响最终用户或创建额外的网络费用。 |
| 工作负荷体系结构： 维护小型和优化的映像。 | 简化映像有助于降低成本，因为新节点需要下载这些映像。 以允许容器尽快启动的方式生成映像，以帮助避免应用程序启动时用户请求失败或超时，这可能会导致过度预配。 |
| 群集体系结构： 使 群集自动缩放程序 能够自动减少代理节点数，以响应资源容量过剩。 | 自动纵向缩减 AKS 群集中的节点数，使你可以在需求较低时运行高效的群集，并在需求返回时纵向扩展。 |
| 群集体系结构： 启用 节点自动预配 以自动选择 VM SKU。 | 节点自动预配简化了 SKU 选择过程，并根据挂起的 Pod 资源要求决定以最高效、最经济的方式运行工作负荷的最佳 VM 配置。 |
| 工作负荷体系结构： 使用 水平 Pod 自动缩放程序。 | 根据 CPU 使用率或其他选择指标（支持群集缩减操作）调整部署中的 Pod 数。 |
| 工作负荷体系结构： 使用 垂直 Pod 自动缩放程序 （预览版）。 | 对 Pod 进行权限化，并根据历史使用情况动态设置 请求和限制 。 |
| 工作负荷体系结构： 使用 Kubernetes 事件驱动的自动缩放 （KEDA）。 | 根据正在处理的事件数进行缩放。 从包含 50 多个 KEDA 缩放器的丰富目录中进行选择。 |
| 群集和工作负载体系结构： 采用云财务规则和文化做法来驱动云使用情况的所有权。 | 启用成本优化的基础是节省成本的群集的分散。 财务运营方法（FinOps）通常用于帮助组织降低云成本。 这是一种做法，涉及财务、运营和工程团队之间的协作，以推动成本节约目标的一致性，并为云成本带来透明度。 |
| 群集体系结构： 注册 Azure 预留 或 Azure 保存计划。 | 如果已正确规划容量，则工作负荷可预测且存在较长时间，请 注册 Azure 预留 或 节省计划 以进一步降低资源成本。 |
| 群集体系结构： 查看 使用 Azure Monitor 监视 Kubernetes 的最佳做法，以确定工作负荷的最佳监视策略。 | 空值 |
| 群集体系结构： 配置 AKS 成本分析加载项。 | 通过成本分析群集扩展，可以深入了解群集或命名空间中各种 Kubernetes 资源相关的成本。 |
有关更多建议，请参阅成本优化支柱的原则和Azure Kubernetes 服务中的优化成本。
策略定义
虽然没有与成本优化相关的内置策略，但可以为 AKS 资源和 Kubernetes 的 Azure Policy 加载项创建自定义策略。 这样，就可以添加想要在群集和工作负荷体系结构中强制执行的额外成本优化约束。
云效率
使工作负荷更具 可持续性和云效率，需要结合成本 优化、 减少碳排放和 优化能耗等工作。 优化应用程序的成本是使工作负荷更具可持续性的第一步。
了解如何在 Azure Kubernetes 服务 （AKS） 中的可持续软件工程原则中构建可持续高效的 AKS 工作负载。
卓越运营
监视和诊断至关重要。 不仅可以测量性能统计信息，还可以快速使用指标来排查和修正问题。 建议查看 卓越运营设计原则 和 第 2 天操作指南。
与 Azure Kubernetes 服务 讨论卓越运营时，必须区分群集卓越运营和工作负荷卓越运营卓越。 群集操作是群集管理员与其资源提供程序之间的共同责任，而工作负荷操作是开发人员的域。 Azure Kubernetes 服务针对这两个角色都提供了注意事项和建议。
在下面的设计清单和建议列表中，将发出标注，以指示每个选择是否适用于群集体系结构、工作负荷体系结构或两者。
设计清单
- 群集体系结构： 使用 Bicep、Terraform 或其他基于模板的部署。 确保所有部署都是可重复的、可跟踪的，并存储在源代码存储库中。
- 群集体系结构： 构建自动化过程，确保群集已启动并具有必要的群集范围配置和部署。 这通常使用 GitOps 执行。
- 工作负荷体系结构： 在软件开发生命周期内对工作负荷使用可重复和自动化的部署过程。
- 群集体系结构： 启用诊断设置以确保记录控制平面或核心 API 服务器交互。
- 群集和工作负荷体系结构： 查看 使用 Azure Monitor 监视 Kubernetes 的最佳做法，以确定工作负荷的最佳监视策略。
- 工作负荷体系结构： 工作负荷应设计为发出可收集的遥测数据，其中还应包括实时线和就绪状态。
- 群集和工作负荷体系结构： 使用面向 Kubernetes 的混沌工程做法来识别应用程序或平台可靠性问题。
- 工作负荷体系结构： 优化工作负荷以在容器中高效运行和部署。
- 群集和工作负荷体系结构： 使用 Azure Policy 强制实施群集和工作负荷治理。
建议
浏览下表，以优化 AKS 配置以用于操作。
| 建议 | 好处 |
|---|---|
| 群集和工作负荷体系结构： 查看 AKS 最佳做法 文档。 | 若要在 AKS 中成功生成和运行应用程序，需要了解和实施一些关键注意事项。 相关方面包括多租户和计划程序功能、群集和 Pod 安全性，或者业务连续性和灾难恢复。 |
| 群集和工作负荷体系结构： 查看 Azure Chaos Studio。 | Azure Chaos Studio 可帮助模拟故障并触发灾难恢复情况。 |
| 群集和工作负荷体系结构： 查看 使用 Azure Monitor 监视 Kubernetes 的最佳做法，以确定工作负荷的最佳监视策略。 | 空值 |
| 群集体系结构： 通过部署跨不同 Azure 区域部署的 AKS 群集来最大程度地提高可用性并提供业务连续性，从而采用 多区域策略 。 | 面向 Internet 的工作负荷应利用 Azure Front Door 或 Azure 流量管理器在 AKS 群集之间全局路由流量。 |
| 群集体系结构： 使用 Azure Policy 操作群集和 Pod 配置标准。 | Azure Policy 可帮助以集中、一致的方式在群集上大规模实施和保护。 它还可以控制向哪些函数授予 Pod，以及是否针对公司策略运行任何函数。 |
| 工作负荷体系结构： 在发布工程过程中使用平台功能。 | Kubernetes 和入口控制器支持许多高级部署模式，以包含在发布工程过程中。 考虑蓝绿部署或 Canary 发布等模式。 |
| 群集和工作负荷体系结构： 对于任务关键型工作负荷，请使用印章级蓝/绿部署。 | 自动化任务关键型设计领域，包括 部署和测试。 |
有关更多建议，请参阅 卓越运营支柱的原则。
Azure 顾问还就以下策略部分中列出的项的子集提出建议，例如不支持的 AKS 版本和未配置的诊断设置。 同样，它会围绕使用默认命名空间提出工作负荷建议。
策略定义
Azure Policy 提供适用于 Azure 资源和 AKS 的各种内置策略定义，例如标准策略定义，以及使用适用于 Kubernetes 的 Azure Policy 加载项（也适用于群集中）。 许多 Azure 资源策略同时出现在审核/拒绝中，但也出现在“部署 If Not Exists”变体中。
这里总结了许多与此支柱相关的关键政策。 有关更详细的视图，请参阅 Kubernetes 的内置策略定义。
群集体系结构
- 适用于 Kubernetes 的 Azure Policy 加载项
- GitOps 配置策略
- 诊断设置策略
- AKS 版本限制
- 阻止命令调用
群集和工作负荷体系结构
- Namespace部署限制
除了内置策略之外，还可以为 AKS 资源和 Kubernetes 的 Azure Policy 加载项创建自定义策略。 这样，可以添加想要在群集和工作负荷体系结构中强制执行的其他安全约束。
性能效率
性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 建议查看 性能效率原则。
使用 Azure Kubernetes 服务 讨论性能时，必须区分群集性能和工作负荷性能。 群集性能是群集管理员与其资源提供程序之间的共同责任，而工作负荷性能是开发人员的域。 Azure Kubernetes 服务针对这两个角色都提供了注意事项和建议。
在下面的设计清单和建议列表中，将发出标注，以指示每个选择是否适用于群集体系结构、工作负荷体系结构或两者。
设计清单
为Azure Kubernetes 服务做出设计选择时，请查看性能效率原则。
- 群集和工作负荷体系结构： 执行和迭代详细的容量计划练习，其中包括 SKU、自动缩放设置、IP 寻址和故障转移注意事项。
- 群集体系结构： 使 群集自动缩放程序 能够自动调整响应工作负荷需求中的代理节点数。
- 群集体系结构： 使用 水平 Pod 自动缩放程序 根据 CPU 利用率或其他选择指标调整部署中的 Pod 数。
- 群集和工作负荷体系结构： 执行持续负载测试活动，以练习 Pod 和群集自动缩放程序。
- 群集和工作负荷体系结构： 将工作负荷分成不同的节点池，允许独立缩放。
建议
浏览下表中的建议，以优化Azure Kubernetes 服务配置的性能。
| 建议 | 好处 |
|---|---|
| 群集和工作负荷体系结构： 制定详细的容量计划，并不断审查和修订。 | 正式化容量计划后，应通过持续观察群集的资源利用率来频繁更新它。 |
| 群集体系结构： 使 群集自动缩放程序 能够自动调整代理节点数，以响应资源约束。 | 通过自动增加或减少 AKS 群集中的节点数，你可以运行高效且具有成本效益的群集。 |
| 群集和工作负荷体系结构： 将工作负荷分成不同的节点池，并考虑 缩放 用户节点池。 | 与始终需要运行节点的系统节点池不同，用户节点池允许纵向扩展或缩减。 |
| 工作负荷体系结构： 使用 AKS 高级计划程序功能。 | 帮助控制需要资源的工作负荷的均衡。 |
| 工作负荷体系结构： 使用有意义的工作负荷缩放指标。 | 并非所有缩放决策都可以派生自 CPU 或内存指标。 缩放注意事项通常来自更复杂的甚至外部数据点。 使用 KEDA 基于特定于工作负荷的信号生成有意义的自动缩放规则集。 |
有关更多建议，请参阅 性能效率支柱的原则。
策略定义
Azure Policy 提供适用于 Azure 资源和 AKS 的各种内置策略定义，例如标准策略定义，以及使用适用于 Kubernetes 的 Azure Policy 加载项（也适用于群集中）。 许多 Azure 资源策略同时出现在审核/拒绝中，但也出现在“部署 If Not Exists”变体中。
这里总结了许多与此支柱相关的关键政策。 有关更详细的视图，请参阅 Kubernetes 的内置策略定义。
群集和工作负荷体系结构
- CPU 和内存资源限制
除了内置策略之外，还可以为 AKS 资源和 Kubernetes 的 Azure Policy 加载项创建自定义策略。 这样，可以添加想要在群集和工作负荷体系结构中强制执行的其他安全约束。