2023腾讯云容器和函数计算技术实践精选集

目录 前言2 云监控Barad的云原生实践3 Crane-Scheduler:真实工作负载感知的调度器设计与实现12 FinOps时代如何玩转应用资源配置22 腾讯云Serverless函数跑在K8s上，突破企业服务新格局33 【精彩回顾】ServerlessDays演讲资料大公开！43 浅谈K8sPodIP分配机制50 云原生场景下，如何缓减容器隔离漏洞，监控内核关键路径？63 StableDiffusion腾讯云云原生容器部署实践70 无处不在的离线算力-Crane基于VirtualKubelet的实践88 Kins（K3sinSuperEdge）海量K3s集群秒级部署92 大规模集群仿真模拟与调度器压测方法99 TKE注册节点，IDC轻量云原生上云的最佳路径106 将云原生进行到底：腾讯百万级别容器云平台实践揭秘114 腾讯全面上云之后的首次春保：这里的夜晚静悄悄120 深度复盘-重启etcd引发的异常124 Serverless&游戏案例139 新零售标杆案例：沃尔玛山姆会员店采用腾讯云Serverless的应用实践144 某在线教育企业采用腾讯云Serverless在【全景录制】场景中的落地实践150 降本超30%，智聆口语通过TKE注册节点实现IDCGPU节点降本增效实践155 降本40%，数数科技大数据查询引擎云原生实践169 有赞在使用腾讯云SCFServerless&自研云案例构建有赞云的落地实践178 喜报！腾讯云原生ServerlessSCFonK8s获信通院技术创新领航者奖181 结语188 前言 容器（Container）作为当前智能应用的引擎，以其轻便性、可移植性和可扩展性等优点，正在改变着应用程序的开发、部署和运维方式，越来越多的开发者在享受着容器带来的便利，提升应用的部署效率，降低应用开发的成本，提高业务敏捷性和弹性。而作为无服务器架构的函数计算（Serverless），则进一步让开发者专注于业务逻辑，无需关心底层基础设施的管理，也帮助企业快速部署、扩展和管理应用程序，推动数字化转型。据Gartner预测，到2025年，全球预计有超过75%的企业将在生产环境中使用容器化应用。 在过去3年中，腾讯完成了自有业务的全面上云，并坚定采用了云原生架构，包括QQ、微信、王者荣耀、腾讯视频、腾讯广告、腾讯文档、腾讯会议等自有业务，和腾讯云百万级外部客户一样基于公有云的模式来开发运营。腾讯自研业务产品云上的资源规模已突破5000万核， 3年累计节省成本超30亿元，成为国内最大规模的云原生实践。 现在腾讯云为用户提供基于原生Kubernetes，以容器为核心的、高度可扩展的高性能容器管理服务（TencentKubernetesEngine,TKE），覆盖了Serverless、边缘计算、分布式云等多种业务部署场景，业内首创单个集群兼容多种计算节点的容器资源管理模式，为游戏、教育、企业SaaS、零售等行业的业务上线、运维等提供支撑保障。 随着云原生技术的不断演进，其创造的价值正在从技术价值，走向业务价值，在这一背景下，FinOps作为一种云成本管理与优化解决方案脱颖而出，它强烈倡导业务团队与研发团队之间的紧密沟通与协作，旨在助力组织实现云成本的精细化管理与最优化利用。如此一来，组织便能更有效地控制成本，同时提升资源利用率，从而充分释放云计算的潜力，推动业务持续稳健增长。腾讯云作为云原生Finops领先布道者，主导开源项目Crane，全面助力客户实现资源优化、成本控制。 在2023年，从行业看，越来越多的行业、技术场景采用了容器和函数计算产品，也为了让用户更好的看到腾讯云在容器和函数计算方面的最佳实践，腾讯云特别推出了《容器和函数计算技术实践精选集》，在2023年众多优质刊文中，精心选择了一批代表性技术实践，一起看看在面对不同的技术难题时，腾讯云是如何解决的。同时也带来了云原生FinOps如何落地的重磅好文，期待能吸引更多的开发者和企业能够用好云，实现让用云更简单、更有效。 云监控Barad的云原生实践 赵腾轩讯，云高监级控运的维Ba工ra程d师产品,腾，讯为云云监产控品业提务供运高维效负、责低人成。本的海量指标监控服务。B全a量ra级d容业器务化经部过署云及原多生可能用力区建容设灾以能及力容。灾能力建设，业务已经实现了自研上云 B在降a本ra增d效的业大务背景上下，云腾面讯云临云的监控难团点队继和续提挑升战云原生成熟度，提升系统承载能力和 降低单位成本，包括对Barad业务在容器化占比提升，跨az容灾能力建设，资源利用率优化这些方面，因Barad业务量级庞大，如何保障大量级数据的稳定处理以及单位成本的优化，这里都有着不小的挑战： 1.底层设备量级大，整体上云后并发，时延，稳定性保障 2.系统架构复杂，底层模块和旁路功能涉及40+，迁移这类能力时的稳定性保障 3.海量上报数据实时计算，准确性和实时性的保障 4.业务迁移场景时告警时效性和可触达性的保障 5.大数据处理相关模块迁移上云的性能稳定性保障 6.接入业务多，适配场景众多，控制台使用稳定性保障 7.监控数据存储量级大，存储迁移的查询稳定性保障 整体架构： 关针对键这些优难化点我动们进作行和了如效下优果化操作，包括: 1.基础业务迁移TKE容器化部署2.TKE+TKEServerless弹性调度能力提升3.flink集群容器化建设 4.ctsdb双写并开启压缩能力 这里将Barad的业务调优动作对大家做以介绍，以便于大家针对自身业务特点进行相应的云原生渗透力提升以及容灾能力建设。 B业a务r容a器d化接拓入扑上结构报：模块TKE容器化部署: Barad业务的上报模块之前使用织云平台进行经典模式部署，该模式没有弹性调度能力以及资源容灾特性，根据业务现状，我们对上报服务进行TKE容器化部署，以解决集群弹性调度能力和多可用区容灾建设。 在使用TKE部署中业务同学需要保障在迁移过程中的数据稳定上报，因为Barad作为腾讯云基础监控业务，任何的改动都可能造成用户的监控数据丢失或断点，针对这个情况，Barad在部署业务时多次进行小地域验证，保障数据切换的平稳过渡。 上云过程中，Barad业务也遇到了很多瓶颈，在使用TKE集群时的并发能力保障上，这里针对集群机型，进行了特定的并发能力配置保障，在业务上报clb这里一并进行了带宽上限保障，以保证客户数据万无一失。 TKE弹性调度能力部署 目前针对Barad业务稳定性提升，我们对部分用量伴随时间变化的服务开启和HPA弹性调度能力，在业务CPU用量占limit80%时或并发数超过90万时进行多维度多条件弹性扩充Pod数量，保障业务运行中的量级突增，提升业务的可用性和稳定性。 TKE跨az容灾能力建设 Barad业务进行了多可用区资源置换操作，对TKE集群进行多可用区优化，实现了Barad业务的各地域TKE集群跨az容灾能力建设最终Barad上报由经典部署模式迁移至TKE集群部署，提升集群弹性扩充能力和负载上限，并具备了跨可用区调度能力。 TKE集群优化效果 优化缩容必须确保服务稳定和未来可能突然增长造成影响，为此，这边做了两个监控分别监控资源和指标。 资源可视化监控: 集群节点利用率可视化监控: TTKKEE容+器T化K后E除S了e上rv述e的rl优e点ss，弹也性带来调一度些能问题力:提升 ●每个集群自备CVM，无法共享资源，集群装箱率较低 ●预留资源应对业务突增扩缩容 ●跨az容灾人工运维成本较高 TKE+TKEServerless架构 基于上述问题，我们调研了弹性集群，具有高弹性、低成本、无需进行节点扩缩、按需使用，降低成本等优点。但是由于存量TKE集群迁移弹性集群工作量巨大，希望在TKE集群上直接获得上述能力。调研发现，TKE的超级节点可以满足我们的需求，解决上述问题。为验证超级节点的可靠性，我们在多个小地域做验证，调度及服务稳定都符合预期。另外跨az容灾能力，相比之前使用TKE集群自备CVM的场景降低了跨az建设初期的运维成本。 超级节点相当于一个资源池，只要创建的私有网络有IP，就可以自动调用跟Pod配置匹配的节点，再不用每个集群自备节点，达到资源复用的目的。不用每个集群预留CVM应对流量突增，降低成本。另外，可以使用多个可用区的私有网络达到自动调度到多个可用区节点，完成跨az容灾能力。 目前，我们已经开始了TKEServerless弹性调度能力提升的部署模式，该模式在保障业务数据上报及处理稳定性的前提下，对集群弹性能力有了很大的提升。 flink集群容器化建设及利用率提升 flink容器化 针对于流计算flink集群的云原生渗透力提升，我们在今年上半年开始了flink集群容器化建设，该操作目前已实现Barad小地域全覆盖这些地域的整体架构实现了100%容器化建设，提高了流计算集群的弹性能力， 量级在中小量级150cu(此数值为经验值，一般没有大型作业)以下的集群的隔离性能提升，无复用资源问题，小地域ec区可以降低整体配额60%，消除管控机型预留问题。 在容器化之前，集群采用EMR模式，每个集群由管控节点+worker节点组成，管控节点的构成分为ClusterAdmin，Common，NameNode，DataNode等节点构成。这些节点都是小机型(2U4G和4U8G)然而这些节点的数量和集群规模没有关系，每个集群至少都要这么些管控节点。（5个2U4G，6个4U8G） 而TKE集群的管控节点固定为3台（4U8G）。 以上是仅仅替换集群模式就可以节省22个CU。150CU下的集群数量有30个。则通过置换，可节省资源630CU。 ps:替换资源选择建议16CU的小核心机器。原因是每个节点固定会有两个CU被预留给TKE的管控信息通信。大于16CU可能就不灵活，而8CU的话CU实际工作的占比又太低。 flink资源利用率提升 节点替换，腾笼换鸟 TKE相对于EMR集群，其中一个特点是更强的隔离性，EMR集群下内存隔离性能保证，但是CPU隔离性较弱。同一个机器下的作业，可以调度到分配之外的CPU(只要没有被使 用的话)。这就会引入一个现象:EMR集群下性能弹性空间会更大，CPU利用率可以超过100%。 而实际集群使用中，由于历史遗留和资源不足原因，我们用一些CPU内存不是1:4标准配置的节点来搭建集群，比如16U32G。就会更容易出现这种现象，因为这个节点会被看成8U32G来提供资源，那这样就会有8U对用户是不可见，于是就被闲置了。直到哪个作业超用，才会被使用上。 通过资源合理性替换我们可以将一些机器替换成1:4的机型。这样无效的CU就释放出去，可以达到成本降低的效果，前提条件是CPU不能超用。毕竟有些作业现在已经是CPU利用率超100%运行着。 共用冗余，合理布局 在容器化和缩容/替换后，资源得到了充分利用，但是为了保证稳定性，针对我们Barad作业故障场景，我们还需要有一些临时备用的冗余空间额外拉起作业"补算"，如果缩的太厉害，可能补算作业无法运行。因此。对这种情况，各个地域缩容后的节点可以单独再起一个集群，平时低负载运行一些小型作业，需要补算时，会临时拿来进行离线补算。 此外，将大型作业，动辄300CU以上的作业，单独搭建集群运行。保证充分使用CPU，也不用担心被其他作业的运行影响（EMR的隔离现象） 计算型or内存型 在进行容器化改造和资源利用率提升操作时，我们发现影响稳定运行的，往往体现在某些资源不足。具体表现为内存或者CPU。我们发现有些作业容易OOM的，CPU可能还没有到100%，而有些作业CPU已经接近200%，内存还有大量空间。这两个作业对资源的依赖不同。 前者可以称之为内存依赖型，后者则是计算依赖型。 在TKE集群使用时，如果作业想要充分利用CPU效率，那么可以对粒度进行调整。 举例，原来如果作业并行度为10，默认情况下为1CU。那么转成TKE时，并行度为5，taskman