在k8s环境安装收集器
所有文档
menu

日志服务 BLS

在k8s环境安装收集器

产品详情立即开通

概述

本篇将介绍在k8s环境中如何选择并部署收集器,以及应用其收集容器日志。

方式1:针对CCE容器可直接在容器引擎平台安装日志组件(推荐)

  1. 登录容器引擎控制台
  2. 在左侧导航栏,选择集群列表。
  3. 在“集群列表”页面单击目标集群,进入集群管理页面。
  4. 在集群管理页面左侧导航栏中选择组件管理。
  5. 在“组件管理”页面的“日志”页签下,找到CCE Log Operator组件,单击安装。

338295e1898d73b8548bdfdb04f34ec5.png

6.安装后在BLS平台即可看到已安装日志组建的收集器

image.png

方式2:通过脚本方式部署安装收集器

以下将首先介绍如何选择两种收集器,然后分别讲解DaemonSet和Sidecar两种部署及使用方法和各自的工作原理。

1.如何选择使用DaemonSet或者Sidecar收集器

容器类型 可收集容器日志类型 部署方式 优势 建议场景
DaemonSet 容器标准输出、容器内部日志 集群中每个worker节点部署一个收集器,同一节点上的多个应用容器共用一个收集器。 资源占用较小,基本无侵入性,无丢失日志风险。 需要收集容器标准输出日志,且对资源消耗较敏感,应用容器较多较复杂时使用DaemonSet。
Sidecar 容器内部日志 随每个应用容器一同创建与消亡。 使用方便,任务配置与非容器相同。 在仅收集容器内部日志的情况下,且场景简单,应用容器单一时使用Sidecar。

2.资源下载地址

k8s yaml脚本下载地址 :

DaemonSet脚本

Sidecar脚本

3.DaemonSet模式

(1) 部署方法

脚本修改

下图为DaemonSet脚本局部内容:

image2021-11-18_21-8-2.png

注意:"BLS_CONTAINER_TAG"的name和value为系统使用信息请不要修改,否则将造成功能失效。用户需要修改的为红框所示部分的value值。

首先,"BLS_USER_TOKEN"值为用户console上"收集器安装"下token值,如下图所示,请复制该字符串并填入DaemonSet文件中"BLS_USER_TOKEN" value处。

image.png

注意:该token值为认证logbeat的唯一信息,属于秘密信息,不可轻易泄露给他人。

其次,"BLS_SERVER_ENDPOINT"值为BLS Server的服务地址,请用户根据所在区域需求,选择如下正确的服务地址,并填入DaemonSet文件中"BLS_SERVER_ENDPOINT" value处。

region endpoint
北京 https://bls.bj.baidubce.com:8185
广州 https://bls.gz.baidubce.com:8185
苏州 https://bls.su.baidubce.com:8185
保定 https://bls.bd.baidubce.com:8185
武汉 https://bls.fwh.baidubce.com:8185
香港 https://bls.hkg.baidubce.com:8185

最后,"BLS_TASKS"值为logbeat预先绑定的任务列表,该功能在DaemonSet模式下为可选功能。如果用户需要在logbeat启动后就自动与console中的传输任务绑定并执行相应任务,则需配置该值。建议使用此功能,因为在收集器容器重启后,会产生新的收集器实例,如果没有自动关联任务,则仍需要手动关联。用户需要粘贴console中传输任务ID于此value处,多个任务ID间以逗号分隔。

部署命令

kubectl apply -f logbeat-daemonset.yaml

(2) 使用方法

DaemonSet容器部署命令执行后,且在k8s环境下,查看其创建成功后,则在BLS console中"收集器管理"页可以查看到新增的容器实例。如下图:

image.png

然后,在"传输任务"页创建源端类型是"容器"的传输任务。如下图:

image2021-11-18_22-17-0.png

需要注意的是:

1、任务配置中的Label白、黑名单中的Key应填写container inspect中的label, 如 io.kubernetes.container.name,io.kubernetes.pod.namespace等,而不是k8s资源元数据配置中的label。

