篇五：Kubernetes日志采集
说起日志，我相信每个从业人员都不陌生。从分析问题、观测软件运行状态等都离不开日志，程序日志记录了程序的运行轨迹，往往还包含了一些关键数据、错误信息等。
因此在使用 Kubernetes 的过程中，对应的日志收集也是我们不得不考虑的问题，我们需要日志去了解集群内部的运行状况。
Kubernetes 中的日志收集 VS 传统日志收集
传统应用中，往往是在虚拟机或物理机直接运行程序，程序日志输出到本机的文件系统的某个目录中，或者是由rsyslog、systemd-journald等工具托管。在此类环境中，日志目录是相对固定不变的，因此收集日志只需要访问日志目录即可。
而在 Kubernetes 中，日志收集相比传统虚拟机、物理机方式要复杂得多。
首先，Kubernetes 日志的形式非常多样化，一个完整的日志系统至少需要收集以下三种：
- Kubernetes 各组件的运行日志，如 kubelet、docker、kube-prpoxy 等
- 业务容器的运行日志，如 tomcat、nginx 等
- Kubernetes 的各种 Event，如 Pod 的创建、删除、错误等事件
其次，我们知道 Pod 是“用完即焚”的，当 Pod 的生命周期结束后，其日志也会被删除。但是这个时候我们仍然希望可以看到具体的日志，用于查看和分析业务的运行情况，以及帮助我们发现出容器异常的原因。
再次，Kubernetes 集群中的资源状态可能随时会发生变化，Pod 实例数量随时都可能会受 HPA(Horizontal Pod Autoscaler ) 的影响或管理员的操作而变化。我们并无法预知 Pod 会在哪个节点上运行，而且 Kubernetes 工作节点也无时无刻可能会宕机。
在一切都是动态的场景下，Kubernetes 日志系统在设计时就要考虑这些不确定因素
几种常见的 Kubernetes 日志收集架构
Kubernetes 集群本身其实并没有提供日志收集的解决方案，但依赖 Kubernetes 自身提供的各项能力，可以帮助我们解决日志收集的诉求。根据上面提到的三大基本日志需求，一般来说我们有如下有三种方案来做日志收集：
- 应用程序自身将日志推送到日志系统
- 在每个节点上运行一个 Agent 来采集节点级别的日志
- 在一个 Pod 内使用一个 Sidecar 容器来收集应用日志
下面分别分析这三种方案的使用场景和优缺点。
