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

　　前言

　　上一期主要介绍了Kubernetes日志输出的一些注意事项. 日志输出的最终目标是进行统一的采集和分析. 在Kubernetes中，日志采集方法与普通虚拟机有很大不同，并且相对实现难度和部署成本略高. 但是，如果使用得当，它将比传统方法自动化程度更高，并且操作和维护成本更低.

　　Kubernetes日志采集中的困难

　　在Kubernetes中，日志采集比传统的虚拟机和物理机复杂得多. 最根本的原因是Kubernetes屏蔽了潜在的异常情况，提供了更细粒度的资源调度，并向上提供了稳定而动态的环境. 因此，日志采集面临着更丰富，更动态的环境，还有更多需要考虑的地方.

　　例如:

　　对于运行时间较短的Job应用程序，从开始到停止只需要几秒钟. 如何确保实时日志采集能够跟上并且数据不会丢失？ K8s通常建议使用大型节点. 每个节点可以运行10-100个以上的容器. 如何采集资源消耗最少的100多个容器？在K8中，应用程序以yaml模式部署，但是日志采集仍主要以手动配置文件的形式. 如何在K8s中部署日志采集？

　　Kubernetes传统日志类型文件，stdout，主机文件，日志文件，日志日志源业务容器，系统组件，主机业务，主机采集方法代理（Sidecar，DaemonSet），直接编写（DockerEngine，业务）代理，直接编写独立应用程序编号10-1001-10应用程序动态高低节点动态高低级采集部署模式手册，Yaml手册，自定义

　　采集方法: 主动或被动

　　日志采集方法分为被动采集和主动推送. 在K8中，被动采集通常分为两种方法，Sidecar和DaemonSet. 主动推送有两种方法: DockerEngine推送和业务直接写入.

　　总结一下: 通常不建议使用DockerEngine直接编写；建议在具有大量日志的场景中使用业务直接写入； DaemonSet通常用于中小型集群. 建议将Sidecar用于大型群集. 各种采集方法的详细比较如下:

　　DockerEngine业务直接写DaemonSet方法Sidecar方法来采集*敏*感*词*志进行grep高，可以根据业务特征定制高，可定制查询，统计量高，根据业务特征定制，低自定义，自由扩展，高度耦合以及与DockerEngine的强大绑定. 修改需要重新启动DockerEngine. 模块修改/升级需要重新发布. 业务低迷. 代理可以独立升级. 默认情况下，升级收购代理后，sidecar服务将重新启动. 高场景日志分类清晰，单功能集群大，混合，PAAS类型集群

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

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

　　尽管Docker正式建议使用Stdout打印日志，但您需要注意的是，此建议是基于仅将容器用作简单应用程序的情况. 在实际的业务场景中，我们仍然建议您尽可能多地使用文件. 主要原因是以下几点:

　　标准输出性能问题，从应用程序输出标准输出到服务器，中间会有多个进程（例如常用的JSON LogDriver）: 应用程序标准输出-> DockerEngine-> LogDriver->序列化为JSON->保存到文件->代理采集文件->解析JSON->上传服务器. 整个过程比文件具有更多的额外开销. 在压力测试期间，每秒100,000行日志输出将占用额外的DockerEngine 1 CPU内核. 标准输出不支持分类，也就是说，所有输出混合在一个流中，并且不能像文件一样分类. 通常，有AccessLog，ErrorLog，InterfaceLog（调用外部接口的日志），TraceLog等，并且这些日志的格式和用途不同. 如果混合在同一流中，将很难采集和分析. Stdout仅支持容器主程序的输出. 如果程序在守护程序/分支模式下运行，则无法使用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. 上的日志采集程序的主要功能是:

　　支持实时采集各种数据，包括容器文件，容器Stdout，主机文件，日志，事件等；支持多种采集和部署方法，包括DaemonSet，Sidecar，DockerEngine LogDriver等；支持丰富的日志数据，包括附加的命名空间，Pod，容器，图像，节点和其他信息；稳定且高度可靠，基于Ali自行开发的Logtail采集代理实现，目前整个网络中有数百万个部署实例. 基于CRD扩展，您可以使用Kubernetes通过部署和发布来部署日志采集规则，该规则与CICD完美集成.

