李乾坤

AI、系统与工程实践

1 分钟阅读

简介

两个基本工作

  1. 应用容器化

  2. 编排自动化

  3. 提高资源利用率 容器化计算资源利用率现象剖析 资源利用率提升工具大全 资源画像，让容器资源规格的填写不再纠结 资源画像，看得见的容器资源优化助手

美团点评Kubernetes集群管理实践 笔者从中得到一个启发就是，整个kubernetes 的实践是分层次的。

网易数帆云原生故障诊断系统实践与思考

  1. 规范用户的使用方式，容器 vs 虚拟机
  2. 部分集群连接的 APIServer 客户端数量超过了 4000 个，其中不乏一些用户用脚本对 Pod 资源进行全量 LIST 来获取数据。这些集群的 APIServer 消耗接近 100G 的内存以及 50 核的 CPU 算力，并且 APIServer 所在节点的网卡流量达到了 15G。
  3. 明确集群稳定性保障以及应用稳定性保障的边界以及有效的评估模型，这种责任边界的不明确带来了交付成本上的增长以及不确定性。PS：出问题无法明确是应用的问题还是k8s的问题

vivo AI计算平台在线业务落地实践

  1. 灰度发布 使用了 Argo Rollout
  2. 无损发布
  3. 调度部署策略配置： 应用各实例优先打散在不同的节点上；可以给业务进行分类， 比如 计算密集型 、 IO 密集型 等类型，通过反亲和优先将不同类型的应用调度到一起；给部分业务划分单独的一批节点进行隔离部署
  4. 机房 dns 打通
  5. 业务容器化的规范：base 镜像；jdk版本（cpu核数识别、gc线程数）；日志规范（路径、格式）；无状态化（本地存储改造为访问分布式存储）；域名访问（用域名，避免ip访问，因为不固定）；尽量request 与limit 一致 防止 节点 System OOM
  6. 填坑： vivo AI 计算平台的K8s填坑指南

Kubernetes 两年使用经验总结对几乎所有人来说，开箱即用的 Kubernetes 都远远不够。Kubernetes 平台是一个学习和探索的好地方。但是您很可能需要更多基础设施组件，并将它们很好地结合在一起作为应用程序的解决方案，以使其对开发人员更有意义。通常，这一套带有额外基础设施组件和策略的 Kubernetes 被称为内部 Kubernetes 平台。有几种方法可以扩展 Kubernetes。指标、日志、服务发现、分布式追踪、配置和 secret 管理、持续集成 / 持续部署、本地开发体验、根据自定义指标自动扩展都是需要关注和做出决策的问题。配置一个基础的集群可能并不困难，而大多数问题发生在我们开始部署工作负载时。从调整集群自动伸缩器（autoscaler）到在正确的时间配置资源，再到正确配置网络以实现所需的性能，你都必须自己研究和配置。我们的学习到的是，操作 Kubernetes 是很复杂的。它有很多活动部件。而学习如何操作 Kubernetes 很可能不是你业务的核心。尽可能多地将这些工作卸载给云服务提供商 (EKS、GKE、AKS)。你自己做这些事并不会带来价值。

使用Kubernetes落地云原生困难重重容器技术解决了应用打包和部署自动化问题。微服务架构解决了复杂应用的解耦和治理问题。Kubernetes解决了应用编排和调度自动化问题。为了实现应用管理自动化，还有很多云原生相关的技术，像SDN（网络自动化管理）、SDS（存储自动化管理）、Helm（复杂应用交付自动化）、Service Mesh（无侵入扩展服务治理能力）、Monitoring（监控自动化）、Logging（日志自动化）、Tracing（性能分析自动化）、Chaos engineering（容错自动化）、Gateway（网关自动化）、SPIFFE （应用访问安全自动化）等等，这些技术可以跟Kubernetes结合起来使用，解决应用各个运维特征的管理自动化问题。上面这些技术主要围绕着Kubernetes，所以落地过程主要是Kubernetes落地。PS: 不懂Kubernetes实现云原生的体验

vivo 云原生容器探索和落地实践 梳理的很全面。

降本增效/FinOps

