系列文章:Kubernetes日志采集最佳实践

本文涉及的产品
对象存储 OSS,20GB 3个月
文件存储 NAS,50GB 3个月
对象存储OSS,敏感数据保护2.0 200GB 1年
简介: 在Kubernetes中,日志采集和普通虚拟机的方式有很大不同,相对实现难度和部署代价也略大,但若使用恰当则比传统方式自动化程度更高、运维代价更低。本期将为大家介绍如何正确的进行Kubernetes的日志采集。

前言

上一期主要介绍Kubernetes日志输出的一些注意事项,日志输出最终的目的还是做统一的采集和分析。在Kubernetes中,日志采集和普通虚拟机的方式有很大不同,相对实现难度和部署代价也略大,但若使用恰当则比传统方式自动化程度更高、运维代价更低。

Kubernetes日志采集难点

在Kubernetes中,日志采集相比传统虚拟机、物理机方式要复杂很多,最根本的原因是Kubernetes把底层异常屏蔽,提供更加细粒度的资源调度,向上提供稳定、动态的环境。因此日志采集面对的是更加丰富、动态的环境,需要考虑的点也更加的多。

例如:

  1. 对于运行时间很短的Job类应用,从启动到停止只有几秒的时间,如何保证日志采集的实时性能够跟上而且数据不丢?
  2. K8s一般推荐使用大规格节点,每个节点可以运行10-100+的容器,如何在资源消耗尽可能低的情况下采集100+的容器?
  3. 在K8s中,应用都以yaml的方式部署,而日志采集还是以手工的配置文件形式为主,如何能够让日志采集以K8s的方式进行部署?
Kubernetes 传统方式
日志种类 文件、stdout、宿主机文件、journal 文件、journal
日志源 业务容器、系统组件、宿主机 业务、宿主机
采集方式 Agent(Sidecar、DaemonSet)、直写(DockerEngine、业务) Agent、直写
单机应用数 10-100 1-10
应用动态性
节点动态性
采集部署方式 手动、Yaml 手动、自定义

采集方式:主动 or 被动

日志的采集方式分为被动采集和主动推送两种,在K8s中,被动采集一般分为Sidecar和DaemonSet两种方式,主动推送有DockerEngine推送和业务直写两种方式。

  • DockerEngine本身具有LogDriver功能,可通过配置不同的LogDriver将容器的stdout通过DockerEngine写入到远端存储,以此达到日志采集的目的。这种方式的可定制化、灵活性、资源隔离性都很低,一般不建议在生产环境中使用。
  • 业务直写是在应用中集成日志采集的SDK,通过SDK直接将日志发送到服务端。这种方式省去了落盘采集的逻辑,也不需要额外部署Agent,对于系统的资源消耗最低,但由于业务和日志SDK强绑定,整体灵活性很低,一般只有日志量极大的场景中使用。
  • DaemonSet方式在每个node节点上只运行一个日志agent,采集这个节点上所有的日志。DaemonSet相对资源占用要小很多,但扩展性、租户隔离性受限,比较适用于功能单一或业务不是很多的集群。
  • Sidecar方式为每个POD单独部署日志agent,这个agent只负责一个业务应用的日志采集。Sidecar相对资源占用较多,但灵活性以及多租户隔离性较强,建议大型的K8S集群或作为PAAS平台为多个业务方服务的集群使用该方式。

image.png

总结下来:DockerEngine直写一般不推荐;业务直写推荐在日志量极大的场景中使用;DaemonSet一般在中小型集群中使用;Sidecar推荐在超大型的集群中使用。详细的各种采集方式对比如下:

DockerEngine 业务直写 DaemonSet方式 Sidecar方式
采集日志类型 标准输出 业务日志 标准输出+部分文件 文件
部署运维 低,原生支持 低,只需维护好配置文件即可 一般,需维护DaemonSet 较高,每个需要采集日志的POD都需要部署sidecar容器
日志分类存储 无法实现 业务独立配置 一般,可通过容器/路径等映射 每个POD可单独配置,灵活性高
多租户隔离 弱,日志直写会和业务逻辑竞争资源 一般,只能通过配置间隔离 强,通过容器进行隔离,可单独分配资源
支持集群规模 本地存储无限制,若使用syslog、fluentd会有单点限制 无限制 取决于配置数 无限制
资源占用 低,docker
engine提供 整体最低,省去采集开销 较低,每个节点运行一个容器 较高,每个POD运行一个容器
查询便捷性 低,只能grep原始日志 高,可根据业务特点进行定制 较高,可进行自定义的查询、统计 高,可根据业务特点进行定制
可定制性 高,可自由扩展 高,每个POD单独配置
耦合度 高,与DockerEngine强绑定,修改需要重启DockerEngine 高,采集模块修改/升级需要重新发布业务 低,Agent可独立升级 一般,默认采集Agent升级对应Sidecar业务也会重启(有一些扩展包可以支持Sidecar热升级)
适用场景 测试、POC等非生产场景 对性能要求极高的场景 日志分类明确、功能较单一的集群 大型、混合型、PAAS型集群


日志输出:Stdout or 文件

和虚拟机/物理机不同,K8s的容器提供标准输出和文件两种方式。在容器中,标准输出将日志直接输出到stdout或stderr,而DockerEngine接管stdout和stderr文件描述符,将日志接收后按照DockerEngine配置的LogDriver规则进行处理;日志打印到文件的方式和虚拟机/物理机基本类似,只是日志可以使用不同的存储方式,例如默认存储、EmptyDir、HostVolume、NFS等。

虽然使用Stdout打印日志是Docker官方推荐的方式,但大家需要注意这个推荐是基于容器只作为简单应用的场景,实际的业务场景中我们还是建议大家尽可能使用文件的方式,主要的原因有以下几点:

  1. Stdout性能问题,从应用输出stdout到服务端,中间会经过好几个流程(例如普遍使用的JSON LogDriver):应用stdout -> DockerEngine -> LogDriver -> 序列化成JSON -> 保存到文件 -> Agent采集文件 -> 解析JSON -> 上传服务端。整个流程相比文件的额外开销要多很多,在压测时,每秒10万行日志输出就会额外占用DockerEngine 1个CPU核。
  2. Stdout不支持分类,即所有的输出都混在一个流中,无法像文件一样分类输出,通常一个应用中有AccessLog、ErrorLog、InterfaceLog(调用外部接口的日志)、TraceLog等,而这些日志的格式、用途不一,如果混在同一个流中将很难采集和分析。
  3. Stdout只支持容器的主程序输出,如果是daemon/fork方式运行的程序将无法使用stdout。
  4. 文件的Dump方式支持各种策略,例如同步/异步写入、缓存大小、文件轮转策略、压缩策略、清除策略等,相对更加灵活。

因此我们建议线上应用使用文件的方式输出日志,Stdout只在功能单一的应用或一些K8s系统/运维组件中使用。

CICD集成:Logging Operator

image.png
Kubernetes提供了标准化的业务部署方式,可以通过yaml(K8s API)来声明路由规则、暴露服务、挂载存储、运行业务、定义缩扩容规则等,所以Kubernetes很容易和CICD系统集成。而日志采集也是运维监控过程中的重要部分,业务上线后的所有日志都要进行实时的收集。

原始的方式是在发布之后手动去部署日志采集的逻辑,这种方式需要手工干预,违背CICD自动化的宗旨;为了实现自动化,有人开始基于日志采集的API/SDK包装一个自动部署的服务,在发布后通过CICD的webhook触发调用,但这种方式的开发代价很高。

在Kubernetes中,日志最标准的集成方式是以一个新资源注册到Kubernetes系统中,以Operator(CRD)的方式来进行管理和维护。在这种方式下,CICD系统不需要额外的开发,只需在部署到Kubernetes系统时附加上日志相关的配置即可实现。

Kubernetes日志采集方案

