目录

实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

实验软件

链接：https://pan.baidu.com/s/1P3Z_ujk22dYDXzM37WI5FA?pwd=v01w
提取码：v01w

2022.2.18-39.亲合性调度-实验代码.zip

本节实践

1. 实践：nodeSelector测试(测试成功)-2022.5.16
2. 实践：节点亲和性测试(测试成功)-2022.5.16
3. 实践：pod亲和性(测试成功)-2022.5.16
4. 实践：pod反亲和性(测试成功)-2022.5.16
5. 实践：污点与容忍(测试成功)-2022.5.16
6. 实践：nodeName测试(测试成功)-2022.5.16

1、调度器

kube-scheduler 是 kubernetes 的核心组件之一，主要负责整个集群资源的调度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合理、更加充分的利用集群的资源，这也是我们选择使用 kubernetes 一个非常重要的理由。如果一门新的技术不能帮助企业节约成本、提供效率，我相信是很难推进的。

🍂 什么是调度？

调度，可以说是Kubernetes最核心的功能之一了。

Pod是Kubernetes中最小的调度单元，而Pod又是运行在Node之上的。所谓调度，简单来说就是为一个新创建出来的 Pod，寻找一个最适合它运行的Node。

🍂 调度概览

🍂 调度器分类

1.单体调度器：对于大规模批量调度诉求场景，不能胜任！(基于pod的事件调度)！
2.两层调度器：应用平台–hadoop,spark；资源调度器(负责底层计算资源的管理)，应用调度器；resource offers，存在的问题：1.资源争抢如何解决？2.分配资源不合理如何处理 解决办法：悲观锁 先锁定资源，再进行资源的腾挪处理。–>效率不高
3.状态共享调度器：基于版本控制/事务控制的基于乐观锁的调度！ full state,本地缓存，回写，冲突判断，重试。

2、调度流程

1.默认调度器

kube-scheduler

kube-scheduler负责分配调度Pod 到集群内的节点上，它监听kube-apiserver，查询还未分配Node的Pod，然后根据调度策略为这些Pod分配节点（更新Pod 的NodeName字段)。(生产者-消费者模型，plugin)

默认情况下，kube-scheduler 提供的默认调度器能够满足我们绝大多数的要求，我们前面和大家接触的示例也基本上用的默认的策略，都可以保证我们的 Pod 可以被分配到资源充足的节点上运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行特定类型的应用，这就需要我们的调度器能够可控。

例如：随便导出一个pod的yaml文件，可以看到其默认调度器就是`default-scheduler`.
$ kubectl get po apisix-etcd-0 -napisix -oyaml
……
schedulerName: default-scheduler
……

#也就是k8s集群默认使用的：
$ kubectl get po -A
……
kube-system            kube-scheduler-master1                             1/1     Running    3 (27d ago)   108d

kube-scheduler 的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监听 API Server，获取到 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创建一个 binding。

这个过程在我们看来好像比较简单，但在实际的生产环境中，需要考虑的问题就有很多了：

• 如何保证全部的节点调度的公平性？要知道并不是所有节点资源配置一定都是一样的
• 如何保证每个节点都能被分配资源？
• 集群资源如何能够被高效利用？
• 集群资源如何才能被最大化使用？
• 如何保证 Pod 调度的性能和效率？(假设说有1w个节点，我是否可以在其中1k个节点上进行筛选呢，这样就可以大幅度提高调度效率了😀)
• 用户是否可以根据自己的实际需求定制自己的调度策略？

🍂 调度主要分为以下几个部分：

• 首先是预选过程，过滤掉不满足条件的节点，这个过程称为 Predicates（过滤）
• 然后是优选过程，对通过的节点按照优先级排序，称之为 Priorities（打分）
• 最后从中选择优先级最高的节点，如果中间任何一步骤有错误，就直接返回错误

Predicates 阶段首先遍历全部节点，过滤掉不满足条件的节点，属于强制性规则，这一阶段输出的所有满足要求的节点将被记录并作为第二阶段的输入，如果所有的节点都不满足条件，那么 Pod 将会一直处于 Pending 状态，直到有节点满足条件，在这期间调度器会不断的重试。

所以我们在部署应用的时候，如果发现有 Pod 一直处于 Pending 状态，那么就是没有满足调度条件的节点，这个时候可以去检查下节点资源是否可用。

Priorities 阶段即再次对节点进行筛选，如果有多个节点都满足条件的话，那么系统会按照节点的优先级(priorites)大小对节点进行排序，最后选择优先级最高的节点来部署 Pod 应用。

01、如果你的pod处于pending状态，那么一定就是调度器出现了问题，那么原因会很多，有可能是你的node资源不足，有可能是你的节点已经被占用了……(因此需要使用kubectl describle pod xxx来查看原因)

02、所谓的bing操作就是如下：
$ kubectl get po apisix-etcd-0 -napisix -oyaml
……
nodeName: node2 #将pod的配置清单的nodeName字段补充完成。
……

🍂 下面是调度过程的简单示意图：

更详细的流程是这样的：

• 首先，客户端通过 API Server 的 REST API 或者 kubectl 工具创建 Pod 资源

• API Server 收到用户请求后，存储相关数据到 etcd 数据库中

• 调度器监听 API Server 查看到还未被调度(bind)的 Pod 列表，循环遍历地为每个 Pod 尝试分配节点，这个分配过程就是我们上面提到的两个阶段：

  • 预选阶段(Predicates)，过滤节点，调度器用一组规则过滤掉不符合要求的 Node 节点，比如 Pod 设置了资源的 request，那么可用资源比 Pod 需要的资源少的主机显然就会被过滤掉。
  • 优选阶段(Priorities)，为节点的优先级打分，将上一阶段过滤出来的 Node 列表进行打分，调度器会考虑一些整体的优化策略，比如把 Deployment 控制的多个 Pod 副本尽量分布到不同的主机上，使用最低负载的主机等等策略。

• 经过上面的阶段过滤后选择打分最高的 Node 节点和 Pod 进行 binding 操作，然后将结果存储到 etcd 中， 最后被选择出来的 Node 节点对应的 kubelet 去执行创建 Pod 的相关操作（当然也是 watch APIServer 发现的）。

🍂 Predicates plugin工作原理

链式过滤器

🍂 调度插件

LeastAllocated：空闲资源多的分高 --使的node上的负载比较合理一点！
MostAllocated：空闲资源少的分高 – 可以退回Node资源！

2.扩展调度器

包括很多时候，默认的调度器已经不能满足业务需求，需要对它做自定义的扩展和实现，具体该怎么做，背后的原理又是什么样的，业界有没有优秀案例可供参考，这些都是非常令人头疼的问题。

extender本身就是一个拉低性能的因素。

🍂 考虑到实际环境中的各种复杂情况，kubernetes 的调度器采用插件化的形式实现，可以方便用户进行定制或者二次开发，我们可以自定义一个调度器并以插件形式和 kubernetes 进行集成。

开发人员注意即可：

kubernetes 调度器的源码位于 kubernetes/pkg/scheduler 中，其中 Scheduler 创建和运行的核心程序，对应的代码在 pkg/scheduler/scheduler.go，如果要查看 kube-scheduler 的入口程序，对应的代码在 cmd/kube-scheduler/scheduler.go。

https://github1s.com/kubernetes/kubernetes/tree/v1.22.5

3.调度框架

基于Scheduler Framework实现扩展

未来主流的方法。

🍂 目前调度器已经全部通过插件的方式实现了调度框架，默认开启的调度插件如以下代码所示：

// pkg/scheduler/algorithmprovider/registry.go

func getDefaultConfig() *schedulerapi.Plugins {
    return &schedulerapi.Plugins{
        QueueSort: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: queuesort.Name},
            },
        },
        PreFilter: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: noderesources.FitName},
                {Name: nodeports.Name},
                {Name: podtopologyspread.Name},
                {Name: interpodaffinity.Name},
                {Name: volumebinding.Name},
            },
        },
        Filter: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: nodeunschedulable.Name},
                {Name: noderesources.FitName},
                {Name: nodename.Name},
                {Name: nodeports.Name},
                {Name: nodeaffinity.Name},
                {Name: volumerestrictions.Name},
                {Name: tainttoleration.Name},
                {Name: nodevolumelimits.EBSName},
                {Name: nodevolumelimits.GCEPDName},
                {Name: nodevolumelimits.CSIName},
                {Name: nodevolumelimits.AzureDiskName},
                {Name: volumebinding.Name},
                {Name: volumezone.Name},
                {Name: podtopologyspread.Name},
                {Name: interpodaffinity.Name},
            },
        },
        PostFilter: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: defaultpreemption.Name},
            },
        },
        PreScore: &schedulerapi.PluginSet{ #打分
            Enabled: []schedulerapi.Plugin{
                {Name: interpodaffinity.Name},
                {Name: podtopologyspread.Name},
                {Name: tainttoleration.Name},
            },
        },
        Score: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: noderesources.BalancedAllocationName, Weight: 1},
                {Name: imagelocality.Name, Weight: 1},
                {Name: interpodaffinity.Name, Weight: 1},
                {Name: noderesources.LeastAllocatedName, Weight: 1},
                {Name: nodeaffinity.Name, Weight: 1},
                {Name: nodepreferavoidpods.Name, Weight: 10000},
                // Weight is doubled because:
                // - This is a score coming from user preference.
                // - It makes its signal comparable to NodeResourcesLeastAllocated.
                {Name: podtopologyspread.Name, Weight: 2},
                {Name: tainttoleration.Name, Weight: 1},
            },
        },
        Reserve: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: volumebinding.Name},
            },
        },
        PreBind: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: volumebinding.Name},
            },
        },
        Bind: &schedulerapi.PluginSet{
            Enabled: []schedulerapi.Plugin{
                {Name: defaultbinder.Name},
            },
        },
    }
}

