通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Kubernetes 服务 (AKS) 中的中小型工作负荷性能和缩放的最佳做法

  • 项目

注意

本文重点介绍中小型工作负荷的常规最佳做法。 有关特定于大型工作负荷的最佳做法，请参阅Azure Kubernetes 服务 (AKS) 中的大型工作负荷的性能和缩放最佳做法。

在 AKS 中部署和维护群集时，以下最佳做法可以帮助优化性能和缩放。

本文介绍：

  • 用于自动缩放工作负荷的权衡和建议。
  • 根据工作负荷需求来管理节点缩放和效率。
  • 入口和出口流量的网络注意事项。
  • 监视控制平面和节点性能并对其进行故障排除。
  • 容量规划、激增方案和群集升级。
  • 数据平面性能的存储和网络注意事项。

应用程序自动缩放与基础结构自动缩放

应用程序自动缩放

处理成本优化或基础结构限制时，应用程序自动缩放非常有用。 配置良好的自动缩放程序可为应用程序维持高可用性，同时将成本降到最低。 无论需求如何，只需为维持可用性所需的资源付费。

例如，如果现有节点有足够空间，但子网中没有足够的 IP，那么它可能可以跳过创建新节点，立即在新 Pod 上开始运行应用程序。

水平 Pod 自动缩放

对于资源需求稳定且可预测的应用程序来说，实现水平 Pod 自动缩放非常有用。 水平 Pod 自动缩放程序 (HPA) 可动态缩放 Pod 副本数，从而有效地在多个 Pod 和节点之间分配负载。 这种缩放机制通常对那些可分解为较小的、独立的、可并行运行的组件的应用程序帮助最大。

HPA 默认提供资源利用率指标。 还可以集成自定义指标，或利用 Kubernetes 事件驱动自动缩放程序 (KEDA)（预览版） 等工具。 这些扩展使 HPA 能够基于多个角度和标准做出缩放决策，从而提供更全面的应用程序性能情况。 这对于具有不同复杂缩放要求的应用程序尤其有用。

注意

如果保持应用程序的高可用性是重中之重，我们建议为 HPA 的最小 Pod 数量留下稍高的缓冲区，以考虑缩放时间。

垂直 Pod 自动缩放

对于资源需求波动和不可预知的应用程序来说，实现垂直 Pod 自动缩放非常有用。 通过垂直 Pod 自动缩放程序 (VPA)，可以微调单个 Pod 的资源请求（包括 CPU 和内存），从而精确控制资源分配。 这种粒度可最大程度地减少资源浪费，并提高群集的整体利用效率。 VPA 还通过自动化资源分配、为关键任务腾出资源来简化应用程序管理。

警告

不应在同一 CPU 或内存指标上同时使用 VPA 和 HPA。 这种组合可能会导致冲突，因为两个自动缩放程序都会尝试使用相同的指标响应需求的变化。 但是，可以将 VPA 用于 CPU 或内存，HPA 用于自定义指标以防止重叠，并确保每个自动缩放程序侧重于工作负荷缩放的不同方面。

注意

VPA 基于历史数据工作。 建议在部署 VPA 后等待至少 24 小时再应用更改，给它足够的时间收集建议数据。

基础结构自动缩放

群集自动缩放

如果现有节点缺乏足够的容量，那么实现群集自动缩放会非常有用，因为它有助于纵向扩展和预配新节点。

在考虑群集自动缩放时，何时删除节点的决定涉及优化资源利用率和确保资源可用性之间的权衡。 消除未充分利用的节点可增强群集利用率，但可能导致新工作负荷需等待资源预配才能部署。 必须在这两个因素之间寻找符合群集和工作负荷要求的平衡，并相应地配置群集自动缩放程序配置文件设置。

群集自动缩放程序配置文件设置普遍应用于群集中所有启用自动缩放程序的节点池。 这意味着，一个启用自动缩放程序节点池中发生任何缩放操作，都可能会影响另一个节点池中的自动缩放行为。 请务必在所有相关节点池应用一致和同步的配置文件设置，以确保自动缩放程序按预期运行。

预配过度

超量预配是一种策略，通过确保有超量的可用资源来帮助降低应用程序压力的风险。 此方法特别适用于负载变化很大、群集缩放模式频繁纵向扩展和缩减的应用程序。

若要确定最佳超量预配量，可以使用以下公式：

1-buffer/1+traffic

例如，假设你希望避免在群集中达到 100% 的 CPU 使用率。 可以选择 30% 的缓冲区来保持安全系数。 如果预计平均流量增长率为 40%，则可以考虑过度预配 50%，如公式计算：

