k8s容器日志收集方案

• 相当于把方案一里的logging agent，放在了应用pod里。如图1.3:

• 在这种方案里，你的应用还可以直接把日志输出到固定的文件里而不是stdout，你的logging-agent还可以使用fluentd，后端存储还可以是ElasticSearch。只不过，fluentd的输入源变成了应用的日志文件。一般来说，我们会把fluentd的输入源配置保存在一个ConfigMap里，如下所以：

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: fluentd-config
  data:
    fluentd.conf: |
      <source>
        type tail
        format none
        path /var/log/1.log
        pos_file /var/log/1.log.pos
        tag count.format1
      </source>
      
      <source>
        type tail
        format none
        path /var/log/2.log
        pos_file /var/log/2.log.pos
        tag count.format2
      </source>
      
      <match **>
        type google_cloud
      </match>
  复制代码

• 我们在应用pod的定义里，就可以生命一个Fluentd容器作为sidecar，专门负责将应用生成的1.log和2.log转发到ElasticSearch中，这个配置，如下所示：

  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-agent
      image: k8s.gcr.io/fluentd-gcp:1.30
      env:
      - name: FLUENTD_ARGS
        value: -c /etc/fluentd-config/fluentd.conf
      volumeMounts:
      - name: varlog
        mountPath: /var/log
      - name: config-volume
        mountPath: /etc/fluentd-config
    volumes:
    - name: varlog
      emptyDir: {}
    - name: config-volume
      configMap:
        name: fluentd-config
  复制代码

• 如上所示，这个Fluentd容器使用的输入源，就是通过引用我们前面写的ConfigMap来指定的。这里用到了Projected Volume来把ConfigMap挂在到Pod里。
• 这种方案最燃部署简单，并且最宿主机非常友好，但是这个sidecar容器很可能会消耗较多的资源，甚至拖垮应用容器。由于日志没有输出到stdout上，所以你通过kubectl logs 是看不到日志信息的。

总结

以上，就是k8s最常用的三种收集日志的手段了，综合对比以上方案，比较建议你将应用日志输出到stdout和stderr，然后通过在苏书记尚部署logging-agent的方式集中处理日志、这种方案不但简单，而且kubectl logs依然可以使用，也是官方推荐的一种。