从上面我们可以看出调度器的一系列算法由各种插件在调度的不同阶段来完成，下面我们就先来了解下调度框架。

调度框架定义了一组扩展点，用户可以实现扩展点定义的接口来定义自己的调度逻辑（我们称之为扩展），并将扩展注册到扩展点上，调度框架在执行调度工作流时，遇到对应的扩展点时，将调用用户注册的扩展。调度框架在预留扩展点时，都是有特定的目的，有些扩展点上的扩展可以改变调度程序的决策方法，有些扩展点上的扩展只是发送一个通知。

我们知道每当调度一个 Pod 时，都会按照两个过程来执行：调度过程和绑定过程。

调度过程为 Pod 选择一个合适的节点，绑定过程则将调度过程的决策应用到集群中（也就是在被选定的节点上运行 Pod），将调度过程和绑定过程合在一起，称之为调度上下文（scheduling context）。需要注意的是**调度过程是同步运行的（同一时间点只为一个 Pod 进行调度）**，绑定过程可异步运行（同一时间点可并发为多个 Pod 执行绑定）。

调度过程和绑定过程遇到如下情况时会中途退出：

• 调度程序认为当前没有该 Pod 的可选节点
• 内部错误

这个时候，该 Pod 将被放回到 待调度队列，并等待下次重试。

1.扩展点（Extension Points）

下图展示了调度框架中的调度上下文及其中的扩展点，一个扩展可以注册多个扩展点，以便可以执行更复杂的有状态的任务。

调度阶段：
1.predicate(预选)：
2.priority/score(优选)：
绑定阶段：

🍂 详细过程：

1. QueueSort 扩展用于对 Pod 的待调度队列进行排序，以决定先调度哪个 Pod，QueueSort 扩展本质上只需要实现一个方法 Less(Pod1, Pod2) 用于比较两个 Pod 谁更优先获得调度即可，同一时间点只能有一个 QueueSort 插件生效。
2. Pre-filter 扩展用于对 Pod 的信息进行预处理，或者检查一些集群或 Pod 必须满足的前提条件，如果 pre-filter 返回了 error，则调度过程终止。
3. Filter 扩展用于排除那些不能运行该 Pod 的节点，对于每一个节点，调度器将按顺序执行 filter 扩展；如果任何一个 filter 将节点标记为不可选，则余下的 filter 扩展将不会被执行。调度器可以同时对多个节点执行 filter 扩展。
4. Post-filter 是一个通知类型的扩展点，调用该扩展的参数是 filter 阶段结束后被筛选为可选节点的节点列表，可以在扩展中使用这些信息更新内部状态，或者产生日志或 metrics 信息。
5. Scoring 扩展用于为所有可选节点进行打分，调度器将针对每一个节点调用 Soring 扩展，评分结果是一个范围内的整数。在 normalize scoring 阶段，调度器将会把每个 scoring 扩展对具体某个节点的评分结果和该扩展的权重合并起来，作为最终评分结果。
6. Normalize scoring 扩展在调度器对节点进行最终排序之前修改每个节点的评分结果，注册到该扩展点的扩展在被调用时，将获得同一个插件中的 scoring 扩展的评分结果作为参数，调度框架每执行一次调度，都将调用所有插件中的一个 normalize scoring 扩展一次。
7. Reserve 是一个通知性质的扩展点，有状态的插件可以使用该扩展点来获得节点上为 Pod 预留的资源，该事件发生在调度器将 Pod 绑定到节点之前，目的是避免调度器在等待 Pod 与节点绑定的过程中调度新的 Pod 到节点上时，发生实际使用资源超出可用资源的情况（因为绑定 Pod 到节点上是异步发生的）。这是调度过程的最后一个步骤，Pod 进入 reserved 状态以后，要么在绑定失败时触发 Unreserve 扩展，要么在绑定成功时，由 Post-bind 扩展结束绑定过程。
8. Permit 扩展用于阻止或者延迟 Pod 与节点的绑定。Permit 扩展可以做下面三件事中的一项：
   • approve（批准）：当所有的 permit 扩展都 approve 了 Pod 与节点的绑定，调度器将继续执行绑定过程
   • deny（拒绝）：如果任何一个 permit 扩展 deny 了 Pod 与节点的绑定，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展。
   • wait（等待）：如果一个 permit 扩展返回了 wait，则 Pod 将保持在 permit 阶段，直到被其他扩展 approve，如果超时事件发生，wait 状态变成 deny，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展
9. Pre-bind 扩展用于在 Pod 绑定之前执行某些逻辑。例如，pre-bind 扩展可以将一个基于网络的数据卷挂载到节点上，以便 Pod 可以使用。如果任何一个 pre-bind 扩展返回错误，Pod 将被放回到待调度队列，此时将触发 Unreserve 扩展。
10. Bind 扩展用于将 Pod 绑定到节点上：
    • 只有所有的 pre-bind 扩展都成功执行了，bind 扩展才会执行
    • 调度框架按照 bind 扩展注册的顺序逐个调用 bind 扩展
    • 具体某个 bind 扩展可以选择处理或者不处理该 Pod
    • 如果某个 bind 扩展处理了该 Pod 与节点的绑定，余下的 bind 扩展将被忽略
11. Post-bind 是一个通知性质的扩展：
    • Post-bind 扩展在 Pod 成功绑定到节点上之后被动调用
    • Post-bind 扩展是绑定过程的最后一个步骤，可以用来执行资源清理的动作
12. Unreserve 是一个通知性质的扩展，如果为 Pod 预留了资源，Pod 又在被绑定过程中被拒绝绑定，则 unreserve 扩展将被调用。Unreserve 扩展应该释放已经为 Pod 预留的节点上的计算资源。在一个插件中，reserve 扩展和 unreserve 扩展应该成对出现。

🍂 如果我们要实现自己的插件，必须向调度框架注册插件并完成配置，另外还必须实现扩展点接口，对应的扩展点接口我们可以在源码 pkg/scheduler/framework/v1alpha1/interface.go 文件中找到，如下所示：

// Plugin is the parent type for all the scheduling framework plugins.
type Plugin interface {
    Name() string
}

type QueueSortPlugin interface {
    Plugin
    Less(*PodInfo, *PodInfo) bool
}

// PreFilterPlugin is an interface that must be implemented by "prefilter" plugins.
// These plugins are called at the beginning of the scheduling cycle.
type PreFilterPlugin interface {
    Plugin
    PreFilter(pc *PluginContext, p *v1.Pod) *Status
}

// FilterPlugin is an interface for Filter plugins. These plugins are called at the
// filter extension point for filtering out hosts that cannot run a pod.
// This concept used to be called 'predicate' in the original scheduler.
// These plugins should return "Success", "Unschedulable" or "Error" in Status.code.
// However, the scheduler accepts other valid codes as well.
// Anything other than "Success" will lead to exclusion of the given host from
// running the pod.
type FilterPlugin interface {
    Plugin
    Filter(pc *PluginContext, pod *v1.Pod, nodeName string) *Status
}

// PostFilterPlugin is an interface for Post-filter plugin. Post-filter is an
// informational extension point. Plugins will be called with a list of nodes
// that passed the filtering phase. A plugin may use this data to update internal
// state or to generate logs/metrics.
type PostFilterPlugin interface {
    Plugin
    PostFilter(pc *PluginContext, pod *v1.Pod, nodes []*v1.Node, filteredNodesStatuses NodeToStatusMap) *Status
}

// ScorePlugin is an interface that must be implemented by "score" plugins to rank
// nodes that passed the filtering phase.
type ScorePlugin interface {
    Plugin
    Score(pc *PluginContext, p *v1.Pod, nodeName string) (int, *Status)
}

// ScoreWithNormalizePlugin is an interface that must be implemented by "score"
// plugins that also need to normalize the node scoring results produced by the same
// plugin's "Score" method.
type ScoreWithNormalizePlugin interface {
    ScorePlugin
    NormalizeScore(pc *PluginContext, p *v1.Pod, scores NodeScoreList) *Status
}

