K8S 容器调度

王小工

已于 2024-08-19 11:09:00 修改

阅读量1.1k

点赞数 29

分类专栏：云原生文章标签： kubernetes 容器云原生

于 2024-08-19 09:45:28 首次发布

本文链接：https://blog.csdn.net/mqiqe/article/details/141239192

版权

云原生专栏收录该内容

24 篇文章 1 订阅

订阅专栏

在Kubernetes中，容器调度是一个自动化的过程，负责将容器（在Kubernetes中称为Pod）分配到集群中的合适节点上运行。这一过程由Kubernetes的调度器（kube-scheduler）控制，它通过一系列算法和策略来确保Pod被高效且合理地分配到节点上。以下是关于Kubernetes容器调度的详细解释：

一、调度器的作用

Kubernetes调度器是一个独立的控制平面组件，它负责监视新创建的Pod，这些Pod尚未被分配到节点上，或者Pod当前运行的节点不再满足其要求。调度器通过一系列算法和策略，为这些未调度的Pod找到一个最合适的节点来运行。

二、调度过程

Kubernetes的调度过程主要分为两个阶段：节点筛选（Predicates）和节点优先级选择（Priorities）。

节点筛选（Predicates）：

在此阶段，调度器会检查每个节点的资源是否满足Pod的需求，如CPU、内存、存储等。
同时，还会考虑Pod的亲和性（affinity）、节点的污点（taints）设置等因素，从而过滤出符合Pod运行条件的节点候选集。

节点优先级选择（Priorities）：

在筛选出的节点候选集中，调度器会根据一系列优先级函数为每个节点打分。
最终选择得分最高的节点来运行Pod。如果存在多个得分最高的节点，调度器会从中随机选取一个。

kube-scheduler工作流程

监听Pod创建事件：

kube-scheduler持续监听API服务器上的Pod创建事件。当有新Pod需要被调度时，kube-scheduler会介入处理。

预选阶段（Predicates）：

kube-scheduler遍历集群中的所有节点，应用一系列的预选策略来过滤节点。
预选策略包括但不限于：节点资源是否充足（如CPU、内存）、节点标签是否与Pod的NodeSelector匹配、节点上是否有与Pod请求的端口冲突等。
只有通过所有预选策略的节点才会被保留作为候选节点。

优选阶段（Priorities）：

在预选阶段之后，kube-scheduler会对剩余的候选节点应用一系列优选函数进行打分。
优选函数考虑的因素可能包括节点的资源空闲比例、负载均衡情况、节点的亲和性偏好等。
kube-scheduler根据优选函数的打分结果，选择分数最高的节点作为Pod的最终运行节点。

绑定Pod到节点：

kube-scheduler将Pod绑定到选定的节点上，并将这一信息更新到API服务器中。
被绑定的节点上的kubelet组件会从API服务器获取Pod的详细信息，并启动容器。

三、调度策略

Kubernetes提供了多种调度策略，以满足不同的应用场景和需求，包括：

优先级调度：通过配置不同的优先级规则，可以确保高优先级的Pod优先获得资源。
亲和性调度：允许Pod指定偏好运行在某些具有特定标签的节点上，或者避免运行在具有特定标签的节点上。
反亲和性调度：与亲和性调度相反，反亲和性调度用于确保Pod之间的分散性，避免它们运行在同一节点上。

策略：

NodeSelector：
用户可以在Pod的定义中指定NodeSelector，要求Pod只能被调度到具有特定标签的节点上。
这是一种简单且直接的调度方式，适用于基于节点标签进行调度的场景。
NodeAffinity：
NodeAffinity提供了比NodeSelector更灵活的调度规则，包括硬亲和性和软亲和性。
硬亲和性规则是强制性的，如果找不到满足条件的节点，Pod将保持未调度状态。
软亲和性规则是优先级的，调度器会尽量满足这些规则，但如果找不到完全满足条件的节点，也会选择其他节点来运行Pod。
PodAffinity和PodAntiAffinity：
这些调度策略允许用户根据Pod的标签来选择或避免与特定Pod调度到同一个节点上。
PodAffinity用于将具有相同或相似属性的Pod调度到同一个节点上，以优化缓存、数据局部性等。
PodAntiAffinity则用于将具有不同属性的Pod分散到不同的节点上，以提高应用的可用性和容错性。
污点和容忍度（Taints and Tolerations）：
污点（Taints）允许节点拒绝某些Pod的调度，除非这些Pod声明了能够容忍节点的污点。
容忍度（Tolerations）是Pod定义中的一个字段，用于指定Pod能够容忍哪些节点的污点。
这种机制提供了一种灵活的方式来控制Pod的调度位置，特别是当某些节点具有特殊属性（如只能运行特定类型的Pod）时。

