全面解析K8s日志监控：三种最佳实践详解

K8s是怎么做日志监控的？

在Kubernetes（K8s）环境中，日志监控是非常重要的一部分，可以帮助运维人员和开发者了解系统运行状态、排查故障和优化性能。常见的日志监控方式有三种：

1. Fluentd安装在宿主机上

这种方式将Fluentd安装在每个宿主机上，然后把日志转发到远端的Elasticsearch等存储服务中，以便备份和检索。

• 优点：在一个节点上只需要部署一个Agent，不会对应用和Pod有任何入侵性，对系统资源的占用较少。
• 缺点：应用程序需要将日志输出到容器的stdout和stderr，增加了一些配置复杂性。

例如：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    command: ["myapp"]
    args: ["--logtostderr"]
  - name: fluentd
    image: fluentd:latest
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    hostPath:
      path: /var/log

2. Sidecar容器日志收集

当容器日志可以输出到某些文件时，可以通过一个Sidecar容器来读取这些日志文件，并将其重定向到stdout和stderr，然后再使用第一种方式将日志收集到Fluentd。

• 优点：弥补了第一种方式的不足，解决了应用程序必须输出到stdout和stderr的问题。
• 缺点：增加了资源消耗和配置复杂性。

例如：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    volumeMounts:
    - name: applogs
      mountPath: /var/log/myapp
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: applogs
      mountPath: /var/log/myapp
  volumes:
  - name: applogs
    emptyDir: {}

3. Sidecar容器直接收集日志

这种方式是将Fluentd容器直接部署在Pod中，通过Sidecar容器将应用程序的日志直接发送到远端存储中，如Elasticsearch。

• 优点：实现了集中管理和高效收集，日志处理延迟低。
• 缺点：Sidecar容器会消耗更多的资源，不适用于日志量非常大的应用场景。

例如：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: myapp:latest
  - name: log-collector
    image: fluentd:latest
    env:
    - name: FLUENTD_OUTPUT
      value: "elasticsearch"
    volumeMounts:
    - name: applogs
      mountPath: /var/log/myapp
  volumes:
  - name: applogs
    emptyDir: {}

• 第一种方式：适用于日志量不大且可以输出到stdout和stderr的应用。
• 第二种方式：适用于日志量中等且需要文件日志收集的应用。
• 第三种方式：适用于日志量大且需要高效集中管理的应用。

详细解释K8s日志监控的三种方式示例

1. Fluentd安装在宿主机上

这种方式将Fluentd安装在每个宿主机上，收集所有容器的日志，然后转发到远端存储。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    command: ["myapp"]
    args: ["--logtostderr"]
  - name: fluentd
    image: fluentd:latest
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    hostPath:
      path: /var/log

解释：

• apiVersion: v1
  : 表示API版本是v1。
• kind: Pod
  : 资源类型是Pod。
• metadata
  : 定义Pod的元数据。
• name: mypod
  : 指定Pod的名称为mypod。
• spec
  : 定义Pod的规格。
• name: varlog
  : 卷的名称为varlog。
• hostPath
  : 卷类型为hostPath，表示使用宿主机的文件系统。
• path: var/log
  : 指定挂载路径为宿主机的/var/log
  目录。
• name: myapp
  : 容器名称为myapp。
• image: myapp:latest
  : 使用myapp的最新镜像。
• command: ["myapp"]
  : 指定容器启动命令为myapp。
• args: ["--logtostderr"]
  : 传递参数，将日志输出到stderr。
• name: fluentd
  : 容器名称为fluentd。
• image: fluentd:latest
  : 使用Fluentd的最新镜像。
• volumeMounts
  : 定义挂载的卷。
• name: varlog
  : 卷的名称为varlog。
• mountPath: var/log
  : 将卷挂载到容器的/var/log
  目录。
• containers
  : 包含Pod中的容器列表。
• volumes
  : 定义Pod使用的卷。

这个示例将应用程序的日志输出到stderr，Fluentd容器收集宿主机的/var/log
目录中的日志，并转发到远端存储。

2. Sidecar容器日志收集

