自动采集编写( 6个K8s日志系统建设中的典型问题，你遇到过几个？)

　　自动采集编写(

6个K8s日志系统建设中的典型问题，你遇到过几个？)

　　

　　作者 | 元一阿里云存储服务技术专家

　　简介：上一篇文章主要介绍了Kubernetes日志输出的一些注意事项。日志输出的最终目的是做统一的采集和分析。在Kubernetes中，记录采集的方式与普通虚拟机有很大不同，相对实现难度和部署成本也略高，但如果使用得当，自动化程度比传统方式高，运维成本更低。本文是日志系列文章的第四篇。

　　第一篇：《K8s日志系统建设中的6个典型问题，你遇到过几个？》

　　第二篇：《一篇文章理解K8s日志系统的设计与实践》

　　第三篇：《解决K8s中日志输出问题的9个技巧》

　　Kubernetes 日志采集 难点

　　在 Kubernetes 中，log采集 比传统的虚拟机和物理机要复杂得多。最根本的原因是Kubernetes屏蔽了底层异常，提供了更细粒度的资源调度，向上提供了一个稳定动态的环境。因此，日志采集面临着更丰富、更动态的环境，需要考虑的点也更多。

　　例如：

　　Kubernetes 传统方式

　　日志类型

　　文件、标准输出、主机文件、日志

　　档案、日记

　　日志源

　　业务容器、系统组件、主机

　　商务，主持人

　　采集如何

　　Agent (Sidecar, DaemonSet), Direct Write (DockerEngine, Business)

　　代理，直写

　　独立应用程序的数量

　　10-100

　　1-10

　　应用动态

　　高的

　　低的

　　节点动态

　　高的

　　低的

　　采集部署方式

　　手动，Yaml

　　手动, 定制

　　采集模式：主动或被动

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

　　

　　总结一下：

　　各种采集方法的详细对比如下：

　　DockerEngine 业务直写 DaemonSet 方法 Sidecar 方法

　　采集日志类型

　　标准输出

　　业务日志

　　标准输出 + 部分文件

　　文档

　　部署和维护

　　低原生支持

　　低，只维护配置文件

　　一般需要维护DaemonSet

　　更高，每个需要采集日志的POD都需要部署一个sidecar容器

　　日志分类存储

　　达不到

　　业务独立配置

　　一般可以通过容器/路径等方式进行映射。

　　每个 POD 都可以单独配置以实现高灵活性

　　多租户隔离

　　虚弱的

　　弱，日志直写会和业务逻辑竞争资源

　　一般只通过配置之间的隔离

　　强，通过容器隔离，资源可单独分配

　　支持集群大小

　　无限本地存储，如果使用syslog和fluentd，会有单点限制

　　无限

　　取决于配置的数量

　　无限

　　资源占用

　　低，码头工人

　　引擎提供

　　总体最低，节省 采集 开销

　　较低，每个节点运行一个容器

　　更高，每个 POD 运行一个容器

　　查询方便

　　低，只能grep原创日志

　　高，可根据业务特点定制

　　高，可进行自定义查询和统计

　　高，可根据业务特点定制

　　可定制性

　　低的

　　高，可自由扩展

　　低的

　　高，每个 POD 单独配置

　　耦合

　　高，强绑定DockerEngine，修改需要重启DockerEngine

　　高，采集模块修改/升级需要重新发布业务

　　低，代理可以独立升级

　　一般Sidecar服务对应的默认采集Agent升级也会重启（有一些扩展包可以支持Sidecar热升级）

　　适用场景

　　测试、POC等非生产场景

　　对性能要求极高的场景

　　日志分类清晰、功能单一的集群

　　大型混合 PAAS 集群

　　日志输出：标准输出或文件

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

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

　　因此，我们建议在线应用使用文件输出日志，而Stdout仅用于功能单一或部分K8s系统/运维组件的应用。

　　CICD 集成：日志记录操作员

　　

　　Kubernetes提供了标准化的业务部署方式，可以通过yaml（K8s API）声明路由规则、暴露服务、挂载存储、运行业务、定义伸缩规则等，因此Kubernetes很容易与CICD系统集成。日志采集也是运维监控过程的重要组成部分。必须实时采集业务上线后的所有日志。

