Kubernetes没有为集群级日志记录提供原生解决方案。但有常见方案：

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

SideCar方式

方式一

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

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

$ cat count-pod.yaml

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: counter
  5. spec:
  6.   containers:
  7.   - name: count
  8.     image: busybox
  9.     args:
  10.     - /bin/sh
  11.     - -c
  12.     - >
  13.       i=0;
  14.       while true;
  15.       do
  16.         echo "$i: $(date)" >> /var/log/1.log;
  17.         echo "$(date) INFO $i" >> /var/log/2.log;
  18.         i=$((i+1));
  19.         sleep 1;
  20.       done
  21.     volumeMounts:
  22.     - name: varlog
  23.       mountPath: /var/log
  24.   - name: count-log-1
  25.     image: busybox
  26.     args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
  27.     volumeMounts:
  28.     - name: varlog
  29.       mountPath: /var/log
  30.   - name: count-log-2
  31.     image: busybox
  32.     args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
  33.     volumeMounts:
  34.     - name: varlog
  35.       mountPath: /var/log
  36.   volumes:
  37.   - name: varlog
  38.     emptyDir: {}

$ kubectl create -f counter-pod.yaml
$ kubectl logs -f counter -c count-log-1

缺陷：

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

方式二

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

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

劣势：

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

参考

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