1-30%/1+40%=50%

有效的过度预配方法需要使用暂停 Pod。 暂停 Pod 是低优先级部署，可以轻松替换为高优先级部署。 创建低优先级 Pod，其唯一目的是保留缓冲区空间。 当高优先级 Pod 需要空间时，暂停 Pod 将被删除并重新安排在另一个节点或新节点上，以容纳高优先级 Pod。

以下 YAML 演示了示例暂停 Pod 清单：

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

节点缩放和效率

最佳做法指导：

仔细监视资源利用率和计划策略，以确保高效使用节点。

节点缩放允许根据工作负荷需求来动态调整群集中的节点数。 请注意，向群集添加更多节点并不总是提高性能的最佳解决方案。 为了确保最佳性能，应仔细监视资源利用率和计划策略，以确保高效使用节点。

节点映像

最佳做法指导：

使用最新的节点映像版本来确保具有最新的安全修补程序和 bug 修复。

使用最新的节点映像版本可提供最佳性能体验。 AKS 在每周映像版本中提供性能改进。 最新的 daemonset 映像缓存在最新的 VHD 映像上，从而降低了节点预配和启动的延迟。 更新滞后可能会对性能产生负面影响，因此请务必避免出现较大的版本差距。

Azure Linux

AKS 上的 Azure Linux 容器主机使用本机 AKS 映像，并为 Linux 开发提供单一位置。 每个包都是从源代码生成的并已经过验证，确保服务在已认证的组件上运行。

Azure Linux 是一个轻量级软件，只包含运行容器工作负荷所需的一组包。 它减小了受攻击面，消除了不必要的包的修补和维护工作。 Azure Linux 的基础层包含一个针对 Azure 优化的 Microsoft 强化内核。 此映像非常适合对性能敏感的工作负荷以及管理 AKS 群集群的平台工程师或操作员。

Ubuntu 2204

Ubuntu 2204 映像是 AKS 的默认节点映像。 它是针对运行容器化工作负荷而优化的轻型高效操作系统。 这意味着它可以帮助减少资源使用量并提高整体性能。 该映像包括最新的安全修补程序和更新，有助于确保工作负荷免受漏洞攻击。

Microsoft、Canonical 和 Ubuntu 社区完全支持 Ubuntu 2204 映像，可帮助你提高容器化工作负荷的性能和安全性。

虚拟机 (VM)

最佳做法指导：

选择虚拟机时，请确保 OS 磁盘和虚拟机 SKU 的大小和性能没有很大的差异。 大小或性能差异可能会导致性能问题和资源争用。

应用程序性能与工作负荷中使用的虚拟机 SKU 密切相关。 更大且功能更强大的虚拟机通常性能更好。 对于任务关键型工作负荷或产品工作负荷，建议至少使用具有 8 核 CPU 的虚拟机。 硬件代系较新（如 v4 和 v5）的虚拟机也有助于提高性能。 请记住，创建和缩放延迟可能因使用的虚拟机 SKU 而异。

使用专用系统节点池

为了缩放性能和可靠性，我们建议使用专用系统节点池。 使用此配置，专用系统节点池会为关键系统资源（如系统 OS 守护程序）保留空间。 然后，应用程序工作负荷可以在用户节点池中运行，以提高应用程序的可分配资源的可用性。 此配置还有助于缓解系统与应用程序之间的资源竞争风险。

创建操作

查看在创建预配期间已启用的扩展和加载项。 扩展和加载项可能会增加创建操作的总体持续时间的延迟。 如果不需要扩展或加载项，建议将其删除以降低创建延迟。

还可以使用可用性区域提供更高级别的可用性，以防止潜在的硬件故障或计划维护事件。 AKS 群集将资源分配到底层 Azure 基础结构的逻辑部分。 可用性区域在物理上将节点与其他节点分开，以帮助确保单个故障不会影响应用程序的可用性。 可用性区域仅在特定区域可用。 有关详细信息，请参阅 Azure 中的可用性区域。

Kubernetes API 服务器

LIST 和 WATCH 操作

Kubernetes 使用 LIST 和 WATCH 操作与 Kubernetes API 服务器交互，并监视有关群集资源的信息。 这些操作是 Kubernetes 执行资源管理的基础。

LIST 操作可检索符合特定条件的资源列表，例如特定命名空间中的所有 Pod 或群集中的所有服务。 如果想要大致了解群集资源，或者需要同时对多个资源进行操作，此操作非常有用。

LIST 操作可以检索大量数据，尤其是在拥有多个资源的大型群集中。 请注意，无限制或频繁调用 LIST 会在 API 服务器上造成大量负载，并且可能关闭响应时间。