四、自定义调度策略

Kubernetes允许用户根据需要自定义调度策略，主要通过定义自定义的Predicates和Priorities来实现。此外，用户还可以通过设置节点亲和性和污点来进一步细化调度策略。

如果内置的kube-scheduler无法满足用户的特殊需求，用户可以编写自定义调度器。
自定义调度器需要监听API服务器上的Pod创建事件，并根据自己的调度算法来选择节点。
用户可以通过Pod的spec.schedulerName字段来指定使用哪个调度器（内置或自定义）。

五、使用示例

要使用Kubernetes进行容器调度，首先需要创建一个资源清单文件（YAML文件），其中包含了容器的资源需求和约束信息。然后，使用kubectl命令行工具将资源清单文件应用到Kubernetes集群中。调度完成后，可以使用kubectl命令行工具查看Pod的运行状态和所在的节点。

1. NodeSelector

节点标签：首先，用户需要为集群中的节点打上相应的标签。这些标签可以是任意的键值对，用于描述节点的特性，如硬件配置、地理位置、网络特性等。
Pod定义：在创建Pod时，用户可以在Pod的定义中指定NodeSelector。NodeSelector是一个字段，包含了一个或多个键值对，这些键值对需要与节点的标签相匹配。
调度过程：当Pod被创建时，Kubernetes调度器会检查Pod的NodeSelector，并遍历集群中的所有节点，寻找具有匹配标签的节点。如果找到匹配的节点，调度器就会将Pod调度到该节点上；如果没有找到匹配的节点，Pod将保持未调度状态，直到有节点满足条件或NodeSelector被修改。
使用场景
资源隔离：将不同类型的应用程序或服务调度到专门标记的节点上，以便更好地隔离资源，避免资源争用和干扰。
硬件约束：根据节点的硬件特性（如GPU、CPU架构等）将Pod调度到特定的节点上，以满足应用的硬件需求。
地理位置：在多地域集群中，通过NodeSelector将Pod调度到特定地理位置的节点上，以降低网络延迟和提高用户体验。
版本控制：将Pod调度到具有特定软件版本或配置的节点上，以便更好地控制应用程序的版本和兼容性。
示例

apiVersion: v1  
kind: Pod  
metadata:  
  name: example-pod  
spec:  
  containers:  
  - name: example-container  
    image: nginx  
  nodeSelector:  
    disktype: ssd

2. NodeAffinity

NodeAffinity允许开发者通过定义Pod与节点之间的亲和性关系，来影响Pod的调度位置。它允许用户根据节点的标签（Label）和表达式（Expression）来指定Pod应该被调度到哪些节点上，或者应该避免被调度到哪些节点上。

两种类型
1. 硬亲和性：
- 硬亲和性规则是强制性的。如果找不到满足条件的节点，Pod将保持未调度状态，直到有节点满足条件或NodeAffinity规则被修改。
- 它确保了Pod只能被调度到符合特定条件的节点上，有助于满足应用的硬件、软件或地理位置等需求。
1. 软亲和性：
- 软亲和性规则是优先级的。调度器会尽量满足这些规则，但如果找不到完全满足条件的节点，也会选择其他节点来运行Pod。
- 它提供了一种灵活的调度方式，允许在满足其他调度条件的前提下，优先将Pod调度到符合特定条件的节点上。
使用场景
1. 硬件约束：将需要特定硬件资源的Pod调度到具有相应硬件标签的节点上，如GPU、特定型号的CPU等。
2. 数据本地性：将依赖特定数据存储的Pod调度到具有相同存储特性的节点上，以减少数据访问延迟和提高性能。
3. 地理位置感知：将需要在同一地理位置运行的Pod调度到具有相同地理位置标签的节点上，以满足应用的地理位置要求。
4. 负载均衡：通过软亲和性规则，将Pod优先调度到负载较低的节点上，以实现集群的负载均衡。
示例

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: example-deployment  
spec:  
  replicas: 3  
  selector:  
    matchLabels:  
      app: example-app  
  template:  
    metadata:  
      labels:  
        app: example-app  
    spec:  
      containers:  
      - name: example-container  
        image: nginx  
      affinity:  
        nodeAffinity:  
          requiredDuringSchedulingIgnoredDuringExecution:  
            nodeSelectorTerms:  
            - matchExpressions:  
              - key: disktype  
                operator: In  
                values:  
                - ssd  
          preferredDuringSchedulingIgnoredDuringExecution:  
          - weight: 10  
            preference:  
              matchExpressions:  
              - key: zone  
                operator: In  
                values:  
                - us-west-1

