关于k8s:极客星球数据智能公司K8S生产环境落地之日志篇

91次阅读

共计 1940 个字符,预计需要花费 5 分钟才能阅读完成。

前言

公司在经验 2019-2020 年的疾速倒退后,业务的高速成长给运维基建带来了微小挑战,业务个性转变为大流量、高并发(千万级)。为保障业务稳固和平安,运维团队在架构上做了重大调整,从传统架构逐步演化成混合云架构,同时实现业务异地容灾、容器化、跨机房调度等。公司从 2020 年开始布局容器,到当初已落地 150 个我的项目,过程中遇到蕴含日志、监控、网络、CI/CD 等版块问题,本篇文章将重点围绕日志版块进行具体论述。

一、背景

每家公司在成长的过程中或多或少都会存在一些历史遗留问题,如:

  • 业务资源使用率偏低
  • 公司每季度服务器资源投入老本微小
  • 业务突发资源扩缩容操作工夫过长
  • 以后 Kvm 虚拟化实现自动化整合难度大

二、抉择 K8S 的起因

容器化编排有 K8S、Swarm、Mesos,近年 K8S 成为支流趋势,Swarm 和 Mesos 曾经逐步小众化,因而咱们抉择了 K8S 作为编排。其领有以下长处,如:

  • 弹性伸缩具备应突发、省老本、自动化的业务价值
  • 平台侧将各业务零散、闲置资源进行整合,造成一个大规模资源池,通过 K8S 弹性调度、库存管控技术在公司经营老本和业务体感中寻求较好的均衡
  • api 接口丰盛,易于融入自动化运维体系

三、挑战难题之日志篇

日志宏大,Pod 适应于无状态的,而业务重日志是有状态的,如何保障数十 T 级别的日志平安稳固,运维团队面临着十分艰巨的挑战。
日志大体上划分为三类:

  • 业务日志,数十 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 举荐在超大型的集群中应用

具体的各种采集形式比照如下:

五、解决方案

1. 业务日志选型:

为尽量减少业务开发的革新老本,容器化须要尽快推广,并抉择 sidecar 形式对业务日志进行采集,链路图如下:

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

装置日志采集 agent 的 yaml 配置,采集蕴含容器 namespace、pod ip、nodename 等,辨别不同容器集群和不同环境。

2. 归档日志 & 数仓日志

归档日记和入数仓日志是咱们的外围数据,不仅须要很强的性能要求,而且日志的稳固和平安也很重要,开源的组件无奈满足需要,自研日志网关解决。

历史归档日志几十 P 甚至数百 P 时,在浩瀚的归档日志中查找到咱们须要的一小段日志是一件很艰巨的事,设计分布式集群日志网关,解决了诸多痛点:
日志网关从多个维度记录了归档日志的索引信息,归档日志规范化,极大得升高了运维和业务对归档日志的时效性
归档机存储主动平衡,解放了归档机存贮存满时运维手动迁徙数据时候的繁琐,缩小人力老本
通过可视化平台融入自动化体系,对归档日志的查看和下载进行审计,安全性失去保障

六、总结

在 K8S 落地后,公司已上线的业务线资源均匀使用率由历史的 10% 进步至 40%,帮忙公司极大升高了服务器资源老本。但团队在落地和推广的过程中依然存在很多问题还没有解决,如:

  • 容器外部无奈看到调配的内存和 cpu 核数
  • 容器的 IOPS 和 IO Buffer 的限度
  • 通容器平安隔离防护
  • 业务线老本资源和容器集群绑定
  • ….

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

正文完
 0