MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

Kubernetes 中如何高效进行资源调度

2024-05-235.4k 阅读

Kubernetes 资源调度基础

在 Kubernetes 环境中，资源调度是确保容器化应用高效运行的关键环节。Kubernetes 的调度器负责将 Pod 分配到集群中的节点上，这一过程涉及多个方面的考量，包括资源的可用性、节点的特性以及 Pod 的需求等。

资源类型认知

Kubernetes 主要管理两种类型的资源：可压缩资源（compressible resources）和不可压缩资源（incompressible resources）。

  • 可压缩资源：如 CPU，即使节点上运行的 Pod 对 CPU 需求超出了节点的供应能力，系统也不会立即终止 Pod，而是会降低这些 Pod 的 CPU 使用率。例如，一个 Pod 申请了 100m（即 0.1 个 CPU 核心）的 CPU 资源，当节点 CPU 资源紧张时，该 Pod 实际获得的 CPU 资源可能会小于 100m，但仍能继续运行。
  • 不可压缩资源：典型的如内存和存储。如果节点上没有足够的不可压缩资源来满足 Pod 的请求，Kubernetes 调度器将不会把该 Pod 调度到这个节点上。比如一个 Pod 请求 512MiB 的内存，而某个节点剩余内存不足 512MiB，该 Pod 就不会被调度到这个节点。

Pod 资源请求与限制

在定义 Pod 时，可以通过 resources 字段来设置资源的请求（requests）和限制（limits）。以下是一个简单的 Pod 资源设置示例：

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: resource-demo-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  • 请求（requests）：表示 Pod 运行时需要的最小资源量。调度器根据节点上的可用资源和 Pod 的请求来决定是否将 Pod 调度到该节点。例如，一个节点有 1GiB 内存和 2 个 CPU 核心，若有多个 Pod 请求的总内存超过 1GiB 或者总 CPU 超过 2 个核心，调度器会选择合适的节点或拒绝调度部分 Pod。
  • 限制（limits）：定义了 Pod 能够使用的最大资源量。如果 Pod 使用的资源超过了限制，对于 CPU 而言，Pod 会被限制在设定的 CPU 使用率内；对于内存，如果 Pod 试图使用超过限制的内存，容器可能会被 OOM（Out Of Memory） killer 终止。

节点亲和性与反亲和性

节点亲和性（Node Affinity）和反亲和性（Node Anti - Affinity）是 Kubernetes 调度器用来控制 Pod 调度到特定节点的重要机制。

节点亲和性

节点亲和性允许你定义 Pod 应该被调度到满足某些条件的节点上。有两种类型的节点亲和性：硬亲和性（requiredDuringSchedulingIgnoredDuringExecution）和软亲和性（preferredDuringSchedulingIgnoredDuringExecution）。

  • 硬亲和性示例：
apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
  containers:
  - name: with-node-affinity-container
    image: nginx

在这个例子中，requiredDuringSchedulingIgnoredDuringExecution 表示硬亲和性，Pod 只会被调度到具有 disktype=ssd 标签的节点上。如果集群中没有这样的节点，Pod 将一直处于 Pending 状态。

  • 软亲和性示例：
apiVersion: v1
kind: Pod
metadata:
  name: with-preferred-node-affinity
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: zone
            operator: In
            values:
            - zone1
  containers:
  - name: with-preferred-node-affinity-container
    image: nginx

这里的 preferredDuringSchedulingIgnoredDuringExecution 表示软亲和性，weight 表示权重，权重越高，调度器越倾向于将 Pod 调度到满足条件的节点上。即使没有 zone=zone1 的节点，Pod 也会被调度到其他节点。

节点反亲和性

节点反亲和性与亲和性相反，它定义了 Pod 不应该被调度到哪些节点上。同样有硬反亲和性和软反亲和性。

  • 硬反亲和性示例：
apiVersion: v1
kind: Pod
metadata:
  name: with-node-anti-affinity
spec:
  affinity:
    nodeAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: app
            operator: In
            values:
            - legacy-app
  containers:
  - name: with-node-anti-affinity-container
    image: nginx