// ReservePlugin is an interface for Reserve plugins. These plugins are called
// at the reservation point. These are meant to update the state of the plugin.
// This concept used to be called 'assume' in the original scheduler.
// These plugins should return only Success or Error in Status.code. However,
// the scheduler accepts other valid codes as well. Anything other than Success
// will lead to rejection of the pod.
type ReservePlugin interface {
    Plugin
    Reserve(pc *PluginContext, p *v1.Pod, nodeName string) *Status
}

// PreBindPlugin is an interface that must be implemented by "prebind" plugins.
// These plugins are called before a pod being scheduled.
type PreBindPlugin interface {
    Plugin
    PreBind(pc *PluginContext, p *v1.Pod, nodeName string) *Status
}

// PostBindPlugin is an interface that must be implemented by "postbind" plugins.
// These plugins are called after a pod is successfully bound to a node.
type PostBindPlugin interface {
    Plugin
    PostBind(pc *PluginContext, p *v1.Pod, nodeName string)
}

// UnreservePlugin is an interface for Unreserve plugins. This is an informational
// extension point. If a pod was reserved and then rejected in a later phase, then
// un-reserve plugins will be notified. Un-reserve plugins should clean up state
// associated with the reserved Pod.
type UnreservePlugin interface {
    Plugin
    Unreserve(pc *PluginContext, p *v1.Pod, nodeName string)
}

// PermitPlugin is an interface that must be implemented by "permit" plugins.
// These plugins are called before a pod is bound to a node.
type PermitPlugin interface {
    Plugin
    Permit(pc *PluginContext, p *v1.Pod, nodeName string) (*Status, time.Duration)
}

// BindPlugin is an interface that must be implemented by "bind" plugins. Bind
// plugins are used to bind a pod to a Node.
type BindPlugin interface {
    Plugin
    Bind(pc *PluginContext, p *v1.Pod, nodeName string) *Status
}

🍂 对于调度框架插件的启用或者禁用，我们可以使用安装集群时的 KubeSchedulerConfiguration 资源对象来进行配置。下面的例子中的配置启用了一个实现了 reserve 和 preBind 扩展点的插件，并且禁用了另外一个插件，同时为插件 foo 提供了一些配置信息：

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration

...

plugins:
  reserve:
    enabled:
    - name: foo
    - name: bar
    disabled:
    - name: baz
  preBind:
    enabled:
    - name: foo
    disabled:
    - name: baz

pluginConfig:
- name: foo
  args: >
    foo插件可以解析的任意内容

🍂 扩展的调用顺序如下：

• 如果某个扩展点没有配置对应的扩展，调度框架将使用默认插件中的扩展
• 如果为某个扩展点配置且激活了扩展，则调度框架将先调用默认插件的扩展，再调用配置中的扩展
• 默认插件的扩展始终被最先调用，然后按照 KubeSchedulerConfiguration 中扩展的激活 enabled 顺序逐个调用扩展点的扩展
• 可以先禁用默认插件的扩展，然后在 enabled 列表中的某个位置激活默认插件的扩展，这种做法可以改变默认插件的扩展被调用时的顺序

假设默认插件 foo 实现了 reserve 扩展点，此时我们要添加一个插件 bar，想要在 foo 之前被调用，则应该先禁用 foo 再按照 bar foo 的顺序激活。示例配置如下所示：

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration

...

plugins:
  reserve:
    enabled:
    - name: bar
    - name: foo
    disabled:
    - name: foo

在源码目录 pkg/scheduler/framework/plugins/examples 中有几个示范插件，我们可以参照其实现方式。

2.示例(代码部分)

因为涉及到代码部分，本次这里不做演示，看下就好。

其实要实现一个调度框架的插件，并不难，我们只要实现对应的扩展点，然后将插件注册到调度器中即可，下面是默认调度器在初始化的时候注册的插件：

// pkg/scheduler/algorithmprovider/registry.go
func NewRegistry() Registry {
    return Registry{
        // FactoryMap:
        // New plugins are registered here.
        // example:
        // {
        //  stateful_plugin.Name: stateful.NewStatefulMultipointExample,
        //  fooplugin.Name: fooplugin.New,
        // }
    }
}

但是可以看到默认并没有注册一些插件，所以要想让调度器能够识别我们的插件代码，就需要自己来实现一个调度器了，当然这个调度器我们完全没必要完全自己实现，直接调用默认的调度器，然后在上面的 NewRegistry() 函数中将我们的插件注册进去即可。在 kube-scheduler 的源码文件 kubernetes/cmd/kube-scheduler/app/server.go 中有一个 NewSchedulerCommand 入口函数，其中的参数是一个类型为 Option 的列表，而这个 Option 恰好就是一个插件配置的定义：

// Option configures a framework.Registry.
type Option func(framework.Registry) error

// NewSchedulerCommand creates a *cobra.Command object with default parameters and registryOptions
func NewSchedulerCommand(registryOptions ...Option) *cobra.Command {
  ......
}

所以我们完全就可以直接调用这个函数来作为我们的函数入口，并且传入我们自己实现的插件作为参数即可，而且该文件下面还有一个名为 WithPlugin 的函数可以来创建一个 Option 实例：

// WithPlugin creates an Option based on plugin name and factory.
func WithPlugin(name string, factory framework.PluginFactory) Option {
    return func(registry framework.Registry) error {
        return registry.Register(name, factory)
    }
}

所以最终我们的入口函数如下所示：

func main() {
    rand.Seed(time.Now().UTC().UnixNano())

    command := app.NewSchedulerCommand(
        app.WithPlugin(sample.Name, sample.New),
    )

    logs.InitLogs()
    defer logs.FlushLogs()

    if err := command.Execute(); err != nil {
        _, _ = fmt.Fprintf(os.Stderr, "%v\n", err)
        os.Exit(1)
    }

}

其中 app.WithPlugin(sample.Name, sample.New) 就是我们接下来要实现的插件，从 WithPlugin 函数的参数也可以看出我们这里的 sample.New 必须是一个 framework.PluginFactory 类型的值，而 PluginFactory 的定义就是一个函数：

type PluginFactory = func(configuration *runtime.Unknown, f FrameworkHandle) (Plugin, error)

所以 sample.New 实际上就是上面的这个函数，在这个函数中我们可以获取到插件中的一些数据然后进行逻辑处理即可，插件实现如下所示，我们这里只是简单获取下数据打印日志，如果你有实际需求的可以根据获取的数据就行处理即可，我们这里只是实现了 PreFilter、Filter、PreBind 三个扩展点，其他的可以用同样的方式来扩展即可：

// 插件名称
const Name = "sample-plugin"

type Args struct {
    FavoriteColor  string `json:"favorite_color,omitempty"`
    FavoriteNumber int    `json:"favorite_number,omitempty"`
    ThanksTo       string `json:"thanks_to,omitempty"`
}

type Sample struct {
    args   *Args
    handle framework.FrameworkHandle
}

func (s *Sample) Name() string {
    return Name
}

func (s *Sample) PreFilter(pc *framework.PluginContext, pod *v1.Pod) *framework.Status {
    klog.V(3).Infof("prefilter pod: %v", pod.Name)
    return framework.NewStatus(framework.Success, "")
}

