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

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

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

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

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

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

　　第3章：《解决K8s日志输出问题的九个技巧》

　　Kubernetes 日志 采集 难点

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

　　例如：

　　Kubernetes 传统方式

　　日志类型

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

　　档案、日记

　　日志来源

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

　　商务、主持人

　　采集方法

　　代理（Sidecar、DaemonSet）、直写（DockerEngine、业务）

　　代理，直接写作

　　单机应用数量

　　10-100

　　1-10

　　应用动态

　　高的

　　低的

　　节点动态

　　高的

　　低的

　　采集部署方式

　　手册，Yaml

　　手动、定制

　　采集方法：主动或被动

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

　　

　　总结一下：

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

　　DockerEngine 业务直接写入 DaemonSet 模式 Sidecar 模式

　　采集日志类型

　　标准输出

　　业务日志

　　标准输出+文件的一部分

　　文档

　　部署运维

　　低，本机支持

　　低，只需要维护好配置文件

　　一般需要维护DaemonSet

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

　　日志分类存储

　　达不到

　　业务独立配置

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

　　每个POD可单独配置，灵活性高

　　多租户隔离

　　虚弱的

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

　　一般只能通过配置室隔离

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

　　支持集群大小

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

　　无限

　　取决于配置的数量

　　无限

　　资源占用

　　低，码头工人

　　引擎提供

　　总体最低，节省 采集 开销

　　下层，每个节点运行一个容器

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

　　查询方便

　　低，只能grep原创日志

　　高，可根据业务特点定制

　　高，可自定义查询统计

　　高，可根据业务特点定制

　　可定制

　　低的

　　高，可自由扩展

　　低的

　　高，每个POD单独配置

　　耦合

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

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

　　低，Agent可独立升级

　　一般默认采集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系统集成。日志采集也是运维监控过程的重要组成部分，所有业务上线后的日志都要实时采集。

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

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

　　Kubernetes 日志采集 方案

　　

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

　　安装日志采集组件

　　目前，这个采集计划是对公众开放的。我们提供了一个 Helm 安装包，其中包括 Logtail 的 DaemonSet、AliyunlogConfig 的 CRD 语句和 CRD Controller。安装后可以直接使用DaemonSet采集和CRD配置NS。安装方法如下：

　　阿里云Kubernetes集群可以通过勾选激活时间来安装，这样在集群创建时会自动安装上述组件。如果激活时没有安装，可以手动安装；如果是自建Kubernetes，无论是在阿里云、其他云还是离线自建，也可以使用这个采集方案，具体安装方法参考自建Kubernetes安装。

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

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

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

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

　　

　　比如下面的例子是部署一个容器标准输出采集，其中定义要求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等技术领域，关注云原生流行技术趋势、云原生*敏*感*词*落地实践，是最了解云原生开发者的技术圈.”