Serverless服务日记收集,你们采用哪种方案?

原创 吴就业 152 0 2024-02-16

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/41e83629c035471283b33e4c6a59a522

作者:吴就业
链接:https://wujiuye.com/article/41e83629c035471283b33e4c6a59a522
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

此为文章配套视频,如阅读本篇文章有不理解的地方,可观看此讲解视频!

看了很多大佬的观点,关于应用容器化部署之后,日记如何收集的问题,也就三个方案:

Serverless帮助我们实现了自动扩缩容,但要实现真正的按需付费,就要使用弹性的物理节点,例如AWS的Fargate,使用EKS将Pod调度到Fargate上。这也注定了不会有固定的Node去运行Pod,因此在Node上以DaemonSet部署日记收集容器的方案就走不通了。

DaemonSet收集日记

只剩两种方案:

方案一是通过SideCar容器使用FileBeat或其它工具收集日记,SideCar容器和主容器使用相同的PV(共享Volume),主容器日记落盘到PV,SideCar容器从PV读日记。

SideCar收集日记

这种方式的缺点是,需要为每个Pod加一个SideCar容器,占用资源多。但这种方式也比较灵活,不需要业务去配置改动升级,而且日记收集一般是中间件团队维护,收集工具的bug修复和性能优化迭代的发布,都能通过k8s提供的Pod容器原地升级的能力去更新。

这种方式相比DaemonSet,还实现了物理上的隔离,多个Pod之间互不影响,不需要应用服务指定不同的日记输出路径,架构上会比DaemonSet更“多租户”。

不过使用SideCar模式需要开发管理的能力,怎么注入SideCar,以及SideCar容器的原地升级的实现。

方案二的实现就是将日记通过网络传输打到远端代理服务上。优点是架构简单,不会占用过多资源。但缺点是,需要代码层面改动配置,需要引入sdk,另外就是会占用出口带宽,日记丢失的风险大。

通过网络传输打到远端代理服务上

例如腾讯云的日记服务也提供tencentcloud-cls-log4j-appender SDK实现日记不落盘直接网络传输。当然我们也可以自己实现Appender,然后通过kafka将日记发送到kafka服务,再由一个消费者去消费转存。另外我们也可以自研,将日记打到一个日记收集服务再转存。

自研日记收集服务

为什么需要中转一下?因为如果我们ES去存储日记的话,流量直接打到ES,ES会扛不住。通过kafka去消费也可以起动削峰填谷的作用。

#云原生

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

k8s 自定义调度器禁用了某个评分插件,对默认调度器是否有影响?

不会影响到默认调度器,只会影响到scheduler-plugins调度器本身。默认调度器不会因为自定义调度器的配置而改变。

版本回滚是否应该把配置也一起回滚?

最近跟同事们争论的一个问题:一个应用发布平台,版本回滚是否应该支持把配置一同回滚?针对这个事情的讨论,我们分成了两派,一边是赞成派,一边反对派。

我开源了一款k8s命令行工具,提供命令输入提示和自动补全功能

kubectlx是一款基于go-prompt库开发的k8s命令行工具,目的是简化kubectl工具的一些常用命令的使用, 并提供命令输入提示、自动补全。

为什么java不适合云原生

云原生的优势在于利用Serverless技术优化基础设施成本,要求应用启动速度快且内存占用低。然而,Java应用在自动弹性扩缩容和内存消耗方面存在问题。文章以部署个人项目的视角,通过比较小明使用Go语言和小聪使用Java语言开发的博客系统的部署情况,展示了Java的启动速度慢和内存占用大的不适应性。

极致成本优化背景下,如何通过优化k8s调度器实现计算资源的按需付费(四)

验证gce的自动缩容时机以及扩容需要的时长:扩容一个节点需要等待多长时间,一个节点在没有Pod的情况下多久后会回收。结合scheduler-plugins框架验证。由于scheduler-plugins只是在Score阶段对节点打分,并未在其它阶段阻止Pod调度到分数为0的Node上,例如基于目标负载感知调度,当所有Node的负载都达到目标负载后,即便节点的requests满足Pod所需,是否能走扩容节点,而不是硬塞到现有节点上。

极致成本优化背景下,如何通过优化k8s调度器实现计算资源的按需付费(三)

本篇介绍的内容是scheduler-plugins框架的TargetLoadPacking插件,这是一个k8s调度框架的评分插件。TargetLoadPacking即目标负载调度器,用于控制节点的CPU利用率不超过目标值x%(例如65%),通过打分让所有cpu利用率超过x%的都不被选中。目标负载调度器只支持CPU。