建设一家网站多少钱,seo优化招商,如何在自己建设的网站上发表文章,短网址链接生成上篇文章详细介绍了弹性云混部的落地历程#xff0c;弹性云是滴滴内部提供给网约车等核心服务的容器平台#xff0c;其基于 k8s 实现了对海量 node 的管理和 pod 的调度。本文重点介绍弹性云的调度能力#xff0c;分为以下部分#xff1a; 调度链路图#xff1a;介绍当前弹… 上篇文章详细介绍了弹性云混部的落地历程弹性云是滴滴内部提供给网约车等核心服务的容器平台其基于 k8s 实现了对海量 node 的管理和 pod 的调度。本文重点介绍弹性云的调度能力分为以下部分 调度链路图介绍当前弹性云调度体系链路对架构体系有一个初步的认知k8s 调度能力的运用整体介绍弹性云现在用到的 k8s 调度能力和对其的增强k8s 版本的升级介绍到从 k8s 1.12 到 1.20 跨版本升级的方案服务画像/真实使用率调度原生的 request 调度存在着和真实使用率之间的 gap 等缺陷尝试通过对 node 上业务做数据画像来让调度做出更符合真实情况的调度重调度由于调度只能依据当前数据随着业务的增长、集群机器的下线等调度效果可能不达预期比如会产生一些宿主机热点等介绍重调度对这块的处理能力调度规则引擎通用的调度策略不能满足所有业务场景直接在调度主流程中做适配比较 hack介绍 GalahadWebhook 对调度资源的灵活注入从而影响最终的调度结果的能力调度稳定性建设介绍整体调度的稳定性保障体系 调度链路图 kube-rescheduler重调度模块自动轮询集群状态并发起异常 pod 的漂移kube-odin弹性云的上游 pass 层用户通过 kube-odin 接入弹性云galahad调度规则引擎按标签选取业务 pod 或 node 的调度策略存储主要解决物理机集群差异化快速变化的需求与 k8s 集群管理的灵活度匹配kube-hookk8s 的 mutatingwebhook 和对应服务用于将 galahad 注入 pod 或 nodemaster原生的 k8s 三大件ipam弹性云的 pod ip 分配模块IRMAS内核组件包括 Odin-Agent 监控数据上报、pod quota 分配等能力kube-agentnode 组件做真实使用率数据的获取和写入zhivago基于 Prometheus 的服务画像引擎涉及数据清洗数据分析数据存储大盘展示等多个模块 k8s 调度能力的运用 涉及资源 无状态服务Deployment弹性云最开始使用的 workload但因为历史原因比如要兼容业务在物理机时代的使用方式等目前已废弃。有状态服务StatefulSet弹性云目前支持的主 workload优化了控制器逻辑实现了自定义部署顺序策略、无序删除策略、打散策略等等。静态容器Pod直接管理 pod在现有的 Kubernetes 原生调度编排之上提供和 VM 类似的资源交付手段是为了兼容类似物理机使用方式的妥协不 cloudnative不建议新业务接入Endponit接流组件监听其变化在pod漂移后自动接上dsi/lvs的流量Deamonsetnode 上 agent 的 workload k8s 调度器的实现 kube-scheduler 的根本工作任务是根据各种调度算法将 Pod 绑定bind到最合适的工作节点整个调度流程分为两个阶段预选策略Predicates和优选策略Priorities这里不再赘述。 弹性云调度预选卡点 在 k8s 原生的预选卡点上我们做了很多增强 弹性云调度优选算分 重点介绍两个优选算法 很长一段时间我们一直使用如下的优选打分权重也就是 Balanced 和 Least 并重但在资源紧张的情况下重调度效果显示调度在即使有比较低利用率 cpu 的 node也会选取另一个利用率较高但比较均衡的 node而这个 node 更可能成为热点这就是我们说的“调度bad case”。 为此当前在某些峰值利用率较高、热点较大的大机房做了如下优选权重的调整更加关注资源的使用率而不是平铺度。 调度器框架 在将 k8s 版本升级到 1.20 后我们将上述弹性云的预选卡点和优选算法全部通过 SchedulerFramework 做了重新实现主要拆解为 PreFilter、Filter 和 Score 三种扩展点。 k8s 版本的升级 不久之前弹性云部分机房 k8s 版本还是 1.12升级到 1.20 的难点如下 集群体量大最大集群规模已经远远超出了社区推荐的5千个 node 上限有问题的爆炸半径大场景复杂多样隔离集群、有状态服务容器、不可变更ip漂移容器、静态容器等周边涉及范围广kube-odin、各种 operator 和控制器等诸多上游组件。 替换升级方案介绍 两个 k8s 集群1.12 和 1.20直接搭建新的一套新的 1.20 master 和周边组件1.20 集群中创建和 1.12 和等量的业务负载也就是 sts 和 pod 通过上游的流量管控应用决定流量分布一开始流量都在 1.12 的 sts 的 pod中逐步切流到 1.20 的 sts 的 pod有问题的时候可以快速回切流量。 原地升级方案介绍 只有一个 k8s 集群将 master 和周边组件直接从 1.12 升级到 1.20逐步将集群中的 node 也就是 kubelet 从 1.12 版本升级到 1.20不做任何业务负载相关的操作也就是 sts 和 pod 无需重建其实的流量分布也不做操作随着 node 升级流量天然就逐步从 1.12 切到 1.20 了有问题的时候需要部分回滚 node 的 kubelet当出现全局性风险的时候需要全量回滚 master 和周边组件。 两个方案对比如下 从方案可落地以及成本角度最终选取了原地升级。 核心实现 有状态服务比如 redis 等需要 kubelet 升级容器不重启修改原生的kubelet 实现按hash值是否变化来决定是否重建容器的策略。 升级中间态风险规避master 1.20 部分 Kubelet 1.12 的场景梳理和关注高版本 apiserver 中资源或协议的变化推动周边系统使用非 alpha 或 beta版本资源。 目前已无损升级滴滴所有核心机房万级别的 node 和十万级别 pod 且升级过程中业务完全无感未发生一次故障。 服务画像/真实使用率调度 从全局资源优化角度看调度是动词是策略的运用关键是这个策略从何而来、怎么优化我们知道 k8s 原生使用 request 做装箱而一般为了成本考虑都会做 node 上的超卖这在 node 上所有 pod 利用率都较高的情况下会产生热点和资源争抢。 服务画像的核心目标是探索不影响业务情况下的单机使用率上限以及寻找真实资源的全局分布最优解。其核心能力包括元信息完备的多维数据map能力灵活的聚合计算语言 promQLreduce 能力配置化的数据可视化大盘 可观测性能力以及灵活可配置的数据-策略通路画像能力。 数据分析 MapReduce MapReduce 是一种数据处理思想Map 代表数据预处理包括归一化、格式化、补全数据元信息等Reduce 代表数据聚合可以进一步分为四种运算操作过滤filters、聚合aggregations、集合操作set operations和联结joins。 举个例子如何用MapReduce的思想分析数据 北京机房下X2234节点、wyc产品线的所有8核规格容器中所有可漂移的容器过去七天消耗的最大CPU核数按宿主机维度求和。 表达式: sum(max_over_time(ddcloud_pod_cpu_used{regionbeijing,
setX2234, prod_linewyc,cpu_limit8,
flexibletrue}[7d]))by(m_host) 结论 依据该分析可得出 wyc 产品线的容器在北京机房部分物理机上的分布情况并据此人工或自动消除 wyc 产品线容器热点。 真实使用率调度 在过去一段时间整个弹性云公共集群一直处于超卖较大的情况而真实利用率的限制是真正保证高峰期宿主不会被打爆的主要策略。 如何算出真实使用率算法是取当前宿主所有 pod对其进行拟合取七天内最大的点作为调度参考值。当 pod 发生漂移时值也随之改变。zhivago 会将 pod 和 node 的7天最大值提前计算好保存到对应的配置中此配置会被调度读取并作为调度决策的重要参考每1分钟为更新周期。 为什么取七天最大值因为从当前的数据的同比、环比可以看到滴滴的业务特性7天为循环周期。取7天最大值可以在最坏的情况下尽量不产生热点。调度会保证宿主上所有 pod 7天真实使用率之和不超过真实资源的一定比例包括cpu、内存、io 和磁盘等。 重调度 kubernetes 调度 pod 是一次性决策的实时状态决策但业务的压力是变化的所以长期运行后 node 的状态不一定合理。我们的服务画像/真实使用率调度是一个偏“保守”的调度策略如果业务流量保持和前7天完全一致可以确保各个 node 在高峰期的 cpu 利用率都不会超过一定比例。但在很多场景下业务流量会创新高比如服务先扩容后切流 还有比如集群新增了亲和/互斥的策略如何将策略作用于存量 pod 集群修改超卖规则超卖系数压缩怎么对存量 pod 生效怎么处理不满足新调度规则的 pod对这些场景我们都希望用重调度来再做一次调度 核心流程 定时任务1每10分钟做一次筛选对不满足调度 Good Case 的 pod 入队列定时任务2每分钟做一次筛选对满足漂移条件的 pod 做漂移定时任务3每分钟做一次漂移失败的 pod 的检查重新入队列定时任务4每天捞一轮数据以生成重调度的成功率、失败数以及未恢复 pod 的日报。 紧急均衡 由于 CPU 属于抖动性最强的资源在利用率较高的情况下一般业务都会受到影响所以提供了紧急情况立即均衡的能力不区分业务高峰期。紧急均衡触发条件为物理机实际利用率高于一定的水位可配置调整。 兜底策略 重调度是统一的再调度中心具备自动化能力但调度本身较重需要规避不可控的爆炸半径。因此有如下重调度的限制 效果说明 在流量和核数相同的情况下重处理前后的集群热点率对比 调度规则引擎 一直以来我们努力的方向是完善调度策略精确性或者说是完善基础能力虽有一定的效果但已经无法满足日益复杂的调度需求。为了让调度的管理能力可配置化而不再依赖于代码的上线需要一个单独的组件对涉及到的如下属性做修改和使用 Annotations 各种开关、阈值、附加属性等Labels 阈值、标签Resource pod所需资源、node总资源Taints/Tolerations nodes taint and pods tolerationsAffinity nodes and pods soft and hard [anti]affnity 修改的对象可以是 Pod、Node、Pod Controller如Statefulset等。这就是 Galahad它是核心调度组件负责集群资源调度与管控寻找集群调度过程中的圣杯。 Galahad 全景图如下图所示 核心实现 通过 Galahad 可以提供对 k8s 各个资源的自定义配置如容器维度的调度打散亲和性、物理机维度的资源超卖资源限制、业务集群维度的物理机亲和性等等。具体是和 webhook 配合使用基于 k8s 的 mutatingwebhook 实现对新建 pod 或者修改 node 的资源注入。 效果说明 支持以下场景 为了满足混合调度的需求尽量减少调度器的修改通过 Galahad 区分 pod 在不同集群的调度策略在隔离集群等需要特殊打散配置的场景下直接通过 Galahad 注入 pod 打散策略在 map 等公共集群重数据服务上云的场景下通过 Galahad 注入 pod 的跨 sts 平铺。 调度稳定性 稳定性体系 1、调度可观测 调度链路的可观测apiserver-hook-etcd 的 trace 串联 调度现场的可观测调度失败详情、优选打分日志、调度现场的pod和node快照 集群状态的可观测包括集群 node 和 pod 详情、剩余套餐数、热点和可解释大盘等 2、核心指标保障周调度成功率、堆积和延迟重调度成功率和延迟各组件指标比如apiserver qps等通过核心指标大盘体现。 3、功能点自动化回归验证自动化巡检能力。 4、放火能力失败验证故障注入和系统自我止损能力。 组件稳定性 1、apiserver 稳定性 请求均衡基于 go away 的长连接请求打平限流保护原生的 apf 限流对内部组件请求豁免的优化来源感知复杂请求链路梳理、推动调用方增加 client 信息应急预案master 备机和快速扩容 sop 2、调度器性能优化 在离线 pod 调度优先级差异化处理和退避策略保障在线调度性能percentageOfNodesToScore 等调度器参数优化 3、控制器性能优化 endponit 控制器同步缓存数据优化时间复杂度从n*n-1发布封线时间缩短4/51.12版本 taintController 直接从 etcd list pod 请求的优化 4、galahadwebhook 稳定性 1.12 默认的 apiserver 对 webhook 长连接优化为短连接webhook 部署优化容器和物理机冷备galahad 操作工单化防止误操作强弱依赖不可用演练 5、etcd 稳定性 apiserver 对 etcd 的前置限流保护event 和主 etcd 的拆分穿透到 etcd 的 list 请求治理客户端定时压缩优化为服务端自己主动压缩高峰期前的 deflag 磁盘碎片整理 故障治理能力 1、事前 监控和告警补全周边依赖梳理强依赖稳定性保障压测环境单集群容量上限摸底 2、事中 护堤手册和大盘通用问题排查手册故障场景止损 SOP 3、事后 复盘和改进落地流程 总结 滴滴弹性云基于 k8s 实现了容器调度支持多云调度、在线隔离、在离混部的多种复杂业务场景目前在线公共集群的平均利用率已经接近50%未出现明显异常。 在这个过程中基于对 k8s 的理解完善了画像、重调度、规则引擎能力提升了调度效果并通过稳定性治理保证了系统99.99%的可用。后续会进一步在业务精细化调度、隔离能力完善、多调度器支持以及可观测提升等方面做深耕。 云原生夜话 聊聊看您对k8s的使用落地有什么心得怎么解决集群资源分配的问题呢如需与我们进一步交流探讨也可直接私信后台。 作者将选取1则最有意义的留言送出滴滴200元打车券。10月24日晚9点开奖。