注意事项

在使用NodeAffinity时，需要确保集群中有足够数量的节点具有匹配的标签，否则Pod可能会无法被调度。
NodeAffinity的表达式和操作符需要正确配置，以确保调度规则能够按预期工作。
硬亲和性规则是强制性的，如果配置不当可能会导致Pod无法被调度。因此，在配置硬亲和性规则时需要谨慎考虑。

3. PodAffinity（Pod亲和性）

定义：
PodAffinity使得一个Pod倾向于与其具有相同标签选择器的其他Pod安排在同一节点（或同一拓扑域），或者与具有特定标签的已运行Pod靠近。这有助于保持相关工作负载的紧密耦合，比如将微服务的多个组件部署在一起以减少网络延迟。
使用场景：

故障区域感知：将同一应用程序的Pod调度到不同的故障区域，提高应用程序的高可用性。
数据本地性：将需要紧密协同工作的Pod调度到同一节点，减少网络延迟，提高性能。
硬件依赖性：将依赖相同硬件资源的Pod调度到同一节点，避免硬件争用。
示例：

apiVersion: v1  
kind: Pod  
metadata:  
  name: my-pod  
spec:  
  affinity:  
    podAffinity:  
      requiredDuringSchedulingIgnoredDuringExecution:  
        - labelSelector:  
            matchExpressions:  
              - key: app  
                operator: In  
                values:  
                  - my-app  
          topologyKey: kubernetes.io/hostname

在这个示例中，requiredDuringSchedulingIgnoredDuringExecution规则表示，Pod在调度时必须被安排到与具有app=my-app标签的Pod相同的节点上（由topologyKey: kubernetes.io/hostname指定）。

4. PodAntiAffinity（Pod反亲和性）

定义：
PodAntiAffinity则确保一个Pod不与具有特定标签的已运行Pod安排在同一节点（或同一拓扑域），从而实现故障隔离或资源分散。例如，避免在同一节点上部署两个消耗大量内存的应用实例。
使用场景：

故障隔离：避免将所有副本或相关服务的实例部署在同一节点或同一可用区，以降低单点故障的风险。
资源隔离或竞争：防止资源消耗相似的Pod集中在一个节点上，导致资源争抢或过度使用。
示例：

apiVersion: v1  
kind: Pod  
metadata:  
  name: my-pod  
spec:  
  affinity:  
    podAntiAffinity:  
      requiredDuringSchedulingIgnoredDuringExecution:  
        - labelSelector:  
            matchExpressions:  
              - key: app  
                operator: In  
                values:  
                  - my-other-app  
          topologyKey: kubernetes.io/hostname

在这个示例中，requiredDuringSchedulingIgnoredDuringExecution规则表示，Pod在调度时必须被安排到与不具有app=my-other-app标签的Pod相同的节点上（由topologyKey: kubernetes.io/hostname指定），从而实现反亲和性。

5. Taints（污点）

Taints（污点）是一种节点属性，用于确保Pod不会被调度到不希望的节点上。污点可以被添加到节点上，以表示该节点具有某些不希望的特性或问题，比如节点正在维护中、节点具有特定的硬件或软件限制等。然后，只有那些能够容忍（Tolerate）这些污点的Pod才会被调度到这些节点上。

组成
三个部分组成：
1. key：污点的键，用于唯一标识污点。
2. value：污点的值，与键一起形成污点的唯一标识。这个值可以是空字符串，但在某些情况下，它可能包含有关污点性质的额外信息。
3. effect：污点的作用效果，它决定了Pod与污点节点的交互方式。Kubernetes定义了三种effect：
  - NoSchedule：如果节点上存在至少一个未被Pod容忍的污点，则Kubernetes不会将新的Pod调度到该节点上。但是，已经在该节点上运行的Pod不会被驱逐。
  - PreferNoSchedule：这是一个软性约束，Kubernetes会尽量避免将Pod调度到具有该污点的节点上，但如果没有其他更合适的节点，Pod仍然可能被调度到该节点上。
  - NoExecute（仅当节点出现问题时）：一旦节点上添加了具有NoExecute effect的污点，并且Pod不能容忍该污点，则Pod将被立即驱逐出节点。这通常用于节点维护或节点出现故障时。
