Kubernetes学习笔记——Pod调度

学习笔记 , , 评论

0x01. Deployment/RC全自动调度

效果：在集群内始终维持用户指定的副本数量

使用：spec.replicas

原理：系统自动调度算法。由Master的Scheduler经过一系列算法计算得出，用户无法干预调度过程和结果。

0x02. NodeSelector

效果：通过Node的标签和Pod的nodeSelector属性进行匹配，将Pod调度到指定的Node上

使用：

  1. 为目标Node打标签

    1
    kubectl label nodes <node-name> <label-key>=<label-value>

  2. 在Pod定义中加上nodeSelector的设置

    1
    2
    3
    4
    #pod.yaml
    ...
    nodeSelector:
        <label-key>: <your-selected-label-name>

补充：

  • 如果多个Node定义了相同的标签，则会根据调度算法从这组Node中挑选一个可用的Node进行调度
  • 若Pod指定的nodeSelector条件集群中不存在符合的节点，则该Pod无法被成功调度，即使集群中还有可用的Node

0x03. 亲和性调度

篇幅原因，另外一篇单独记录

0x04. 污点(Taints)和容忍(Tolerations)

效果：Pod无法在标记了Taint属性的节点上运行, 同时，设置了Tolerations的Pod可以运行在标注了Taint的Node上

使用：

  1. 为Node设置Taint信息

    1
    kubectl taint nodes node1 key1=value1:NoSchedule

  2. 在Pod的配置文件中配置tolerations属性

1
2
3
4
5
tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchdule"

补充：

  • Taint和Toleration声明需要保持对应一致，且operator需要为Exists或者Equal（Equal需要指定相等value）；
  • 空key配合Exists能够匹配所有键值，空effect匹配所有effect；
  • effect取值也可以设置为Prefer，例如PreferNoSchedule，视为软限制；
  • 同个Node可以设置多个Taint，对应的，Pod也可以设置多个Toleration。

0x05. DaemonSet

效果：在每个Node上调度运行同一个（种）Pod，例如日志采集、性能监控、存储的Daemon进程

使用：

1
2
3
apiVersion: extensions/v1beta1
kind: DaemonSet
...

补充：

除了使用系统内置算法在每台Node上调度外，也可以在Pod定义中使用NodeSelector或者NodeAffinity来指定满足料件的Node范围进行调度

0x06. 批处理调度

效果：并行/串行启动多个计算进程去处理一批工作项（Work Item，下称WI），处理完成后，批处理任务结束

任务模式分类：

  • Job Template Expansion模式：Job和WI一对一对应，适用于WI数量少，但是单WI处理数据量大的场景；
  • Queue with Pod Per Work Item模式：使用一个任务队列存放WI，Job作为Consumer去完成WI（对应的，Job会启动多个Pod，每个Pod对应一个WI），可用MQ实现；
  • Queue with Variable Pod Count模式：与2模式类似，但是Job启动的Pod数量是可变的，可用Redis或数据库实现；
  • Single Job with Static Work Assignment模式：一个Job产生多个Pod，但是采用程序静态方式分配任务（Kubernetes不支持，书中所写）。

Job分类：

  • Non-parallel Jobs：一个Job启动一个Pod，Pod正常结束则Job结束。
  • Parallel Jobs with a fixed completion count：Job会启动多个Pod（数目为spec.completions），正常结束的Pod达到这个数目后Job结束。spec.parallelism可以用来控制并行度。
  • Parallel Jobs with a work queue：WI在Queue中存放，无法设置并行度参数。每个Pod都能够独立判断是否还有任务需要处理，同时，一个Pod成功结束则其他Pod必定处于即将结束、退出的状态，且Job不会再启动新的Po）。所有Pod结束，且至少一个Pod成功结束则Job算成功结束。

（个人理解：上述的规则说明其实是在说所有Pod表现为同一整体，Pod启动失败会重启是一种容错机制。然而从整个过程的跨度来看，无需关心失败启动的数目，只要不是所有Pod全部失败结束，只需存在一个成功结束的Pod即表明Job流程内的其他划分任务都正常完成，整体任务也已成功完成。）

0x07. 定时任务

效果：定期触发任务执行

使用：

  1. 在API Server启动进程上添加配置参数

    1
    --runtime-config=batch/v2alpha1=true

  2. 编写Cron Job配置文件

    1
    2
    3
    4
    5
    6
    #cron.yaml
    apiVersion: batch/v2alpha1
    kind: CronJob
    ...
    spec:
      schedule: "*/1 * * * *"

  3. schedule格式如下

    1
    Min Hour DayOfMonth Month DayOfWeek

  4. *表示任意值，即每个时间单元节点都会触发

/表示开始触发的时间，例如5/20，表明第一次触发在第5个时间单位，此后每隔20个时间单位触发

0x08. 自定义调度器

在Pod中提供自定义的调度器名称，则默认调度器就会失效，转而使用指定的调度器完成对应Pod 的调度，自定义的调度器需要通过kube-proxy来运行，如果自定义调度器始终未启动，则Pod将会卡Pending状态。

1
2
3
4
5
apiVersion: v1
kind: Pod
...
spec:
  schedulerName: my-scheduler

0x09. 补充

  • Admission controller需要仔细研究
  • TaintBasedEviction和Eureka中的驱逐机制（包括SELF PRESERVATION)是否在设计层面上有一定的共通点
  • 自定义调度器实现有时间需要手动验证一次

MiiW

只是一个普通的开发者。