func (s *Sample) Filter(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status {
    klog.V(3).Infof("filter pod: %v, node: %v", pod.Name, nodeName)
    return framework.NewStatus(framework.Success, "")
}

func (s *Sample) PreBind(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status {
    if nodeInfo, ok := s.handle.NodeInfoSnapshot().NodeInfoMap[nodeName]; !ok {
        return framework.NewStatus(framework.Error, fmt.Sprintf("prebind get node info error: %+v", nodeName))
    } else {
        klog.V(3).Infof("prebind node info: %+v", nodeInfo.Node())
        return framework.NewStatus(framework.Success, "")
    }
}

//type PluginFactory = func(configuration *runtime.Unknown, f FrameworkHandle) (Plugin, error)
func New(configuration *runtime.Unknown, f framework.FrameworkHandle) (framework.Plugin, error) {
    args := &Args{}
    if err := framework.DecodeInto(configuration, args); err != nil {
        return nil, err
    }
    klog.V(3).Infof("get plugin config args: %+v", args)
    return &Sample{
        args: args,
        handle: f,
    }, nil
}

完整代码可以前往仓库 https://github.com/cnych/sample-scheduler-framework 获取。

实现完成后，编译打包成镜像即可，然后我们就可以当成普通的应用用一个 Deployment 控制器来部署即可，由于我们需要去获取集群中的一些资源对象，所以当然需要申请 RBAC 权限，然后同样通过 --config 参数来配置我们的调度器，同样还是使用一个 KubeSchedulerConfiguration 资源对象配置，可以通过 plugins 来启用或者禁用我们实现的插件，也可以通过 pluginConfig 来传递一些参数值给插件：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sample-scheduler-clusterrole
rules:
  - apiGroups:
      - ""
    resources:
      - endpoints
      - events
    verbs:
      - create
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - pods
    verbs:
      - delete
      - get
      - list
      - watch
      - update
  - apiGroups:
      - ""
    resources:
      - bindings
      - pods/binding
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - pods/status
    verbs:
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      - replicationcontrollers
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - apps
      - extensions
    resources:
      - replicasets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - apps
    resources:
      - statefulsets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - policy
    resources:
      - poddisruptionbudgets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - persistentvolumeclaims
      - persistentvolumes
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "storage.k8s.io"
    resources:
      - storageclasses
      - csinodes
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "coordination.k8s.io"
    resources:
      - leases
    verbs:
      - create
      - get
      - list
      - update
  - apiGroups:
      - "events.k8s.io"
    resources:
      - events
    verbs:
      - create
      - patch
      - update
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sample-scheduler-sa
  namespace: kube-system
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sample-scheduler-clusterrolebinding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: sample-scheduler-clusterrole
subjects:
- kind: ServiceAccount
  name: sample-scheduler-sa
  namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: scheduler-config
  namespace: kube-system
data:
  scheduler-config.yaml: |
    apiVersion: kubescheduler.config.k8s.io/v1beta1
    kind: KubeSchedulerConfiguration
    leaderElection:
      leaderElect: true
      leaseDuration: 15s
      renewDeadline: 10s
      resourceLock: endpointsleases
      resourceName: sample-scheduler
      resourceNamespace: kube-system
      retryPeriod: 2s
    profiles:
      - schedulerName: sample-scheduler
        plugins:
          preFilter:
            enabled:
              - name: "sample-plugin"
          filter:
            enabled:
              - name: "sample-plugin"
        pluginConfig:
          - name: sample-plugin
            args:  # runtime.Object
              favorColor: "#326CE5"
              favorNumber: 7
              thanksTo: "Kubernetes"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-scheduler
  namespace: kube-system
  labels:
    component: sample-scheduler
spec:
  selector:
    matchLabels:
      component: sample-scheduler
  template:
    metadata:
      labels:
        component: sample-scheduler
    spec:
      serviceAccountName: sample-scheduler-sa
      priorityClassName: system-cluster-critical
      volumes:
        - name: scheduler-config
          configMap:
            name: scheduler-config
      containers:
        - name: scheduler
          image: cnych/sample-scheduler:v0.2.4
          imagePullPolicy: IfNotPresent
          command:
            - sample-scheduler
            - --config=/etc/kubernetes/scheduler-config.yaml
            - --v=3
          volumeMounts:
            - name: scheduler-config
              mountPath: /etc/kubernetes
#          livenessProbe:
#            httpGet:
#              path: /healthz
#              port: 10251
#            initialDelaySeconds: 15
#          readinessProbe:
#            httpGet:
#              path: /healthz
#              port: 10251

直接部署上面的资源对象即可，这样我们就部署了一个名为 sample-scheduler 的调度器了，接下来我们可以部署一个应用来使用这个调度器进行调度：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-scheduler
spec:
  selector:
    matchLabels:
      app: test-scheduler
  template:
    metadata:
      labels:
        app: test-scheduler
    spec:
      schedulerName: sample-scheduler  # 指定使用的调度器，不指定使用默认的default-scheduler
      containers:
        - image: nginx:1.7.9
          imagePullPolicy: IfNotPresent
          name: nginx
          ports:
            - containerPort: 80

这里需要注意的是我们现在手动指定了一个 schedulerName 的字段，将其设置成上面我们自定义的调度器名称 sample-scheduler。

我们直接创建这个资源对象，创建完成后查看我们自定义调度器的日志信息：

➜ kubectl get pods -n kube-system -l component=sample-scheduler
NAME                               READY   STATUS    RESTARTS   AGE
sample-scheduler-896658cd7-k7vcl   1/1     Running   0          57s
➜ kubectl logs -f sample-scheduler-896658cd7-k7vcl -n kube-system
I0114 09:14:18.878613       1 eventhandlers.go:173] add event for unscheduled pod default/test-scheduler-6486fd49fc-zjhcx
I0114 09:14:18.878670       1 scheduler.go:464] Attempting to schedule pod: default/test-scheduler-6486fd49fc-zjhcx
I0114 09:14:18.878706       1 sample.go:77] "Start PreFilter Pod" pod="test-scheduler-6486fd49fc-zjhcx"
I0114 09:14:18.878802       1 sample.go:93] "Start Filter Pod" pod="test-scheduler-6486fd49fc-zjhcx" node="node2" preFilterState=&{Resource:{MilliCPU:0 Memory:0 EphemeralStorage:0 AllowedPodNumber:0 ScalarResources:map[]}}
I0114 09:14:18.878835       1 sample.go:93] "Start Filter Pod" pod="test-scheduler-6486fd49fc-zjhcx" node="node1" preFilterState=&{Resource:{MilliCPU:0 Memory:0 EphemeralStorage:0 AllowedPodNumber:0 ScalarResources:map[]}}
I0114 09:14:18.879043       1 default_binder.go:51] Attempting to bind default/test-scheduler-6486fd49fc-zjhcx to node1
I0114 09:14:18.886360       1 scheduler.go:609] "Successfully bound pod to node" pod="default/test-scheduler-6486fd49fc-zjhcx" node="node1" evaluatedNodes=3 feasibleNodes=2
I0114 09:14:18.887426       1 eventhandlers.go:205] delete event for unscheduled pod default/test-scheduler-6486fd49fc-zjhcx
I0114 09:14:18.887475       1 eventhandlers.go:225] add event for scheduled pod default/test-scheduler-6486fd49fc-zjhcx

可以看到当我们创建完 Pod 后，在我们自定义的调度器中就出现了对应的日志，并且在我们定义的扩展点上面都出现了对应的日志，证明我们的示例成功了，也可以通过查看 Pod 的 schedulerName 来验证：

➜ kubectl get pods
NAME                              READY   STATUS    RESTARTS       AGE
test-scheduler-6486fd49fc-zjhcx   1/1     Running   0              35s
➜ kubectl get pod test-scheduler-6486fd49fc-zjhcx -o yaml
......
restartPolicy: Always
schedulerName: sample-scheduler
securityContext: {}
serviceAccount: default
......

从 Kubernetes v1.17 版本开始，Scheduler Framework 内置的预选和优选函数已经全部插件化，所以要扩展调度器我们应该掌握并理解调度框架这种方式。

3、调度器调优

作为 kubernetes 集群的默认调度器，kube-scheduler 主要负责将 Pod 调度到集群的 Node 上。在一个集群中，满足一个 Pod 调度请求的所有节点称之为 可调度 Node，调度器先在集群中找到一个 Pod 的可调度 Node，然后根据一系列函数对这些可调度 Node 进行打分，之后选出其中得分最高的 Node 来运行 Pod，最后，调度器将这个调度决定告知 kube-apiserver，这个过程叫做绑定。

在 Kubernetes 1.12 版本之前，kube-scheduler 会检查集群中所有节点的可调度性，并且给可调度节点打分。Kubernetes 1.12 版本添加了一个新的功能，允许调度器在找到一定数量的可调度节点之后就停止继续寻找可调度节点。该功能能提高调度器在大规模集群下的调度性能，这个数值是集群规模的百分比，这个百分比通过 percentageOfNodesToScore 参数来进行配置，其值的范围在 1 到 100 之间，最大值就是 100%，如果设置为 0 就代表没有提供这个参数配置。

Kubernetes 1.14 版本又加入了一个特性，在该参数没有被用户配置的情况下，调度器会根据集群的规模自动设置一个集群比例，然后通过这个比例筛选一定数量的可调度节点进入打分阶段。该特性使用线性公式计算出集群比例，比如100个节点的集群下会取 50%，在 5000节点的集群下取 10%，这个自动设置的参数的最低值是 5%，换句话说，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。

注意

当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有节点，因为可调度节点太少，不足以停止调度器最初的过滤选择。如果我们想要关掉这个范围参数，可以将 percentageOfNodesToScore 值设置成 100。

percentageOfNodesToScore 的值必须在 1 到 100 之间，而且其默认值是通过集群的规模计算得来的，另外 50 个 Node 的数值是硬编码在程序里面的，设置这个值的作用在于：当集群的规模是数百个节点并且 percentageOfNodesToScore 参数设置的过低的时候，调度器筛选到的可调度节点数目基本不会受到该参数影响。当集群规模较小时，这个设置对调度器性能提升并不明显，但是在超过 1000 个 Node 的集群中，将调优参数设置为一个较低的值可以很明显的提升调度器性能。

不过值得注意的是，该参数设置后可能会导致只有集群中少数节点被选为可调度节点，很多 Node 都没有进入到打分阶段，这样就会造成一种后果，一个本来可以在打分阶段得分很高的 Node 甚至都不能进入打分阶段。由于这个原因，所以这个参数不应该被设置成一个很低的值，通常的做法是不会将这个参数的值设置的低于 10，很低的参数值一般在调度器的吞吐量很高且对 Node 的打分不重要的情况下才使用。换句话说，只有当你更倾向于在可调度节点中任意选择一个 Node 来运行这个 Pod 时，才使用很低的参数设置。

