上一节我们对阿里云Kubernetes集群日志采集方案做了总体介绍，本节将深入解释日志采集配置与Kubernetes无缝集成的技术实现。
不同于其他开源日志采集Agent，日志服务Logtail从设计之初就已经考虑到配置管理的难题。因此Logtail从第一个版本开始就支持中心化的配置管理，支持在日志服务控制台或者SDK中对所有采集配置进行统一管理，大大降低了日志采集的管理负担。
但在Kubernetes集群环境下，业务应用、服务、组件的持续集成和自动发布已经成为常态，使用控制台或SDK操作采集配置的方式很难与各类CI、编排框架集成，导致业务应用发布后用户只能通过控制台以手动配置的方式部署与之对应的日志采集配置。
因此日志服务专门为Kubernetes进行了扩展，用以支持原始的配置管理。
如图9-3所示，日志服务为Kubernetes新增了一个CRD扩展，名为AliyunLogConfig。同时开发了alibaba-log-controller用于监听AliyunLogConfig事件。
图9-3 日志服务与Kubernetes集成
当用户创建、删除、修改AliyunLogConfig资源时，alibaba-log-controller会监听到资源变化，并在日志服务上创建、删除、修改相应的采集配置，以此实现Kubernetes内部AliyunLogConfig与日志服务中采集配置的关联关系。
alibaba-log-controller主要由6个模块组成，各个模块的功能以及依赖关系如图9-4所示。
图9-4 阿里云Kubernetes集群日志服务控制器实现
EventListener：负责监听AliyunLogConfig的CRD资源。这个EventListener是广义上的Listener，主要功能有：
● 初始化时会罗列所有的AliyunLogConfig资源。
● 注册AliyunLogConfig监听变化的事件。
● 定期再扫描全部AliyunLogConfig资源，防止事件出现遗漏或处理失效。
● 将事件打包，交由EventHandler处理。
EventHandler：负责处理对应的创建、删除、修改事件，作为Controller的核心模块，主要功能如下：
● 首先检查ConfigMapManager中对应的Checkpoint，如该事件已经被处理（版本号相同且状态为200），则直接跳过。
● 为防止历史事件干扰处理结果，从服务端拉取最新的资源状态，检查是否为同一版本，若版本不一致，则使用服务端版本替换。
● 对事件进行一定的预处理，使之符合LogSDK的基本格式需求。
● 调用LogSDKWrapper，创建日志服务Logstore，创建、删除、修改对应的配置。
● 根据上述处理结果，更新对应的AliyunLogConfig资源的状态。
ConfigMapManager：依赖于Kubernetes的ConfigMap机制实现Controller的Checkpoint管理，包括：
● 维护Checkpoint到ConfigMap的映射关系。
● 提供基础的Checkpoint增删改查接口。
LogSDKWrapper：基于阿里云LOG golang sdk的二次封装，功能包括：
● 初始化创建日志服务资源，包括Project、MachineGroup、Operation Logstore等。
● 将CRD资源转换为对应的日志服务资源操作，CRD与日志服务资源为一对多关系。
● 包装SDK接口，自动处理网络异常、服务器异常、权限异常。
● 负责权限管理，包括自动获取role，更新STS Token等。
ScheduledSyner：后台的定期同步模块，防止进程或节点失效期间配置改动而遗漏事件，保证配置管理的最终一致性：
● 定期刷新所有的Checkpoint和AliyunLogConfig。
● 检查Checkpoint和AliyunLogConfig资源的映射关系，如果Checkpoint中出现不存在的配置，则删除对应的资源。
● Monitor：alibaba-log-controller除了将本地运行日志输出到stdout外，还会将日志直接采集到日志服务中，便于远程排查问题。采集日志种类如下：
● Kubernetes API内部异常日志。
● alibaba-log-controller运行日志。
● alibaba-log-controller内部异常数据（自动聚合）。