阿里云易立：云原生如何破解企业降本提效难题？受访者表示所在企业过去一年在 Kubernetes 环境的计算资源成本有所增加。这背后的原因是什么？我们发现企业目前面临五大难题：

  1. 规划难。当业务迁移到容器场景后，需要对应用进行容量规划，过度分配资源会导致资源浪费，资源超售过度则会导致稳定性问题。
  2. 计费难。容器应用与传统应用相比具备更高的弹性和动态性，可以按需创建和释放资源，这也对费用估算带来更大的挑战。
  3. 分账难。与传统应用部署与资源绑定的方式不同。现在多个容器应用共享一个 K8s 集群。一个计算节点上可以运行多个 Pod，而且 Pod 可以弹性伸缩，在节点间动态迁移。应用层与资源层计量计费在空间、时间等多个维度都无法做到一对一对应，造成成本治理的复杂性。
  4. 优化难。云原生技术中例如：弹性、混部、Serverless、超卖等技术都有各自适合的典型场景。如果使用不当，比如弹性配置错误，可能带来意想不到的资源浪费甚至稳定性问题。
  5. 管理难。混合云已经成为企业 IT 架构的新常态。Kubernetes 可以帮助企业屏蔽基础差异。而不同环境财资管理能力参差不一，缺乏统一开放的用量数据模型进行管理，使得企业难以从全局的视角进行整体的成本分析与优化。 应对：AHPA、混部

CPU利用率从10%提升至60%：中型企业云原生成本优化实战指南

  1. 包年包月 ==> 按需实例 ==> 竞价实例
  2. 业务机器规格保持在 8 核 3G 的配比，使用率相对均衡。采用了公有云上的高规格裸金属服务器，借助 SchedulX 对公有云裸金属原材料进行了二次切割，经过切割后的算力规格能够精准匹配业务 8 核 3G 的规格需求。裸金属服务器究竟是什么
  3. 引入了 MetricsQPS 指标。该指标将 QPS 中不同请求对机器资源占用的时长纳入了考量，通过对 QPS 按时长进行分段并配以相应的权重最终拟合而成。相对于普通 QPS 指标，MetricsQPS 更能精确地反映出业务实际负载情况。持续采集该指标，精准匹配算力波动曲线并实时联动扩缩容；（而不是使用常规的QPS、CPU利用率等指标）
  4. 公有云上西部机房同规格的算力比东部机房更便宜，通过将近 100 台离线服务器迁移到西部机房，同时借助 SchedulX 快速大批量数据迁移的能力实现东数西算，节省成本 10%。
  5. 接入公有云相应的部署发布、监控告警、限流自愈等附属功能，从而节省出一个运维的人力
  6. 降本配套设施
    1. 需要明确算力衡量指标体系，前期可以粗略使用 CPU 利用率等系统指标，后期需要借助精准的业务指标，比如 QPS 及单请求的耗时结合的复合指标。
    2. 降本过程需要有较完备的监控告警系统及容灾 SOP，防止在优化过程中出现意外情况。比如在优化低频冗余算力环节，小王在下机器的时候，提前根据 CPU 等指标设置好了扩缩容策略，在系统保持一周无异常后才将下线的机器清退。
    3. 为了精准量度业务算力，需要搭配压测系统及方案。前期为尽量减少业务投入成本，主要是基于以下思路来操作：测试环境 ->线上日志回放 ->mock 调用接口 ->采集算力衡量指标 ->逐步放大调用压力 ->响应超时的服务器达到一定比例时结束压测。后期可以逐步迭代为全链路压测，从网关到调用链路到存储全隔离的形态，衡量效果会更精准，当然相应研发成本和投入也会更重。
    4. 为了充分体现每一步的优化成果，需要有成本看板，对每一阶段优化前后的机器资源和成本消耗进行环比或横比展示。成本看板主要针对中高层人群，所以信息要简明扼要，成本信息突出。
  7. 降本遇到的非技术问题
    1. 由于改造的投入成本和机会成本都很高，所以要求改造带来的收益要足够大。降本工作的推进也会影响稳定性保障、业务研发等工作，所以降本工作需要先成为公司的重点项目或者产研团队的 KPI。在推动层级方面，公司成本优化总体来说是一把手工程，过程中难免需要各部门的协同配合及利益分摊，所以由 CTO 发起并提供支持是小王完成成本优化目标的重要前提。
    2. 公司确定降本工作是重点项目后，还需要在公司层面或者产研层面进行正式立项，指定项目负责人、项目技术负责人等，并明确项目的目标，以及项目人员的沟通。原则上所有受降本影响的部门都要派出自己的代表，实际可以确保所有的职能都派出代表，这样既能控制项目组规模又有足够的代表性。比较好的项目组核心人员组合是，由收益最大或工作量最大的部门作为项目的负责方并派出项目负责人，受影响最大的部门派出技术负责人。
    3. 云化、弹性等都会带来新的预算管理和成本核算方式，需推动公司内部成本管理机制升级。在项目早期，就要对降本项目的优化效果进行量化。只有明确的、量化的目标和明显的收益，方能为各个部门提供足够动力配合推进。
    4. 试点业务要适中，过小的业务没有代表性，而如果业务过大，一旦出现问题，后果会很严重。在试点业务成功实践之后，再推动到公司的核心业务。核心业务有足够的代表性和说服力，只有在核心业务落地才可能在全公司全面落地。这也需要项目组与核心业务密切配合，核心业务的负责人或代表最好就是项目负责人或者技术负责人。有了试点效果后高层更乐于协助推进。
    5. 针对项目收益分配，比较好的做法是把各种收益进行拆分，然后再依据分别的贡献进行分配。比如项目整体荣誉归项目组、项目管理的收益归项目负责人及其所在部门、项目技术上的收益归技术负责人及其所在部门、各模块的收益归模块负责人及其部门。在晋升时也需要项目负责人协调好各自的边界，避免相互冲突的情况。项目负责人及其所在部门要把更多的利益分给项目组中其他的部门，从而更好地激励大家积极参与之后的其他改造与建设项目。
    6. 在优化节奏方面，建议先从成本占比、优化难度、优化效果、是否核心等维度对业务进行排序打分，先从成本占比大，优化难度小，优化效果明显、非核心的业务开始优化。