如果你的集群规模只有数百个节点或者更少，实际上并不推荐你将这个参数设置得比默认值更低，因为这种情况下不太会有效的提高调度器性能。

4、创建一个Pod的工作流程

一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均。但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们希望一些机器学习的应用只跑在有 GPU 的节点上；但是有的时候我们的服务之间交流比较频繁，又希望能够将这服务的 Pod 都调度到同一个的节点上。这就需要使用一些调度方式来控制 Pod 的调度了，主要有两个概念：亲和性和反亲和性，亲和性又分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。

1.架构图

Kubernetes基于list-watch机制的控制器架构，实现组件间交互的解耦。
其他组件监控自己负责的资源，当这些资源发生变化时，kube-apiserver会通知这些组件，这个过程类似于发布与订阅。

2.剖析过程

• 我们通过命令行创建一个pod：

• 当我们在执行命令kubectl run pod4 --image=nginx后，各组件之间的调用流程是如何的呢？

1、kubectl向apiserver发送一个创建pod的请求
2、apiserver接收到并向etcd写入存储，写入成功返回一个提示

#这个过程类似于老板和顾客之间的关系:
	api-server:开店老板
	etcd：仓库
	其他组件：顾客

• 注意：如果在执行如下kubectl run pod4 --image=nginx命令时，卡着了，说明什么问题呢？

–>说明：
etcd数据库写入有问题/达到性能瓶颈，或者，api-server和etcd 2者总有一个有问题：

• 继续：scheduler向apiserver查询未分配的pod资源，通过自身调度算法选择一个合适的node进行绑定（给这个pod资源打一个标记，标记分配到node1）注意：它这个调度算法还是比较复杂、均匀一点的，它会考虑到你的机器的硬件配置，pod属性等等一些综合的属性；

• 问题：如果scheduler组件有问题，那么此时pod会出现什么状态？

答：pod会出现通过kubectl get pod根本看不到你刚创建的pod信息的，更别说它的状态了，因为它根本没分配。

因此，如果你创建的pod信息根本看不到，那么会是哪个组件可能有问题？–>scheduler组件可能出在问题。

• 如果是pending状态：pod是已经绑定到某个节点了。

• 继续流程讲解：

4、kubelet向apiserver查询分配到自己节点的pod，调用docker api（/var/run/docker.sock）创建容器
5、kubelet获取docker创建容器的状态，并汇报给apiserver，apiserver更新状态到etcd存储
6、kubectl get pods就能查看pod状态

备注：
kubelet的功能主要是管理容器：

这个是默认调用的docker api接口
[root@k8s-master ~]#ll /var/run/docker.sock
srw-rw---- 1 root docker 0 Jun 14 11:46 /var/run/docker.sock

• 问题：controller-manager为什么没用到?

controller-manager是用于管理控制器，例如deployment（rs）、service，因为创建的是一个pod，不受它管理。

如果controller-manager要放在这里，一般是放在etcd后面的：

• kube-proxy为什么没用到？

proxy是用于管理pod网络，例如service，因为没创建service。

kube-proxy的主要功能就是维护好service，service是k8s的抽象资源；

• 扩展

比如，这个容器创建的时候创建失败了，不是一个running状态，也不是一个pending状态。可能就是docker在启动容器时，用你那个镜像启动容器失败了。所以这是你需要用docker去run一个镜像看能不能起来。

3.Pod中影响调度的主要属性

⚠️ 注意

resources: {} 资源调度依据这个，挺重要的；
很多大厂都会去二开"schedulerName: default-scheduler"这个调度器的，会去加一些调度策略，进而完成他们的需求；

🍂 调度原因失败分析

kubectl get pod <NAME> -o wide

查看调度失败原因：kubectl describe pod <NAME>
• 节点CPU/内存不足
• 有污点，没容忍 (tolerations)
• 没有匹配到节点标签 （n）

4.调度器需要充分考虑诸多的因素

资源高效利用：装箱率要高！
afinity：微服务，分步式系统，网络调用，本机调用，排除了网络调用，额外的传输时间，物理网卡带宽限制！
anti-affinity：某个业务的不同副本，不能让其跑在一台机器上，一个机架上，一个地域里，使其分布在不同的故障域。
locality：数据本地化，是一个很重要的概念，哪里有数据，我的作业就去哪里，这样可以减少数据拷贝的开销。k8s里的拉取镜像。

🍂

听起来很简单，但这个过程中会涉及Predicate、Priority等各种调度算法，还有优先级（Priority ）、**抢占（Preemption）**等各种机制。在实际的调度设计中，有非常多需要考虑的问题，比如：

1. 公平：如何保证每个节点都能被分配资源

2. 资源高效利用：怎样压榨集群的资源能力，让资源被最大化使用

3. 效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作

4. 灵活：允许用户根据自己的需求控制调度的逻辑

5.Kubernetes中的资源分配

1.limits：在Cgroups里使用；cpu.cfs_quota/cpu.cfs_period(10w)=1
2.requests：cpu这个requests其实在Cgroup里也起作用。当你多个应用发生资源抢占时，他们抢占的cpu时间比较是多少呢？是通过cpu.share去调节的。k8s是如何实现的呢？这里如果设置的是一个cpu，request是1的话，那么cpu.share是1024。 如果你设置的是100m，相当于是0.1个cpu，那么cpu.share就是0.1*1024=102. 也就是cpu.requests也是最终会体现到Cgroups里面去的。

6.Init container的资源需求

5、nodeSelector

nodeSelector：用于将Pod调度到匹配Label的Node上，如果没有匹配的标签会调度失败。

作用：

• 约束Pod到特定的节点运行
• 完全匹配节点标签

应用场景：

• 专用节点：根据业务线将Node分组管理
• 配备特殊硬件：部分Node配有SSD硬盘、GPU

💘 实践：nodeSelector测试(测试成功)-2022.5.16

在了解亲和性之前，我们先来了解一个非常常用的调度方式：nodeSelector。我们知道 label 标签是 kubernetes 中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的 Service 对象通过 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。

• 我们可以通过下面的命令查看我们的 node 的 label：

[root@master1 ~]#kubectl get node --show-labels 
NAME      STATUS   ROLES                  AGE    VERSION   LABELS
master1   Ready    control-plane,master   109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
node1     Ready    <none>                 109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2     Ready    <none>                 109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

• 现在我们先给节点 node2 增加一个com=youdianzhishi的标签，命令如下：

[root@master1 ~]#kubectl label nodes node2 com=youdianzhishi
node/node2 labeled

我们可以通过上面的 --show-labels 参数可以查看上述标签是否生效。

[root@master1 ~]#kubectl get node node2 --show-labels 
NAME    STATUS   ROLES    AGE    VERSION   LABELS
node2   Ready    <none>   109d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,com=youdianzhishi,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

• Pod里配置nodeSelector字段：

当节点被打上了相关标签后，在调度的时候就可以使用这些标签了，只需要在 Pod 的 spec 字段中添加 nodeSelector 字段，里面是我们需要被调度的节点的 label 标签，比如，下面的 Pod 我们要强制调度到 node2 这个节点上去，我们就可以使用 nodeSelector 来表示了：

$ vim 01-node-selector-demo.yaml

# 01-node-selector-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: busybox-pod
  name: test-busybox
spec:
  containers:
  - command:
    - sleep
    - "3600"
    image: busybox
    imagePullPolicy: Always
    name: test-busybox
  nodeSelector: #注意：nodeSelector是和containers同级的；注意，这个放的顺序一定要放在containers后面。不然会报错的！
    com: youdianzhishi

• 部署后，我们就可以通过 describe 命令查看调度结果：

hg@LAPTOP-G8TUFE0T:/mnt/c/Users/hg/Desktop/yaml$ kubectl apply -f 01-node-selector-demo.yaml 
pod/test-busybox created

hg@LAPTOP-G8TUFE0T:/mnt/c/Users/hg/Desktop/yaml$ kubectl get po  -owide
NAME           READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
test-busybox   1/1     Running   0          78s   10.244.2.210   node2   <none>           <none>


[root@master1 ~]#kubectl describe po test-busybox  
Name:         test-busybox
Namespace:    default
Priority:     0
Node:         node2/172.29.9.53
Start Time:   Thu, 17 Feb 2022 19:45:11 +0800
Labels:       app=busybox-pod
Annotations:  <none>
Status:       Running
IP:           10.244.2.210
IPs:
  IP:  10.244.2.210
