简介
两个基本工作
-
应用容器化
-
编排自动化
美团点评Kubernetes集群管理实践 笔者从中得到一个启发就是,整个kubernetes 的实践是分层次的。
网易数帆云原生故障诊断系统实践与思考 PS: 我们自己wrench工具的分布式版
- 规范用户的使用方式,容器 vs 虚拟机
- 部分集群连接的 APIServer 客户端数量超过了 4000 个,其中不乏一些用户用脚本对 Pod 资源进行全量 LIST 来获取数据。这些集群的 APIServer 消耗接近 100G 的内存以及 50 核的 CPU 算力,并且 APIServer 所在节点的网卡流量达到了 15G。
- 明确集群稳定性保障以及应用稳定性保障的边界以及有效的评估模型,这种责任边界的不明确带来了交付成本上的增长以及不确定性。PS:出问题无法明确是应用的问题还是k8s的问题
- 灰度发布 使用了 Argo Rollout
- 无损发布
- 调度部署策略配置: 应用各实例优先打散在不同的节点上;可以给业务进行分类, 比如 计算密集型 、 IO 密集型 等类型,通过反亲和优先将不同类型的应用调度到一起;给部分业务划分单独的一批节点进行隔离部署
- 机房 dns 打通
- 业务容器化的规范:base 镜像;jdk版本(cpu核数识别、gc线程数);日志规范(路径、格式);无状态化(本地存储改造为访问分布式存储);域名访问(用域名,避免ip访问,因为不固定);尽量request 与limit 一致 防止 节点 System OOM
- 填坑: vivo AI 计算平台的K8s填坑指南
Kubernetes 两年使用经验总结对几乎所有人来说,开箱即用的 Kubernetes 都远远不够。Kubernetes 平台是一个学习和探索的好地方。但是您很可能需要更多基础设施组件,并将它们很好地结合在一起作为应用程序的解决方案,以使其对开发人员更有意义。通常,这一套带有额外基础设施组件和策略的 Kubernetes 被称为内部 Kubernetes 平台。有几种方法可以扩展 Kubernetes。指标、日志、服务发现、分布式追踪、配置和 secret 管理、持续集成 / 持续部署、本地开发体验、根据自定义指标自动扩展都是需要关注和做出决策的问题。配置一个基础的集群可能并不困难,而大多数问题发生在我们开始部署工作负载时。从调整集群自动伸缩器(autoscaler)到在正确的时间配置资源,再到正确配置网络以实现所需的性能,你都必须自己研究和配置。我们的学习到的是,操作 Kubernetes 是很复杂的。它有很多活动部件。而学习如何操作 Kubernetes 很可能不是你业务的核心。尽可能多地将这些工作卸载给云服务提供商 (EKS、GKE、AKS)。你自己做这些事并不会带来价值。
多集群
Kubernetes 多集群项目介绍 阿里: 还在为多集群管理烦恼吗?OCM来啦! CNCF 沙箱项目 OCM Placement 多集群调度指南 腾讯: Clusternet - 新一代开源多集群管理与应用治理项目 Clusternet v0.5.0 重磅发布: 全面解决多集群应用分发的差异化配置难题 其它: 关于多集群Kubernetes的一些思考 多云环境下的资源调度:Karmada scheduler的框架和实现
vivo大规模 Kubernetes 集群自动化运维实践 未读。
降本增效
CPU利用率从10%提升至60%:中型企业云原生成本优化实战指南
- 包年包月 ==> 按需实例 ==> 竞价实例
- 业务机器规格保持在 8 核 3G 的配比,使用率相对均衡。采用了公有云上的高规格裸金属服务器,借助 SchedulX 对公有云裸金属原材料进行了二次切割,经过切割后的算力规格能够精准匹配业务 8 核 3G 的规格需求。
- 引入了 MetricsQPS 指标。该指标将 QPS 中不同请求对机器资源占用的时长纳入了考量,通过对 QPS 按时长进行分段并配以相应的权重最终拟合而成。相对于普通 QPS 指标,MetricsQPS 更能精确地反映出业务实际负载情况。持续采集该指标,精准匹配算力波动曲线并实时联动扩缩容;(而不是使用常规的QPS、CPU利用率等指标)
- 公有云上西部机房同规格的算力比东部机房更便宜,通过将近 100 台离线服务器迁移到西部机房,同时借助 SchedulX 快速大批量数据迁移的能力实现东数西算,节省成本 10%。
- 接入公有云相应的部署发布、监控告警、限流自愈等附属功能,从而节省出一个运维的人力
- 降本配套设施
- 需要明确算力衡量指标体系,前期可以粗略使用 CPU 利用率等系统指标,后期需要借助精准的业务指标,比如 QPS 及单请求的耗时结合的复合指标。
- 降本过程需要有较完备的监控告警系统及容灾 SOP,防止在优化过程中出现意外情况。比如在优化低频冗余算力环节,小王在下机器的时候,提前根据 CPU 等指标设置好了扩缩容策略,在系统保持一周无异常后才将下线的机器清退。
- 为了精准量度业务算力,需要搭配压测系统及方案。前期为尽量减少业务投入成本,主要是基于以下思路来操作:测试环境 ->线上日志回放 ->mock 调用接口 ->采集算力衡量指标 ->逐步放大调用压力 ->响应超时的服务器达到一定比例时结束压测。后期可以逐步迭代为全链路压测,从网关到调用链路到存储全隔离的形态,衡量效果会更精准,当然相应研发成本和投入也会更重。
- 为了充分体现每一步的优化成果,需要有成本看板,对每一阶段优化前后的机器资源和成本消耗进行环比或横比展示。成本看板主要针对中高层人群,所以信息要简明扼要,成本信息突出。
- 降本遇到的非技术问题
- 由于改造的投入成本和机会成本都很高,所以要求改造带来的收益要足够大。降本工作的推进也会影响稳定性保障、业务研发等工作,所以降本工作需要先成为公司的重点项目或者产研团队的 KPI。在推动层级方面,公司成本优化总体来说是一把手工程,过程中难免需要各部门的协同配合及利益分摊,所以由 CTO 发起并提供支持是小王完成成本优化目标的重要前提。
- 公司确定降本工作是重点项目后,还需要在公司层面或者产研层面进行正式立项,指定项目负责人、项目技术负责人等,并明确项目的目标,以及项目人员的沟通。原则上所有受降本影响的部门都要派出自己的代表,实际可以确保所有的职能都派出代表,这样既能控制项目组规模又有足够的代表性。比较好的项目组核心人员组合是,由收益最大或工作量最大的部门作为项目的负责方并派出项目负责人,受影响最大的部门派出技术负责人。
- 云化、弹性等都会带来新的预算管理和成本核算方式,需推动公司内部成本管理机制升级。在项目早期,就要对降本项目的优化效果进行量化。只有明确的、量化的目标和明显的收益,方能为各个部门提供足够动力配合推进。
- 试点业务要适中,过小的业务没有代表性,而如果业务过大,一旦出现问题,后果会很严重。在试点业务成功实践之后,再推动到公司的核心业务。核心业务有足够的代表性和说服力,只有在核心业务落地才可能在全公司全面落地。这也需要项目组与核心业务密切配合,核心业务的负责人或代表最好就是项目负责人或者技术负责人。有了试点效果后高层更乐于协助推进。
- 针对项目收益分配,比较好的做法是把各种收益进行拆分,然后再依据分别的贡献进行分配。比如项目整体荣誉归项目组、项目管理的收益归项目负责人及其所在部门、项目技术上的收益归技术负责人及其所在部门、各模块的收益归模块负责人及其部门。在晋升时也需要项目负责人协调好各自的边界,避免相互冲突的情况。项目负责人及其所在部门要把更多的利益分给项目组中其他的部门,从而更好地激励大家积极参与之后的其他改造与建设项目。
- 在优化节奏方面,建议先从成本占比、优化难度、优化效果、是否核心等维度对业务进行排序打分,先从成本占比大,优化难度小,优化效果明显、非核心的业务开始优化。
排查问题文章汇总
kubernetes 问题排查: 磁盘 IO 过高导致 Pod 创建超时 kubernetes 平台开发者的几个小技巧 内存回收导致关键业务抖动案例分析-论云原生OS内存QoS保障 去哪儿容器化落地过程踩过的那些坑Qunar 在做容器化过程中,各个系统 portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造
- portal:Qunar 的 PAAS 平台入口,提供CI CD 能力、资源管理、自助运维、应用画像、应用授权(db授权、支付授权、应用间授权)等功能
- 运维工具:提供应用的可观测性工具, 包括 watcher(监控和报警)、bistoury (java 应用在线 debug)、qtrace (tracing 系统), loki/elk (提供实时日志/离线日志查看)
- 中间件:应用用到的所有中间件, mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk等
- 虚拟化集群:底层的 k8s 和 openstack 集群,多k8s集群管理工具 kubesphere
- noah:测试环境管理平台,支持应用 kvm / 容器混合部署