成本最高降低70%，腾讯大规模业务集群的云原生成本优化实践！ 不错的文章，系统的梳理的降本增效。

如何治理资源浪费？百度云原生成本优化最佳实践浪费的根因主要是由于业务申请的资源过大，实际使用的资源过小，整体利用率不高，并且业务自身存在波峰波谷且申请时一般会按照波峰申请。同时，如果企业有在线业务也有离线业务的话，会存在在离线分池，技术栈不统一、资源池不统一的问题。成本优化主要手段涉及资源优化和应用优化两个层面：

  1. 资源优化：包年包月 ==> 弹性/竞价/潮汐实例 ==> Serverless Pod
  2. 应用（利用率）优化：资源画像；应用利用率预估==> 应用配额推荐；节点利用率预估（在线超卖）；在离线混部

成本优化核心技术

  1. 在线超卖，在线资源通常存在分配率高但使用率低的现象，主要原因是业务规格申请过大，此外还存在核存比例不平均以及节点规格过小、碎片很多的问题。超卖有两个方向：一是节点级别的超卖，二是应用规格的智能调整。二者手段虽不同，但总体逻辑就是用最少的节点去承载更多的业务。对于资源超卖的质量保障主要通过精细调度(负载感知调度)、可迁移性分级、热点治理以及单机驱逐等手段完成。
  2. 在离线混部
  3. 质量保障，资源利用率提升之后，如何保证质量？如前文所述，主要通过如下手段：
    1. 节点热点：一般 CPU 超过80%或内存使用超过80%我们叫做热点
    2. 精细调度：通过资源画像精细调度避免热点产生
    3. 热点调度(热点治理)：产生热点后根据业务迁移等级和打分进行有序迁移

通常情况况下，Pod压缩与Node超卖两种手段需同时使用。Pod压缩已实现从静态到动态的优化，其压缩比（Request/limit）可以根据历史状态进行动态修改。同样，Node超卖也实现了由静态向动态的升级，Node节点可以根据实时负载进行动态调整，以防止节点负载过高。当Node负载不均或Node利用率过高时，大概率会对节点上运行的Pod资源产生影响。这种情况下，我们可以根据节点当前的状态信息以及节点上Pod的实际利用率对Pod进行动态驱逐。这里的参考维度是多样的，一般包括：CPU、Memory、FD、Inode等，且不同业务针对参数的权重与指标也存在差异。

排查问题文章汇总

kubernetes 问题排查: 磁盘 IO 过高导致 Pod 创建超时 kubernetes 平台开发者的几个小技巧 内存回收导致关键业务抖动案例分析-论云原生OS内存QoS保障 去哪儿容器化落地过程踩过的那些坑Qunar 在做容器化过程中，各个系统 portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造

  1. portal：Qunar 的 PAAS 平台入口，提供CI CD 能力、资源管理、自助运维、应用画像、应用授权(db授权、支付授权、应用间授权)等功能
  2. 运维工具：提供应用的可观测性工具, 包括 watcher（监控和报警）、bistoury （java 应用在线 debug）、qtrace （tracing 系统）, loki/elk （提供实时日志/离线日志查看）
  3. 中间件：应用用到的所有中间件, mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk等
  4. 虚拟化集群：底层的 k8s 和 openstack 集群，多k8s集群管理工具 kubesphere
  5. noah：测试环境管理平台，支持应用 kvm / 容器混合部署

留下评论

猜您还喜欢

Code Agent

1 分钟阅读

简介（未完成）