　　安装日志采集组件

　　当前，该采集程序向公众开放. 我们提供了一个Helm安装包，其中包括Logtail的DaemonSet，AliyunlogConfig的CRD语句和CRD控制器. 安装后，您可以直接使用DaemonS云采集器和CRD配置. . 安装方法如下:

　　阿里云Kubernetes集群在激活后可以进行检查和安装，因此在创建集群时将自动安装上述组件. 如果激活时未安装，则可以手动安装. 如果是自建的Kubernetes，无论是在阿里云，其他云还是离线环境下自建，您都可以使用此采集方案. 有关特定的安装方法，请参阅[自建Kubernetes安装]（）.

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

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

　　除了在Log Service控制台上进行手动配置外，Kubernetes还支持两种其他配置方法: 环境变量和CRD.

　　环境变量是自集群时代以来一直使用的一种配置方法. 您只需要在要采集的容器环境变量上声明要采集的数据地址，Logtail就会自动将这些数据采集到服务器. 该方法易于部署，学习成本低，易于学习. 但是可以支持的配置规则很少，并且不支持许多高级配置（例如，解析方法，过滤方法，黑白名单等），并且不支持此声明方法Modify / delete，每次修改实际上创建了一个新的集合配置. 历史采集配置需要手工清理，否则会造成资源浪费.

　　CRD配置方法与Kubernetes正式推荐的标准扩展方法非常一致. 采集配置以K8s资源的形式进行管理. 通过将特殊的CRD资源AliyunLogConfig部署到Kubernetes，可以声明需要采集的数据. 例如，以下示例将部署容器标准输出的集合，其中定义要求同时采集Stdout和Stderr，并且收录COLLEXT_STDOUT_FLAG的容器: 环境变量中的false被排除.

　　基于CRD的配置方法以Kubernetes标准资源扩展的方式进行管理，支持配置添加，删除，修改和查询的完整语义，并支持各种高级配置. 这是我们极力推荐的集合配置方法.

　　推荐的采集规则配置方法

　　在实际应用场景中，通常使用DaemonSet或DaemonSet和Sidecar的混合. DaemonSet的优点是资源利用率高，但是存在一个问题，DaemonSet的所有Logtail都共享全局配置，并且单个Logtail具有配置支持，因此，它不能支持具有大量应用程序的集群.

　　以上是我们推荐的配置方法. 核心思想是:

　　一种配置采集尽可能多的相同类型的数据，减少配置数量，并减轻DaemonSet的压力；必须为核心应用程序集合提供足够的资源，并且可以使用Sidecar方法；配置方法尽可能使用CRD方法； Sidecar是因为每个Logtail都是单独的配置，所以对配置数量没有限制，这更适合于非常大的集群.

　　实践1-中小型集群

　　大多数Kubernetes集群都是中小型的. 对于中小型企业，没有明确的定义. 通常，应用程序数量小于500，节点大小小于1,000. 没有明确的Kubernetes平台操作和维护. 在这种情况下，应用程序的数量不会特别大，DaemonSet可以支持所有集合配置:

　　大多数业务应用程序的数据都是使用DaemonS 优采云采集器方法采集的. 使用Sidecar方法分别采集核心应用程序（用于满足采集可靠性要求，例如订单/交易系统）

　　练习2个大型集群

　　对于用作PAAS平台的某些大型/超大型集群，一般业务在1000以上，节点规模也在1000以上，并且有专门的Kubernetes平台运维人员. 在这种情况下，应用程序数量没有限制，DaemonSet无法支持它，因此必须使用Sidecar. 总体规划如下:

　　Kubernetes平台本身的系统组件日志和内核日志的类型相对固定. 日志的这一部分使用DaemonS云采集器，该采集器主要为平台的运维人员提供服务； Sidecar采集每个企业的日志，并且每个企业Sidecar的采集目标地址可以独立设置，为企业的DevOps人员提供足够的灵活性.

　　原创链接

　　更多行业云案例，请关注[阿里云运企编号]