节点性能调优

要提高基于容器的应用的性能，一种方法是通过添加节点或向节点添加 CPU 或内存等资源来增加集群资源。然而，这种方法可能成本高昂。对集群节点进行调优以获得更好的性能，可帮助您以经济实惠的方式优化工作负载的资源利用率。本文档介绍了如何使用 Performance Tuning Operator 来调整工作器节点，以优化 GKE on Bare Metal 的工作负载性能。

为了充分利用底层硬件和软件，不同类型的应用（尤其是高性能应用）可以从节点设置调优中受益，如下所示：

专用于对性能敏感的工作负载的 CPU
标准 Kubernetes 守护程序和服务的预留 CPU
内存页大小增加，使用 1 GiB（吉比字节）或 2 MiB（兆比字节）大内存页
基于系统架构的工作负载分布，例如多核处理器和 NUMA

借助 Performance Tuning Operator，您可以通过创建应用性能配置的 Kubernetes 自定义资源来配置节点级性能设置。这样做有以下好处：

单一、统一的配置界面：使用 Performance Tuning Operator，您可以更新可应用于具有节点选择器的工作器节点的一个或多个 PerformanceTuningProfile 清单。您无需使用多个配置和政策设置单独配置每个节点。此方法可让您以统一的方式管理节点级和容器级配置。
持久性和可靠性：您还可以获得 Kubernetes 通过其高可用性架构提供的所有可靠性。PerformanceTuningProfile 自定义资源可以随时更新，并且其设置可以跨主要集群操作（如升级）持续保存。

Performance Tuning Operator 的工作方式是编排以下与性能相关的 Kubernetes 和操作系统 (OS) 功能和工具：

为防止冲突，当您使用 Performance Tuning Operator 时，建议您不要单独使用前面提到的 Kubernetes 和操作系统工具和功能。

前提条件和限制

以下是使用 Performance Tuning Operator 的前提条件和限制：

仅限 Red Hat Enterprise Linux (RHEL)：只有运行支持的 RHEL 版本的节点支持 Performance Tune Operator。
具有工作器节点的用户集群或混合集群：Performance Tuning Operator 仅支持与用户集群或混合集群中的工作器节点搭配使用。不支持使用 Performance Tuning Operator 为控制平面节点调优。Performance Tuning Operator 使用节点选择器来确定如何应用调优配置文件。为了确保仅将调优配置文件应用于工作器节点，每个配置文件自定义资源中的 nodeSelector 必须包含标准工作器节点标签 node-role.kubernetes.io/worker: ""。如果调节配置文件中的 nodeSelector 与控制平面节点上的标签匹配，则不会对该节点进行调优，并会设置错误条件。如需详细了解错误条件，请参阅检查状态。在安装 Performance Tuning Operator 并应用调优配置文件之前，请确保您的集群正常运行。
TuneD 2.22.0：Performance Tuning Operator 要求在要调优的工作器节点中预先安装 TuneD 2.22.0。如需详细了解 TuneD 相关信息（包括安装说明），请参阅 Red Hat Enterprise Linux 文档中的 TuneD 使用入门。Performance Tuning Operator 通过 cpu-partitioning 配置文件使用 TuneD。如果您没有此配置文件，可以使用以下命令进行安装：
```
dnf install -y tuned-profiles-cpu-partitioning
```
工作负载资源要求：要充分利用性能调优，您应该充分了解工作负载的内存和 CPU 要求（资源请求和限制）。
可用的节点资源：查明节点的 CPU 和内存资源。您可以在 /proc/cpuinfo 和 /proc/meminfo 文件中分别获取节点的详细 CPU 和内存信息。您还可以使用 kubectl get nodes 来检索工作器节点拥有的可供 Pod 使用的计算和内存资源 (status.allocatable) 的数量。
需要排空：在调优过程中，Performance Tuning Operator 首先排空节点，然后再应用调优配置文件。因此，在性能调优期间，节点可能会报告 NotReady 状态。我们建议您使用滚动更新策略 (spec.updateStrategy.type: rolling) 而不是批量更新，以最大限度地减少工作负载不可用。
需要重新启动：为了使节点调优更改生效，Performance Tuning Operator 会在应用调优配置文件后重新启动节点。

