如何在k8s环境部署收集器
概述
本篇将介绍在k8s环境中如何选择并部署收集器，以及应用其收集容器日志。
以下将首先介绍如何选择两种收集器，然后分别讲解DaemonSet和Sidecar两种部署及使用方法和各自的工作原理。
如何选择使用DaemonSet或者Sidecar收集器
| 容器类型 | 可收集容器日志类型 | 部署方式 | 优势 | 建议场景 |
|---|---|---|---|---|
| DaemonSet | 容器标准输出、容器内部日志 | 集群中每个worker节点部署一个收集器，同一节点上的多个应用容器共用一个收集器。 | 资源占用较小，基本无侵入性，无丢失日志风险。 | 需要收集容器标准输出日志，且对资源消耗较敏感，应用容器较多较复杂时使用DaemonSet。 |
| Sidecar | 容器内部日志 | 随每个应用容器一同创建与消亡。 | 使用方便，任务配置与非容器相同。 | 在仅收集容器内部日志的情况下，且场景简单，应用容器单一时使用Sidecar。 |
资源下载地址
k8s yaml脚本下载地址 ：
DaemonSet模式
部署方法
脚本修改
下图为DaemonSet脚本局部内容：
注意："BLS_CONTAINER_TAG"的name和value为系统使用信息请不要修改，否则将造成功能失效。用户需要修改的为红框所示部分的value值。
首先，"BLS_USER_TOKEN"值为用户console上"收集器安装"下token值，如下图所示，请复制该字符串并填入DaemonSet文件中"BLS_USER_TOKEN" value处。
注意：该token值为认证logbeat的唯一信息，属于秘密信息，不可轻易泄露给他人。
其次，"BLS_SERVER_ENDPOINT"值为BLS Server的服务地址，请用户根据所在区域需求，选择如下正确的服务地址，并填入DaemonSet文件中"BLS_SERVER_ENDPOINT" value处。
最后，"BLS_TASKS"值为logbeat预先绑定的任务列表，该功能在DaemonSet模式下为可选功能。如果用户需要在logbeat启动后就自动与console中的传输任务绑定并执行相应任务，则需配置该值。建议使用此功能，因为在收集器容器重启后，会产生新的收集器实例，如果没有自动关联任务，则仍需要手动关联。用户需要粘贴console中传输任务ID于此value处，多个任务ID间以逗号分隔。
部署命令
kubectl apply -f logbeat-daemonset.yaml使用方法
DaemonSet容器部署命令执行后，且在k8s环境下，查看其创建成功后，则在BLS console中"收集器管理"页可以查看到新增的容器实例。如下图：
然后，在"传输任务"页创建源端类型是"容器"的传输任务。如下图：
需要注意的是：
1、任务配置中的Label白、黑名单中的Key应填写container inspect中的label， 如 io.kubernetes.container.name，io.kubernetes.pod.namespace等，而不是k8s资源元数据配置中的label。
2、在dasmonset中，收集容器内日志的情况下，需要将容器内日志文件的任意级父路径挂载到宿主机中，如：emptyDir等。
需要在传输任务创建完成后，再为该任务添加收集器，此时可添加的收集器仅为DaemonSet容器，如下图所示，因为将容器类型任务发送到普通收集器中，将不能正常工作。
添加完收集器约一分钟后，任务将被下发到收集器，届时可以任务详情页查看任务在收集器上的运行状态。
原理解释
k8s 的DaemonSet 类型资源可确保全部节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
正是DaemonSet 的这种特性，可用其在每个节点上部署一个日志收集守护进程，可用来收集该节点上的全部容器日志。
结合container runtime API 与k8s 特性，我们可以通过docker API 过滤出需要收集日志的应用容器，再通过容器自身机制寻找日志文件的路径，确定日志文件在节点中的位置，进而完成日志收集工作。
Sidecar模式
部署方法
脚本修改
下图为Sidecar脚本局部内容：
Sidecar模式的脚本填值方法与DaemonSet相同。唯一的区别是"BLS_TASKS"值在Sidecar模式下是必填值，这主要取决于工作模式的不同，后面将展开介绍。
- 注意点1：必须先在console上创建好相应的传输任务，再将任务ID拷贝至"BLS_TASKS"值处，且多个任务ID之间以逗号分割。
- 注意点2：此处的传输任务应是源端类型为主机型任务，而不是容器型任务。
- 注意点3：由于Sidecar容器的日志收集原理是与应用容器共享日志目录或文件，因此需要注意共享目录或文件的正确性，如下图示例所示。
部署命令
kubectl apply -f logbeat-sidecar.yaml使用方法
Sidecar类型收集器随应用容器一起部署后，由于自动关联了传输任务，因而在容器被创建后，将自动开始对日志文件进行采集传输。
需要着重强调的是，在创建Sidecar类型的传输任务时，源端类型应选择『主机』，而不是『容器』。因为『容器』类型是专门为DaemonSet类型容器准备的。
正因为Sidecar容器类型收集器与非容器类型收集器工作模式相同，都是收集本地文件，所以Sidecar容器类型收集器只能收集应用容器内部文件日志，不能收集应用容器标准输出日志。
原理解释
关于工作原理，首先，如上图所示，Sidecar类型收集器是与应用容器部署在一个POD内，它的生命周期与应用容器相同。
另外，由于Sidecar容器是与应用容器共享了日志目录或文件，因此，Sidecar收集器就像收集本地日志文件一样去收集日志，所以使用上并不会感觉到Sidecar类型收集器是容器，其上传输任务与非容器类型收集器上运行的传输任务相同，只不过由于容器部署的灵活性，需要通过配置中的任务ID参数，事先绑定好传输任务，以便随时启动，随时工作，不惧容器漂移。
但是，同时因为它与应用容器的生命周期相同，在应用容器的日志未挂载到宿主机的情况下，可能会出现该日志还未来得及全部收集完成，就随容器一起销毁的情况。
总结
以上就是在k8s环境部署和使用收集器的介绍，如您在使用过程中有任何不便或有任何优化建议，请您提工单或到如流群（群号：2799264）中与我们联系。