Kubernetes 容器日志搜集与管理

日志采集场景

---

日志采集场景主要分为以下四种：

集群核心组件日志：
审计需要Kube-apiserver日志，诊断调度需要kube-scheduler日志，接入层流量分析需要Ingress日志。（一部分为k8s控制面板组件，还有一些核心的中间件，比如ingress）

主机内核日志：

内核日志可以用于帮助开发及运维同学诊断影响节点稳定的异常，如：文件系统异常，网络栈异常，设备驱动异常等。

应用运行时日志：

Docker是最常见的容器运行时，可以利用Docker和Kubelet日志排查Pod创建和启动失败等问题。

业务应用日志：

通过分析业务的运行日志分析和观察业务状态，诊断异常。

 

 

日志采集目标

---

Kubernetes对容器日志的期望处理方式为：集群级日志处理（cluster-level-logging）

即：与容器、Pod、节点生命周期完全无关。

对于一个容器，当应用将日志输出到stdout和stderr后，docker默认将这些日志输出到宿主机上一个JSON文件中。（标准输出可以使用kubectl logs查看，如果你的应用将日志输出到其他地方了，比如容器当中的某个文件里面，或者远程存储里面，这就属于特殊情况了）

 

 

日志采集方式

---

Kubernetes本身并不会对用户进行任何的日志搜集工作。为了实现集群级日志处理，需要在集群前，提前对日志采集管理进行方案规划。

Kubernetes本身推荐3种日志方案。

日志采集方式1：使用节点级日志代理

---

核心是logging-agent （fluentd，etc ），Logging-agent以DaemonSet方式运行在节点上，挂载宿主机上的容器日志目录，转发日志至后端存储（ElasticSearch, etc）

优点：对应用和Pod完全无侵入，一个节点仅需部署一个agent。

缺点：要求应用日志直接输出至容器的stdout和stderr。

 

日志采集方式2：使用sidecar容器和日志代理

---

容器全部或部分日志输出到文件，一个或多个sidecar容器将应用程序日志传送到自己的stdout和stderr。(pod里面只有一个容器，默认日志输出是在容器的某个目录下面，在这种情况下使用kubectl logs命令是完全看不到任何应用日志的)

优点：能够继续使用日志采集方式1。

缺点：成倍增加磁盘占用，造成浪费。（sidcare容器对cpu内存占用并不会很高，应用和sidecar容器写入两份相同日志文件，这样就能够间接实时的看到容器的内容。宿主机上面就存在着两份相同的日志文件，一份是应用自己写入的，另外一方是sidecar标准输入输出在节点上对应的json文件，这对磁盘是一个非常大的浪费）

 

 

日志采集方式3：使用具有日志代理功能的sidecar容器

---

相当于将logging-agent直接集成进Pod，应用和输出日志至stdout&stderr或文件，Logging-agent的输入源为应用日志文件。（使用sidecar容器直接将应用的日志发送到远程的存储，日志还是输出到文件而不是标准输出，kubectl logs无法查看日志）

优点：部署简单，对宿主机友好。

缺点：1. Sidecar容器可能消耗较多资源，甚至拖挂应用容器。

           2. 无法使用kubectl logs命令查看容器日志。

总结：

实现集群级日志采集的三种方式：

1. 使用节点级日志代理。

2. 使用sidecar容器和日志代理。

3. 使用具有日志代理功能的sidecar容器。

建议：使用方案1，将应用日志输出到stdout&stderr，通过宿主机上直接部署logging-agent的方式集中处理日志。

1. 管理简单。

2. 可以使用kubectl logs命令查看日志。

3. 宿主机本身可能已有rstlogd等成熟日志收集组件可使用。

不管使用哪种方案，都必须及时的将这些日志及时的从宿主机上面清理，或者挂载一个大容量的磁盘，否则主分区被写满了，系统就会处于崩溃的状态。 

选型推荐

fluentd会在每个节点上都会运行一个agent，这个agent会将数据离线到后端存储，比如es，如果业务需要使用sidecar方案，推荐使用fluentdbit做sidecar容器。