云原生离线在线资源混部实践

云原生离线在线资源混部实践 演讲人：携程-周昕毅 -资源混部的前世今生 -携程第一代混部：虚拟化，胖容器 -Spark,K8SorYarn? -技术储备：Kernel/OS/K8S/弹性能力 -携程第二代混部：云原生混部技术 -总结和展望 AboutTrip.com •一站式OTA平台 •机票/酒店/火车票/旅游预订服务 •国内&海外业务 AboutCloudTeam@Trip.com •ProvideCloudInfraServiceforbothOnlineandOfflineworkloads •Virtualization,CloudNetworking,CloudStorage,Kernel&Security 在线服务 离线作业 延迟敏感，直接影响用户体验延迟不敏感，可以接受重试 典型:搜索，web应用典型:大数据分析，AI训练任务白天流量高，和用户行为相关凌晨执行T+1任务消耗资源量大 Online固定资源池 混步资源池 Offline固定资源池 Java Node- Js Node 角色切换 在线BMnode OnlineService 在线VMnode CPU利用率20%-30% Spark 闲时利用率5%-10% 忙时利用率90%-100% 离线VMnode 离线BMnode OfflineJob Yarn AppVM AppVM OpenStack–Nove/Neutron YarnVM 凌晨1点自动拉起，6点销毁 -KVMnodeCPU超配 -凌晨额外启动YarnNodeManagerVM，资源汇报到YarnResourceManager -混部资源分析：KVM宿主机平均内存使用率约60%，凌晨CPU使用率显著 下降，具备超配空间 YarnPod AppPod AppPod 凌晨1点自动扩容，6点缩容 Kubernetes -胖容器的混部架构与VM混部一致，仅仅用Kubernetes调度替换了nova调度 -容器固定ip，域名提前申请(kerberos证书签发及域名反解) -相比VM混部的优势：镜像维护和更新方便，扩容、缩容耗时从分钟级降低到 秒级。 -资源隔离问题 -在线资源池机房和离线资源池机房之间的网络带宽需求 -KVM、K8S在线资源池宿主机平均分配率较高时，混部可用资源规模受限 -定时任务不能覆盖所有场景，人肉运维 云原生&Kubernatize‘Offline’Workloads -JimZemlin:KubernetesisbecomingtheLinuxofthecloud(2017) -2019开始，Spark/Flink/Kafka/Tensorflow等大数据开源框架纷 纷推出KubernetesNativeintegretion -OfflineJob对原生Kubernetes方案带来挑战： -GangScheduling(ML训练任务的特殊需求) -吞吐量指数级上升(创建、删除5K+Pods/Perminute) -CPUquota/SharevsOnlineWorkload低延迟的诉求 -网络IO及磁盘IO的隔离能力是否能满足需求 Spark,onYarnoronK8S? -SparkOnK8S优势 -Spark依赖打包容器化 -Namespace级别资源管控 -更好的权限、APIGroup -作业提交版本控制(imagetag) -SparkOnK8S劣势 -传统大数据生态的改造成本 -现有系统对接成本高 -Yarn统治大数据workload调度的前十年 -折衷 -部分新业务场景onK8S -Yarnnodemanager通过K8S调度 技术储备–在线应用HPA落地 技术储备–Kernel&Cloudnetworking P0APPpod P1APPpod Sparkpod PendingP0 APP-pod 抢占 K8SNode Sparkpod Apppod Apppod Apppod Sparkpod Sparkpod node1 node2 node3 Kubernetes 调度 HPA VPA 监控 抢占 -资源利用率提升，降本增效是技术团队不变的追求 -拥抱云原生 -Betterutilizationofresources,fasterprovisioning,bettergovernance. THANKYOU!