Containers:
  test-busybox:
    Container ID:  containerd://1b4d323942e6d305a4ea25f655eaced77f8cb8e4229eaf1972dc9dfb1246a0c0
    Image:         busybox
    Image ID:      docker.io/library/busybox@sha256:5acba83a746c7608ed544dc1533b87c737a0b0fb730301639a0179f9344b1678
    Port:          <none>
    Host Port:     <none>
    Command:
      sleep
      3600
    State:          Running
      Started:      Thu, 17 Feb 2022 19:45:31 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-p5z6t (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-p5z6t:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              com=youdianzhishi
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  2m45s  default-scheduler  Successfully assigned default/test-busybox to node2
  Normal  Pulling    2m43s  kubelet            Pulling image "busybox"
  Normal  Pulled     2m26s  kubelet            Successfully pulled image "busybox" in 17.583571931s
  Normal  Created    2m26s  kubelet            Created container test-busybox
  Normal  Started    2m25s  kubelet            Started container test-busybox
[root@master1 ~]#

我们可以看到 Events 下面的信息，我们的 Pod 通过默认的 default-scheduler 调度器被绑定到了 node2 节点。不过需要注意的是nodeSelector 属于强制性的，如果我们的目标节点没有可用的资源，我们的 Pod 就会一直处于 Pending 状态。

通过上面的例子我们可以感受到 nodeSelector 的方式比较直观，但是还不够灵活，控制粒度偏大。接下来我们再和大家了解下更加灵活的方式：节点亲和性(nodeAffinity)。

测试结束。😘

🍂 问题：

因pod中nodeSelector里的标签未出现在all node节点，但后续给node打好符合要求的标签，原来处于pending状态的pod会自动迁移过去的吗？–>会的。

6、亲和性和反亲和性调度

前面我们了解了 kubernetes 调度器的调度流程，我们知道默认的调度器在使用的时候，经过了 predicates 和 priorities 两个阶段，但是在实际的生产环境中，往往我们需要根据自己的一些实际需求来控制 Pod 的调度，这就需要用到 nodeAffinity(节点亲和性)、podAffinity(pod 亲和性) 以及 podAntiAffinity(pod 反亲和性)。

🍂 亲和性调度可以分成软策略和硬策略两种方式:

• 软策略就是如果现在没有满足调度要求的节点的话，Pod 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓
• 硬策略就比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然就不干了

对于亲和性和反亲和性都有这两种规则可以设置： preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution，前面的就是软策略，后面的就是硬策略。

1.节点亲和性

节点亲和性（nodeAffinity）主要是用来控制 Pod 要部署在哪些节点上，以及不能部署在哪些节点上的，它可以进行一些简单的逻辑组合了，不只是简单的相等匹配(比如前面的nodeSelector就是标签的=)。

nodeAffinity：节点亲和类似于nodeSelector，可以根据节点上的标签来约束Pod可以调度到哪些节点。

🍂 相比nodeSelector：

• 匹配有更多的逻辑组合，不只是字符串的完全相等，支持的操作符有：In、NotIn、Exists、DoesNotExist、Gt、Lt
• 调度分为软策略和硬策略，而不是硬性要求
  • 硬（required）：必须满足
  • 软（preferred）：尝试满足，但不保证

🍂 这里的匹配逻辑是 label 标签的值在某个列表中，现在 Kubernetes 提供的操作符有下面的几种：

• In：label 的值在某个列表中 (这里的操作符，我们一般只用到in就足够了；)
• NotIn：label 的值不在某个列表中
• Gt：label 的值大于某个值
• Lt：label 的值小于某个值
• Exists：某个 label 存在
• DoesNotExist：某个 label 不存在

⚠️ 注意：

但是需要注意的是如果 nodeSelectorTerms 下面有多个选项的话，满足任何一个条件就可以了；如果 matchExpressions有多个选项的话，则必须同时满足这些条件才能正常调度 Pod。

🍂

比nodeSelector更高级的一个！
matchExpressions比selector更加灵活。

💘 实践：节点亲和性测试(测试成功)-2022.5.16

• 比如现在我们用一个 Deployment 来管理8个 Pod 副本，现在我们来控制下这些 Pod 的调度，如下例子：

# 02-node-affinity-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-affinity
  labels:
    app: node-affinity
spec:
  replicas: 8
  selector:
    matchLabels:
      app: node-affinity
  template:
    metadata:
      labels:
        app: node-affinity
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
          name: nginxweb
      affinity: #定义亲和性
        nodeAffinity: #节点亲和性 
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: NotIn
                values:
                - master1 #相当于只能调度到node1和node2节点。默认就不会调度到master1节点
          preferredDuringSchedulingIgnoredDuringExecution:  # 软策略(尽可能调度到node2节点)
          - weight: 1
            preference:
              matchExpressions:
              - key: com
                operator: In
                values:
                - youdianzhishi

上面这个 Pod 首先是要求不能运行在 master1 这个节点上，如果有个节点满足 com=youdianzhishi 的话就优先调度到这个节点上。

由于上面 node02 节点我们打上了 com=youdianzhishi 这样的 label 标签，所以按要求会优先调度到这个节点来的。

• 现在我们来创建这个 Pod，然后查看具体的调度情况是否满足我们的要求。

➜ kubectl apply -f node-affinty-demo.yaml
deployment.apps/node-affinity created
➜ kubectl get pods -l app=node-affinity -o wide #老师这个有部分pod被调度到node1节点
NAME                            READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
node-affinity-cdd9d54d9-bgbbh   1/1     Running   0          2m28s   10.244.2.247   node2   <none>           <none>
node-affinity-cdd9d54d9-dlbck   1/1     Running   0          2m28s   10.244.4.16    node1   <none>           <none>
node-affinity-cdd9d54d9-g2jr6   1/1     Running   0          2m28s   10.244.4.17    node1   <none>           <none>
node-affinity-cdd9d54d9-gzr58   1/1     Running   0          2m28s   10.244.1.118   node1   <none>           <none>
node-affinity-cdd9d54d9-hcv7r   1/1     Running   0          2m28s   10.244.2.246   node2   <none>           <none>
node-affinity-cdd9d54d9-kvxw4   1/1     Running   0          2m28s   10.244.2.245   node2   <none>           <none>
node-affinity-cdd9d54d9-p4mmk   1/1     Running   0          2m28s   10.244.2.244   node2   <none>           <none>
node-affinity-cdd9d54d9-t5mff   1/1     Running   0          2m28s   10.244.1.117   node2   <none>           <none>

从结果可以看出有5个 Pod 被部署到了 node2 节点上，但是可以看到并没有一个 Pod 被部署到 master1 这个节点上，因为我们的硬策略就是不允许部署到该节点上，而 node2 是软策略，所以会尽量满足。

测试结束。😘

2.pod 亲和性和pod 反亲和性

Pod 亲和性（podAffinity）主要解决 Pod 可以和哪些 Pod 部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster、zone 等等），而 Pod 反亲和性主要是解决 Pod 不能和哪些 Pod 部署在同一个拓扑域中的问题，它们都是处理的 Pod 与 Pod 之间的关系。比如一个 Pod 在一个节点上了，那么我这个也得在这个节点，或者你这个 Pod 在节点上了，那么我就不想和你待在同一个节点上。

👉🏼 这个是很重要的，线上业务基本要配置这种podAntiAffinity。

🍂 拓扑域

这里要重点理解下什么是拓扑域？–>你可以把它看成为一个分组。

💘 实验：pod亲和性(测试成功)-2022.5.16

• 由于我们这里只有一个集群，并没有区域或者机房的概念，所以我们这里直接使用主机名来作为拓扑域，把 Pod 创建在同一个主机上面。

[root@master1 ~]# kubectl get node --show-labels 
NAME      STATUS   ROLES                  AGE    VERSION   LABELS
master1   Ready    control-plane,master   110d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
node1     Ready    <none>                 110d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node1,kubernetes.io/os=linux
node2     Ready    <none>                 110d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,com=youdianzhishi,kubernetes.io/arch=amd64,kubernetes.io/hostname=node2,kubernetes.io/os=linux

• 同样，还是针对上面的资源对象，我们来测试下 Pod 的亲和性：

# 03-pod-affinity-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-affinity
  labels:
    app: pod-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-affinity
  template:
    metadata:
      labels:
        app: pod-affinity
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
          - labelSelector: #去选择具有app in ["busybox-pod"]的pod所在的hostname这个域。
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox-pod
            topologyKey: kubernetes.io/hostname

上面这个例子中的 Pod 需要调度到某个指定的节点上，并且该节点上运行了一个带有 app=busybox-pod 标签的 Pod。我们可以查看有标签 app=busybox-pod 的 pod 列表：

[root@master1 ~]#kubectl get pods -l app=busybox-pod -o wide
NAME           READY   STATUS    RESTARTS      AGE   IP             NODE    NOMINATED NODE   READINESS GATES
test-busybox   1/1     Running   5 (23m ago)   18h   10.244.2.210   node2   <none>           <none>

• 我们看到这个 Pod 运行在了 node2 的节点上面，所以按照上面的亲和性来说，上面我们部署的3个 Pod 副本也应该运行在 node2 节点上：

$ kubectl apply -f 03-pod-affinity-demo.yaml 
deployment.apps/pod-affinity created
$ kubectl get pods -o wide -l app=pod-affinity
NAME                           READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod-affinity-785f687c5-52t54   1/1     Running   0          60s   10.244.2.228   node2   <none>           <none>
pod-affinity-785f687c5-g594p   1/1     Running   0          60s   10.244.2.229   node2   <none>           <none>
pod-affinity-785f687c5-s6j7h   1/1     Running   0          60s   10.244.2.227   node2   <none>           <none>

• 如果我们把上面的 test-busybox 和 pod-affinity 这个 Deployment 都删除，然后重新创建 pod-affinity 这个资源，看看能不能正常调度呢：

$ kubectl delete -f 01-node-selector-demo.yaml
pod "test-busybox" deleted
$ kubectl delete -f 03-pod-affinity-demo.yaml
deployment.apps "pod-affinity" deleted

$ kubectl apply -f 03-pod-affinity-demo.yaml 
deployment.apps/pod-affinity created
$ kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
pod-affinity-785f687c5-2256q   0/1     Pending   0          80s
pod-affinity-785f687c5-7gpz5   0/1     Pending   0          80s
pod-affinity-785f687c5-97gpj   0/1     Pending   0          80s

我们可以看到都处于 Pending 状态了，这是因为现在没有一个节点上面拥有 app=busybox-pod 这个标签的 Pod，而上面我们的调度使用的是硬策略，所以就没办法进行调度了，大家可以去尝试下重新将 test-busybox 这个 Pod 调度到其他节点上，观察下上面的3个副本会不会也被调度到对应的节点上去。(这里可以自己测试下，可以利用node1的kubernetes.io/hostname: node1标签用nodeSelector来实现)

• 我们这个地方使用的是 kubernetes.io/hostname 这个拓扑域，意思就是我们当前调度的 Pod 要和目标的 Pod 处于同一个主机上面，因为要处于同一个拓扑域下面。为了说明这个问题，我们把拓扑域改成 beta.kubernetes.io/os，同样的我们当前调度的 Pod 要和目标的 Pod 处于同一个拓扑域中，目标的 Pod 是拥有 beta.kubernetes.io/os=linux 的标签，而我们这里所有节点都有这样的标签，这也就意味着我们所有节点都在同一个拓扑域中，所以我们这里的 Pod 可以被调度到任何一个节点，重新运行上面的 app=busybox-pod 的 Pod，然后再更新下我们这里的资源对象：

$ kubectl get po -owide
NAME                            READY   STATUS    RESTARTS   AGE    IP             NODE    NOMINATED NODE   READINESS GATES
pod-affinity-6bf5bb4fc4-j6ctw   1/1     Running   0          22s    10.244.2.230   node2   <none>           <none>
pod-affinity-6bf5bb4fc4-xb7tr   1/1     Running   0          22s    10.244.2.231   node2   <none>           <none>
pod-affinity-6bf5bb4fc4-xl6pn   1/1     Running   0          22s    10.244.1.97    node1   <none>           <none>

可以看到现在是分别运行在2个节点下面的，因为他们都属于 beta.kubernetes.io/os 这个拓扑域(而busybox-pod也刚好在这个域下，因此符合硬策略要求)。

⚠️ 这里需要注意下：通过上面这个实验可以看到，这2个node节点都属于beta.kubernetes.io/os这个拓扑域，但只有node1上有app=pod-affitity这个标签的pod，从结果可以看到也是可以调度到node2上的。

实验结束。😘

🍂 pod 反亲和性(podAntiAffinity)

Pod 反亲和性（podAntiAffinity）则是反着来的，比如一个节点上运行了某个 Pod，那么我们的模板 Pod 则不希望被调度到这个节点上面去了。

💘 实验：pod反亲和性(测试成功)-2022.5.16

• 我们把上面的 podAffinity 直接改成 podAntiAffinity：

# 04-pod-antiaffinity-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-antiaffinity
  labels:
    app: pod-antiaffinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pod-antiaffinity
  template:
    metadata:
      labels:
        app: pod-antiaffinity
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: nginxweb
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
          - labelSelector: #3个pod副本不会调度到具有app=busybox-pod所在的hostanme这个域(节点)上面
              matchExpressions:
              - key: app
                operator: In
                values:
                - busybox-pod
            topologyKey: kubernetes.io/hostname #注意：pod反亲和性是直接不往这个域里直接调度pod的！！！

这里的意思就是如果一个节点上面有一个 app=busybox-pod 这样的 Pod 的话，那么我们的 Pod 就别调度到这个节点上面来，上面我们把app=busybox-pod 这个 Pod 固定到了 node2 这个节点上面的，所以正常来说我们这里的 Pod 不会出现在该节点上：

$ kubectl apply -f 04-pod-antiaffinity-demo.yaml 
deployment.apps/pod-antiaffinity created
$ kubectl get po -owide
NAME                                READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
pod-antiaffinity-57c57dd9f7-jspkt   1/1     Running   0          25s   10.244.1.100   node1   <none>           <none>
pod-antiaffinity-57c57dd9f7-mm78w   1/1     Running   0          25s   10.244.1.99    node1   <none>           <none>
pod-antiaffinity-57c57dd9f7-x9mft   1/1     Running   0          25s   10.244.1.98    node1   <none>           <none>

我们可以看到没有被调度到 node2 节点上，因为我们这里使用的是 Pod 反亲和性。

• 大家可以思考下，如果这里我们将拓扑域更改成 beta.kubernetes.io/os 会怎么样呢？可以自己去测试下看看。

$ kubectl apply -f 04-pod-antiaffinity-demo.yaml 
deployment.apps/pod-antiaffinity created
$ kubectl get po
NAME                               READY   STATUS    RESTARTS   AGE
pod-antiaffinity-c5fb4db4d-jj5j7   0/1     Pending   0          4s
pod-antiaffinity-c5fb4db4d-xxnhg   0/1     Pending   0          4s
pod-antiaffinity-c5fb4db4d-zkbgp   0/1     Pending   0          4s

实验结束。😘

7、污点与容忍

Taint（污点）与Tolerations（污点容忍）

Taints：避免Pod调度到特定Node上

Tolerations：允许Pod调度到持有Taints的Node上

应用场景：

• 专用节点：根据业务线将Node分组管理，希望在默认情况下不调度该节点，只有配置了污点容忍才允许分配
• 配备特殊硬件：部分Node配有SSD硬盘、GPU，希望在默认情况下不调度该节点，只有配置了污点容忍才允许分配
• 基于Taint的驱逐

对于 nodeAffinity 无论是硬策略还是软策略方式，都是调度 Pod 到预期节点上。而污点（Taints）恰好与之相反，如果一个节点标记为 Taints ，除非 Pod 也被标识为可以容忍污点节点，否则该 Taints 节点不会被调度 Pod。

比如用户希望把 Master 节点保留给 Kubernetes 系统组件使用，或者把一组具有特殊资源预留给某些 Pod，则污点就很有用了，Pod 不会再被调度到 taint 标记过的节点。我们使用 kubeadm 搭建的集群默认就给 master 节点添加了一个污点标记，所以我们看到我们平时的 Pod 都没有被调度到 master 上去。

⚠️ 污点：其实是一个label标签，只不过它是一个特殊的label标签。

[root@master1 ~]#kubectl get node master1 --show-labels 
NAME      STATUS   ROLES                  AGE    VERSION   LABELS
master1   Ready    control-plane,master   110d   v1.22.2   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=(注意，这个是一个空标签),node.kubernetes.io/exclude-from-external-load-balancers=

[root@master1 ~]#kubectl describe node master1
Name:               master1
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=master1
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/master=
......
Taints:             node-role.kubernetes.io/master:NoSchedule
Unschedulable:      false
......

我们可以使用上面的命令查看 master 节点的信息，其中有一条关于 Taints 的信息：node-role.kubernetes.io/master:NoSchedule，就表示master 节点打了一个污点的标记，其中影响的参数是 NoSchedule，表示 Pod 不会被调度到标记为 taints 的节点。除了 NoSchedule 外，还有另外两个选项：

• PreferNoSchedule：NoSchedule 的软策略版本，表示尽量不调度到污点节点上去
• NoExecute：该选项意味着一旦 Taint 生效(被打上taint)，如该节点内正在运行的 Pod 没有对应容忍（Tolerate）设置，则会直接被逐出。 哈哈😂这个命令也是够狠。。。kubectl taint node k8s-node1 disktype=ssd:NoExecute

🍂 污点 taint 标记节点的命令如下：

➜ kubectl taint nodes node2 test=node2:NoSchedule
node "node2" tainted

上面的命名将 node2 节点标记为了污点，影响策略是 NoSchedule，只会影响新的 Pod 调度，如果仍然希望某个 Pod 调度到 taint 节点上，则必须在 Spec 中做出 Toleration 定义，才能调度到该节点。

🍂 最后如果我们要取消节点的污点标记，可以使用下面的命令：

➜ kubectl taint nodes node2 test-
node "node2" untainted

💘 实践：污点与容忍(测试成功)-2022.5.16

• 比如现在我们想要将一个 Pod 调度到 master 节点：

# 05-taint-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: taint
  labels:
    app: taint
spec:
  replicas: 3
  selector:
    matchLabels:
      app: taint
  template:
    metadata:
      labels:
        app: taint
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - name: http
          containerPort: 80
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"

由于 master 节点被标记为了污点，所以我们这里要想 Pod 能够调度到改节点去，就需要增加容忍的声明：

tolerations:
- key: "node-role.kubernetes.io/master"
  operator: "Exists"
  effect: "NoSchedule"

• 然后创建上面的资源，查看结果：

➜ kubectl apply -f taint-demo.yaml
deployment.apps "taint" created

➜ kubectl get pods -o wide
NAME                                      READY     STATUS             RESTARTS   AGE       IP             NODE
......
taint-845d8bb4fb-57mhm                    1/1       Running            0          1m        10.244.4.247   node2
taint-845d8bb4fb-bbvmp                    1/1       Running            0          1m        10.244.0.33    master1
taint-845d8bb4fb-zb78x                    1/1       Running            0          1m        10.244.4.246   node2
......

我们可以看到有一个 Pod 副本被调度到了 master 节点，这就是容忍的使用方法。

那么问题来了：我这个pod可以调度到没打这个污点的node上去吗？还是说会优先调度到这个打了污点的节点上去呢？。。。

–>经测试：是可以调度上去的。pod配置了容忍之后，原来打了污点的node就可以和其他节点一样去负载pod了，具体调度策略是看调度器的。

• 最后如果我们要取消节点的污点标记，可以使用下面的命令：

➜ kubectl taint nodes node2 test-
node "node2" untainted

实验结束。😘

🍂

Taints和Tolerations用于保证Pod 不被调度到不合适的Node上，其中Taint应用于Node上，而Toleration则应用于Pod上。

🍂 nodeSelector/nodeAffinity与Taint/Tolerations区别

nodeSelector/nodeAffinity--一种主观意识，我要分配在哪个node节点上去；
而Taint/Tolerations：是一种排斥行为，在node上排斥pod分配到自己身上；

nodeSelector/nodeAffinity--管理员强迫node
taint/toleration--node主动的一脸嫌弃

🍂

k8s的自愈能力/故障转移能力：–>污点和容忍！

🍂 tolerations 属性的写法

对于 tolerations 属性的写法，其中的 key、value、effect 与 Node 的 Taint 设置需保持一致， 还有以下几点说明：

• 如果 operator 的值是 Exists，则 value 属性可省略
• 如果 operator 的值是 Equal，则表示其 key 与 value 之间的关系是 equal(等于)
• 如果不指定 operator 属性，则默认值为 Equal

另外，还有两个特殊值：

• 空的 key 如果再配合 Exists 就能匹配所有的 key 与 value，也就是是能容忍所有节点的所有 Taints ！！！😋

• 空的 effect 匹配所有的 effect

例子：

master节点上，为什么除了静态pod之外，上面还有calico/kube-proxy组件可以运行。

为什么呢？原因在这里：污点容忍是可以直接放宽条件写的，例如calico，不分什么key什么value，符合带有污点是NoSchedule都可以允许分配。

8、nodeName

nodeName：指定节点名称，用于将Pod调度到指定的Node上，不经过调度器 (nodeName指哪打哪😂,nodeName一般在测试中用，但工作中根本没怎么用到)

💘 实践：nodeName测试(测试成功)-2022.5.16

• 创建pod的yaml并修改

[root@k8s-master ~]#kubectl run pod6 --image=nginx --dry-run=client -o yaml > pod6.yaml
[root@k8s-master ~]#vim pod6.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: nginx
spec:
  nodeName: k8s-node1
  containers:
  - name: nginx
    image: nginx:1.15 

• 注意：原来k8s-node1节点是已经打好污点了的。

[root@k8s-master ~]#kubectl describe nodes |grep Taint
Taints:             node-role.kubernetes.io/master:NoSchedule
Taints:             ssd=ok:NoSchedule
Taints:             <none>
[root@k8s-master ~]#kubectl describe nodes k8s-node1 |grep Taint
Taints:             ssd=ok:NoSchedule
[root@k8s-master ~]#

• apply并查看效果

[root@k8s-master ~]#kubectl apply -f pod6.yaml
pod/pod6 created
[root@k8s-master ~]#kubectl get pod -o wide

• 结论

如果在pod里指定了nodeName字段，那么即使该pod没有配置污点容忍，也会被强制开通的指定的节点上去的。

测试结束。😘

9、优先级调度

与前面所讲的**调度优选策略中的优先级（Priorities）**不同，前面所讲的优先级指的是节点优先级，而我们这里所说的优先级指的是 Pod 的优先级，高优先级的 Pod 会优先被调度，或者在资源不足的情况牺牲低优先级的 Pod，以便于重要的 Pod 能够得到资源部署。

🍂 要定义 Pod 优先级，就需要先定义 PriorityClass 对象，该对象没有 Namespace 的限制：

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

其中：

• value 为 32 位整数的优先级，该值越大，优先级越高
• globalDefault 用于未配置 PriorityClassName 的 Pod，整个集群中应该只有一个 PriorityClass 将其设置为 true

🍂 然后通过在 Pod 的 spec.priorityClassName 中指定已定义的 PriorityClass 名称即可：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

另外一个值得注意的是当节点没有足够的资源供调度器调度 Pod，导致 Pod 处于 pending 时，抢占（preemption）逻辑就会被触发，抢占会尝试从一个节点删除低优先级的 Pod，从而释放资源使高优先级的 Pod 得到节点资源进行部署。

10、多调度器

11、动态调度器

代码的实现而是很简单的。

🍂
docs.gorance.io

🍂

p8s基本是k8s的标配！
这个调度插件只一个锦上添花的能力，而不会影响主调度能力的。

🍂

webhook，节点超售–实际生产上有大规模使用的！

🍂 动态调度成效

思考

1.不用 DaemonSet，如何使用 Deployment 是否实现同样的功能？

我们知道 DaemonSet 控制器的功能就是在每个节点上运行一个 Pod，如何要使用 Deployment 来实现，首先就要设置副本数量为节点数，比如我们这里加上 master 节点一共3个节点，则要设置3个副本，要在 master 节点上执行自然要添加容忍，那么要如何保证一个节点上只运行一个 Pod 呢？是不是前面的提到的 Pod 反亲和性就可以实现，以自己 Pod 的标签来进行过滤校验即可，新的 Pod 不能运行在一个已经具有该 Pod 的节点上，是不是就是一个节点只能运行一个？

• 模拟的资源清单如下所示：

# 06-daemonset-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mock-ds-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mock-ds-demo
  template:
    metadata:
      labels:
        app: mock-ds-demo
    spec:
      tolerations: #加上容忍，这样才有机会运行在master节点上
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
          name: ngpt
      affinity:
        podAntiAffinity:  # pod反亲合性
          requiredDuringSchedulingIgnoredDuringExecution:  # 硬策略
          - labelSelector:
              matchExpressions:
              - key: app   # Pod的标签
                operator: In
                values: ["mock-ds-demo"]
            topologyKey: kubernetes.io/hostname  # 以hostname为拓扑域，相当于每一个节点都是一个拓扑域

• 创建上面的资源清单验证：

$ kubectl apply -f 06-daemonset-deployment.yaml 
deployment.apps/mock-ds-demo created
$ kubectl get po -owide
NAME                            READY   STATUS    RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
mock-ds-demo-8694759c69-882fx   1/1     Running   0          18s   10.244.0.15    master1   <none>           <none>
mock-ds-demo-8694759c69-frfhx   1/1     Running   0          18s   10.244.1.108   node1     <none>           <none>
mock-ds-demo-8694759c69-p5cjw   1/1     Running   0          18s   10.244.2.235   node2     <none>           <none>

可以看到我们用 Deployment 部署的服务在每个节点上都运行了一个 Pod，实现的效果和 DaemonSet 是一致的。

2.同样的如果想在每个节点（或指定的一些节点）上运行2个（或多个）Pod 副本，如何实现？

DaemonSet 是在每个节点上运行1个 Pod 副本，显然我们去创建2个（或多个）DaemonSet 即可实现该目标，但是这不是一个好的接近方案，而 PodAntiAffinity 只能将一个 Pod 调度到某个拓扑域中去，所以都不能很好的来解决这个问题。

要实现这种更细粒度的控制，我们可以通过设置拓扑分布约束来进行调度，设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，从而实现高可用性或节省成本，具体实现方式请看下文。

关于我

我的博客主旨：

• 排版美观，语言精炼；
• 文档即手册，步骤明细，拒绝埋坑，提供源码；
• 本人实战文档都是亲测成功的，各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人帮您解决问题，让我们一起进步！

1. 个人微信二维码：x2675263825 （舍得）， qq：2675263825。

   

2. 个人微信公众号：《云原生架构师实战》

   

3. 个人csdn

   https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

   

4. 个人博客：(www.onlyyou520.com)

   

5. 开源干货😘

   语雀：https://www.yuque.com/go/doc/73723298?#

   

最后

好了，关于本次就到这里了，感谢大家阅读，最后贴上我女神的photo，祝大家生活快乐，每天都过的有意义哦，我们下期见！