WATCH 操作可执行实时资源监视。 在资源上设置 WATCH 时，只要该资源发生更改，API 服务器就会向你发送更新。 这对于控制器非常重要，例如依赖 WATCH 来维护所需资源状态的 ReplicaSet 控制器。

请注意，监视过多的可变资源或发出过多的并发 WATCH 请求可能会使 API 服务器不堪重负，并导致资源消耗过多。

为避免潜在问题并确保 Kubernetes 控制平面的稳定性，可以使用以下策略：

资源配额

实现资源配额，限制特定用户或命名空间可列出或监视的资源数，以防止调用过多。

API 优先级和公平性

Kubernetes 引入了 API 优先级和公平性 (APF) 的概念，用于确定和管理 API 请求的优先级。 可以在 Kubernetes 中使用 APF 来保护群集的 API 服务器，并减少客户端应用程序看到的 HTTP 429 Too Many Requests 响应数。

自定义资源 关键功能
PriorityLevelConfigurations • 为 API 请求定义不同的优先级。
• 指定唯一的名称并分配表示优先级的整数值。 优先级越高，整数值越小，表示它们更为关键。
• 可使用多个 PriorityLevelConfigurations，根据请求的重要性将其分到不同的优先级。
• 使你可以指定特定优先级的请求是否应受速率限制的约束。
FlowSchemas • 定义如何根据请求属性将 API 请求路由到不同的优先级。
• 根据 API 组、版本和资源等条件，指定与请求匹配的规则。
• 当请求与给定规则匹配时，请求会被定向到关联的 PriorityLevelConfiguration 中指定的优先级级别。
• 当多个 FlowSchemas 与请求匹配时，可用于设置评估顺序，以确保某些规则优先。

使用 PriorityLevelConfigurations 和 FlowSchemas 配置 API，可使关键 API 请求优先于不太重要的请求。 这可确保基本操作不会因优先级较低的请求而缺少资源或出现延迟。

优化标签和选择器

使用 LIST 操作时，优化标签选择器以缩小要查询的资源范围，以减少返回的数据量和 API 服务器上的负载。

在 Kubernetes 中，CREATE 和 UPDATE 操作是指管理和修改群集资源的操作。

CREATE 和 UPDATE 操作

CREATE 操作可在 Kubernetes 群集中创建新资源，例如 Pod、服务、部署、configmap 和机密。 在CREATE 操作期间，客户端（例如 kubectl 或控制器）将请求发送到 Kubernetes API 服务器以创建新资源。 API 服务器验证该请求，确保符合任何允许控制器策略，然后在群集所需的状态下创建资源。

UPDATE 操作可修改 Kubernetes 群集中的现有资源，包括对资源规格的更改，例如副本数量、容器映像、环境变量或标签。 在 UPDATE 操作期间，客户端会向 API 服务器发送请求以更新现有资源。 API 服务器会验证该请求，应用对资源定义的更改，并更新群集资源。

在下列情况下，CREATE 和 UPDATE 操作可能会影响 Kubernetes API 服务器的性能：

  • 高并发：当多个用户或应用程序发出并发的 CREATE 或 UPDATE 请求时，可能会导致同时到达服务器的 API 请求激增。 这可能会给 API 服务器的处理能力造成压力，导致性能问题。
  • 复杂的资源定义：过于复杂或涉及多个嵌套对象的资源定义会增加 API 服务器验证并处理 CREATE 和 UPDATE 请求所需的时间，这可能导致性能降低。
  • 资源验证和许可控制：Kubernetes 会对传入的 CREATE 和 UPDATE 请求强制实施各种许可控制策略和验证检查。 大型资源定义（例如具有大量注释或配置）可能需要更多的处理时间。
  • 自定义控制器：监视资源更改的自定义控制器（如部署或 StatefulSet 控制器）可能在缩放或推出更改时生成大量更新。 这些更新可能会给 API 服务器的资源造成压力。

有关详细信息，请参阅 对 AKS 中的 API 服务器和 etcd 问题进行故障排除。

数据平面性能

Kubernetes 数据平面负责管理容器和服务之间的网络流量。 数据平面的问题可能会导致响应时间变慢、性能下降和应用程序停机。 请务必仔细监视并优化数据平面配置，例如网络延迟、资源分配、容器密度和网络策略，以确保容器化应用程序顺利高效地运行。

存储类型