设置和移除污点
可以使用kubectl taint命令来设置或移除节点的污点。
- 设置污点：

kubectl taint nodes <node-name> key=value:effect

例如，要给名为node1的节点添加一个key=specialUser、value=user1、effect=NoSchedule的污点，你可以运行：

kubectl taint nodes node1 specialUser=user1:NoSchedule

- 移除污点：

kubectl taint nodes <node-name> key:effect-

注意，在移除污点时，不需要指定value（如果value不是空字符串的话）。例如，要移除上面添加的污点，你可以运行：

kubectl taint nodes node1 specialUser:NoSchedule-

应用场景
污点和容忍度机制在Kubernetes中非常有用，可以用于多种场景，如：
节点维护：在节点进行维护之前，给节点添加污点，防止新的Pod被调度到该节点上。
资源隔离：将具有特殊资源需求的Pod调度到具有相应资源的节点上，通过给这些节点添加污点，并只给需要这些资源的Pod设置容忍度，实现资源隔离。
故障隔离：在节点出现故障时，给节点添加具有NoExecute effect的污点，将已经在该节点上运行的Pod驱逐出去，防止故障扩散。

6. Tolerations（容忍度）

Tolerations（容忍度）是Pod规格（spec）中的一部分，用于定义Pod能够容忍的节点上的Taints（污点）。当节点被标记了污点时，只有那些具有相应容忍度的Pod才能被调度到该节点上。这提供了一种机制，允许Pod根据节点的特定属性或条件进行调度。

组成
每个Toleration都由以下部分组成：
- key：可选。如果指定，则必须与节点上Taint的key相匹配。如果未指定，则Toleration将容忍所有具有相应effect的Taints，而不考虑它们的key和value。
- operator：可选。用于定义key与value的匹配方式。默认值为Equal，表示key和value都必须匹配。另一个可能的值是Exists，表示只需检查key是否存在，而不需要匹配value。
- value：可选。与key一起使用，表示要匹配的Taint的值。如果operator是Exists，则不需要指定value。
- effect：可选。表示Toleration可以容忍的Taint的effect。如果未指定，则Toleration将容忍所有具有相应key和value（如果指定了）的Taints，而不考虑它们的effect。但是，通常建议明确指定effect，以确保Pod只容忍期望的Taints。
- tolerationSeconds：可选。仅当effect为NoExecute时有效。表示Pod在节点上停留的最长时间（以秒为单位），在超过这个时间后，如果Pod仍然不能容忍节点的Taints，则Pod将被驱逐。
示例
以下是一个Pod的YAML定义示例，其中包含了对特定Taints的容忍度：

apiVersion: v1  
kind: Pod  
metadata:  
  name: my-pod  
spec:  
  containers:  
  - name: my-container  
    image: my-image  
  tolerations:  
  - key: "key1"  
    operator: "Equal"  
    value: "value1"  
    effect: "NoSchedule"  
  - key: "key2"  
    operator: "Exists"  
    effect: "NoExecute"  
    tolerationSeconds: 300

在这个示例中，Pod my-pod 定义了两个容忍度：
1. 第一个容忍度容忍了具有key1=value1和effect=NoSchedule的Taints。这意味着，即使节点上有这样的Taints，Pod仍然可以被调度到该节点上。
2. 第二个容忍度容忍了具有key2（不关心value）和effect=NoExecute的Taints，并且设置了tolerationSeconds为300秒。这意味着，如果节点上出现了这样的Taints，并且Pod已经在该节点上运行，Pod将在接下来的300秒内继续在该节点上运行。但是，如果300秒后Pod仍然不能容忍这些Taints（例如，如果Taints没有被移除或Pod没有更新其容忍度），则Pod将被驱逐出节点。

应用场景
Tolerations在Kubernetes中非常有用，特别是在以下场景中：
节点维护：在节点进行维护之前，给节点添加Taints，并通过在Pod上设置相应的Tolerations来允许特定的维护Pod被调度到这些节点上。
资源隔离：通过给具有特定资源的节点添加Taints，并只给需要这些资源的Pod设置Tolerations，可以实现资源隔离。
故障隔离：在节点出现故障时，给节点添加具有NoExecute effect的Taints，并设置tolerationSeconds，以便在一段时间内允许已经在该节点上运行的Pod完成其任务，然后再被驱逐出节点。