安装 Performance Tuning Operator

Performance Tuning Operator 主要由两个控制器（Deployment 和 DaemonSet）组成，它们会根据您的配置文件设置相互交互来对节点进行调优。默认情况下，Performance Tuning Operator 不会随 GKE on Bare Metal 安装。您可以从 Cloud Storage 下载 Performance Tuning Operator 清单，并使用 kubectl apply 在集群上创建 Performance Tuning Operator 资源。

如需为集群启用使用默认值的性能调优，请执行以下操作：

在管理员工作站上创建 performance-tuning 目录。
从 performance-tuning 目录中，从 Cloud Storage 版本存储桶下载最新的 Performance Tuning Operator 软件包：
```
gsutil cp -r gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 .
```
下载的文件包括 performance-tuning-operator Deployment 和 nodeconfig-controller-manager DaemonSet 的清单。此外，还包括相关功能（例如基于角色的访问权限控制 (RBAC) 和动态准入控制的清单。
以根用户身份，以递归方式将所有 Performance Tuning Operator 清单应用于用户（或混合）集群：
```
kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG
```
创建并运行 Deployment 和 DaemonSet 后，唯一的互动操作是修改和应用 PerformanceTuningProfile 清单。

查看工作负载的资源要求

在对节点进行调优之前，您需要了解工作负载的计算和内存资源要求。如果您的工作器节点有足够的资源，则可以保证节点在有保证的服务质量 (QoS) 类中为您的工作负载提供有保证的内存（标准和大内存页）。

Kubernetes 会根据您为关联容器指定的资源限制条件，为每个 Pod 分配 QoS 类。然后，Kubernetes 使用 QoS 类来确定如何调度 Pod 和容器并将资源分配给工作负载。为了充分利用工作负载的节点调优功能，您的工作负载必须具有 CPU 或内存资源请求或限制设置。

为了获得有保证的 QoS 类，您的 Pod 必须满足以下要求：

对于 Pod 中的每个容器：
- 为内存资源请求 (spec.containers[].resources.requests.memory) 和限制 (spec.containers[].resources.limits.memory) 指定值。
- 内存限制值必须等于内存请求值。
- 为 CPU 资源请求 (spec.containers[].resources.requests.cpu) 和限制 (spec.containers[].resources.limits.cpu) 指定值。
- CPU 限制值必须等于 CPU 请求值。

以下 Pod 规范摘录显示了满足有保证的 QoS 类要求的 CPU 资源设置：

spec:
  containers:
  - name: sample-app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "128Mi"
        cpu: "2"
      limits:
        memory: "128Mi"
        cpu: "2"
  ...

当您使用 kubectl get pods 检索 pod 详细信息时，status 部分应包含已分配的 QoS 类，如以下示例所示：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-09-22T21:05:23Z"
  generateName: my-deployment-6fdd69987d-
  labels:
    app: metrics
    department: sales
    pod-template-hash: 6fdd69987d
  name: my-deployment-6fdd69987d-7kv42
  namespace: default
  ...
spec:
  containers:
  ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-09-22T21:05:23Z"
    status: "True"
    type: Initialized
  ...
  qosClass: BestEffort
  startTime: "2023-09-22T21:05:23Z"

如需详细了解 QoS 类，请参阅 Kubernetes 文档中的 Pod 服务质量。如需了解如何配置 Pod 和容器以便为它们分配 QoS 类，请参阅配置 Pod 的服务质量。

CPU 要求

对节点进行调优时，您可以为 kubelet 和容器运行时等正在运行的 Kubernetes 系统守护程序指定一组预留的 CPU 核心 (spec.cpu.reservedCPUs)。这同一组预留的 CPU 也会运行操作系统守护程序，例如 sshd 和 udev。其余 CPU 核心分配为隔离。隔离的 CPU 适用于受 CPU 限制的应用，这些应用需要专用 CPU 时间，而不会受其他应用干扰或者被网络或其他设备中断。