这种方式通过Sidecar容器来读取应用程序日志文件，并将其重定向到stdout和stderr。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: myapp:latest
    volumeMounts:
    - name: applogs
      mountPath: /var/log/myapp
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: applogs
      mountPath: /var/log/myapp
  volumes:
  - name: applogs
    emptyDir: {}

解释：

• apiVersion: v1
  : 表示API版本是v1。
• kind: Pod
  : 资源类型是Pod。
• metadata
  : 定义Pod的元数据。
• name: mypod
  : 指定Pod的名称为mypod。
• spec
  : 定义Pod的规格。
• name: applogs
  : 卷的名称为applogs。
• emptyDir
  : 卷类型为emptyDir，表示使用Pod的临时目录。
• name: myapp
  : 容器名称为myapp。
• image: myapp:latest
  : 使用myapp的最新镜像。
• volumeMounts
  : 定义挂载的卷。
• name: log-collector
  : 容器名称为log-collector。
• image: fluentd:latest
  : 使用Fluentd的最新镜像。
• volumeMounts
  : 定义挂载的卷。
• name: applogs
  : 卷的名称为applogs。
• mountPath: /var/log/myapp
  : 将卷挂载到容器的/var/log/myapp
  目录。
• name: applogs
  : 卷的名称为applogs。
• mountPath: /var/log/myapp
  : 将卷挂载到容器的/var/log/myapp
  目录。
• containers
  : 包含Pod中的容器列表。
• volumes
  : 定义Pod使用的卷。

这个示例通过一个Sidecar容器读取应用程序的日志文件，并将日志重新输出到Fluentd容器的stdout和stderr。

3. Sidecar容器直接收集日志

这种方式是将Fluentd容器直接部署在Pod中，通过Sidecar容器将应用程序的日志直接发送到远端存储。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: myapp:latest
  - name: log-collector
    image: fluentd:latest
    env:
    - name: FLUENTD_OUTPUT
      value: "elasticsearch"
    volumeMounts:
    - name: applogs
      mountPath: /var/log/myapp
  volumes:
  - name: applogs
    emptyDir: {}

解释：

• apiVersion: v1
  : 表示API版本是v1。
• kind: Pod
  : 资源类型是Pod。
• metadata
  : 定义Pod的元数据。
• name: mypod
  : 指定Pod的名称为mypod。
• spec
  : 定义Pod的规格。
• name: applogs
  : 卷的名称为applogs。
• emptyDir
  : 卷类型为emptyDir，表示使用Pod的临时目录。
• name: myapp
  : 容器名称为myapp。
• image: myapp:latest
  : 使用myapp的最新镜像。
• name: log-collector
  : 容器名称为log-collector。
• image: fluentd:latest
  : 使用Fluentd的最新镜像。
• env
  : 定义环境变量。
• volumeMounts
  : 定义挂载的卷。
• name: FLUENTD_OUTPUT
  : 环境变量名称为FLUENTD_OUTPUT。
• value: "elasticsearch"
  : 环境变量值为"elasticsearch"。
• name: applogs
  : 卷的名称为applogs。
• mountPath: /var/log/myapp
  : 将卷挂载到容器的/var/log/myapp
  目录。
• containers
  : 包含Pod中的容器列表。
• volumes
  : 定义Pod使用的卷。

这个示例中，Fluentd容器直接从应用程序的日志目录收集日志，并将其发送到远端的Elasticsearch存储。

这三种日志监控方式分别适用于不同的场景，具体选择哪种方式可以根据实际的需求和环境来决定。如果日志量不大且可以输出到stdout和stderr，可以选择第一种方式。如果需要收集文件日志，可以选择第二种方式。如果日志量大且需要高效管理，可以选择第三种方式。

非常感谢您读到这里！如果您觉得这篇文章对您有帮助，请不要忘记关注公众号。关注后，您将第一时间获得最新的AI、云计算、运维（Linux、数据库，容器等）技术，以及更多实用的技能干货。

点击页面右上角的“关注”按钮，不错过任何精彩内容！


扫码获取联系方式