此 Pod 不会被调度到具有 app=legacy-app 标签的节点上。

  • 软反亲和性示例：
apiVersion: v1
kind: Pod
metadata:
  name: with-preferred-node-anti-affinity
spec:
  affinity:
    nodeAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
          - key: role
            operator: In
            values:
            - master
  containers:
  - name: with-preferred-node-anti-affinity-container
    image: nginx

软反亲和性表示尽量不将 Pod 调度到具有 role=master 标签的节点上，但如果没有其他合适的节点，也会进行调度。

Pod 亲和性与反亲和性

Pod 亲和性与反亲和性允许根据已运行的 Pod 来决定新 Pod 的调度位置，这对于一些特定的应用场景，如分布式系统中的组件部署非常有用。

Pod 亲和性

Pod 亲和性使得新 Pod 能够被调度到与某些已存在 Pod 相同的拓扑域（如节点、机架、区域等）中。

  • 基于拓扑域的 Pod 亲和性示例：
apiVersion: v1
kind: Pod
metadata:
  name: pod - affinity - example
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod - affinity - container
    image: nginx

在这个例子中，新 Pod 会被调度到与具有 app=database 标签的 Pod 相同的节点（kubernetes.io/hostname 为拓扑键）上。如果没有符合条件的节点，Pod 将处于 Pending 状态。

Pod 反亲和性

Pod 反亲和性确保新 Pod 不会被调度到与某些已存在 Pod 相同的拓扑域中。

  • 基于拓扑域的 Pod 反亲和性示例：
apiVersion: v1
kind: Pod
metadata:
  name: pod - anti - affinity - example
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - frontend
        topologyKey: kubernetes.io/hostname
  containers:
  - name: pod - anti - affinity - container
    image: nginx

此新 Pod 不会被调度到与具有 app=frontend 标签的 Pod 相同的节点上。通过 Pod 亲和性与反亲和性，可以更好地组织和管理应用组件在集群中的分布，提高系统的可靠性和性能。

污点（Taints）与容忍（Tolerations）

污点和容忍是 Kubernetes 中用于控制节点与 Pod 调度关系的机制，它们可以确保某些节点只运行特定的 Pod。

污点

污点是应用在节点上的标记，它使得节点拒绝接受不具有对应容忍的 Pod。可以通过 kubectl taint 命令来给节点添加污点。例如，给名为 node1 的节点添加一个污点：

kubectl taint nodes node1 key=value:NoSchedule

这里的 NoSchedule 是污点的效果，它表示没有对应容忍的 Pod 不会被调度到该节点。除了 NoSchedule，还有 PreferNoSchedule（尽量不调度）和 NoExecute（不仅不调度，已运行的 Pod 若不匹配容忍也会被驱逐）等效果。

容忍

容忍是定义在 Pod 上的属性，用于匹配节点上的污点。以下是一个包含容忍的 Pod 定义示例：

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-toleration
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
  containers:
  - name: pod-with-toleration-container
    image: nginx

在这个例子中，Pod 定义了一个容忍，它可以匹配节点上 key=value:NoSchedule 的污点，从而可以被调度到带有该污点的节点上。通过合理设置污点和容忍，可以实现对节点资源的精细化管理，例如将某些有特殊需求的 Pod 调度到特定的节点上，或者避免某些 Pod 被调度到不适合的节点。

资源配额与限制范围

为了在多租户或复杂的集群环境中更好地管理资源，Kubernetes 提供了资源配额（Resource Quotas）和限制范围（Limit Ranges）机制。

资源配额

资源配额用于限制命名空间（Namespace）内可以使用的资源总量。可以通过创建 ResourceQuota 对象来定义配额。例如，限制命名空间 my - namespace 内的 CPU 和内存使用：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute - resource - quota
  namespace: my - namespace
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

这个配额定义了 my - namespace 命名空间内所有 Pod 请求的 CPU 总量不能超过 1 个核心，请求的内存总量不能超过 1GiB，限制的 CPU 总量不能超过 2 个核心，限制的内存总量不能超过 2GiB。如果命名空间内的 Pod 资源请求超出这些配额，创建 Pod 的操作将会失败。

