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