运维大规模K8S集群的注意事项 1 pod无法启动 有几个组件的pod,有的是deployment,有的是cronjob,运行了380多天了,突然有一天,这个pod就启动不起来了,一直在 #在pod的spec里面配置 enableServiceLinks: false 在k8s的默认配置中,会将svc的相关信息注入到pod中,而在pod进行启动init进程的时候,环境变量会作为参数传递进入 急匆匆上线,急匆匆扩大规模,到了一定的时间段,卧槽。。。 如果你架构上面做了双k8s的架构那还有挽救的可能,否则,你将毫无办法。 坑多了,其实压力也蛮大的,因为毕竟自己设计的自己运维,而且是大规模的集群,升级起来何其痛苦,要通知各种人,各种防御手段,一想到这,我就准备把同事嘎了,怎么他们就没阻止我。
11 月 23 日,Erda 与 OSCHINA 社区联手发起了【高手问答第 271 期 -- 聊聊大规模 K8s 集群管理】,目前问答活动已持续一周,由 Erda SRE 团队负责人骆冰利为大家解答 ---- Q1:K8s 上面部署不通的应用对于存储有不同的要求,有的要高吞吐,有的是要低响应。大规模 K8s 部署的时候是怎么协调这种存储差异的问题?还是说需要根据不同的场景,运维不同的存储服务? Q2:请问下你们维护的最大 K8s 集群规模大小是多少?遇到了哪些性能、稳定性问题?做了哪些优化? A2:我们目前维护的单个集群规模不大,总量相对大些,维护了几百个集群。 Q8:请问老师你们运维的 K8s 集群是运行在物理机上还是虚拟机上呢?现在不少公司都已经有虚拟化环境,虚拟机和容器共存有什么经验、建议吗? A8:我们现在运维的 K8s 集群大部分都是在虚拟机上。 Q10:如果存在要跨地域建 K8s、跨时区的场景下,如何保障 K8s 集群的稳定性,主机时间如何处理? A10:个人不建议跨地域、跨时区,构建同一个 K8s 集群。建议考虑多集群的方案。
3、apiserver 的负载均衡 通常为了保证集群的高可用,集群中一般会有多个 master 节点,kubelet 的连接也会被均分到不同的 apiserver,在 k8s v1.10 以前的版本中, 动态调度支持:由于 kubernetes 的默认调度器只在 pod 创建过程中进行一次性调度,后续不会重新去平衡 pod 在集群中的分布,导致实际的资源使用率不均衡,此时集群中会存在部分热点宿主,为了解决默认调度器的功能缺陷 六、kube-proxy 优化 1、使用 ipvs 模式 由于 iptables 匹配时延和规则更新时延在大规模集群中呈指数增长,增加以及删除规则非常耗时,所以需要转为 ipvs,ipvs 使用 hash 八、客户端优化 在大规模场景下,集群中所有的 daemonset、webhook 以及 operator 等组件非常多,每个客户端都要从 apiserver 中获取资源,此时对 apiserver 的压力非常大 十、动态调整 Pod 资源限制 在大规模集群场景,服务可能会因高峰期资源不足导致响应慢等问题,对于某些应用时间内 HPA 或者 VPA 都不是件容易的事情。
建设单个大规模集群的原因 随着业务的快速增长,TDW的节点数也在增加,对单个大规模Hadoop集群的需求也越来越强烈。 TDW需要做单个大规模集群,主要是从数据共享、计算资源共享、减轻运营负担和成本等三个方面考虑。 1. 数据共享。 十几个集群同时需要稳定运营,而且当一个集群的问题解决时,也需要解决其他集群已经出现的或者潜在的问题。一个Hadoop版本要在十几个集群逐一变更,监控系统也要在十几个集群上部署。 建设单个大规模集群的方案及优化 面临的挑战 TDW从单集群400台规模建设成单集群4000台规模,面临的最大挑战是Hadoop架构的单点问题:计算引擎单点JobTracker负载重,使得调度效率低、集群扩展性不好 结语 TDW从实际情况出发,采取了一系列的优化措施,成功实施了单个大规模集群的建设。为了满足用户日益增长的计算需求,TDW正在进行更大规模集群的建设,并向实时化、集约化方向发展。
那么怎样才能在复杂的大规模场景中,做到真正先于用户发现问题呢?下面我会带来我们在管理大规模 ASI 集群过程中对于快速发现问题的一些经验和实践,希望能对大家有所启发。 2 背景 2.1 复杂的场景和曾面临的困境 我们所管理的大规模 ASI 集群场景非常复杂,这为我们的工作带来了极大挑战,任何一个场景处理不慎就有可能导致意料之外的伤害扩大化。 大规模场景下,数据无法达到 100% 的完全一致性。 当集群规模足够大时,数据的一致性问题将会愈加显现。比如全局风控组件是否全集群链路覆盖?相关流控配置是否全集群链路推平? 同时,当 etcd 集群因为某些原因不可用了,我们也可以通过手动触发等其他方式做探活,也能第一时间得到是否恢复的信息。 3.2 定向巡检 在大规模集集群/系统场景下,数据一致性是一定会面临的难题。 Operator 叫 Kuberhealthy 也可以做类似的事情,我们曾经也考虑采用,并且深度使用过 Kuberhealthy 和参与 kuberhealthy 的社区贡献,最终得出不适合的结论,主要原因是对大规模集群的支持较弱
有一个渲染应用场景,单一个工作负载(Deployment)就有数百个副本,为了降低运维成本,选择了某云商的弹性容器实例产品作为载体,其按pod数量以小时计费,相较于准备大量的Node的方式要划算得多。
本篇文章就以此为背景,介绍大规模调度场景下分布式任务调度的难点、解决策略及现有的一些方案。 这些年发展迅速的Kubernetes也包含调度器,其本质上还是面向应用运行层面,默认调度器的策略比较丰富,扩展性也比较好,但在面对大规模的调度时,吞吐性能表现不是那么完美。 对于大规模的计算集群也一样,应用程序由群集上的多个任务(通常在不同的主机上)组成。集群调度程序基本上必须解决: 多租户: 在群集上,许多用户代表多个组织启动了许多不同的应用程序。 Firmament 调度 Firmament 通过对调度算法的优化使得大规模计算集群的任务调度可以很好地在性能和准确之间找到平衡。 有些类似梯度递减形式的机器学习模型可以开始应用在调度上,已经有一些公司在做相关的探索,相信在未来大规模分布式调度会变得越来越重要。
Kubernetes 搭建大规模集群最佳实践 Kubernetes 自 v1.6 以来,官方就宣称单集群最大支持 5000 个节点。 通过给 ETCD 配置 --quota-backend-bytes 参数增大空间配额,最大支持 8G。 eth0 parent 1: protocol ip prio 2 u32 match ip dport 2379 0xffff flowid 1:1 分离 Kubernetes events 存储 为了在大规模集群下提高性能 推荐配置: 1-5 节点: n1-standard-1 6-10 节点: n1-standard-2 11-100 节点: n1-standard-4 101-250 节点: n1-standard-8 参考材料 Building large clusters Scaling Kubernetes to 2,500 Nodes Kubernetes 大规模集群 大规模集群配置优化
大规模 Kubernetes 集群管理的帮助 在 KubeCon Paris 2024 上,OVHcloud 将宣布一款名为 OVHcloud Managed Rancher Service 的新产品, 这是一个完全开源、自助、现成的平台,公司可以使用它来管理 Kubernetes 集群。 值得注意的是,Managed Rancher Service 为多云和混合云场景提供支持,使公司能够轻松管理和编排 K8s 集群,无论它们来自公有云还是私有云、内部部署基础设施、第三方或其他来源。 “Rancher 将帮助他们管理工作负载并在不同容量的 K8s 集群中编排,无论是在我们的云中,还是作为我们云和他们自己的内部部署设施的混合解决方案的一部分,甚至与其他服务提供商一起。” 对于在多个服务提供商的数据中心中运营多个 K8s 集群的公司而言,这是一个特别的挑战,因为 K8s 集群管理出了名的复杂。
添加一个节点 添加节点相对麻烦一点,分作两步: 使用 etcdctl member add 或 members API 添加节点 使用新的集群配置启动新加入的节点,包含一份所有当前成员的列表 [root /etcdctl member list 1b80a88a471eb4b8: name=h104 peerURLs=http://192.168.100.104:2380 clientURLs=http /etcdctl member list 1b80a88a471eb4b8: name=h104 peerURLs=http://192.168.100.104:2380 clientURLs=http
第一次更新成功是因为 cas 指定的值 1061 与 ModifyIndex 相等,第二次失败是因为,cas 指定的值 1061与ModifyIndex 的 1076 不相等
Scheduler:调度服务,负责对业务接入申请单进行自动调度部署、集群自动化扩容、各集群运营数据统计等。 运维管理系统: Web可视化管理集群,提供业务接入、集群管理、容量管理、配置管理等功能。 他在农历春节期间就快马加鞭实现了异步迁移原型,在这过程中我们协助其测试、反馈BUG和瓶颈、不断改进、优化迁移性能,最终异步迁移不仅支持任意大小Key迁移,而且迁移性能相比同步迁移要快5-6倍,我们也是第一个在线上大规模应用实践 应答成功,则进入准备就绪状态,Dashboard将此状态同时分发到所有Proxy,Proxy收到此状态后,访问此哈希槽中的Key的业务请求将被阻塞等待,若有Proxy应答失败,则会立刻回退到上个状态(时序图8,9,10 基于Quorum的分布式探测Agent,如Redis的Sentinel,Sentinel在新浪微博等公司已经进行了较大规模应用,Codis也是基于此实现主备自动切换,我们在此基础上增加了告警和当网络出现分区时 低负载优化 集群缩容和相同业务复用同集群 存储机多实例部署,现在默认8个实例 通过Agent顺序触发个实例aof rewrite和rdb save,避免多个实例同时fork,从而提高存储机内存使用率至最高
Sun Grid Engine 大规模集群监控 #!/usr/bin/perl #! /bin/bash ## 最近查看队列使用情况 发现如下问题,用户使用SGE 集群的时候内存溢出 ## 此程序用于查看SGE (Sun Grid Engine) 整体集群监控 ##仅以此程序,帮助大家查看
本文中,我们将对支持 Pinterest 的大规模缓存集群的架构进行深入的技术研究。 Mcrouter 提供了解耦的控制平面和数据平面:Memcached 服务器集群的整个拓扑结构被划分为多个“池”(逻辑集群),而管理客户端和服务器池之间交互的请求路由策略和行为均被独立管理。 mcrouter 中的流量路由功能使我们可以进行各种弹性测试,包括集群到集群的暗流量以及在实际生产请求中人为加入的延迟和停机时间的测试,而不会影响生产。 ,针对位于基于闪存的容量集群后方的基于内存集群的 L1L2 路由(具有穿透)等。 我们管理维护着约一百个不同的 Memcached 集群,其中,许多集群具有不同的租户(tenancy)特征(专用与共享)、硬件实例类型和路由策略。
3、apiserver 的负载均衡 通常为了保证集群的高可用,集群中一般会有多个 master 节点,kubelet 的连接也会被均分到不同的 apiserver,在 k8s v1.10 以前的版本中, 十、动态调整 Pod 资源限制 参考:超大规模商用 K8s 场景下,阿里巴巴如何动态解决容器资源的按需分配问题? 在大规模集群场景,服务可能会因高峰期资源不足导致响应慢等问题,对于某些应用时间内 HPA 或者 VPA 都不是件容易的事情。 参考: eBay应用程序集群管理器TESS.IO在大规模集群下的性能优化 Meet a Kubernetes Descheduler 网易云基于Kubernetes的深度定制化实践 开放下载《阿里巴巴云原生实践 CafeDeployment 腾讯成本优化黑科技:整机CPU利用率最高提升至90% 华为云在 K8S 大规模场景下的 Service 性能优化实践 优化Kubernetes集群负载的技术方案探讨 记一次
最后我们决定做一个更加云原生的诊断工具,使用 operator 实现集群跟诊断项的管理,抽象出集群跟诊断项的资源概念,以此来解决大规模 Kubernetes 集群的诊断问题,通过在中心下发诊断项到其他集群 ,并统一收集其他集群的诊断结果,实现任何时刻都可以从中心获取到其他所有集群的运行状态,做到对大规模 Kubernetes 集群的有效管理以及诊断。 Kubernetes 集群设计的诊断工具,用于在 Kubernetes 集群中执行诊断项以证明集群的各项功能是否正常,Kubeprober 有如下特点: 支持大规模集群 支持多集群管理,支持在管理端配置集群跟诊断项的关系以及统一查看所有集群的诊断结果 诊断项配置,诊断结果收集,未来也会解决大规模 Kubernetes 集群的运维问题。 image.png 如何使用 Kubeprober 主要解决大规模 Kubernetes 集群的诊断问题,通常我们选择其中一个集群作为 master 集群,部署probe-master,其他集群作为被纳管集群
治大国若烹小鲜,大规模Kubernetes集群的运营哲学 鲍永成 TIGCHAT 昨天 ? 其实不然,集群运营,特别是大规模集群运营,需要丰富的经验,成熟的体系,辅助的工具链等等,因此其难度并不亚于开发一套大型系统。所谓治大国若烹小鲜,集群需要精细化的运营,对于细节的要求更是严格甚至苛刻。 借助于运营数据的收集和可视化,我们发现了更多在集群规模扩充时可能发生瓶颈的潜在问题,也对其进行了优化处理。 etcd 的容量。etcd 默认是 2G 的容量,在大规模的集群下很容易达到瓶颈。 运营工具 大规模的运营需要成套的运营工具链进行辅助,缓解运营人员的工作压力,同时也提供更为自动化的流程,对整个集群提供更为稳固的保障。 在运营了大规模 Kubernetes 集群之后,我们对更高的技术层次发起了挑战,那就是调度。下一章预告《第三章:庖丁解牛,调度的框架与策略》。
摘要:Google的Borg系统是一个运行着成千上万项作业的集群管理器,它同时管理着很多个应用集群,每个集群都有成千上万台机器,这些集群之上运行着Google的很多不同的应用。 我们的分布式存储系统如GFS [34]及其后继CFS,Bigtable [19]和Megastore [8]都运行在Borg上。 2.2 集群和单元 单元中的机器属于单个集群,由连接它们的高性能数据中心规模的网络架构定义。 一个集群位于单个数据中心大楼内,大厦集合构成一个站点。 数据自2013年8月1日起。 4.可用性 故障是大规模系统中的常态[10,11,22]。图3提供了15个样本cell中任务驱逐原因的分解。
上一遍记录了当时集群资源死锁的问题,后来想了想其实小文件较多也会让集群变慢,小文件较多在执行作业时rpc时间就会增加,从而拖垮了job的执行速度。 在数据进入集群之前,将小文件进行合并 2. 小文件写入集群之后,定期合并小文件 3. 使用HBase存储数据 4. 对于已经在集群上的运算结果,采取文件合并的方式 由于不同的引擎,相应使用的方法不同,目前集群主要使用了hive,Impala,Spark进行数据计算。
目前主流的代码管理工具有,Github、Gitlab等。本文所介绍的内容中,所有代码均托管于私有的 Gitlab 中。