AKS 建议并默认使用临时 OS 磁盘。 临时 OS 磁盘是在本地虚拟机存储上创建的，不会保存到远程 Azure 存储（例如托管 OS 磁盘）。 它们的重新映像和启动时间更快，从而加快了群集操作，并降低了在 AKS 代理节点的 OS 磁盘上的读/写延迟。 临时 OS 磁盘适用于无状态工作负荷，其中应用程序可以容忍单个虚拟机故障，但不能容忍虚拟机部署时间或单个 虚拟机重置映像实例。 只有某些虚拟机 SKU 支持临时 OS 磁盘，因此需要确保与所需的 SKU 生成和大小兼容。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的临时 OS 磁盘。

如果工作负荷无法使用临时 OS 磁盘，AKS 默认使用高级 SSD OS 磁盘。 如果高级 SSD OS 磁盘与工作负荷不兼容，AKS 会默认使用标准 SSD 磁盘。 目前，唯一可用的其他 OS 磁盘类型是标准 HDD。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的存储选项。

下表提供了 AKS 支持的 OS 磁盘的建议用例明细：

OS 磁盘类型 关键功能 建议的用例
临时 OS 磁盘 • 重新映像和启动时间更快。
• 降低 AKS 代理节点的 OS 磁盘上的读/写延迟。
• 高性能和可用性。		 • 要求高的企业工作负荷，例如 SQL Server、Oracle、Dynamics、Exchange Server、MySQL、Cassandra、MongoDB、SAP Business Suite 等。
• 需要高可用性和低延迟的无状态生产工作负荷。
高级 SSD OS 磁盘 • 性能稳定，延迟低。
• 高可用性。		 • 要求高的企业工作负荷，例如 SQL Server、Oracle、Dynamics、Exchange Server、MySQL、Cassandra、MongoDB、SAP Business Suite 等。
• 输入/输出 (IO) 密集型企业工作负荷。
标准 SSD OS 磁盘 • 性能稳定。
• 与标准 HDD 磁盘相比，可用性和延迟更好。		 • Web 服务器。
• 每秒输入/输出操作数 (IOPS) 低的应用程序服务器。
• 轻度使用的企业应用程序。
• 开发/测试工作负荷。
标准 HDD 磁盘 • 成本低。
• 性能和延迟存在差异。		 • 备份存储。
• 不经常访问的大容量存储。

IOPS 和吞吐量

每秒输入/输出操作数 (IOPS) 是指磁盘每秒可以执行的读取和写入操作数。 吞吐量是指可以在给定时间段内传输的数据量。

OS 磁盘负责存储操作系统及其关联的文件，虚拟机负责运行应用程序。 选择虚拟机时，请确保 OS 磁盘和虚拟机 SKU 的大小和性能没有很大的差异。 大小或性能差异可能会导致性能问题和资源争用。 例如，如果 OS 磁盘比虚拟机小很多，则可能会限制应用程序数据可用的空间量，并导致系统磁盘空间耗尽。 如果 OS 磁盘的性能低于虚拟机，则它可能会成为瓶颈，限制系统的整体性能。 请确保大小和性能均衡，以确保 Kubernetes 的性能最佳。

可以使用以下步骤在 Azure 门户中监视 OS 磁盘上的 IOPS 和带宽计量：

  1. 导航到 Azure 门户。
  2. 搜索“虚拟机规模集”并选择你的虚拟机规模集。
  3. 在“监视”下，选择“指标”。

临时 OS 磁盘可以为应用程序提供动态 IOPS 和吞吐量，而托管磁盘的 IOPS 和吞吐量有上限。 有关详细信息，请参阅 Azure 虚拟机的临时 OS 磁盘。

Azure 高级 SSD v2 专为 IO 密集型企业工作负荷设计，这些工作负荷需要亚毫秒磁盘延迟、高 IOPS、高吞吐量和低成本。 它适用于各种工作负荷，例如 SQL Server、Oracle、MariaDB、SAP、Cassandra、MongoDB、大数据/分析、游戏等。 此磁盘类型是目前可用于永久性卷的最高性能选项。

Pod 调度

分配给虚拟机的内存和 CPU 资源会直接影响虚拟机上运行的 Pod 的性能。 创建 Pod 时，会为其分配一定的内存和 CPU 资源，用于运行应用程序。 如果虚拟机没有足够的内存或 CPU 资源可用，可能会导致 Pod 变慢甚至崩溃。 如果虚拟机可用的内存或 CPU 资源太多，可能会导致 Pod 运行效率低下，浪费资源并增加成本。 建议根据可分配的资源总量监视工作负荷中的 Pod 请求总数，以获得最佳的计划可预测性和性能。 也可以使用 --max-pods 根据容量规划设置每个节点的最大 Pod 数。