基于K8s调度器实现自定义调度

本文介绍了如何基于Kubernetes平台实现自定义调度器,通过官方文档提供的指导配置多个调度器,并在程序中使用工具类进行辅助操作。内容涉及到与数据库交互的经验,以及对比UDF和Hive自定义函数的相似之处。

就是按照约定写代码,和我最开始写mysql UDF,hive自定义函数,都是一样的。

官方配置多个调度器:

https://kubernetes.io/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/

背景:为了实现基于K8s的数据库服务的调度功能
难点:  1,原生K8s的资源只有cpu和mem,但是MySQL调度需要考虑磁盘资源,
            2,原生调度策略不符合线上环境,比如线上容器和物理机存在混跑,服务存在定制策略等
方案: 1,基于K8s 调度器的源码进行修改,定制化调度器,所有服务器调度时指定新调度器实现自定义策略
            2,将需要的元数据,比如MySQL端口容量,服务器磁盘容量等信息通过脚本同步到K8s中的annotations中
流程:
            1,下载调度器源码至本地服务器
 可从官方下载,此处原为内部git地址,省去
            2,本地修改完成后,编译,
CGO_ENABLED=0 GOOS=linux GOARCH=amd64  make all WHAT=cmd/kube-scheduler/
            3,编译完成&&没有报错,打包images 并 push到仓库
docker build -f Dockerfile -t registry.xxxx.xxxx.com.cn/xxxx/scheduler:1.0 .
docker login registry.xxx.xxx.com.cn -u xxxx
docker push registry.xxxx.xxxx.com.cn/xxxx/scheduler
            4,在南北K8s集群上找到运行着的 scheduler,并delete,scheduler以deployment方式部署,delete完成后确认下新scheduler是否running即可
kubectl get pod -n kube-system | grep kube-scheduler-db
kubectl delete pod kube-scheduler-db-xxxxxx-xxxxxxx -n kube-system
            5,至此 scheduler 更新流程流程,之后可以观察修改生效情况,重大更新建议先测试再正式上线
修改的细节(举例)
            scheduler 的目录结构如下
Kubernetes 提供了多种扩展机制,允许开发者和运维人员根据特定需求实现自定义调度逻辑。这些扩展方式主要包括 **调度器插件(Scheduler Plugins)**、**调度器扩展(Scheduler Extenders)** 和 **自定义调度器(Custom Scheduler)**。 ### 1. 使用调度器插件(Scheduler Plugins) 从 Kubernetes v1.19 开始,调度器支持基于插件架构的扩展机制。调度器的核心逻辑被模块化为多个插件,用户可以通过启用或禁用插件来定制调度行为。 - **调度阶段插件**:包括 `QueueSort`, `PreFilter`, `Filter`, `PostFilter`, `PreScore`, `Score`, `NormalizeScore`, `Reserve`, `Permit`, `Bind` 等。 - **配置方式**:通过修改调度器配置文件(如 `scheduler-config.yaml`),指定需要加载的插件及其行为。 例如,以下是一个简单的调度器配置示例: ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: custom-scheduler plugins: score: enabled: - name: MyCustomScoringPlugin weight: 30 ``` 该配置启用了名为 `MyCustomScoringPlugin` 的评分插件,并赋予其权重值为 30 [^2]。 ### 2. 使用调度器扩展(Scheduler Extenders) 调度器扩展是一种外部服务机制,允许在调度过程中调用外部 HTTP 服务来影响调度决策。这种机制适用于无法直接修改调度器源码的情况。 - **功能支持**: - Filter:筛选符合条件的节点。 - Prioritize:对节点进行打分排序。 - Bind:决定将 Pod 绑定到哪个节点。 - **配置方式**:在调度器配置中添加 extender 配置项,指向外部服务地址。 示例配置如下: ```yaml extenders: - urlPrefix: "http://my-extender-service" filterVerb: "filter" prioritizeVerb: "prioritize" weight: 5 enableHttps: false ``` 该配置将调度器与外部服务集成,使得在调度过程中会调用对应的 HTTP 接口执行过滤和优先级排序操作 [^2]。 ### 3. 实现自定义调度器(Custom Scheduler) 如果内置调度器和插件机制无法满足需求,可以完全开发一个独立的调度器替代默认调度器。 - **实现方式**: - 编写一个新的调度器程序,监听未调度的 Pod 并为其分配节点。 - 调度器实现与 kube-apiserver 的交互,获取集群状态并更新 Pod 的 `.spec.nodeName` 字段。 - **部署方式**:作为 Deployment 或 DaemonSet 部署到集群中,并确保其具有足够的 RBAC 权限。 自定义调度器的优点是灵活性极高,缺点是维护成本较高,需自行处理高可用性、性能优化等问题 [^2]。 ### 4. 使用 CRD 和控制器实现高级调度策略 除了调度器本身的扩展机制外,还可以结合 Kubernetes 的 **CRD(Custom Resource Definitions)** 和 **自定义控制器(Custom Controllers)** 实现更复杂的调度逻辑。 - **CRD 定义**:用于描述新的资源类型,如虚拟机实例、GPU 分配策略等。 - **控制器逻辑**:监听相关资源变化,动态调整调度策略或触发特定动作。 这种方式通常用于实现多租户调度、异构计算资源管理等场景 [^2]。 ### 总结 Kubernetes 提供了丰富的扩展机制来实现自定义调度逻辑,具体选择哪种方式取决于实际需求和团队技术能力。对于轻量级的调度增强,推荐使用调度器插件或调度器扩展;而对于高度定制化的调度逻辑,则可考虑实现自定义调度器或结合 CRD 与控制器的方式。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值