阿里云容器Kubernetes监控(一) - 资源监控

摘要：容器经过集装箱式的编译、打包、部署，大大提升了应用的迭代速度。对于架构师而言，容器带来的是分钟级的部署、秒级的伸缩与恢复、一个量级的迭代速度提高、50%左右的基础成本节省。

 

简介

 

容器经过集装箱式的编译、打包、部署，大大提升了应用的迭代速度。对于架构师而言，容器带来的是分钟级的部署、秒级的伸缩与恢复、一个量级的迭代速度提高、50%左右的基础成本节省。可是对于落地实施容器的开发者而言。80%的工做处理的是容器前和容器后的问题，容器前指的是如何本地开发、集成、测试并部署到容器环境；而容器后指的是如何对部署到容器环境后的监控、运维、告警与调优。今天咱们主要来探讨的是如何在容器的环境中进行资源维度的监控。

 

先谈容器与监控

 

关于容器的监控方案有很是多的种类，你们耳熟能详的一些组件包括：prometheus、Telegraf、InfluxDB、Cadvisor、Heapster等等。可是从原理上来说无外乎分为推模式采集与拉模式采集。推模式采集是指经过部署相应的agent，将监控的指标推送到server再进行数据聚合和报警的方式，例如Telegraf就是这种模式的表明。拉模式采集是指经过中心化的server使用API或者脚本等方式从容器直接拉取资源利用率的方式，而prometheus则是这种方式的集大成者。和传统应用监控相比，容器监控面临更大的挑战：首先因为容器更多的是在资源池中调度，传统的静态配置化的监控agent就变得很是麻烦，若是只在宿主机部署监控agent则会形成缺少必要信息来识别监控对象；其次容器的生命周期与传统应用相比而言会更加短暂，而由容器抽象的上层概念例如swarm mode中的service或者kubernetes中的ReplicaSet、Deployment等等则没有太好的办法从采集的数据中进行反向的抽象，形成单纯的容器监控数据没法有效的进行监控数据的聚合和告警，一旦应用的发布可能会致使原有的监控与报警规则没法生效；最后容器的监控须要更多的维度，资源维度、逻辑资源的维度、应用的维度等等。

 

如何在容器服务上进行资源监控

 

其实容器之因此难以监控的主要缘由在于没法将逻辑的概念和物理概念没法在监控数据、生命周期上面实现统一。阿里云容器服务Kubernetes与云监控进行了深度集成，用应用分组来抽象逻辑概念，今天咱们来看下如何进行Kuberbetes的资源监控和告警。

 

首先Kubernetes节点从职能上分为Worker和Master两种不一样的节点。Master节点上面一般会部署管控类型的应用，总体的资源要求以强鲁棒性为主；而Worker节点更多的承担实际的Pod调度，总体的资源以调度能力为主。当你建立一个Kubernetes集群时，容器服务会为你自动建立两个资源分组，一个是Master组，一个是Worker组。Master组中包含了Master节点以及与其相关的负载均衡器。Worker组包含了全部的工做节点。

 

 

能够经过点击列表视图显示当前资源分组中的资源，例如本例中Master分组包含了三个Master节点以及2个SLB。另外任何在资源组下的资源的报警规则都会被自动继承，所以在拓扑总览页面便可看到全部资源的健康状态。

 

 

在监控视图中能够详细的在组级别以及实例级别查看详细的监控数据

 

 

对于Mater节点而言，其上运行的各类组件的健康状态是更加剧要的，所以在Master分组中设置了全部节点的核心组件的健康检查，健康检查状态出现问题时便可经过钉钉、邮件、短信的方式在第一件获取到Kubernetes的集群状态。

 

 

对于版本在1.8.4及以上的老集群而言，能够经过升级监控服务的方式快速创建资源报警分组。对于资源组中的资源能够经过新建报警规则的方式设置自定义的报警，而报警规则会自动应用到资源组中，且在集群自动伸缩等场景也会自动添加。

 

 

最后

 

本片文章咱们讲解了如何如何经过资源分组进行监控与告警，针对kubernetes的pod、service的监控也即将在4月份进行发布，尽请期待。

 

原文连接

阅读更多干货好文，请关注扫描如下二维码：