背景
针对K8S日志采集存在的采集目标多、弹性伸缩难、运维成本大、侵入性高、采集性能低等问题，在18年2月份日志服务和容器服务团队一起发布了 阿里云 Kubernetes日志解决方案。1分钟内即可完成整个集群部署，实现该节点上宿主机日志、容器日志、容器stdout等所有数据源的一站式采集。并且后续集群动态伸缩无需对采集做任何二次部署。
今天阿里云Kubernetes日志解决方案再次升级，为您带来以下改进：
- 极致部署体验：只需一条命令一个参数即可完成整个K8S集群的日志解决方案部署。
- 支持更多配置方式：除原生控制台、SDK配置方式外，支持通过CRD方式进行配置（kubectl、控制台、K8S openapi）。
- K8S无缝集成：采集配置支持 yaml 方式部署，兼容K8S各种集成方式。
日志服务介绍
阿里云的日志服务（log service）是针对日志类数据的一站式服务，2013年研发，有5年多线上运行经验，经历双十一、新春红包等考验。日志采集Agent Logtail运行在100W+机器上，为万级别应用提供服务。主要特点如下：
日志服务主要包括 实时采集与消费、数据投递、查询与实时分析 等功能，接下来我们介绍下如何利用日志服务进行Kubernetes日志采集。
Kubernetes日志采集方案介绍
方案简介
阿里云Kubernetes日志采集方案如上图所示：
- K8S的每个worker 节点都会运行一个Logtail容器，该容器可采集宿主机以及该宿主机上其他容器的日志（包括标准输出和日志文件）。
- Logtail以daemon set模式运行，保证每个节点都有一个Logtail容器在运行
- 使用自定义标识机器组，支持集群动态缩/扩容
- 所有的采集配置支持通过docker lable以及环境变量过滤指定容器
- K8S内部会注册自定义资源（CRD，CustomResourceDefinition）AliyunLogConfig，并部署alibaba-log- Controller
- 支持用户通过CRD方式或日志服务控制台对采集配置进行管理
运行流程
以CRD配置方式为例，内部工作流程如下：
- 用户使用kubectl或其他工具应用aliyunlogconfigs CRD配置。
- alibaba-log-controller监听到配置更新。
- alibaba-log-controller根据CRD内容以及服务端状态，自动向日志服务提交logstore创建、配置创建以及应用机器组的请求。
- 以DaemonSet模式运行的Logtail会定期请求配置服务器，获取新的或已更新的配置并进行热加载。
- Logtail根据配置信息采集各个容器(POD)上的标准输出或日志文件。
- 最终Logtail将处理、聚合好的数据发送到日志服务。
部署方法
阿里云Kubernetes用户只需一条命令即可完成日志采集部署，命令中只需输入一个参数。
- 开通阿里云日志服务，日志服务开通链接。
- 登录您的阿里云容器服务Kubernetes的Master节点，如何登录参考SSH访问集群。
- 将下述命令中的${your_k8s_cluster_id}替换为您的Kubernetes集群id，执行此命令。
wget -O alicloud-log-k8s-install.sh; chmod 744 ./alicloud-log-k8s-install.sh; sh ./alicloud-log-k8s-install.sh ${your_k8s_cluster_id} - 非阿里云Kubernetes用户也支持，请参考Kubernetes日志采集
配置方式
日志采集配置默认支持控制台配置方式，同时针对Kubernetes微服务开发模式，我们还提供CRD的配置方式，您可以直接使用kubectl对配置进行管理或集成到其他编排服务。两种配置方式特点如下：
CRD方式控制台方式操作复杂度低一般功能项支持除控制台方式外的高级配置一般上手难度一般低网络连接连接Kubernetes集群连接互联网与组件/应用部署集成支持不支持 鉴权 方式Kubernetes鉴权云账号鉴权
如果您刚开始使用日志服务，建议使用控制台的配置方式，此种方式所见即所得，非常易于上手。
若后续您需要将日志采集与服务/组件发布集成，建议使用CRD的配置方式。可以直接将采集配置和服务配置放到同一个yaml文件部署和管理。
方案优势
相比其他采集方案，日志服务Kubernetes采集方案具备以下优势：
核心技术介绍
在上一篇阿里云Kubernetes日志解决方案中我们对容器数据采集、自定义标识机器组等技术做了相关的介绍。本次主要为大家带来日志采集配置与K8S无缝集成的技术实现。
K8S无缝集成
问题背景
不同于其他开源日志采集Agent，日志服务Logtail从设计之初就已经考虑到 配置管理 的难题。因此Logtail从第一个版本发布就支持中心化的配置管理。支持在日志服务控制台或者SDK远程对所有采集配置进行统一管理，大大降低了日志采集的管理负担。
但在K8S集群环境下，业务应用/服务/组件的持续集成和自动发布已经成为常态，使用控制台或SDK操作采集配置的方式很难与各类CI、编排框架集成，导致业务应用发布后用户只能通过控制台手动配置的方式部署与之对应的日志采集配置。
因此日志服务专门为K8S进行了扩展，用以支持原始的配置管理。
实现方式
如上图所示，日志服务为K8S新增了一个CustomResourceDefinition扩展，名为AliyunLogConfig。同时开发了alibaba-log-controller用于监听AliyunLogConfig事件。
当用户创建/删除/修改AliyunLogConfig资源时，alibaba-log-controller会监听到资源变化，并对应的在日志服务上创建/删除/修改相应的采集配置。以此实现K8S内部AliyunLogConfig与日志服务中采集配置的关联关系。
alibaba-log-controller内部实现
alibaba-log-controller主要由6个模块组成，各个模块的功能以及依赖关系如上图所示：
- EventListener：负责监听AliyunLogConfig的CRD资源。这个EventListener是广义上的listener，主要功能有初始化时会list所有的AliyunLogConfig资源注册AliyunLogConfig监听变化的事件定期再扫描全量的AliyunLogConfig资源防止事件出现遗漏或处理失效将事件打包，交由EventHandler处理
- EventHandler：负责处理对应的Create/Update/Delete事件，作为Controller的核心模块，主要功能如下：首先检查ConfigMapManager中对应的 checkpoint ，如该事件已经被处理（版本号相同且状态为200），则直接跳过为防止历史事件干扰处理结果，从服务端拉取最新的资源状态，检查是否为同一版本，若版本不一致，使用服务端版本替换对事件进行一定的预处理，使之符合LogSDK的基本格式需求调用LogSDKWrapper，创建日志服务Logstore，Create/Update/Delete对应的配置根据上述处理结果，更新对应AliyunLogConfig资源的状态
- ConfigMapManager：依赖于K8S的ConfigMap机制实现Controller的checkpoint管理，包括：维护checkpoint到ConfigMap的映射关系提供基础的checkpoint增删改查接口
- LogSDKWrapper：基于阿里云LOG golang sdk的二次封装，功能包括：初始化创建日志服务资源，包括Project、MachineGroup、Operation Logstore等将CRD资源转换为对应的日志服务资源操作，为1对多关系包装SDK接口，自动处理网络异常、服务器异常、权限异常负责权限管理，包括自动获取role，更新sts token等
- ScheduledSyner：后台的定期同步模块，防止进程/节点失效期间配置改动而遗漏事件，保证配置管理的最终一致性：定期刷新所有的checkpoint和AliyunLogConfig检查checkpoint和AliyunLogConfig资源的映射关系，如果checkpoint中出现不存在的配置，则删除对应的资源
- Monitor：alibaba-log-controller除了将本地运行日志输出到stdout外，还会将日志直接采集到日志服务，便于远程排查问题。采集日志种类如下：k8s api内部异常日志alibaba-log-controller运行日志alibaba-log-controller内部异常数据（自动聚合）
快速入门
总结
阿里云日志服务本次带来的提升更进一步简化了K8S日志采集的上手门槛以及集成体验。让广大用户真正体验到一个字：爽，从此日志运维人员的生活质量大大提高。
目前Logtail除支持宿主机文件、容器文件、容器stdout采集外，还支持以下多种采集方式（这些方式k8s中均支持）：
- syslog采集
- Mysql binlog采集
- JDBC采集
- http采集
