基于EFK的Kubernetes日志采集方案

于 2024-07-25 16:12:52 发布
阅读量752 收藏 20
点赞数 12
文章标签： kubernetes 容器 云原生 elk
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xiangfeideyuwei/article/details/140691659
版权

日志采集架构

k8s日志收集架构

https://kubernetes.io/docs/concepts/cluster-administration/logging/

容器日志的存储

Docker容器的日志

容器日志驱动

https://docs.docker.com/config/containers/logging/configure/

查看当前的docker主机的驱动：

$ docker info --format '{{.LoggingDriver}}'

json-file格式，docker会默认将标准和错误输出保存为宿主机的文件，路径为：

/var/lib/docker/containers/<container-id>/<container-id>-json.log

并且可以设置日志轮转：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "labels": "production_status",
    "env": "os,customer"
  }
}

k8s Pod的日志存储

$ ll /var/log/pods/

总体分为三种方式：

  • 使用在每个节点上运行的节点级日志记录代理。
  • 在应用程序的 pod 中，包含专门记录日志的 sidecar 容器。
  • 将日志直接从应用程序中推送到日志记录后端。

使用节点级日志代理

优势：

  • 部署方便，使用DaemonSet类型控制器来部署agent即可
  • 对业务应用的影响最小，没有侵入性

劣势:

  • 只能收集标准和错误输出，对于容器内的文件日志，暂时收集不到

使用 sidecar 容器和日志代理

方式一：sidecar 容器将应用程序日志传送到自己的标准输出。

思路：在pod中启动一个sidecar容器，把容器内的日志文件吐到标准输出，由宿主机中的日志收集agent进行采集。

$ cat count-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}
    
$ kubectl apply -f counter-pod.yaml
$ kubectl logs -f counter -c count-log-1

优势：

  • 可以实现容器内部日志收集
  • 对业务应用的侵入性不大

劣势：

  • 每个业务pod都需要做一次改造
  • 增加了一次日志的写入，对磁盘使用率有一定影响

方式二：sidecar 容器运行一个日志代理，配置该日志代理以便从应用容器收集日志。

思路：直接在业务Pod中使用sidecar的方式启动一个日志收集的组件（比如fluentd），这样日志收集可以将容器内的日志当成本地文件来进行收取。

优势：不用往宿主机存储日志，本地日志完全可以收集

劣势：每个业务应用额外启动一个日志agent，带来额外的资源损耗

从应用中直接暴露日志目录

企业日志方案选型

目前来讲，最建议的是采用节点级的日志代理。

方案一：自研方案，实现一个自研的日志收集agent，大致思路：

  • 针对容器的标准输出及错误输出，使用常规的方式，监听宿主机中的容器输出路径即可
  • 针对容器内部的日志文件
    • 在容器内配置统一的环境变量，比如LOG_COLLECT_FILES，指定好容器内待收集的日志目录及文件
    • agent启动的时候挂载docker.sock文件及磁盘的根路径
    • 监听docker的容器新建、删除事件，通过docker的api，查出容器的存储、环境变量、k8s属性等信息
    • 配置了LOG_COLLECT_FILES环境变量的容器，根据env中的日志路径找到主机中对应的文件路径，然后生成收集的配置文件
    • agent与开源日志收集工具（Fluentd或者filebeat等）配合，agent负责下发配置到收集工具中并对进程做reload

fluentd-pilot

方案二：日志使用开源的Agent进行收集（EFK方案），适用范围广，可以满足绝大多数日志收集、展示的需求。

fluentd概念及工作流程

EFK架构工作流程

  • Elasticsearch

    一个开源的分布式、Restful 风格的搜索和数据分析引擎，它的底层是开源库Apache Lucene。它可以被下面这样准确地形容：

    • 一个分布式的实时文档存储，每个字段可以被索引与搜索；
    • 一个分布式实时分析搜索引擎；
    • 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据。

  • Kibana

    Kibana是一个开源的分析和可视化平台，设计用于和Elasticsearch一起工作。可以通过Kibana来搜索，查看，并和存储在Elasticsearch索引中的数据进行交互。也可以轻松地执行高级数据分析，并且以各种图标、表格和地图的形式可视化数据。

  • Fluentd

    一个针对日志的收集、处理、转发系统。通过丰富的插件系统，可以收集来自于各种系统或应用的日志，转化为用户指定的格式后，转发到用户所指定的日志存储系统之中。

Fluentd 通过一组给定的数据源抓取日志数据，处理后（转换成结构化的数据格式）将它们转发给其他服务，比如 Elasticsearch、对象存储、kafka等等。Fluentd 支持超过300个日志存储和分析服务，所以在这方面是非常灵活的。主要运行步骤如下

  1. 首先 Fluentd 从多个日志源获取数据
  2. 结构化并且标记这些数据
  3. 然后根据匹配的标签将数据发送到多个目标服务

Fluentd架构

为什么推荐使用fluentd作为k8s体系的日志收集工具？

  • 可插拔架构设计