限制范围

限制范围用于为命名空间内的容器设置默认的资源请求和限制。可以通过创建 LimitRange 对象来定义限制范围。例如：

apiVersion: v1
kind: LimitRange
metadata:
  name: mem - cpu - limit - range
  namespace: my - namespace
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 250m
    defaultRequest:
      memory: 256Mi
      cpu: 125m
    type: Container

在这个例子中，对于 my - namespace 命名空间内的容器，如果没有在 Pod 定义中显式设置资源请求和限制，将使用 defaultRequest 和 default 中的值作为默认的请求和限制。这有助于确保命名空间内的容器使用合理的资源，避免因资源设置不当导致的问题。

调度器扩展与自定义调度

Kubernetes 的调度器是可扩展和可自定义的，这为满足不同的业务需求提供了灵活性。

调度器扩展点

Kubernetes 调度器提供了多个扩展点，允许开发者插入自定义的调度逻辑。主要的扩展点包括：

  • 预选（Predicates）：在预选阶段，调度器会根据一系列规则筛选出符合条件的节点。例如，默认的 PodFitsResources 预选规则会检查节点是否有足够的资源来满足 Pod 的请求。开发者可以编写自定义的预选规则，比如根据节点的网络带宽、地理位置等因素进行筛选。
  • 优选（Priorities）：在优选阶段，调度器会对预选通过的节点进行打分，选择得分最高的节点来运行 Pod。默认的优选规则包括 LeastRequestedPriority（优先选择资源请求最少的节点）等。开发者可以编写自定义的优选规则，如根据节点的负载均衡情况、节点的性能指标等进行打分。

自定义调度器

除了使用调度器扩展点，还可以开发完全自定义的调度器。这需要深入了解 Kubernetes 的调度器架构和 API。自定义调度器可以通过以下步骤实现：

  1. 实现调度逻辑：根据业务需求编写调度算法，包括预选和优选逻辑。例如，对于一个需要高 I/O 性能的应用，可以编写一个调度器，优先选择具有高性能存储设备的节点。
  2. 与 Kubernetes API 交互：使用 Kubernetes 的客户端库（如 Go 语言的 client - go）与 API Server 进行通信，获取节点、Pod 等资源信息，并将调度结果反馈给 API Server。
  3. 部署和配置：将自定义调度器作为一个独立的 Pod 部署到 Kubernetes 集群中，并通过配置文件指定使用自定义调度器来调度特定的 Pod。例如，可以在 Pod 的 spec.schedulerName 字段中指定自定义调度器的名称。

通过调度器扩展和自定义调度，可以更好地满足复杂的业务场景对资源调度的特殊需求，进一步提升 Kubernetes 集群的资源利用效率和应用运行的稳定性。

资源调度中的常见问题与解决方法

在 Kubernetes 资源调度过程中，可能会遇到各种问题，以下是一些常见问题及其解决方法。

Pod 长时间处于 Pending 状态

  • 原因分析：
    • 资源不足：集群中没有足够的资源来满足 Pod 的请求，如节点的 CPU、内存等资源已被其他 Pod 占用。
    • 调度规则不匹配：Pod 的亲和性、反亲和性、污点容忍等调度规则与节点的设置不匹配，导致没有合适的节点可供调度。
    • 网络问题：网络插件配置错误或网络故障，使得 Pod 无法与 API Server 通信，调度器无法正常工作。
  • 解决方法：
    • 增加资源：通过添加节点或调整现有节点的资源配置来增加集群的资源总量，或者调整其他 Pod 的资源请求，释放部分资源。
    • 检查调度规则：仔细检查 Pod 的调度规则设置，确保与节点的标签、污点等设置相匹配。例如，如果 Pod 设置了特定的节点亲和性，检查是否有节点满足该亲和性条件。
    • 排查网络问题：检查网络插件的配置，确保其正常运行。可以通过查看网络插件的日志、检查节点之间的网络连通性等方式来排查网络故障。