如需在工作器节点的隔离的 CPU 上调度 Pod，请执行以下操作：

配置 Pod 以获得有保证的服务质量 (QoS)。
CPU 要求和限制必须以整数指定。如果您在 Pod 规范中指定部分 CPU 资源（例如 cpu: 0.5 或 cpu: 250m (250 millicores)），则无法保证调度。

内存要求

使用 Performance Tuning Operator 对节点进行调优时，您可以创建大内存页并将其与机器上的非统一内存访问 (NUMA) 节点关联。根据 Pod 和节点设置，您可以为 Pod 调度 NUMA 节点亲和性。

创建性能调优配置文件

安装 Performance Tune Operator 后，您可以仅与运行工作负载的集群进行交互。您可以直接在用户集群或混合集群上（而不是在管理员集群上）创建 PerformanceTuningProfile 自定义资源。每个 PerformanceTuningProfile 资源都包含一组参数，用于指定应用于节点的性能配置。

资源中的 nodeSelector 决定了应用调优配置文件的节点。如需将配置文件应用于节点，请将相应的键值对标签放置在节点上。调优配置文件应用于具有在 nodeSelector 字段中指定的所有标签的节点。

您可以在一个集群中创建多个 PerformanceTuningProfile 资源。如果有多个配置文件与给定节点匹配，则会在 PerformanceTuningProfile 自定义资源的 status 中设置错误条件。如需详细了解 status 部分，请参阅检查状态。

将 PerformanceTuningProfile 自定义资源的命名空间设置为 kube-system。

如需对一个或多个工作器节点进行调优，请执行以下操作：

修改 PerformanceTuningProfile 清单。

如需了解清单中的每个字段和示例清单，请参阅 PerformanceTuningProfile 资源参考文档。
（可选）对于要应用配置文件的工作器节点，请添加标签以匹配 spec.nodeSelector 键值对。

如果 PerformanceTuningProfile 自定义资源中未指定 spec.nodeSelector 键值对，则配置文件将应用于所有工作器节点。
将清单应用到您的集群。
```
kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG
```
替换以下内容：
- PROFILE_MANIFEST：PerformanceTuningProfile 自定义资源的清单路径。
- KUBECONFIG：集群 kubeconfig 文件的路径

移除调优配置文件

如需将节点重置为原始的未调优状态，请执行以下操作：

从集群中删除 PerformanceTuningProfile 自定义资源。
更新或移除节点上的标签，使其再次不会被调优配置文件选择。

如果您已将多个调优配置文件与节点关联，请根据需要重复上述步骤。

暂停调优配置文件

如果您需要对集群执行维护，可以通过修改 PerformanceTuningProfile 自定义资源来暂停调优。建议您在执行关键集群操作（例如集群升级）之前暂停调优。

您可能要暂停调优的另一种情况是应用配置文件失败。如果调优过程失败，则控制器可能会继续尝试对节点进行调优，这可能会导致节点反复重新启动。如果您发现节点状态在就绪和未就绪状态之间反复切换，请暂停调优，以便从损坏的状态中恢复。

如需暂停调优，请执行以下操作：

修改 PerformanceTuningProfile 自定义资源清单，将 spec.paused 设置为 true。
使用 kubectl apply 更新资源。

暂停性能调优后，Performance Tuning Operator 控制器会停止其所有操作。暂停可防止 Performance Tuning Operator 控制器操作与任何 GKE on Bare Metal 控制器操作发生冲突。

`PerformanceTuningProfile` 资源参考文档

本部分介绍 PerformanceTuningProfile 自定义资源中的每个字段。此资源用于为一个或多个集群节点创建调优配置文件。创建配置文件后，资源中的所有字段都是可变的。配置文件必须位于 kube-system 命名空间中。

具有 8 个 CPU 核心的节点的以下 numa 示例配置文件清单指定了下面的资源分配：

