随着生产环境部分服务已经切换至Kubernetes，最近的工作都围绕着周边基础设施来进行，最先考虑到的就是架构可观测性的欠缺，包括了日志系统和监控系统，相比之下我觉得日志系统更为迫切些。
关于日志这个事情其实可大可小，一切取决于应用的规模，日志的重要度以及复杂度会随着规模的变大而直线上升。日系系统包含的东西其实很多，一方面包含日志基础设置的建设，更重要的在于日志的规范的制定和体系的建立。这次除了需要搭建Kubernetes下的日志平台，还想趁着这次机会梳理一下与日志相关的方方面面，来建立较为完善的日志体系。
基于开源的日志方案首选就是ELK，未引入容器化之前我们采用的也是ELK + Filebeat，全部基于文件采集的方式，那么这次日志环境搭建的思路就是正确的把这套日志方案移入Kubernetes环境，当然基于EFK(、、）的方案也是 Kubernetes 官方比较推荐的一种方案。
- 采集的数据可以对接ElasticSearch来做实时的查询检索。
- 数据的可视化可以使用grafana、kibana等常用的可视化组件。
以我们目前的日志要求以及量级，以上方案就足够了，至于定制化的数据清洗，实时或者离线的数据分析，这些作为后续扩展的储备。
在 Kubernetes 中，日志采集相比传统虚拟机、物理机方式要复杂很多，最根本的原因是 Kubernetes 把底层异常屏蔽，提供更加细粒度的资源调度，向上提供稳定、动态的环境。因此日志采集面对的是更加丰富、动态的环境，需要考虑的点也更加的多。
- 日志的形式变得更加复杂，不仅有物理机/虚拟机上的日志，还有容器的标准输出、容器内的文件、容器事件、Kubernetes 事件等等信息需要采集。
- 环境的动态性变强，在 Kubernetes 中，机器的宕机、下线、上线、Pod销毁、扩容/缩容等都是常态，这种情况下日志的存在是瞬时的（例如如果 Pod 销毁后该 Pod 日志就不可见了），所以日志数据必须实时采集到服务端。同时还需要保证日志的采集能够适应这种动态性极强的场景；
- 日志的种类变多，一个请求从客户端需要经过 CDN、Ingress、Service Mesh、Pod 等多个组件，涉及多种基础设施，其中的日志种类增加了很多，例如 K8s 各种系统组件日志、审计日志、ServiceMesh 日志、Ingress 等；
日志的采集方式主要分为主动和被动，主动推送包括业务直写和DockerEngine 推送两种方式，前者在应用中集成日志sdk，和应用强绑定，后者太依赖容器运行时，灵活性也不够，这里都不做考虑。
至于被动方式，主要依靠在节点上运行日志Agent，通过轮训方式（阿里的logtail貌似是事件通知方式）采集节点日志。在Kubernetes环境下，也有两种方式：
- DaemonSet 方式在每个 node 节点上只运行一个日志 agent，采集这个节点上所有的日志。DaemonSet 相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或业务不是很多的集群；
- Sidecar 方式为每个 POD 单独部署日志 agent，这个 agent 只负责一个业务应用的日志采集。Sidecar 相对资源占用较多，但灵活性以及多租户隔离性较强，建议大型的 K8s 集群或作为 PaaS 平台为多个业务方服务的集群使用该方式。
网上找的一个对比表格，在这贴一下：
| 低，只需维护好配置文件即可 | 较高，每个需要采集日志的POD都需要部署sidecar容器 | ||
| 一般，可通过容器/路径等映射 | 每个POD可单独配置，灵活性高 | ||
| 弱，日志直写会和业务逻辑竞争资源 | 一般，只能通过配置间隔离 | 强，通过容器进行隔离，可单独分配资源 | |
| 本地存储无限制，若使用syslog、fluentd会有单点限制 | |||
| 整体最低，省去采集开销 | 较低，每个节点运行一个容器 | 较高，每个POD运行一个容器 | |
| 低，只能grep原始日志 | 高，可根据业务特点进行定制 | 较高，可进行自定义的查询、统计 | 高，可根据业务特点进行定制 |
| 高，每个POD单独配置 | |||
| 高，采集模块修改/升级需要重新发布业务 | 低，Agent可独立升级 | 一般，默认采集Agent升级对应Sidecar业务也会重启（有一些扩展包可以支持Sidecar热升级） | |
| 测试、POC等非生产场景 | 日志分类明确、功能较单一的集群 | 大型、混合型、PAAS型集群 |
通过对比后，DaemonSet方式最适合目前的情况。
规则进行处理；日志打印到文件的方式和虚拟机/物理机基本类似，只是日志可以使用不同的存储方式，例如默认存储、EmptyDir、HostVolume、NFS 等。
- 文件方式性能会更好一点，因为Stdout方式中间会经过好几个流程。
- 文件方式不同的日志可以放入不同的文件，在采集和分析过程中达到了分类的效果；而Stdout方式输出都在一个流中。
- 操作文件的策略会更加多样化，例如同步/异步写入、缓存大小、文件轮转策略、压缩策略、清除策略等，相对更加灵活。
所以在搭建基础平台时我会先使用stdout方式，文件方式更多会依赖日志体系的具体规则。
- Fluentd 利用 Exception Plugin 检测日志是否为容器抛出的异常日志，如果是就将异常栈的多行日志合并。
- ElasticSearch 建立对应索引，持久化日志信息。
关于ECK（）官方是这么说明的：
简而言之就是官方提供的一种新的基于Kubernetes的简便的部署Elasticsearch的方式。ECK方式安装的架构图如下：
在安装Elasticsearch之前，是需要扯一下存储问题的，由于Elasticsearch需要存储日志数据，所以它并不是一个无状态应用，需要为它准备相应的持久化存储，我们并没有云存储或者nfs，还好Kubernetes提供了Local PV的概念基于本地磁盘来提供持久化存储。但是目前还是有一些局限性：
fluentd配置资源文件如下
这里要说一个问题，如果你的Docker地址在各个节点上都一致，请略过；如果不一致，请看过来
比如我这里因为磁盘挂的目录不一致，所有docker目录也不一致，这个有个问题：
会发现日志文件最终链接的还是Docker下的日志文件，所以如果Docker的目录不是/var/lib/docker，需要调整上述配置，否则会出现采集不到日志的情况
若各节点Docker地址不相同，全部挂载
其他的配置项可以根据自己的需要修改，提交资源文件
Kibana默认用户名是elastic，密钥需要通过以下命令获得：
至此部署过程结束了，至于使用过程，我觉得还是需要结合日志规则再详细说一说，此篇就此结束。