极小的资源占用

基于C和Ruby语言， 30-40MB，13,000 events/second/core

  • 极强的可靠性

    • 基于内存和本地文件的缓存
    • 强大的故障转移

fluentd事件流的生命周期及指令配置

https://docs.fluentd.org/v/0.12/quickstart/life-of-a-fluentd-event

Input -> filter 1 -> ... -> filter N -> Buffer -> Output

启动命令

$ fluentd -c fluent.conf

指令介绍：

source ，数据源，对应Input 通过使用 source 指令，来选择和配置所需的输入插件来启用 Fluentd 输入源， source 把事件提交到 fluentd 的路由引擎中。使用type来区分不同类型的数据源。如下配置可以监听指定文件的追加输入：

<source>
  @type tail
  path /var/log/httpd-access.log
  pos_file /var/log/td-agent/httpd-access.log.pos
  tag myapp.access
  format apache2
</source>

filter，Event processing pipeline（事件处理流）

filter 可以串联成 pipeline，对数据进行串行处理，最终再交给 match 输出。 如下可以对事件内容进行处理：

<source>
  @type http
  port 9880
</source>

<filter myapp.access>
  @type record_transformer
  <record>
    host_param “#{Socket.gethostname}”
  </record>
</filter>

  • filter 获取数据后，调用内置的 @type record_transformer 插件，在事件的 record 里插入了新的字段 host_param，然后再交给 match 输出。

  • label指令

    可以在 source 里指定 @label，这个 source 所触发的事件就会被发送给指定的 label 所包含的任务，而不会被后续的其他任务获取到。

<source>
  @type forward
</source>

<source>
### 这个任务指定了 label 为 @SYSTEM
### 会被发送给 <label @SYSTEM>
### 而不会被发送给下面紧跟的 filter 和 match
  @type tail
  @label @SYSTEM
  path /var/log/httpd-access.log
  pos_file /var/log/td-agent/httpd-access.log.pos
  tag myapp.access
  format apache2
</source>

<filter access.**>
  @type record_transformer
  <record>
  # …
  </record>
</filter>

<match **>
  @type elasticsearch
  # …
</match>

<label @SYSTEM>
  ### 将会接收到上面 @type tail 的 source event
  <filter var.log.middleware.**>
    @type grep
    # …
  </filter>

  <match **>
    @type s3
    # …
  </match>
</label>

match，匹配输出

查找匹配 “tags” 的事件，并处理它们。match 命令的最常见用法是将事件输出到其他系统（因此，与 match 命令对应的插件称为 “输出插件”）

<source>
  @type http
  port 9880
</source>

<filter myapp.access>
  @type record_transformer
  <record>
    host_param “#{Socket.gethostname}”
  </record>
</filter>

<match myapp.access>
  @type file
  path /var/log/fluent/access
</match>

事件的结构：

time：事件的处理时间

tag：事件的来源，在fluentd.conf中配置

record：真实的日志内容，json对象

比如，下面这条原始日志：

192.168.0.1 - - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777

经过fluentd 引擎处理完后的样子可能是：

2024-07-25 12:40:35 +0000 apache.access: {"user":"-","method":"GET","code":200,"size":777,"host":"192.168.0.1","path":"/"}

fluentd的buffer事件缓冲模型

Input -> filter 1 -> ... -> filter N -> Buffer -> Output

因为每个事件数据量通常很小，考虑数据传输效率、稳定性等方面的原因，所以基本不会每条事件处理完后都会立马写入到output端，因此fluentd建立了缓冲模型，模型中主要有两个概念：

  • buffer_chunk：事件缓冲块，用来存储本地已经处理完待发送至目的端的事件，可以设置每个块的大小。
  • buffer_queue：存储chunk的队列，可以设置长度

可以设置的参数，主要有：

  • buffer_type，缓冲类型，可以设置file或者memory
  • buffer_chunk_limit，每个chunk块的大小，默认8MB
  • buffer_queue_limit ，chunk块队列的最大长度，默认256
  • flush_interval ，flush一个chunk的时间间隔
  • retry_limit ，chunk块发送失败重试次数，默认17次，之后就丢弃该chunk数据
  • retry_wait ，重试发送chunk数据的时间间隔，默认1s，第2次失败再发送的话，间隔2s，下次4秒，以此类推

大致的过程为：

随着fluentd事件的不断生成并写入chunk，缓存块持变大，当缓存块满足buffer_chunk_limit大小或者新的缓存块诞生超过flush_interval时间间隔后，会推入缓存queue队列尾部，该队列大小由buffer_queue_limit决定。

比较理想的情况是每次有新的缓存块进入缓存队列，则立马会被写入到后端，同时，新缓存块也持续入列，但是入列的速度不会快于出列的速度，这样基本上缓存队列处于空的状态，队列中最多只有一个缓存块。