为 Kubernetes 系统开销预留 4 个 CPU 核心 (0-3)。
仅为工作负载预留 4 个 CPU 核心 (4-7)。
默认情况下，节点内存会拆分为 2 MiB 页面，而不是标准 4 Ki 页面。
预留 10 页大小为 1 GiB 的内存，供 NUMA 节点 0 使用。
预留 5 页大小为 2 MiB 的内存，供 NUMA 节点 1 使用。
拓扑管理器使用尽力而为政策来调度工作负载。

apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
  name: numa
  namespace: kube-system
spec:
  cpu:
    isolatedCPUs: 4-7
    reservedCPUs: 0-3
  defaultHugepagesSize: 2M
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  pages:
  - count: 10
    numaNode: 0
    size: 1G
  - count: 5
    numaNode: 1
    size: 2M
  topologyManagerPolicy: best-effort

您可以从集群中的 anthos.gke.io 组检索相关的 PerformanceTuningProfile 自定义资源定义。将预览功能注解添加到自行管理的集群资源后，系统就会安装自定义资源定义。

CPU 配置

属性	说明
`cpu.reservedCPUs`	必需。可更改。字符串。此字段定义一组要为 Kubernetes 系统守护程序（例如 kubelet、容器运行时和节点问题检测器）预留的 CPU 核心。这些 CPU 核心也用于操作系统 (OS) 系统守护程序，例如 `sshd` 和 `udev`。 `cpu.reservedCPUs` 字段获取 CPU 编号或 CPU 编号范围的列表。确保 CPU 列表与使用 `cpu.isolatedCPUs` 指定的列表不重叠。这两个字段中列出的 CPU 的并集必须包含节点的所有 CPU。
`cpu.isolatedCPUs`	可选。可更改。字符串。`cpu.isolatedCPUs` 字段定义一组专用于性能敏感应用的 CPU。根据 Kubernetes 服务质量 (QoS) 类，CPU 管理器仅在非预留的 CPU 上调度容器。为了确保工作负载在隔离的 CPU 上运行，请执行以下操作：使用有保证的 QoS 类配置 Pod和为 Pod 或容器分配 CPU 资源。为了进行有保证的 Pod 调度，您必须指定整数 CPU 单位，而不是部分 CPU 资源 (`cpu: "0.5"`)。 apiVersion: v1 kind: Pod ... spec: containers: ... resources: limits: cpu: "1" requests: cpu: "1" ... 为工作负载最大化隔离的 CPU 可提供最好的性能优势。此字段获取 CPU 编号或 CPU 编号范围的列表。确保 CPU 列表与使用 `cpu.reservedCPUs` 指定的列表不重叠，并且这两个字段中的列表并集包含节点的所有 CPU。
`cpu.balanceIsolated`	可选。可更改。布尔值。默认值：`true`。此字段指定隔离的 CPU 组是否有资格跨 CPU 组自动均衡工作负载。如果将此字段设置为 `false`，您的工作负载必须明确将每个线程分配给特定 CPU，才能将跨多个 CPU 分配负载。借助明确 CPU 分配，您可以获得有保证的工作负载的最可预测的性能，但会增加工作负载的复杂性。
`cpu.globallyEnableIRQLoadBalancing`	必需。可更改。布尔值。默认值：`true`。此字段指定是否为隔离的 CPU 组启用中断请求 (IRQ) 负载均衡。

内存配置

属性	说明
`defaultHugePageSize`	可选。可更改。枚举：`1G` 或 `2M`。此字段定义内核启动参数中的默认大内存页大小。大内存页在启动时碎片化内存之前分配。请务必注意，将大内存页的默认大小设置为 1G 会从节点中移除所有 2M 相关文件夹。默认的大内存页大小为 1G 会阻止您在节点中配置 2M 大型页面。
`pages`	可选。可更改。整数。此字段指定要在启动时创建的大内存页的数量。此字段接受页面数组。在指定大内存页之前，请检查节点的可用内存。请求的大内存页数量不要超过需求数量，也不要将所有内存都预留给大内存页。您的工作负载还需要标准内存。

节点选择

属性说明