资源分配不均衡

  • 原因分析：
    • 调度算法局限性：默认的调度算法可能无法完全适应复杂的业务场景，导致资源分配不均衡。例如，某些节点可能被过度使用，而其他节点资源利用率较低。
    • 缺乏精细化控制：没有合理设置资源请求和限制，或者没有利用好节点亲和性、反亲和性等机制，使得 Pod 的分布不合理。
  • 解决方法：
    • 调整调度算法：可以考虑使用自定义调度器或利用调度器扩展点来优化调度算法。例如，根据业务需求开发一个更适合的优选算法，以平衡节点的资源负载。
    • 精细化资源管理：合理设置 Pod 的资源请求和限制，同时充分利用节点亲和性、反亲和性、Pod 亲和性、反亲和性以及污点容忍等机制，确保 Pod 在集群中的合理分布。例如，将对资源需求相似的 Pod 调度到不同的节点上，避免资源集中消耗。

调度性能问题

  • 原因分析：
    • 集群规模过大：随着集群中节点和 Pod 数量的增加，调度器的计算量和数据处理量也会大幅增加，可能导致调度性能下降。
    • 调度器配置不合理：调度器的参数配置不当，如预选和优选阶段的算法复杂度较高，或者资源检查频率设置不合理，都可能影响调度性能。
  • 解决方法：
    • 优化集群架构：对于大规模集群，可以考虑采用分层调度、联邦集群等架构来减轻调度器的负担。例如，通过分层调度，将一部分调度决策下放到子集群或节点本地，减少全局调度的计算量。
    • 调整调度器配置：根据集群的实际情况，合理调整调度器的参数。例如，优化预选和优选算法，降低算法复杂度；调整资源检查频率，在保证调度准确性的前提下提高调度效率。同时，也可以考虑使用性能更高的硬件来运行调度器。

通过对这些常见问题的分析和解决，可以确保 Kubernetes 资源调度的高效运行，为容器化应用提供稳定的运行环境。

资源调度的监控与优化

为了保证 Kubernetes 中资源调度的高效性，监控与优化是必不可少的环节。

资源调度监控指标

  • 节点资源指标：
    • CPU 使用率：反映节点 CPU 资源的使用情况。过高的 CPU 使用率可能导致新的 Pod 无法调度到该节点，或者已运行的 Pod 性能下降。可以通过 kubectl top nodes 命令查看节点的 CPU 使用率。
    • 内存使用率：显示节点内存资源的占用比例。与 CPU 类似，高内存使用率可能影响 Pod 的调度和运行。同样可以通过 kubectl top nodes 命令获取。
    • 磁盘使用率：对于存储敏感的应用，磁盘使用率是一个重要指标。高磁盘使用率可能导致 Pod 写入数据缓慢甚至失败。可以通过在节点上执行 df -h 等命令查看磁盘使用率。
  • Pod 资源指标：
    • CPU 请求与使用：通过 kubectl describe pod 命令可以查看 Pod 的 CPU 请求量，通过 kubectl top pods 命令可以查看 Pod 的当前 CPU 使用量。对比两者可以了解 Pod 的资源使用效率。
    • 内存请求与使用：与 CPU 类似，通过相关命令可以获取 Pod 的内存请求和使用情况，以判断 Pod 是否合理使用内存资源。
  • 调度指标：
    • Pending Pod 数量：长时间存在大量 Pending Pod 可能意味着集群资源不足或调度规则存在问题。可以通过 kubectl get pods --field - selector=status.phase=Pending 命令查看 Pending Pod 的数量。
    • 调度延迟：指从 Pod 创建到被调度到节点上的时间间隔。较长的调度延迟可能影响应用的启动速度和可用性。可以通过分析事件日志或使用专门的监控工具来获取调度延迟指标。