image.png
早在Kubernetes出现之前,我们就开始为容器环境开发日志采集方案,随着K8s的逐渐稳定,我们开始将很多业务迁移到K8s平台上,因此也基于之前的基础专门开发了一套K8s上的日志采集方案。主要具备的功能有:

  1. 支持各类数据的实时采集,包括容器文件、容器Stdout、宿主机文件、Journal、Event等;
  2. 支持多种采集部署方式,包括DaemonSet、Sidecar、DockerEngine LogDriver等;
  3. 支持对日志数据进行富化,包括附加Namespace、Pod、Container、Image、Node等信息;
  4. 稳定、高可靠,基于阿里自研的Logtail采集Agent实现,目前全网已有几百万的部署实例;
  5. 基于CRD进行扩展,可使用Kubernetes部署发布的方式来部署日志采集规则,与CICD完美集成。

安装日志采集组件

目前这套采集方案已经对外开放,我们提供了一个Helm安装包,其中包括Logtail的DaemonSet、AliyunlogConfig的CRD声明以及CRD Controller,安装之后就能直接使用DaemonSet采集以及CRD配置了。安装方式如下:

  1. 阿里云Kubernetes集群在开通的时候可以勾选安装,这样在集群创建的时候会自动安装上述组件。如果开通的时候没有安装,则可以手动安装
  2. 如果是自建的Kubernetes,无论是在阿里云上自建还是在其他云或者是线下,也可以使用这样采集方案,具体安装方式参考[自建Kubernetes安装]()。

安装好上述组件之后,Logtail和对应的Controller就会运行在集群中,但默认这些组件并不会采集任何日志,需要配置日志采集规则来采集指定Pod的各类日志。

采集规则配置:环境变量 or CRD

除了在日志服务控制台上手动配置之外,对于Kubernetes还额外支持两种配置方式:环境变量和CRD。

环境变量是自swarm时代一直使用的配置方式,只需要在想要采集的容器环境变量上声明需要采集的数据地址即可,Logtail会自动将这些数据采集到服务端。这种方式部署简单,学习成本低,很容易上手;但能够支持的配置规则很少,很多高级配置(例如解析方式、过滤方式、黑白名单等)都不支持,而且这种声明的方式不支持修改/删除,每次修改其实都是创建1个新的采集配置,历史的采集配置需要手动清理,否则会造成资源浪费。
image.png
CRD配置方式是非常符合Kubernetes官方推荐的标准扩展方式,让采集配置以K8s资源的方式进行管理,通过向Kubernetes部署AliyunLogConfig这个特殊的CRD资源来声明需要采集的数据。例如下面的示例就是部署一个容器标准输出的采集,其中定义需要Stdout和Stderr都采集,并且排除环境变量中包含COLLEXT_STDOUT_FLAG:false的容器。
基于CRD的配置方式以Kubernetes标准扩展资源的方式进行管理,支持配置的增删改查完整语义,而且支持各种高级配置,是我们极其推荐的采集配置方式。
image.png

采集规则推荐的配置方式

image.png

实际应用场景中,一般都是使用DaemonSet或DaemonSet与Sidecar混用方式,DaemonSet的优势是资源利用率高,但有一个问题是DaemonSet的所有Logtail都共享全局配置,而单一的Logtail有配置支撑的上限,因此无法支撑应用数比较多的集群。
上述是我们给出的推荐配置方式,核心的思想是:

  1. 一个配置尽可能多的采集同类数据,减少配置数,降低DaemonSet压力;
  2. 核心的应用采集要给予充分的资源,可以使用Sidecar方式;
  3. 配置方式尽可能使用CRD方式;
  4. Sidecar由于每个Logtail是单独的配置,所以没有配置数的限制,这种比较适合于超大型的集群使用。

实践1-中小型集群

image.png
绝大部分Kubernetes集群都属于中小型的,对于中小型没有明确的定义,一般应用数在500以内,节点规模1000以内,没有职能明确的Kubernetes平台运维。这种场景应用数不会特别多,DaemonSet可以支撑所有的采集配置:

  1. 绝大部分业务应用的数据使用DaemonSet采集方式
  2. 核心应用(对于采集可靠性要求比较高,例如订单/交易系统)使用Sidecar方式单独采集

实践2-大型集群

