K8S环境使用ELK+Filebeat 收集容器日志的方案和安装部署

最新推荐文章于 2024-05-18 08:00:00 发布

原创

最新推荐文章于 2024-05-18 08:00:00 发布 · 4.1k 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#elk

前言

看到这篇文章的同学相信对K8S已经有一定的了解了，现在很多公司都使用K8S来部署自己的应用，使用K8S来发布应用确实很好，但是日志查看方面还是有诸多的不便，比如主机权限不能随便开放，并且公司层面的K8S 集群内应用数和副本数都比较多，问题定位时不知道从那个副本的日志开始查看，还有一个是容器的重启后想查看重启之前的日志等等问题，造成了在K8S集群查看日志的诸多不便。
所以引申出下面的方案设计

方案说明

此方案使用 ELK +Filebeat 的架构。
本来 ELK 就能实现日志采集，查询和展示，由于 logstash资源占用比较大(800M+内存)，官方使用 GO语言重写了一个Filebeat实现了部分 logstash的功能，资源占用( 30M+) 指数级的资源占用下降，但是日志解析方面还做得不到位，所以我们使用 filebeat采集日志， logstash来进行解析的设计。
Filebeat 使用DaemonSet 部署负责收集每个节点的所有应用日志数据上报 Logstash ,Logstash 对数据进行一次处理，推送到 ES ，最后使用 Kibana进行展示。

架构图

在这里插入图片描述
画了一个简易架构图来说明：
K8S的应用，默认会把标准输出日志，生成一个文件，通过软链接的方式挂载到节点主机的 /var/log/containers 目录，我们在每个节点部署一个Filebeat去采集这个目录下的内容就OK了

安装部署

相关的chart已经上传 github.com 点击此处 ELK+Filbeat 下载原码
或者码云下载

我们这里使用 helm来安装，helm安装特别简单，没啥说的，主要是chart编写，详情这里就不说了，点击之处了解，安装命令在最后，现把主要的编排内容摘抄如下：

ES编排文件

kind: StatefulSet
metadata:
  name: enervated-puma-elasticsearch
  labels:
    heritage: "Tiller"
    release: "enervated-puma"
    chart: "elasticsearch"
    app: "enervated-puma-elasticsearch"
  annotations:
    esMajorVersion: "7"
spec:
  serviceName: enervated-puma-elasticsearch-headless
  selector:
    matchLabels:
      app: "enervated-puma-elasticsearch"
  replicas: 1
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      name: "enervated-puma-elasticsearch"
      labels:
        heritage: "Tiller"
        release: "enervated-puma"
        chart: "elasticsearch"
        app: "enervated-puma-elasticsearch"
      annotations:

    spec:
      securityContext:
        fsGroup: 1000
        runAsUser: 1000

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - "enervated-puma-elasticsearch"
            topologyKey: kubernetes.io/hostname
      terminationGracePeriodSeconds: 120
      volumes:
      initContainers:
      - name: configure-sysctl
        securityContext:
          runAsUser: 0
          privileged: true
        image: "docker.elastic.co/elasticsearch/elasticsearch:7.5.0"
        imagePullPolicy: "Always"
        command: ["sysctl", "-w", "vm.max_map_count=262144"]
        resources:
          {}


      containers:
      - name: "elasticsearch"
        securityContext:
          capabilities:
            drop:
            - ALL
          runAsNonRoot: true
          runAsUser: 1000

        image: "docker.elastic.co/elasticsearch/elasticsearch:7.5.0"
        imagePullPolicy: "Always"
        readinessProbe:
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 3
          timeoutSeconds: 5

          exec:
            command:
              - sh
              - -c
              - |
                #!/usr/bin/env bash -e
                # If the node is starting up wait for the cluster to be ready (request params: 'wait_for_status=green&timeout=1s' )
                # Once it has started only check that the node itself is responding
                START_FILE=/tmp/.es_start_file

                http () {
                    local path="${1}"
                    if [ -n "${ELASTIC_USERNAME}" ] && [ -n "${ELASTIC_PASSWORD}" ]; then
                      BASIC_AUTH="-u ${ELASTIC_USERN