万网站长工具,郑州seo哪家公司最强,show t团队网站艰涩,实体店怎么引流推广戳蓝字“CSDN云计算”关注我们哦#xff01;转自#xff1a;小米云技术作者#xff1a;郭如意本文介绍了高可用、持久存储、可动态调整的Kubernetes监控方案的实现过程。小米的弹性调度平台#xff08;Ocean#xff09;以及容器平台主要基于开源容器自动化管理平台kuberne… 戳蓝字“CSDN云计算”关注我们哦转自小米云技术作者郭如意本文介绍了高可用、持久存储、可动态调整的Kubernetes监控方案的实现过程。小米的弹性调度平台Ocean以及容器平台主要基于开源容器自动化管理平台kubernetes简称k8s来提供服务完善的监控系统提高容器服务的质量的前提。不同于传统物理主机每个容器相当于一个主机导致一台物理主机上的系统指标数量成本增长总的监控指标规模相当庞大经线上统计每node指标达到10000。此外为了避免重复造轮需要最大限度的利用公司的监控报警系统需要把k8s的监控和报警融入其中。在小米现有的基础设施之上落地该监控是一个不小的挑战。1当监控遇上K8S为了更方便的管理容器k8s对container进行了封装拥有了Pod、Deployment、Namespace、Service等众多概念。与传统集群相比k8s集群监控更加复杂1监控维度更多除了传统物理集群的监控还包括核心服务监控apiserver, etcd等、容器监控、Pod监控、Namespace监控等。2监控对象动态可变在集群中容器的销毁创建十分频繁无法提前预置。3监控指标随着容器规模爆炸式增长如何处理及展示大量监控数据。4随着集群动态增长监控系统必须具备动态扩缩的能力。除了k8s集群监控本身的特性外具体监控方案的实现要考虑公司内部的实际情况1目前弹性调度计算平台提供的k8s集群包括融合云容器集群、部分Ocean集群以及CloudML集群拥有十余个集群1000机器。不同k8s集群的部署方式网络模式存储方式等不尽相同监控方案需要兼顾各种差异。2Open-Falcon是公司内通用的监控报警系统有完善的数据收集展示和报警机制但是Open-Falcon并不支持k8s这种拉的采集方案。此外k8s里的各种资源有天然的层次关系这就决定了监控数据的整合需要强大而灵活的聚合能力Falcon在这些方面不太能满足需求。但我们并不想重复造轮子需要最大限度利用公司既有基础设施从而节约开发和运维成本。3对于监控的持久化存储如何结合公司内的数据库实现监控数据的长期存储都是需要考虑的问题。现有业界针对k8s监控也有一些成熟的方案1Heapster/Metrics-Server InfluxDB GrafanaHeapster是k8s原生的集群监控方案现已废弃转向metrics-server从节点上的 cadvisor获取计算、存储、网络等监控数据然后将这些数据输出到外部存储(backend)如InfluxDB最后再通过相应的UI界面进行可视化展示如grafana。此方案部署简单但采集数据单一不合适k8s集群整体监控只适用于监控集群中各容器的资源信息如作为k8s dashboard的数据展示源。2ExporterPrometheusAdapterPrometheus 是一套开源的系统监控报警框架具有多维数据模型、灵活强大的查询语句、性能良好等特点。Prometheus可以通过各种exporter如node-exporter、kube-state-metrics、cadivsor等采集监控metrics监控数据此外Prometheus可以动态发现k8s集群中的podnode等对象。通过Prometheus采集各个维度的数据进行聚合并提供报警然后利用adapter可以将数据写到远程储存中如OpenTSDBInfluxDB 等实现持久化存储。但由于数据采集可能会有丢失所以 Prometheus 不适用于对采集数据要 100% 准确的情形例如实时监控等。2监控方案及演进初始方案前期为了尽快实现k8s的落地监控系统借助Falcon还有内部开发的exporter仅实现了对于核心监控数据的采集如Pod的cpu内存网络等资源使用情况具体架构如下图所示。通过实现cadvisor-exporter采集cadvisor的容器监控数据kube-state-exporter采集k8s关键Pod指标Falcon-agent采集物理节点数据。初始方案仅采集了核心监控数据初步实现对核心资源使用情况的监控缺乏更全面的数据监控例如apiserveretcd等。由于Falcon目前不支持对于容器的监控所以需要手动实现各种exporter来满足k8s的监控需求。而且监控数据没有实现持久化存储不支持长期查询。基于Prometheus的监控系统由于初始监控系统的不足经过调研对比最终选用Prometheus作为k8s的监控方案主要考虑一下几点原因1原生支持k8s监控具有k8s对象服务发现能力而且k8s的核心组件提供了Prometheus的采集接口2强大的性能单个Prometheus可以每秒抓取10万的metrics可以满足一定规模下k8s集群的监控需求3良好的查询能力Prometheus 提供有数据查询语言 PromQL。PromQL 提供了大量的数据计算函数大部分情况下用户都可以直接通过 PromQL 从 Prometheus 里查询到需要的聚合数据。基于Prometheus的k8s监控系统的架构如下图所示:数据源node-exporter采集物理节点指标kube-state-metrics采集k8s相关指标包括资源使用情况以及各种对象的状态信息cadvisor采集容器相关指标apiserver, etcd, scheduler, k8s-lvmgpu等核心组件的监控数据其他自定义metrics通过在pod yaml文件annotations添加 prometheus.io/scrape: true 可实现自动抓取提供的metrics。Prometheus数据处理模块Prometheus以Pod方式部署在k8s上Pod中含有Prometheus、Prom-Reloader。Prometheus负责采集聚合数据prom-config为监控的聚合规则与抓取配置以ConfigMap存储Prom-Reloader实现监控配置的热更新实时监控配置文件无需重启应用即可动态加载最新配置。存储后端Falcon与OpenTSDB。Open-Falcon是公司统一的监控报警系统提供了完善的数据采集、报警、展示、历史数据存储功能以及权限功能。由于Falcon设计较早没有对于容器相关指标提供监控而prometheus原生支持了k8s但是其报警功能只能静态配置且需要实现与公司相关账号打通以方便用户配置监控且有些k8s的指标需要暴露给容器用户。基于此考虑我们使用Falcon作为k8s监控的报警和对外展示平台。通过实现Falcon-Adapter将监控数据转发到Falcon以实现报警与展示。根据k8s服务对象将监控目标分为多个层次cluster, node, namespace, deployment, pod将关键报警指标通过Falcon-Agent打到Falcon用户可自行在配置报警查看指标。原生Prometheus的监控数据放在本地使用tsdb时区数据库默认保存15天数据。监控数据不止用于监控与报警后续的运营分析和精细化运维都需要以这些运营数据作为基础因此需要数据的持久化。在Prometheus社区中也提供了部分读写方案如Influxdb、Graphite、OpenTSDB等。而小米正好有OpenTSDB团队OpenTSDB将时序数据存储在HBase中我们公司的HBase也有稳定的团队支持。基于此通过OpenTSDB为监控数据提供远程存储。实现了OpenTSDB-Adapter将监控数据转发到时序数据库OpenTSDB以实现数据的持久存储满足长期查询以及后期数据分析的需要。部署方式系统监控的核心系统全部通过Deployment/Daemonset形式部署在k8s集群中以保证监控服务的可靠性。全部配置文件使用ConfigMap存储并实现了自动更新。存储方式Prometheus的存储包括本地存储与远程存储本地存储只保存短期内的监控数据按照两个小时为一个时间窗口将两小时内产生的数据存储在一个块(Block)中每一个块中包含该时间窗口内的所有样本数据(chunks)元数据文件(meta.json)以及索引文件(index)。由于各集群提供存储类型的不行目前已经实现多种存储方式的部署包括pvc、lvm、本地磁盘等。远程存储通过实现prometheus的远程读写接口实现对OpenTSDB的操作方便对于长期数据的查询。为了保持Prometheus的简单性Prometheus并没有尝试在自身中解决以上问题而是通过定义两个标准接口(remote_write/remote_read)让用户可以基于这两个接口对接将数据保存到任意第三方的存储服务中这种方式在Promthues中称为Remote Storage。如上图所示可以在Prometheus配置文件中指定Remote Write(远程写)的URL地址一旦设置了该配置项Prometheus将采集到的样本数据通过HTTP的形式发送给适配器(Adapter)。而用户则可以在适配器中对接外部任意的服务。外部服务可以是真正的存储系统公有云的存储服务也可以是消息队列等任意形式。同样地Promthues的Remote Read(远程读)也通过了一个适配器实现。在远程读的流程当中当用户发起查询请求后Promthues将向remote_read中配置的URL发起查询请求(matcherstime ranges)Adapter根据请求条件从第三方存储服务中获取响应的数据。同时将数据转换为Promthues的原始样本数据返回给Prometheus Server。当获取到样本数据后Promthues在本地使用PromQL对样本数据进行二次处理。启用远程读设置后只在数据查询时有效对于规则文件的处理以及Metadata API的处理都只基于Prometheus本地存储完成。远程存储现已支持公司内部的Falcon与OpenTSDB通过Falcon方便用户查看监控数据以及配置报警。写到OpenTSDB已实现持久化存储并且支持通过Prometheus对其进行远程读写。目前基于Prometheus的监控方案已在各集群部署但随着集群规模的增长逐渐暴露出一些问题。其一是随着容器增长监控指标激增对Falcon-agent与transfer造成一定压力致使经常造成Falcon-agent拥堵以及部分监控数据延迟、丢失等问题。在线上测试当通过单个Falcon-agent发送超过150000/m时经常性出现数据丢失现已关闭部分监控数据的发送。根本原因是prometheuse集中的数据聚合和推送把分散在各集群的指标汇聚到了一台主机从而带来了超常的压力。其二是在规模较大的集群Prometheus占用CPU与内存资源都较多(下表中为线上集群Prometheus的运行情况)偶尔会出现某些metrics抓取不到的情况随着集群规模的扩大单个Prometheus将会遇到性能瓶颈。分区监控方案针对单个Prometheus监控方案的不足需要对其进行扩展已满足大规模k8s集群监控并适配Falcon系统agent的性能。通过调研发现Prometheus支持集群联邦。这种分区的方式增加了Prometheus自身的可扩展性同时也可以分散对单个Falcon agent的压力。联邦功能是一个特殊的查询接口允许一个prometheus抓取另一个prometheus的metrics已实现分区的目的。如下所示常见分区两种方式其一是功能分区联邦集群的特性可以帮助用户根据不同的监控规模对Promthues部署架构进行调整可以在各个数据中心中部署多个Prometheus Server实例。每一个Prometheus Server实例只负责采集当前数据中心中的一部分任务(Job)例如可以将不同的监控任务分配到不同的Prometheus实例当中再由中心Prometheus实例进行聚合。其二是水平扩展极端情况下单个采集任务的Target数也变得非常巨大。这时简单通过联邦集群进行功能分区Prometheus Server也无法有效处理时。这种情况只能考虑继续在实例级别进行功能划分。将同一任务的不同实例的监控数据采集任务划分到不同的Prometheus实例。通过relabel设置我们可以确保当前Prometheus Server只收集当前采集任务的一部分实例的监控指标。针对k8s的实际情况分区方案架构如下Prometheus分区包括master Prometheus 与 slave Prometheus以及 kube state Prometheus:由于大量指标的采集来源于node上的服务如kubelet, node-exporter, cadvisor等是以node为单位采集的所以按照node节点来划分不同jobslave Prometheus 按照node切片采集nodepod级别数据kube-state-metrics暂时无法切片单独作为一个kube-state Prometheus供master Prometheus采集其他etcd, apiserver自定义指标等可通过master Prometheus直接采集。Prometheus master对于其他Prometheus slave的抓取可通过如下配置- job_name: federate-slave honor_labels: true metrics_path: /federate params: match[]: - {__name__~pod:.*|node:.*} kubernetes_sd_configs: - role: pod namespaces: names: - kube-system relabel_configs: - source_labels: - __meta_kubernetes_pod_label_app action: keep regex: prometheus-slave.*Prometheus slave的对于抓取任务的分区通过Prometheus提供的hashmod方法来实现- job_name: kubelet scheme: https kubernetes_sd_configs: - role: node namespaces: names: [] tls_config: insecure_skip_verify: true relabel_configs: - source_labels: [] regex: __meta_kubernetes_node_label_(.) replacement: $1 action: labelmap - source_labels: [__meta_kubernetes_node_label_kubernetes_io_hostname] modulus: ${modulus} target_label: __tmp_hash action: hashmod - source_labels: [__tmp_hash] regex: ${slaveId} action: keep部署方式master Prometheus 与 kube-state Prometheus通过deployment部署。slave Prometheus可有多个pod但由于每个pod的配置不同配置中的${slaveId}不同每个slave prometheus需要在配置中体现分区编号而原生的deployment/statefulset/daemonset都不支持同一Pod模板挂载不同的ConfigMap配置。为了方便管理Slave Prometheus通过statefulset来部署slave由于statefulset会将每个pod按顺利编号如slave-0slave-1等。通过Prom-Reloader获得到Pod名称持续监听Prometheus配置变化然后生成带有编号的配置以区分不同的分区模块。测试验证测试包括两方面一是针对分区后的监控方案进行功能测试是否符合预期二是对于其性能进行测试在功能测试中验证分区方案的聚合规则正常特别对于分区前后的数据进行校验通过对一周内的数据进行对比取一小时内平均的差值比率如下图经统计超过95%的时间序列对比误差在1%以内个别指标瞬时波动较大如网络使用率但随着时间增加会抵消差异。在性能测试中针对不同分区监控不同负载下进行测试验证其性能状况。在测试集群上创建1000个虚拟node创建不同数量pod测试Prometheus分区性能对于Prometheus master与Prometheus kube-state在1分钟抓取时间内最多可支持8w pod主要瓶颈在于kube-state-metrics随着pod增加数据量激增一次抓取耗时不断增长。对于Prometheus slave由于采集部分数据压力较小单个Prometheus可抓取超过400个节点60 pod/node。如下图所示在开启remote write后抓取时间不断增加后续将不断增加Remote-Storage-Adapter的性能。经过在k8s测试集群验证Prometheus分区监控架构最多支持8w的pod可以满足预期集群增长需求。3展望目前分区监控方案已在部分集群部署具有高可用、持久存储、可动态调整等特点。另外我们未来将持续改进实现监控的自动扩容针对kube-state-metrics的性能优化目前不支持分区在部署方式上借助prometheus-operator与helm等实现更简洁的配置管理与部署在监控数据的利用上可以应用特定算法对数据进行深度挖掘以提供有价值的信息如利用监控数据提供扩容预测寻找合适的扩容时机。通过不断优化以确保更好地为k8s提供稳定可靠智能的监控服务。福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读三十四载Windows崛起之路 苹果、可视做过微软“铺路石”面试官你简历中写用过docker能说说容器和镜像的区别吗2019年技术盘点容器篇二听腾讯云讲讲踏入成熟期的容器技术 | 程序员硬核评测C、Python、Rust、Scala构建编译器的差异性究竟有多大想换行做 5G 的开发者到底该咋办如何在标准的机器学习流程上玩出新花样独家 | Vitalik Buterin以太坊2.0之跨分片交易滴滴章文嵩不仅软件开源还向学界开放数据真香朕在看了