但是实际情况考虑网络等因素，往往缓存块被写入后端存储的时候会出现延迟或者写入失败的情况，当缓存块写入后端失败时，该缓存块还会留在队列中，等retry_wait时间后重试发送，当retry的次数达到retry_limit后，该缓存块被销毁（数据被丢弃）。

此时缓存队列持续有新的缓存块进来，如果队列中存在很多未及时写入到后端存储的缓存块的话，当队列长度达到buffer_queue_limit大小，则新的事件被拒绝，fluentd报错，error_class=Fluent::Plugin::Buffer::BufferOverflowError error="buffer space has too many data"。

还有一种情况是网络传输缓慢的情况，若每3秒钟会产生一个新块，但是写入到后端时间却达到了30s钟，队列长度为100，那么每个块出列的时间内，又有新的10个块进来，那么队列很快就会被占满，导致异常出现。

fluentd配置实战

实践一：监听业务应用日志，收集并输出

目标：收集容器内的nginx应用的access.log日志，并解析日志字段为JSON格式，原始日志的格式为：

$ tail -f access.log
...
53.49.146.149 1561620585.973 0.005 502 [25/Jun/2024:15:29:45 +0800] 178.73.215.171 33337 GET https

思路：

  • 配置fluent.conf
    • 使用@tail插件通过监听access.log文件
    • 启动fluentd服务
  • 手动追加内容至access.log文件
  • 观察本地输出内容是否符合预期

fluent.conf

<source>
    @type tail
    path /var/log/nginx/access.log
    pos_file /var/log/nginx/nginx_access.posg
    tag nginx_access
    format none
    @log_level trace
</source>
<match  nginx_access>
    @type stdout
</match>

启动服务，追加文件内容：

# https://github.com/fluent/fluentd-kubernetes-daemonset
$ docker run -u root --rm -ti --entrypoint='' fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch-amd64 bash
/ # fluentd -c fluent.conf
/ # echo '53.49.146.149 1561620585.973 0.005 502 [25/Jun/2024:15:29:45 +0800] 178.73.215.171 33337 GET https' >>/var/log/nginx/access.log


# 输出结果：
2024-15-19 03:31:42.956800427 +0000 nginx_access: {"message":"53.49.146.149 1561620585.973 0.005 502 [25/Jun/2024:15:29:45 +0800] 178.73.215.171 33337 GET https"}

实践二：实现业务应用日志的收集及字段解析

目标：收集容器内的nginx应用的access.log日志，并解析日志字段为JSON格式，原始日志的格式为：

$ tail -f access.log
...
53.49.146.149 1561620585.973 0.005 502 [25/Jun/2024:15:29:45 +0800] 178.73.215.171 33337 GET https

收集并处理成：

{
    "serverIp": "53.49.146.149",
    "timestamp": "1561620585.973",
    "respondTime": "0.005",
    "httpCode": "502",
    "eventTime": "25/Jun/2024:15:20:45 +0800",
    "clientIp": "178.73.215.171",
    "clientPort": "33337",
    "method": "GET",
    "protocol": "https"
}

fluent.conf

<source>
    @type tail
    path /var/log/nginx/access.log
    pos_file /var/log/nginx/nginx_access.posg
    tag nginx_access
    format none
    @log_level trace
</source>
<filter  nginx_access>
    @type parser
    key_name message
    format  /(?<serverIp>[^ ]*) (?<timestamp>[^ ]*) (?<respondTime>[^ ]*) (?<httpCode>[^ ]*) \[(?<eventTime>[^\]]*)\] (?<clientIp>[^ ]*) (?<clientPort>[^ ]*) (?<method>[^ ]*) (?<protocol>[^ ]*)/
</filter>
<match  nginx_access>
  @type stdout
</match>

输出结果：

2024-07-25 15:34:43.005963334 +0000 nginx_access: {"serverIp":"53.49.146.149","timestamp":"1561620585.973","respondTime":"0.005","httpCode":"502","eventTime":"27/Jun/2019:15:29:45 +0800","clientIp":"178.73.215.171","clientPort":"33337","method":"GET","protocol":"https"}

使用该网站进行正则校验： http://fluentular.herokuapp.com

实践三：使用ruby实现日志字段的转换及自定义处理

<source>
    @type tail
    path /var/log/nginx/access.log
    pos_file /var/log/nginx/nginx_access.posg
    tag nginx_access
    format none
    @log_level trace
</source>
<filter  nginx_access>
    @type parser
    key_name message
    format  /(?<serverIp>[^ ]*) (?<timestamp>[^ ]*) (?<respondTime>[^ ]*) (?<httpCode>[^ ]*) \[(?<eventTime>[^\]]*)\] (?<clientIp>[^ ]*) (?<clientPort>[^ ]*) (?<method>[^ ]*) (?<protocol>[^ ]*)/
</filter>
<filter  nginx_access>   
   @type record_transformer
   enable_ruby
   <record>
      host_name "#{Socket.gethostname}"
      my_key  "my_val"
      tls ${record["protocol"].index("https") ? "true" : "false"}
    </record>