　　原来的方法是在发布后手动部署log采集的逻辑。这种方式需要人工干预，违背了CICD自动化的目的；为了实现自动化，有人开始根据日志打包API/SDK采集发布后通过CICD的webhook调用自动部署的服务，但这种方式开发成本高。

　　在 Kubernetes 中，集成日志最标准的方式是在 Kubernetes 系统中注册一个新资源，并以 Operator（CRD）的形式对其进行管理和维护。这样CICD系统就不需要额外开发，部署到Kubernetes系统时只需要附加日志相关的配置即可。

　　Kubernetes 日志采集 方案

　　

　　早在 Kubernetes 出现之前，我们就开始为容器环境开发 log采集 解决方案。随着K8s的逐渐稳定，我们开始将很多业务迁移到K8s平台上，所以我们也在之前的基础上开发了一套。K8s 上的 log采集 方案。主要功能有：

　　安装日志采集组件

　　目前，这个采集解决方案已经对外开放。我们提供 Helm 安装包，收录 Logtail 的 DaemonSet、AliyunlogConfig 的 CRD 声明和 CRD Controller。安装后，可以直接使用 DaemonSet 采集 和 CRD 配置。安装方法如下：

　　当阿里云Kubernetes集群启动时，您可以选择安装它，这样在创建集群时会自动安装上述组件。如果打开的时候没有安装，可以手动安装；如果是自建Kubernetes，无论是在阿里云上自建还是在其他云还是离线，也可以使用这个采集方案，具体安装方法参考自建Kubernetes安装。

　　上述组件安装完成后，Logtail和对应的Controller就会在集群中运行，但是这些组件默认没有采集任何日志，需要将日志采集规则配置为采集@ > 指定各种日志的Pod。

　　采集规则配置：环境变量或CRD

　　除了在日志服务控制台上手动配置外，Kubernetes 还支持另外两种配置方式：环境变量和 CRD。

　　该方法部署简单，学习成本低，易于使用；但是可以支持的配置规则很少，很多高级配置（如解析方式、过滤方式、黑白名单等）都不支持，而且这种声明方式也不支持修改/删除，每个修改实际上创建了一个新的 采集 配置。历史采集配置需要手动清理，否则会造成资源浪费。

　　

　　比如下面的例子是部署一个容器的stdout采集，其中定义需要stdout和stderr采集，排除环境变量中收录COLLEXT_STDOUT_FLAG: false的容器。

　　基于CRD的配置方式以Kubernetes标准扩展资源的方式进行管理，支持配置的完整语义的增删改查，支持各种高级配置。这是我们强烈推荐的 采集 配置方法。

　　

　　采集推荐的规则配置方式

　　

　　在实际应用场景中，一般使用 DaemonSet 或者 DaemonSet 和 Sidecar 的混合。DaemonSet 的优点是资源利用率高，但存在一个问题，DaemonSet 的所有 Logtail 共享全局配置，而单个 Logtail 的配置支持有上限。因此，它无法支持具有大量应用程序的集群。

　　以上是我们给出的推荐配置方式。核心思想是：

　　练习 1 - 中小型集群

　　

　　大多数 Kubernetes 集群都是中小型的。中小企业没有明确的定义。一般应用数量小于500，节点规模小于1000。没有功能清晰的Kubernetes平台运维。这个场景的应用数量不是特别多，DaemonSet可以支持所有的采集配置：

　　练习 2 - 大型集群

　　

　　对于一些用作PaaS平台的大型/超大型集群，一般业务在1000以上，节点规模也在1000以上，并且有专门的Kubernetes平台运维人员。该场景对应用数量没有限制，DaemonSet无法支持，所以必须使用Sidecar方式。总体规划如下：

　　有一个阿里团队需要你！

　　云原生应用平台诚邀Kubernetes/容器/Serverless/应用交付技术领域的专家（P7-P8）加入。

　　简历投递：xining.zj AT。

　　

　　“阿里巴巴云原生专注于微服务、Serverless、容器、Service Mesh等技术领域，关注流行的云原生技术趋势，*敏*感*词*落地云原生实践，是懂云的技术圈——本地开发人员最好。”