image.png
对于一些用作PAAS平台的大型/超大型集群,一般业务在1000以上,节点规模也在1000以上,有专门的Kubernetes平台运维人员。这种场景下应用数没有限制,DaemonSet无法支持,因此必须使用Sidecar方式,整体规划如下:

  1. Kubernetes平台本身的系统组件日志、内核日志相对种类固定,这部分日志使用DaemonSet采集,主要为平台的运维人员提供服务;
  2. 各个业务的日志使用Sidecar方式采集,每个业务可以独立设置Sidecar的采集目的地址,为业务的DevOps人员提供足够的灵活性。                                                           
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
0
0
0
79058
分享
相关文章
日志采集效能跃迁:iLogtail 到 LoongCollector 的全面升级
LoongCollector 在日志场景中实现了全面的重磅升级,从功能、性能、稳定性等各个方面均进行了深度优化和提升,本文我们将对 LoongCollector 的升级进行详细介绍。
341 87
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文探讨了日志管理中的常见反模式及其潜在问题,强调科学的日志管理策略对系统可观测性的重要性。文中分析了6种反模式:copy truncate轮转导致的日志丢失或重复、NAS/OSS存储引发的采集不一致、多进程写入造成的日志混乱、创建文件空洞释放空间的风险、频繁覆盖写带来的数据完整性问题,以及使用vim编辑日志文件导致的重复采集。针对这些问题,文章提供了最佳实践建议,如使用create模式轮转日志、本地磁盘存储、单线程追加写入等方法,以降低日志采集风险,提升系统可靠性。最后总结指出,遵循这些实践可显著提高故障排查效率和系统性能。
298 20
警惕日志采集失败的 6 大经典雷区:从本地管理反模式到 LoongCollector 标准实践
本文总结了日志管理中的六大反模式及优化建议,涵盖日志轮转、存储选择、并发写入等常见问题,帮助提升日志采集的完整性与系统可观测性,适用于运维及开发人员优化日志管理策略。
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
本文介绍了阿里集团A+流量分析平台的日志查询优化方案,针对万亿级日志数据的写入与查询挑战,提出基于Flink、Paimon和StarRocks的技术架构。通过Paimon存储日志数据,结合StarRocks高效计算能力,实现秒级查询性能。具体包括分桶表设计、数据缓存优化及文件大小控制等措施,解决高并发、大数据量下的查询效率问题。最终,日志查询耗时从分钟级降至秒级,显著提升业务响应速度,并为未来更低存储成本、更高性能及更多业务场景覆盖奠定基础。
突破极限: 高负载场景下的单机300M多行正则日志采集不是梦
在当今数字化时代,日志数据已成为企业 IT 运营和业务分析的关键资源。然而,随着业务规模的扩大和系统复杂度的提升,日志数据的体量呈现爆发式增长,给日志采集和处理系统带来了巨大挑战。
414 99
WGLOG日志管理系统可以采集网络设备的日志吗
WGLOG日志审计系统提供开放接口,支持外部获取日志内容后发送至该接口,实现日志的存储与分析。详情请访问:https://www.wgstart.com/wglog/docs9.html
日志采集 Agent 性能大比拼——LoongCollector 性能深度测评
为了展现 LoongCollector 的卓越性能,本文通过纵向(LoongCollector 与 iLogtail 产品升级对比)和横向(LoongCollector 与其他开源日志采集 Agent 对比)两方面对比,深度测评不同采集 Agent 在常见的日志采集场景下的性能。
384 33
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
本文介绍如何利用阿里云的分布式云容器平台ACK One的多集群应用分发功能,结合云效CD能力,快速将单集群CD系统升级为多集群CD系统。通过增加分发策略(PropagationPolicy)和差异化策略(OverridePolicy),并修改单集群kubeconfig为舰队kubeconfig,可实现无损改造。该方案具备多地域多集群智能资源调度、重调度及故障迁移等能力,帮助用户提升业务效率与可靠性。
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
101 9
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
398 33

云存储

+关注

相关产品

  • 日志服务
  • 推荐镜像

    更多
    AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等

    登录插画

    登录以查看您的控制台资源

    管理云资源
    状态一览
    快捷访问