基于监控的优化策略

  • 资源调整：根据节点和 Pod 的资源使用情况，适时调整资源请求和限制。例如，如果某个 Pod 的 CPU 使用量长期低于请求量，可以适当降低其 CPU 请求，以释放资源给其他 Pod。对于节点资源使用率过高的情况，可以考虑增加节点资源或迁移部分 Pod 到其他节点。
  • 调度规则优化：基于调度指标的监控结果，优化调度规则。如果发现某些 Pod 因为节点亲和性规则导致长时间无法调度，可以适当放宽亲和性条件。或者根据 Pod 的实际运行情况，调整 Pod 亲和性与反亲和性规则，以提高 Pod 的分布合理性。
  • 性能优化：针对调度性能问题，如调度延迟较长，可以优化调度器的算法和配置。例如，减少不必要的预选和优选规则，提高调度器的计算效率。同时，根据集群规模和负载情况，合理调整调度器的资源分配，确保其能够高效运行。

通过持续监控资源调度相关指标，并基于监控结果进行优化，可以不断提升 Kubernetes 集群资源调度的效率和应用的运行性能。

高级资源调度技术与实践

在复杂的生产环境中，还需要运用一些高级资源调度技术来满足多样化的业务需求。

优先级调度

Kubernetes 支持为 Pod 设置优先级，调度器会优先调度优先级高的 Pod。可以通过创建 PriorityClass 对象来定义优先级类，然后在 Pod 中引用该优先级类。例如：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high - priority - class
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority service pods only."

然后在 Pod 中引用该优先级类：

apiVersion: v1
kind: Pod
metadata:
  name: high - priority - pod
spec:
  priorityClassName: high - priority - class
  containers:
  - name: high - priority - container
    image: nginx

这样，在资源紧张时，具有 high - priority - class 优先级类的 Pod 会优先于其他低优先级 Pod 被调度。优先级调度在处理关键业务应用、应急任务等场景中非常有用。

弹性资源调度

弹性资源调度允许根据集群的负载情况动态调整资源分配。Kubernetes 的 Horizontal Pod Autoscaler（HPA）和 Vertical Pod Autoscaler（VPA）是实现弹性资源调度的重要工具。

  • Horizontal Pod Autoscaler（HPA）：根据 Pod 的 CPU 使用率或其他自定义指标自动调整 Pod 的副本数量。例如，通过以下命令创建一个基于 CPU 使用率的 HPA：
kubectl autoscale deployment my - deployment --cpu - percent=50 --min=1 --max=10

这将根据 my - deployment 中 Pod 的 CPU 使用率自动调整 Pod 副本数量，使其保持在 1 到 10 个之间，当 CPU 使用率超过 50% 时增加副本，低于 50% 时减少副本。

  • Vertical Pod Autoscaler（VPA）：根据 Pod 的资源使用情况自动调整 Pod 的资源请求和限制。可以通过创建 VerticalPodAutoscaler 对象来启用 VPA。例如：
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
  name: my - vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my - deployment
  updatePolicy:
    updateMode: Auto

VPA 会定期分析 my - deployment 中 Pod 的资源使用情况，并自动调整其资源请求和限制，以提高资源利用率。

多集群资源调度

在大型企业环境中，可能会存在多个 Kubernetes 集群。多集群资源调度可以跨多个集群分配 Pod，以实现资源的全局优化。Kubernetes 提供了 Cluster Federation 等机制来实现多集群资源调度。通过将多个集群组成一个联邦，可以在联邦层面进行统一的资源调度和管理。例如，可以根据不同集群的资源特点和负载情况，将特定类型的 Pod 调度到最合适的集群中，提高整体资源利用效率和应用的容灾能力。

这些高级资源调度技术在复杂的生产环境中能够有效提升资源的利用效率、应用的性能和可靠性，满足企业多样化的业务需求。

通过以上对 Kubernetes 中资源调度的全面深入介绍，从基础概念到高级技术，再到常见问题解决和监控优化，希望能帮助开发者和运维人员更好地掌握和运用 Kubernetes 的资源调度功能，构建高效稳定的容器化应用环境。在实际应用中，需要根据具体的业务场景和需求，灵活运用各种资源调度策略和技术，不断优化资源调度效果，以实现最佳的应用运行性能和资源利用效率。