2、在dasmonset中,收集容器内日志的情况下,需要将容器内日志文件的任意级父路径挂载到宿主机中,如:emptyDir等。

需要在传输任务创建完成后,再为该任务添加收集器,此时可添加的收集器仅为DaemonSet容器,如下图所示,因为将容器类型任务发送到普通收集器中,将不能正常工作。

image2021-11-18_22-39-6.png

添加完收集器约一分钟后,任务将被下发到收集器,届时可以任务详情页查看任务在收集器上的运行状态。

(3)原理解释

k8s 的DaemonSet 类型资源可确保全部节点上运行一个 Pod 的副本。 当有节点加入集群时, 也会为他们新增一个 Pod 。 当有节点从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

正是DaemonSet 的这种特性,可用其在每个节点上部署一个日志收集守护进程,可用来收集该节点上的全部容器日志。

结合container runtime API 与k8s 特性,我们可以通过docker API 过滤出需要收集日志的应用容器,再通过容器自身机制寻找日志文件的路径,确定日志文件在节点中的位置,进而完成日志收集工作。

4.Sidecar模式

(1)部署方法

脚本修改 下图为Sidecar脚本局部内容:

image2021-11-18_21-52-31.png

Sidecar模式的脚本填值方法与DaemonSet相同。唯一的区别是"BLS_TASKS"值在Sidecar模式下是必填值,这主要取决于工作模式的不同,后面将展开介绍。

  • 注意点1:必须先在console上创建好相应的传输任务,再将任务ID拷贝至"BLS_TASKS"值处,且多个任务ID之间以逗号分割。
  • 注意点2:此处的传输任务应是源端类型为主机型任务,而不是容器型任务。
  • 注意点3:由于Sidecar容器的日志收集原理是与应用容器共享日志目录或文件,因此需要注意共享目录或文件的正确性,如下图示例所示。

image2021-11-22_23-18-8.png

部署命令

kubectl apply -f logbeat-sidecar.yaml

(2)使用方法

Sidecar类型收集器随应用容器一起部署后,由于自动关联了传输任务,因而在容器被创建后,将自动开始对日志文件进行采集传输。

需要着重强调的是,在创建Sidecar类型的传输任务时,源端类型应选择『主机』,而不是『容器』。因为『容器』类型是专门为DaemonSet类型容器准备的。

正因为Sidecar容器类型收集器与非容器类型收集器工作模式相同,都是收集本地文件,所以Sidecar容器类型收集器只能收集应用容器内部文件日志,不能收集应用容器标准输出日志。

(3)原理解释

image.png

关于工作原理,首先,如上图所示,Sidecar类型收集器是与应用容器部署在一个POD内,它的生命周期与应用容器相同。

另外,由于Sidecar容器是与应用容器共享了日志目录或文件,因此,Sidecar收集器就像收集本地日志文件一样去收集日志,所以使用上并不会感觉到Sidecar类型收集器是容器,其上传输任务与非容器类型收集器上运行的传输任务相同,只不过由于容器部署的灵活性,需要通过配置中的任务ID参数,事先绑定好传输任务,以便随时启动,随时工作,不惧容器漂移。

但是,同时因为它与应用容器的生命周期相同,在应用容器的日志未挂载到宿主机的情况下,可能会出现该日志还未来得及全部收集完成,就随容器一起销毁的情况。

收集器更新

如果需要指定收集器的版本,可以修改yaml文件中的logbeat版本信息;latest表示最新的版本,重启POD将会拉取最新的版本部署logbeat,也可以手动更新到指定版本,例如:修改为 registry.baidubce.com/bce_bls/logbeat:1.6.0,表示使用1.6.0版本。

image.png

总结

以上就是在k8s环境部署和使用收集器的介绍,如您在使用过程中有任何不便或有任何优化建议,请您提工单

上一篇
主机安装收集器
下一篇
收集器管理