</filter>
<match  nginx_access>
  @type stdout
</match>

<div><br class="Apple-interchange-newline">实践三：使用ruby实现日志字段的转换及自定义处理</div>

configMap挂载场景

ConfigMap的配置文件挂载使用场景

开始之前，我们先来回顾一下，configmap的常用的挂载场景。

场景一：单文件挂载到空目录

假如业务应用有一个配置文件，名为 application.yml，如果想将此配置挂载到pod的/etc/application/目录中。

application.yml的内容为：

$ cat application.yml
spring:
  application:
    name: svca-service
  cloud:
    config:
      uri: http://config:8888
      fail-fast: true
      username: user
      password: ${CONFIG_SERVER_PASSWORD:password}
      retry:
        initial-interval: 2000
        max-interval: 10000
        multiplier: 2
        max-attempts: 10

该配置文件在k8s中可以通过configmap来管理，通常我们有如下两种方式来管理配置文件：

  • 通过kubectl命令行来生成configmap

# 通过文件直接创建
$ kubectl -n default create configmap application-config --from-file=application.yml

# 会生成配置文件，查看内容，configmap的key为文件名字
$ kubectl -n default get cm application-config -oyaml

通过yaml文件直接创建

$ cat application-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: application-config
  namespace: default
data:
  application.yml: |
    spring:
      application:
        name: svca-service
      cloud:
        config:
          uri: http://config:8888
          fail-fast: true
          username: user
          password: ${CONFIG_SERVER_PASSWORD:password}
          retry:
            initial-interval: 2000
            max-interval: 10000
            multiplier: 2
            max-attempts: 10

# 创建configmap
$ kubectl apply -f application-config.yaml

准备一个demo-deployment.yaml文件，挂载上述configmap到/etc/application/中

$ cat demo-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      volumes:
      - configMap:
          name: application-config
        name: config
      containers:
      - name: nginx
        image: nginx:alpine
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "/etc/application"
          name: config

创建并查看：

$ kubectl apply -f demo-deployment.yaml

修改configmap文件的内容，观察pod中是否自动感知变化：

$ kubectl edit cm application-config

整个configmap文件直接挂载到pod中，若configmap变化，pod会自动感知并拉取到pod内部。

但是pod内的进程不会自动重启，所以很多服务会实现一个内部的reload接口，用来加载最新的配置文件到进程中。

场景二：多文件挂载

假如有多个配置文件，都需要挂载到pod内部，且都在一个目录中

$ cat application.yml
spring:
  application:
    name: svca-service
  cloud:
    config:
      uri: http://config:8888
      fail-fast: true
      username: user
      password: ${CONFIG_SERVER_PASSWORD:password}
      retry:
        initial-interval: 2000
        max-interval: 10000
        multiplier: 2
        max-attempts: 10

$ cat supervisord.conf
[unix_http_server]
file=/var/run/supervisor.sock
chmod=0700

[supervisord]
logfile=/var/logs/supervisor/supervisord.log
logfile_maxbytes=200MB
logfile_backups=10
loglevel=info
pidfile=/var/run/supervisord.pid
childlogdir=/var/cluster_conf_agent/logs/supervisor
nodaemon=false

同样可以使用两种方式创建：

$ kubectl delete cm application-config

$ kubectl create cm application-config --from-file=application.yml --from-file=supervisord.conf

$ kubectl get cm application-config -oyaml

观察Pod已经自动获取到最新的变化

$ kubectl exec demo-55c649865b-gpkgk ls /etc/application/
application.yml
supervisord.conf

此时，是挂载到pod内的空目录中/etc/application，假如想挂载到pod已存在的目录中，比如：

$  kubectl exec   demo-55c649865b-gpkgk ls /etc/profile.d
color_prompt
locale

更改deployment的挂载目录：

$ cat demo-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      volumes:
      - configMap:
          name: application-config
        name: config
      containers:
      - name: nginx
        image: nginx:alpine
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "/etc/profile.d"
          name: config

重建pod

$ kubectl apply -f demo-deployment.yaml

# 查看pod内的/etc/profile.d目录，发现已有文件被覆盖
$ kubectl exec demo-77d685b9f7-68qz7 ls /etc/profile.d
application.yml
supervisord.conf

场景三 挂载子路径

实现多个配置文件，可以挂载到pod内的不同的目录中。比如：

  • application.yml挂载到/etc/application/
  • supervisord.conf挂载到/etc/profile.d

configmap保持不变，修改deployment文件：

$ cat demo-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  namespace: default
spec:
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      volumes:
      - name: config
        configMap:
          name: application-config
          items:
          - key: application.yml
            path: application
          - key: supervisord.conf
            path: supervisord
      containers:
      - name: nginx
        image: nginx:alpine
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "/etc/application/application.yml"
          name: config
          subPath: application
        - mountPath: "/etc/profile.d/supervisord.conf"
          name: config
          subPath: supervisord

测试挂载：

$ kubectl apply -f demo-deployment.yaml

