目录
前言
日志架构
使用节点级日志代理
使用 sidecar 容器运行日志代理
具有日志代理功能的边车容器
从应用中直接暴露日志目录
解决方案
部署应用
通过DaemonSet运行filebeat
通过ConfinMap创建filebeat配置文件
编写yaml脚本运行filebeat
查看日志
参考文档
前言
本博文中涉及解决方案通过参考k8s官方手册和filebeat手册得出，整体通过k8s DaemonSet部署elastic/filebeat采集应用日志写入到es中。
查阅k8s官方手册，集群级日志架构整体有4种，如下一章节所示（该章节内容摘子K8S官方文档，链接于文末），这里我们采用第一种方案来实现K8S中应用日志的采集。
日志架构
使用节点级日志代理
你可以通过在每个节点上使用 节点级的日志记录代理 来实现群集级日志记录。 日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。 通常，日志记录代理程序是一个容器，它可以访问包含该节点上所有应用程序容器的日志文件的目录。
由于日志记录代理必须在每个节点上运行，通常可以用 DaemonSet 的形式运行该代理。 节点级日志在每个节点上仅创建一个代理，不需要对节点上的应用做修改。
容器向标准输出和标准错误输出写出数据，但在格式上并不统一。 节点级代理 收集这些日志并将其进行转发以完成汇总。
使用 sidecar 容器运行日志代理
利用边车容器向自己的 stdout 和 stderr 传输流的方式， 你就可以利用每个节点上的 kubelet 和日志代理来处理日志。 边车容器从文件、套接字或 journald 读取日志。 每个边车容器向自己的 stdout 和 stderr 流中输出日志。
这种方法允许你将日志流从应用程序的不同部分分离开，其中一些可能缺乏对写入 stdout 或 stderr 的支持。重定向日志背后的逻辑是最小的，因此它的开销几乎可以忽略不计。 另外，因为 stdout、stderr 由 kubelet 处理，你可以使用内置的工具 kubectl logs。
具有日志代理功能的边车容器
如果节点级日志记录代理程序对于你的场景来说不够灵活，你可以创建一个 带有单独日志记录代理的边车容器，将代理程序专门配置为与你的应用程序一起运行。
从应用中直接暴露日志目录
从各个应用中直接暴露和推送日志数据的集群日志机制 已超出 Kubernetes 的范围。
解决方案
部署应用
这里不再赘述应用是如何部署的，但需要注意一点应用的日志输出挂载路径需要和filebeat的日志采集路径一致。
通过DaemonSet运行filebeat
通过ConfinMap创建filebeat配置文件
创建配置文件filebeat-config.yaml并运行（运行操作省略）
apiVersion: v1
kind: ConfigMap
metadata:
name: filebeat-config
namespace: k8s-demo
data:
config: |
filebeat.prospectors:
- input_type: log
paths:
- /var/log/*
json:
keys_under_root: true
processors:
- drop_fields:
fields: ["input_type", "offset", "beat", "type"]
output.elasticsearch:
hosts: ['elasticsearch_host:9200']
username: username
password: pwd
indices:
- index: "filebeat-k8s-demo-log-%{+yyyyMMdd}"
Tips：此处es相关配置请各位查看个人项目修改
注意事项：
- json.keys_under_root=true,是为了将JSON格式的日志key拆分到file顶层，若不加该配置则会统一写入到message属性下
- drop_fields中配置部分属性，是为了写入es是删除filebeat自带的一些属性
编写yaml脚本运行filebeat
创建配置文件elastic-filebeat.yaml并运行（运行操作省略）
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: elastic-filebeat
namespace: k8s-demo
labels:
server: filebeat-5.6.16
spec:
selector:
matchLabels:
name: elastic-filebeat
template:
metadata:
labels:
name: elastic-filebeat
spec:
containers:
- image: elastic/filebeat:5.6.16
name: honeypot-filebeat
securityContext:
runAsUser: 0
runAsGroup: 0
fsGroup: 0
volumeMounts:
- mountPath: /usr/share/filebeat/data
name: fb-data
- mountPath: /var/log
name: fb-log
- mountPath: /usr/share/filebeat/filebeat.yml
subPath: filebeat.yml
name: cfg
readOnly: true
volumes:
- name: fb-data
hostPath:
path: /usr/share/filebeat/data
- name: fb-log
hostPath:
path: /var/application-logs
- name: cfg
configMap:
name: filebeat-config
items:
- key: config
path: filebeat.yml
注意事项
- 示例中该容器以root用户运行，避免卷挂载出现权限问题
- filebeat.yml配置载入使用subPath这一点十分重要,因为/usr/share/filebeat是一个目录而K8S官方文档明确说明如果mountPath如果挂载一个目录指向configMap会将该目录清空并使用configMap中的配置内容，这里但/usr/share/filebeat目录下包含了filebeat的其他我们不需要修改的内容，而我们只需要修改filebeat.yml文件
- 使用daemonSet运行filebeat需要挂载/usr/share/filebeat/data，该目录下有一个registry文件，里面记录了filebeat采集日志位置的相关内容，比如文件offset、source、timestamp等，如果Pod发生异常后K8S自动将Pod进行重启，不挂载的情况下registry会被重置，将导致日志文件又从offset=0开始采集，结果就是es中日志重复一份，这点非常重要
查看日志
运行DaemonSet后，检查DaemonSet是否正常运行：
可以看到正常运行，各位可以进入Pod容器内查看ConfigMap、data是否挂载成功，这里不再赘述。
当我们的应用将日志写入我们filebeat挂载的/var/log目录下后，登录Kibana查看指定索引是否有日志文件。
可以看到日志已经成功写入es中。
参考文档
日志架构 | Kubernetes
elastic/filebeat - Docker Image | Docker Hub
