日志服务支持通过Logtail采集Kubernetes（简称K8S）集群日志，并支持CRD（CustomResourceDefinition）和控制台等方式进行采集配置管理。
为提供更优的扩展性、灵活性，Logtail采集的配置与K8S中的Deploy/Pod配置完全解耦，两者可以一起部署也可以独立部署，具体取决于您的实际应用和业务需求。
下面我们介绍几种典型的配置方式，以便于您在实际应用中进行参考。
前提
- K8S环境中安装好Logtail相关服务组件，若未安装请参考Kubernetes日志采集部署相关组件。
- 假设您对K8S中服务部署已经具备一定基础知识。
注意事项
- K8S集群Logtail组件部署完毕后，会默认创建一个自定义标识的机器分组，后续所有的配置直接应用到该分组即可。
- Logtail容器在K8S中以DaemonSet的模式部署，后续您的集群缩扩容时不需关心。
- 无论是容器的标准输出还是容器文件，均支持
IncludeEnv和ExcludeEnv用来过滤指定的容器，推荐使用环境变量的方式进行配置，具体含义请参考容器标准输出和容器内文本文件。 - 不建议使用容器的标准输和容器文件中的
IncludeLabel和ExcludeLabel中的label是容器的label，和K8S中的label并不是同一概念。
入门型
作为初次接触日志服务的用户，建议您在第一次部署采集配置时使用该方式：只使用一个配置采集所有容器的stdout。（具体操作细节请参考Kubernetes日志采集入门）
具体方式为：
- 在日志服务控制台Logstore列表单击数据接入向导图标，进入配置流程。
- 单击自建软件中的Docker标准输出，并单击下一步。
- 无需修改基础配置，直接单击下一步，并应用到机器组。
- 后续提示无需关心，一直点击下一步直到确认。
按照以上简单配置方式，您就可以将整个集群中所有容器的标准输出（stdout和stderr）全部采集到一个Logstore中。
同时若您的所有容器中日志文件保存路径均一致，也可以通过一个容器文本文件配置全部采集。
伴随型
若您的集群中每个应用都需独立采集到一个logstore中，您可以使用伴随型的方式来进行日志采集部署：
- 在部署您的业务应用时，为需要采集的容器增加一个特殊环境变量。
- 部署应用同时，也加上对应的CRD配置，其中
IncludeEnv配置为步骤1的特殊环境变量。
例如，当需要新部署应用app-comment时，为该容器增加环境变量ALIYUN_LOG_COLLECTION=app-comment, 在部署脚本(yaml文件)后增加对应的CRD配置，配置中指定IncludeEnv为ALIYUN_LOG_COLLECTION=app-comment。
规划型
若您的公司、业务中对于日志管理较为健全，可以使用此种方式进行日志采集的管理：
- 对于需要采集的业务种类、日志形式、日志格式、日志路径等进行提前规划。
- 根据规划创建对应的容器标准输出以及容器文件的采集配置，配置中使用
IncludeEnv进行特殊环境变量标识。 - 部署业务应用容器时，若该容器需采集若干种日志，则为该容器添加步骤2中对应的特殊环境变量。
- 若有对应新的业务日志或新的类型日志需要接入，则继续步骤2、3的流程。
例如，对于某个电商类的K8S集群，业务类日志规划为：前端访问日志、购物车日志、订单日志、交易日志、评论日志等；系统类日志规划为：kernel日志、Trace日志、Debug日志、Crash监控日志、应用异常日志。
其中对于Debug日志，统一存储在容器的/app/logs/debug/debug.log，配置采集的IncludeEnv为 ALIYUN_LOG_DEBUG_LOG_COLLECTION=TRUE；对于Trace日志，统一存储在容器的/app/logs/trace/trace.log，配置采集的IncludeEnv为 ALIYUN_LOG_TRACE_LOG_COLLECTION=TRUE....
最终部署服务时，若该容器需要采集Debug、Trace日志，则为其增加环境变量ALIYUN_LOG_DEBUG_LOG_COLLECTION=TRUE和ALIYUN_LOG_TRACE_LOG_COLLECTION=TRUE。
混合型
混合型即为充分利用Logtail配置灵活的方式，可使用但并不仅限于以下方式：
- 对于全集群统一采集的配置，不配置
IncludeEnv，只配置ExcludeEnv，如有特殊需求不被采集的容器可通过添加对应的环境变量排除采集。 - 对于类型比较确定的日志，可使用规划型的方式，提前创建配置，部署服务时通过为容器添加环境变量进行关联
- 对于比较特殊的应用日志，可使用伴随型的方式，只对该容器进行采集。
类型对比
下述是各种配置模式的对比，其中简单型最容易上手，只推荐入门的用户使用；伴随型灵活性较高，但此种方式配置数过多且对应用日志没有约束；规划型的配置数较少，且各类应用日志都遵循规范输出，日志格式化程度高，最终可分析性较强，目前阿里云中很多产品内部都基于此方式进行日志采集和分析，强烈建议使用；混合型继承了伴随型和规划型的优劣势，若您目前系统很难完成规划型改造，建议使用混合型逐批向规划型迁移。
| 简单型 | 伴随型 | 规划型 | 混合型 | |
|---|---|---|---|---|
| 配置复杂性 | 极低 | 较高 | 较低 | 较高 |
| 配置数 | 1/2个 | 取决于应用数 | 取决于日志分类数 | 取决于日志分类数+特殊应用数 |
| 灵活性 | 极低 | 较高 | 一般 | 高 |
| 日志规范性 | 无要求 | 无要求 | 要求各类应用按规范打日志 | 部分日志需遵循规范 |
| 可分析性 | 极低 | 一般 | 高 | 较高 |
| 推荐指数 | 1星 | 3星 | 5星 | 4星 |