$ kubectl exec demo-78489c754-shjhz ls /etc/application
application.yml

$ kubectl exec demo-78489c754-shjhz ls /etc/profile.d/
supervisord.conf
color_prompt
locale

使用subPath挂载到Pod内部的文件，不会自动感知原有ConfigMap的变更

EFK基于k8s部署

部署es服务

部署分析

  1. es生产环境是部署es集群，通常会使用statefulset进行部署
  2. es默认使用elasticsearch用户启动进程，es的数据目录是通过宿主机的路径挂载，因此目录权限被主机的目录权限覆盖，因此可以利用initContainer容器在es进程启动之前把目录的权限修改掉，注意init container要用特权模式启动。
  3. 若希望使用helm部署，参考 https://github.com/helm/charts/tree/master/stable/elasticsearch

使用StatefulSet管理有状态服务

使用Deployment创建多副本的pod的情况：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

使用StatefulSet创建多副本pod的情况：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-statefulset
  namespace: default
  labels:
    app: nginx-sts
spec:
  replicas: 3
  serviceName: "nginx"
  selector:
    matchLabels:
      app: nginx-sts
  template:
    metadata:
      labels:
        app: nginx-sts
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

无头服务Headless Service

kind: Service
apiVersion: v1
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx-sts
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  clusterIP: None
$ kubectl -n default exec  -ti nginx-statefulset-0 sh
/ # curl nginx-statefulset-2.nginx

部署并验证

es-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: es-config
  namespace: logging
data:
  elasticsearch.yml: |
    cluster.name: "luffy-elasticsearch"
    node.name: "${POD_NAME}"
    network.host: 0.0.0.0
    discovery.seed_hosts: "es-svc-headless"
    cluster.initial_master_nodes: "elasticsearch-0,elasticsearch-1,elasticsearch-2"

es-svc-headless.yaml

apiVersion: v1
kind: Service
metadata:
  name: es-svc-headless
  namespace: logging
  labels:
    k8s-app: elasticsearch
spec:
  selector:
    k8s-app: elasticsearch
  clusterIP: None
  ports:
  - name: in
    port: 9300
    protocol: TCP

es-statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: elasticsearch
  namespace: logging
  labels:
    k8s-app: elasticsearch
spec:
  replicas: 3
  serviceName: es-svc-headless
  selector:
    matchLabels:
      k8s-app: elasticsearch
  template:
    metadata:
      labels:
        k8s-app: elasticsearch
    spec:
      initContainers:
      - command:
        - /sbin/sysctl
        - -w
        - vm.max_map_count=262144
        image: alpine:3.6
        imagePullPolicy: IfNotPresent
        name: elasticsearch-logging-init
        resources: {}
        securityContext:
          privileged: true
      - name: fix-permissions
        image: alpine:3.6
        command: ["sh", "-c", "chown -R 1000:1000 /usr/share/elasticsearch/data"]
        securityContext:
          privileged: true
        volumeMounts:
        - name: es-data-volume
          mountPath: /usr/share/elasticsearch/data
      containers:
      - name: elasticsearch
        image: elasticsearch:7.4.2
        env:
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
        resources:
          limits:
            cpu: '1'
            memory: 2Gi
          requests:
            cpu: '1'
            memory: 2Gi
        ports:
        - containerPort: 9200
          name: db
          protocol: TCP
        - containerPort: 9300
          name: transport
          protocol: TCP
        volumeMounts:
          - name: es-config-volume
            mountPath: /usr/share/elasticsearch/config/elasticsearch.yml
            subPath: elasticsearch.yml
          - name: es-data-volume
            mountPath: /usr/share/elasticsearch/data
      volumes:
        - name: es-config-volume
          configMap:
            name: es-config
            items:
            - key: elasticsearch.yml
              path: elasticsearch.yml
  volumeClaimTemplates:
  - metadata:
      name: es-data-volume
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: "nfs"
      resources:
        requests:
          storage: 5Gi

es-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: es-svc
  namespace: logging
  labels:
    k8s-app: elasticsearch
spec:
  selector:
    k8s-app: elasticsearch
  ports:
  - name: out
    port: 9200
    protocol: TCP
$ kubectl create namespace logging

## 部署服务
$ kubectl apply -f es-config.yaml
$ kubectl apply -f es-svc-headless.yaml
$ kubectl apply -f es-statefulset.yaml
$ kubectl apply -f es-svc.yaml