属性	说明
`nodeSelector`	必需。可更改。此字段始终需要 Kubernetes 工作器节点标签 `node-role.kubernetes.io/worker:""`，这可确保仅在工作器节点上完成性能调优。此字段接受一个可选节点标签作为键值对。键值对标签用于选择具有匹配标签的特定工作器节点。当 `nodeSelector` 标签与工作器节点上的标签匹配时，性能配置文件将应用于该节点。如果您未在配置文件中指定键值标签，则会将配置文件应用于集群中的所有工作器节点。例如，以下 `nodeSelector` 指定调优配置文件仅应用于具有匹配的 `app: database` 标签的工作器节点： ... spec: nodeSelector: app: database node-role.kubernetes.io/worker: "" ...

nodeSelector

必需。可更改。此字段始终需要 Kubernetes 工作器节点标签 node-role.kubernetes.io/worker:""，这可确保仅在工作器节点上完成性能调优。此字段接受一个可选节点标签作为键值对。键值对标签用于选择具有匹配标签的特定工作器节点。当 nodeSelector 标签与工作器节点上的标签匹配时，性能配置文件将应用于该节点。如果您未在配置文件中指定键值标签，则会将配置文件应用于集群中的所有工作器节点。

例如，以下 nodeSelector 指定调优配置文件仅应用于具有匹配的 app: database 标签的工作器节点：


...
spec:
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  ...

Kubelet 配置

属性	说明
`topologyManagerPolicy`	可选。可更改。枚举：`none`、`best-effort`、`restricted` 或 `single-numa-node`。默认值：`best-effort`。此字段根据所分配的服务质量 (QoS) 类，指定用于为您的工作负载分配资源的 Kubernetes 拓扑管理器政策。如需详细了解如何分配 QoS 类，请参阅为 Pod 配置服务质量。

配置文件操作

属性	说明
`paused`	可选。可更改。布尔值。将 `paused` 设置为 `true` 以暂时阻止 DaemonSet 控制器对选定的节点进行调优。
`updateStrategy`	可选。可更改。指定将调优配置更改应用于选定的节点的策略。
`updateStrategy.rollingUpdateMaxUnavailalble`	可选。可更改。整数。默认值：`1`。指定可以同时调优的最大节点数。此字段仅在 `type` 设置为 `rolling` 时适用。
`updateStrategy.type`	可选。可更改。枚举：`batch` 或 `rolling`。默认值：`rolling`。指定如何将配置文件更新应用于选定的节点。如果您要同时将更新应用于所有选定的节点，请将 `type` 设置为 `batch`。默认情况下，更新会按顺序推进到各个节点。

检查状态

创建或更新 PerformanceTuningProfile 自定义资源后，控制器会根据资源中提供的配置对选定的节点进行调优。为了检查 PerformanceTuningProfile 的状态，我们在 Status 中公开了以下字段：

属性	说明
`conditions`	条件表示配置文件资源的当前状态的最新可用观察结果。
`conditions.lastTransitionTime`	始终返回。字符串（采用日期时间格式）。条件上次从一种状态转换到另一种状态的时间。此时间通常表示底层条件更改的时间。如果时间未知，则时间表示 API 字段更改的时间。
`conditions.message`	可选。字符串。人类可读的消息，指示有关转换的详细信息。此字段可能为空。
`conditions.observedGeneration`	可选。整数。如果设置，则此字段表示设置条件所基于的 `metadata.generation`。例如，如果 `metadata.generation` 为 `12`，但 `status.condition[x].observedGeneration` 为 `9`，则表示条件对于实例的当前状态已过时。
`conditions.reason`	必需。字符串。上次条件转换的原因。
`conditions.status`	必需。条件的状态：`True`、`False` 或 `Unknown`。
`conditions.type`	必需。类型是条件类型：`Stalled` 或 `Reconciling`。
`readyNodes`	已成功应用调优配置文件的节点数量。
`reconcilingNodes`	`nodeconfig-controller-manager` DaemonSet 正在与最新的调优配置文件进行协调的选定（或先前选定）节点的数量。
`selectedNodes`	已选择的备注的数量。也就是说，与此 `PerformanceTuningProfile` 自定义资源的节点选择器匹配的节点数量。