vlambda博客
学习文章列表

前言

一、背景

• 业务资源使用率偏低

• 公司每季度服务器资源投入成本巨大

• 业务突发资源扩缩容操作时间过长

• 当前Kvm虚拟化实现自动化整合难度大

• 弹性伸缩具有应突发、省成本、自动化的业务价值

• 平台侧将各业务零散、闲置资源进行整合，形成一个大规模资源池，通过K8S弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡

• api接口丰富，易于融入自动化运维体系

• 业务日志，数十T/日级别

• 归档日志，数十T/日级别

• 入数仓日志，数十T/日级别

四、日志调研

日志的采集方式分为被动采集和主动推送两种，在 K8S 中，被动采集一般分为 Sidecar 和 DaemonSet 两种方式，主动推送分为 DockerEngine 推送和业务直写两种方式： 

• DockerEngine本身具有 LogDriver 功能，可通过配置不同的 LogDriver 将容器的 stdout 通过 DockerEngine 写入到远端存储，以此达到日志采集的目的。这种方式的可定制化、灵活性、资源隔离性都很低，一般不建议在生产环境中使用

• DaemonSet方式在每个 node 节点上只运行一个日志 agent，采集这个节点上所有的日志。DaemonSet 相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或业务不是很多的集群

• 业务直写是在应用中集成日志采集的 SDK，通过 SDK 直接将日志发送到服务端。这种方式省去了落盘采集的逻辑，也不需要额外部署 Agent，对于系统的资源消耗最低，但由于业务和日志 SDK强绑定，整体灵活性很低，一般只有日志量极大的场景中使用

• Sidecar方式为每个POD单独部署日志 agent，这个 agent 只负责一个业务应用的日志采集。Sidecar 相对资源占用较多，但灵活性以及多租户隔离性较强，建议大型的 K8S 集群或作为 PaaS 平台为多个业务方服务的集群使用该方式

• DockerEngine 直写一般不推荐

• 业务直写推荐在日志量极大的场景中使用

• DaemonSet 一般在中小型集群中使用

• Sidecar 推荐在超大型的集群中使用

为尽量减少业务开发的改造成本，容器化需要尽快推广，并选择sidecar方式对业务日志进行采集，链路图如下：

整个架构的数据流承载每秒200万条数据，logstash集群自动按日期切割索引，再通过生命周期管理自动清理过期日志。

安装日志采集agent的yaml配置，采集包含容器namespace、pod ip、nodename等，区分不同容器集群和不同环境。

 2.归档日志&数仓日志

归档日记和入数仓日志是我们的核心数据，不仅需要很强的性能要求，而且日志的稳定和安全也很重要，开源的组件无法满足需求，自研日志网关解决。

历史归档日志几十P甚至数百P时，在浩瀚的归档日志中查找到我们需要的一小段日志是一件很艰难的事，设计分布式集群日志网关，解决了诸多痛点：

• 日志网关从多个维度记录了归档日志的索引信息，归档日志规范化，极大得降低了运维和业务对归档日志的时效性

• 归档机存储自动均衡，解放了归档机存储存满时运维手动迁移数据时候的繁琐，减少人力成本

• 通过可视化平台融入自动化体系，对归档日志的查看和下载进行审计，安全性得到保障

  
  

六、总结

在K8S落地后，公司已上线的业务线资源平均使用率由历史的10%提高至40%，帮助公司极大降低了服务器资源成本。但团队在落地和推广的过程中仍然存在很多问题还没有解决，如：

• 容器内部无法看到分配的内存和cpu核数

• 容器的IOPS和IO Buffer的限制

• 通容器安全隔离防护

• 业务线成本资源和容器集群绑定

• ....

未来，运维团队将继续攻克K8S生产环境落地所面临的多重挑战及难题，后续将分别就“监控”、“网络”、“CI/CD”等话题持续分享， 敬请期待。