## 等待片刻，查看一下es的pod，状态变为running
$ kubectl -n logging get po -o wide  
NAME              READY   STATUS    RESTARTS   AGE   IP  
elasticsearch-0   1/1     Running   0          15m   10.244.0.126 
elasticsearch-1   1/1     Running   0          15m   10.244.0.127
elasticsearch-2   1/1     Running   0          15m   10.244.0.128
# 然后通过curl命令访问一下服务，验证es是否部署成功
$ kubectl -n logging get svc  
es-svc            ClusterIP   10.104.226.175   <none>        9200/TCP   2s
es-svc-headless   ClusterIP   None             <none>        9300/TCP   32m 
$ curl 10.104.226.175:9200
{
  "name" : "elasticsearch-2",
  "cluster_name" : "luffy-elasticsearch",
  "cluster_uuid" : "7FDIACx9T-2ajYcB5qp4hQ",
  "version" : {
    "number" : "7.4.2",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "2f90bbf7b93631e52bafb59b3b049cb44ec25e96",
    "build_date" : "2019-10-28T20:40:44.881551Z",
    "build_snapshot" : false,
    "lucene_version" : "8.2.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"

部署kibana

部署分析

  1. kibana需要暴露web页面给前端使用，因此使用ingress配置域名来实现对kibana的访问
  2. kibana为无状态应用，直接使用Deployment来启动
  3. kibana需要访问es，直接利用k8s服务发现访问此地址即可，http://es-svc:9200

部署并验证

kibana.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana
  namespace: logging
  labels:
    app: kibana
spec:
  selector:
    matchLabels:
      app: "kibana"
  template:
    metadata:
      labels:
        app: kibana
    spec:
      containers:
      - name: kibana
        image: kibana:7.4.2
        resources:
          limits:
            cpu: 1000m
          requests:
            cpu: 100m
        env:
          - name: ELASTICSEARCH_HOSTS
            value: http://es-svc:9200
          - name: SERVER_NAME
            value: kibana-logging
          - name: SERVER_REWRITEBASEPATH
            value: "false"
        ports:
        - containerPort: 5601
        volumeMounts:
          - name: config
            mountPath: /usr/share/kibana/config/
      volumes:
        - name: config
          configMap:
            name: kibana-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kibana-config
  namespace: logging
data:
  kibana.yml: |-
    elasticsearch.requestTimeout: 90000
    server.host: "0"
    xpack.monitoring.ui.container.elasticsearch.enabled: true
---
apiVersion: v1
kind: Service
metadata:
  name: kibana
  namespace: logging
  labels:
    app: kibana
spec:
  ports:
  - port: 5601
    protocol: TCP
    targetPort: 5601
  type: ClusterIP
  selector:
    app: kibana
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kibana
  namespace: logging
spec:
  ingressClassName: nginx
  rules:
  - host: kibana.luffy.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: 
            name: kibana
            port:
              number: 5601
$ kubectl apply -f kibana.yaml  
deployment.apps/kibana created
service/kibana created  
ingress/kibana created

## 配置域名解析 kibana.luffy.com，并访问服务进行验证，若可以访问，说明连接es成功


# GET /_cat/health?v
# GET /_cat/indices

Fluentd服务部署

部署分析

  1. fluentd为日志采集服务，kubernetes集群的每个业务节点都有日志产生，因此需要使用daemonset的模式进行部署
  2. 为进一步控制资源，会为daemonset指定一个选择标签，fluentd=true来做进一步过滤，只有带有此标签的节点才会部署fluentd

部署服务

注意点：

Docker的日志输出格式与Containerd的日志格式不同，因此需要注意解析日志时要使用新的格式解析器：

https://github.com/fluent/fluentd-kubernetes-daemonset#use-cri-parser-for-containerdcri-o-logs

fluentd-config-tail-container-parse.yaml

$ cat tail_container_parse.conf
# configuration example
<parse>
  @type cri
</parse>

# 创建configmap，后面挂载给fluentd使用，适配containerd的日志格式
$ kubectl -n logging create configmap tail-container-parse --from-file=tail_container_parse.conf

fluentd-rbac.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd-es
  namespace: logging
  labels:
    k8s-app: fluentd-es
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: fluentd-es
  labels:
    k8s-app: fluentd-es
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
rules:
- apiGroups:
  - ""
  resources:
  - "namespaces"
  - "pods"
  verbs:
  - "get"
  - "watch"
  - "list"
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: fluentd-es
  labels:
    k8s-app: fluentd-es
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
subjects:
- kind: ServiceAccount
  name: fluentd-es
  namespace: logging
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: fluentd-es
  apiGroup: ""

daemonset定义文件，注意点：

  1. 需要将/var/log/pods/目录挂载到容器中
  2. 需要将fluentd的configmap中的配置文件挂载到容器内
  3. 想要部署fluentd的节点，需要添加fluentd=true的标签

fluentd-daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: logging
  labels:
    k8s-app: fluentd-logging
    version: v1
spec:
  selector:
    matchLabels:
      k8s-app: fluentd-logging
      version: v1
  template:
    metadata:
      labels:
        k8s-app: fluentd-logging
        version: v1
    spec:
      nodeSelector:
        fluentd: "true"
      serviceAccount: fluentd-es
      serviceAccountName: fluentd-es
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch-amd64
        env:
          - name: K8S_NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name:  FLUENT_ELASTICSEARCH_HOST
            value: "es-svc"
          - name:  FLUENT_ELASTICSEARCH_PORT
            value: "9200"
          - name: FLUENT_ELASTICSEARCH_SCHEME
            value: "http"
          - name: FLUENTD_SYSTEMD_CONF
            value: "disable"
          - name: FLUENTD_PROMETHEUS_CONF
            value: "disable"
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        # When actual pod logs in /var/lib/docker/containers, the following lines should be used.
        # - name: dockercontainerlogdirectory
        #   mountPath: /var/lib/docker/containers
        #   readOnly: true
        # When actual pod logs in /var/log/pods, the following lines should be used.
        - name: dockercontainerlogdirectory
          mountPath: /var/log/pods
          readOnly: true
        - mountPath: "/fluentd/etc/tail_container_parse.conf"
          name: config
          subPath: tail-container-parse
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      # When actual pod logs in /var/lib/docker/containers, the following lines should be used.
      # - name: dockercontainerlogdirectory
      #   hostPath:
      #     path: /var/lib/docker/containers
      # When actual pod logs in /var/log/pods, the following lines should be used.
      - name: dockercontainerlogdirectory
        hostPath:
          path: /var/log/pods
      - name: config
        configMap:
          name: tail-container-parse
          items:
          - key: tail_container_parse.conf
            path: tail-container-parse
## 给slave1打上标签，进行部署fluentd日志采集服务
$ kubectl label node k8s-slave1 fluentd=true  
$ kubectl label node k8s-slave2 fluentd=true

# 创建服务
$ kubectl apply -f fluentd-rbac.yaml
$ kubectl apply -f fluentd-daemonset.yaml  

## 然后查看一下pod是否正常运行
$ kubectl -n logging get po -o wide

日志收集功能验证

EFK功能验证

登录kibana界面，按照截图的顺序操作：

思考：日志中出现了很多kubernetes的元数据信息，这些数据从哪采集而来

GitHub - fabric8io/fluent-plugin-kubernetes_metadata_filter: Enrich your fluentd events with Kubernetes metadata

到这里，我们就在 Kubernetes 集群上成功部署了 EFK ，要了解如何使用 Kibana 进行日志数据分析，可以参考 Kibana 用户指南文档：Kibana Guide [8.14] | Elastic

JAVA云计算
关注
  • 12
    点赞
  • 踩
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
实现基于EFK日志平台收集Kubernetes集群日志信息
江晓龙的博客
08-18 1668
kubernetes集群基于EFK实现日志收集平台 文章目录kubernetes集群基于EFK实现日志收集平台1.EFK工作原理2.部署EFK平台2.1.部署nfs2.2.部署elasticsearch2.2.1.创建es的pv及pvc资源2.2.2.准备elasticsearch镜像并推送至harbor2.2.3.编写elasticsearch yaml文件2.2.4.创建lasticsearch资源并查看状态2.3.部署kibana2.3.1.准备kibana的pv及pvc资源2.3.2.准备kiban
Kubernetes 事件日志采集与分析最佳实践
最新发布
观测云的博客
05-17 1150
本文详细介绍 Kubernetes 事件采集分析的最佳实践，以观测云为例，阐述如何有效地收集、存储和分析 Kubernetes 事件。
logstash优点_使用Logstash收集Kubernetes的应用日志
weixin_29498577的博客
12-24 628
前言很多企业内部都有自己的ElasticSearch集群，我们没有必要在kubernetes集群内部再部署一个，而且这样还难于管理，因此我们考虑在容器里部署logstash收集日志到已有的ElasticSearch集群中。方案选择Kubernetes官方提供了EFK的日志收集解决方案，但是这种方案并不适合所有的业务场景，它本身就有一些局限性，例如：所有日志都必须是out前台输出，真实业务场景中无法...
spring-cloud 分布式日志采集
热门推荐
guduyishuai的博客
02-01 4万+
由于微服务架构中每个服务可能分散在不同的服务器上，因此需要一套分布式日志的解决方案。spring-cloud提供了一个 用来trace服务的组件sleuth。它可以通过日志获得服务的依赖关系。基于sleuth，可以通过现有的日志工具实现分布式日志的采集。 这里使用的是ELK，也就是elasticsearch、logstash、kibana。 一、sleuth 第一步：sleuth管理端
怎样合理创建es索引_图解Elasticsearch之一——索引创建过程
weixin_29021195的博客
12-24 905
0、引言这是国外培训ppt课程的节选内容。以下是我们的Core Elasticsearch：Operations课程中的一些很棒的幻灯片，它们有助于解释分片分配的概念。 我们建议您更全面地了解这一点，但我会在此提供我们培训的概述：分片分配是将分片分配给节点的过程。 这可能发生在初始恢复，副本分配，重新平衡或添加或删除节点期间。 大多数时候，你不需要考虑它，这项工作是由Elasticsearch在后...
在 Kubernetes 上搭建 EFK 日志收集系统
ccy19910925的博客
01-28 1017
Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch、Fluentd 和 Kibana（EFK）技术栈，也是官方现在比较推荐的一种方案。 Elasticsearch 是一个实时的、分布式的可扩展的搜索引擎，允许进行全文、结构化搜索，它通常用于索引和搜索大量日志数据，也可用于搜索许多不同类型的文档。 Elasticsearch 通常与 Kibana 一起部署，Kiba...
EFK日志收集 【初步概览】
qq_34819372的博客
11-30 630
引用自官网 https://www.elastic.co/cn/products
kubernetes日志采集方案EFK
总结、分享、交流
06-28 2772
https://www.qikqiak.com/post/install-efk-stack-on-k8s/ EFK简介 Kubernetes中比较流行的日志收集解决方案是Elasticsearch、Fluentd 和 Kibana（EFK）技术栈，也是官方现在比较推荐的一种方案。 Elasticsearch是一个实时的、分布式的可扩展的搜索引擎，允许进行全文、结构化搜索，它通常用于索引和搜索大量...
Kubernetes+EFK构建日志分析平台
z2050025507的博客
08-17 1566
由于 Kubernetes 在容器编排领域的强势领先，使得越来越多的企业将业务迁至基于 Docker+Kubernetes 技术栈打造的容器管理平台，所以在 Kubernetes 集群环境下如何打造高效、可靠的业务日志收集系统也成为企业必须面临的问题。Kubeadm 通过初始化安装是不包括网络插件的，也就是说初始化之后是不具备相关网络功能的，比如 k8s-master 节点上查看节点信息都是“Not Ready”状态、Pod 的 CoreDNS无法提供服务等。Elasticsearch 具有如下特点。
Rancher 日志采集（二）（应用商店EFK）
03-30 2486
使用Rancher 收集日志，但一直没有找到很全面的讲解，通过三篇文讲解Rancher通过fluentd收集集群内日志及配置注意事项
Kubernetes单机部署+EFK日志收集
lxiaoyouyouj的博客
05-11 992
Kubernetes+EFK日志收集 技能目标： 掌握 Kubernetes 离线部署的方法 掌握 Kubernetes 集群下 EFK 模型架构与原理 会基于 Kubernetes 集群的 EFK 安装与配置 学会使用业务容器验证 EFK 日志收集 案例概述 案例前置知识点 1. 什么是 Kubernetes Kubernetes 是 2014 年 Google 和 Redhat 发布的开源项目。因为有了容器之后，就需要有一种方式去帮助用户方便、快速、优雅地管理这些容器，而这也是 K
EFK日志收集系统
qq_35886593的博客
10-31 501
1、史上EFK日志系统最全教程-安装及配置：https://blog.csdn.net/anxianfeng55555/article/details/81325254 2、centos7搭建EFK日志分析系统：https://www.jianshu.com/p/4bf5a8b743d2
EFK 日志收集系统
zhonghua881016的博客
08-11 1183
日志系统采用ES、filebeat、Kabana工具搭建，整个版本是采用6.8。filebeat负责采集，定义日志文件采集格式，并配置输出到es时对日志进行预处理pipeline（能够对特有的字段进行检索，比如根据traceId、appName检索等) ......
SpringBoot+Kafka+ELK 完成海量日志收集（超详细）
JAVA葵花宝典
08-17 223
点击关注公众号，实用技术文章及时了解来源：jiandansuifeng.blog.csdn.net/article/details/107361190整体流程大概如下：服务器准备在这先列出...
efk日志
仅做个人笔记
02-18 459
转自https://blog.csdn.net/weixin_42595012/article/details/90054021，仅做个人备份，浏览请看原文 Elasticsearch，FileBeat，Kibana。其中 ELasticsearch 负责日志分析和存储，FileBeat 负责日志收集，Kibana 负责界面展示。它们之间互相配合使用，完美衔接，高效的满足了很多场合的应用，是目前主流的一种日志分析系统解决方案。 EFK 和 ELK 只有一个区别， 收集日志的组件由 Logstash.
利用EFK对日志进行采集
这人脑子有点不够用
04-20 542
配置完成后将项目打包进行发布，可以先测试一下查看你的logs里时候生成了日志，或者查看日志是否正确，然后访问。your Ip:5601 界面。配置完成后在文件所在目录下执行。然后配置我们的项目日志配置。
EFK部署及日志收集分析
qq_37256882的博客
12-23 1172
EFK日志处理流程本文介绍以下内容。
一种轻量级日志采集解决方案
cz1803472613的博客
04-16 1223
目前各大公司生产部署很多都是采用的集群+微服务的部署方式，如果让日志散落在各个主机上，查询起来会非常的困难，所以目前我了解到的都是采用的日志中心来统一收集管控日志，日志中心的实现方案大多基于ELK(即Elasticsearch、Logstash和Kibana三个开源软件的缩写)，ELK一般都要配合FileBeat使用，其中FileBeat做为采集器，Logstash做为日志过滤格式化工具、Elasticsearch做为存储介质、Kibana做为视图解析器，四个组件搭配组成日志中心。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值