阿里云容器Kubernetes监控(三) - 与云监控的集成与使用-阿里云开发者社区

开发者社区> 阿里云容器服务 ACK> 正文

阿里云容器Kubernetes监控(三) - 与云监控的集成与使用

简介: 简介 监控是运维Kubernetes中非常重要的一环,在kubernetes的生态内,有非常多可选的方案,场景的方案包括内置的Heapster、CNCF的亲儿子Prometheus、Influxdb的采集方案Telegraf等等,当然传统的监控运维工具例如zabbix也对容器的场景进行了适配。

简介

监控是运维Kubernetes中非常重要的一环,在kubernetes的生态内,有非常多可选的方案,常见的方案包括Kubernetes内置的Heapster、CNCF的亲儿子Prometheus、Influxdb的采集方案Telegraf等等,当然传统的监控运维工具例如zabbix也对容器的场景进行了适配。这些方案的实现方式各有不同,有的是采用agent的推模式推送数据,有的是通过集中式的拉模式来采集数据,那么究竟该怎么选择适合自己的监控方案呢?这个问题要从容器监控的难点开始讲起。

容器监控的难点

传统的监控方案,大部分是自顶向下的,配置一个监控的任务、采集端点,然后应用的生命周期与监控的任务生命周期是一致的,采集的目标是固定的。无论应用如何重启、变化,对于采集任务而言只要采集端点没有变化,那么任何的变化都是生命周期中的正常现象。

但是容器的场景则有所不同,大部分容器是被调度器进行调度的,也就是说是在一个资源池中随机调度的,监控系统通常无法感知采集端点的具体位置。因此大部分的监控采用的是自底向上的聚合方式,这种方式的原理就是:通过给容器打标,将一些原本在配置任务时候设定的信息,通过label打标到容器上。然后在聚合的时候从容器的信息,反向聚合出应用的监控。
但是自底向上的聚合方式有一个严重的缺陷,从生命周期上来看,因为监控的生命周期是来自监控数据的,因此一旦监控数据缺失,就会导致上层的监控生命周期收到影响,也就是说无法判断此时应用的生命周期状态。为了解决这个问题,大部分的采集系统会通过额外的label来实现,但是每一个metric都会打上这样的Label使得监控的数据会有大量的冗余信息。

阿里云容器服务Kubernetes与云监控集成

与云监控的集成是通过应用分组进行实现的,与传统的Pod监控不同,阿里云容器服务Kubernetes支持Kubernetes的逻辑概念的监控,例如Deployment、DaemonSet、StatefulSet的监控。对于1.10.4的版本的集群,默认在创建的时候就安装完毕。

所有的部署都会自动创建应用分组,可以通过控制台的部署页面找到对应的部署监控入口。

%E7%B2%98%E8%B4%B4%E5%9B%BE%E7%89%87.png

更多类型的workloads监控可以通过k8s原生的Dashboard进入。

lALPBY0V44Pj9qbNAzfNBTk_1337_823.png_620

点击 监控 可以进入到对应的监控分组中。

lALPBY0V44PhvG3NAzfNBTk_1337_823.png_620

在本例中是一个Deployment,并且此Deployment下包含一个Pod,监控包含两个维度,一个是分组维度,一个是实例维度。

lALPBY0V44Pit7jNAzfNBTk_1337_823.png_620

分组会聚合当前所有实例的指标,假如当前Deployment下有多个Pod,那么此时分组的数据指标就是聚合多个Pod的监控指标。

lALPBY0V44PiuIrNAzfNBTk_1337_823.png_620

如果需要查看特定的Pod的监控,可以分组实例来去查看,选择Pod名称,点击确认即可。

lALPBY0V44PiuujNAzfNBTk_1337_823.png_620
您也可以给当前的监控分组设置报警规则,实现应用的告警。

老集群升级

阿里云容器服务Kubernetes目前已完成与云监控的集成,目前1.10.4版本的集群已经默认支持,老集群可以通过如下的方式进行升级。

根据自己的集群替换REGION与CLUSTER_ID,并重新部署Heapster的yaml

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: heapster
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: heapster
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      serviceAccount: admin
      containers:
      - name: heapster
        image: registry.##REGION##.aliyuncs.com/acs/heapster-amd64:v1.5.1.1
        imagePullPolicy: IfNotPresent
        command:
        - /heapster
        - --source=kubernetes:https://kubernetes.default
        - --historical-source=influxdb:http://monitoring-influxdb:8086
        - --sink=influxdb:http://monitoring-influxdb:8086
        - --sink=socket:tcp://monitor.csk.##REGION##.aliyuncs.com:8093?clusterId=##CLUSTER_ID##&public=true

根据自己集群替换REGION与CLUSTER_ID,并部署alicloud-monitor-controller

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: alicloud-monitor-controller
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: alicloud-monitor-controller
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      hostNetwork: true
      tolerations:
      - effect: NoSchedule
        operator: Exists
        key: node-role.kubernetes.io/master
      - effect: NoSchedule
        operator: Exists
        key: node.cloudprovider.kubernetes.io/uninitialized
      serviceAccount: admin
      containers:
      - name: alicloud-monitor-controller
        image: registry.##REGION##.aliyuncs.com/acs/alicloud-monitor-controller:v1.0.0
        imagePullPolicy: IfNotPresent
        command:
        - /alicloud-monitor-controller
        - agent
        - --regionId=##REGION##
        - --clusterId=##CLUSTER_ID##
        - --logtostderr
        - --v=4

在kube-system命名空间中看到这两个Deployment已经运行中即升级完毕。对于不清楚自己REGION信息的开发者,可以通过如下的方式快速查询,打开ECS控制台,选择自己集群所在的地域,路由中最后一段即是REGION。
lALPBY0V44PzJ9vNAzfNBTk_1337_823.png_620

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云容器服务 ACK
使用钉钉扫一扫加入圈子
+ 订阅

云端最佳容器应用运行环境,安全、稳定、极致弹性

官方博客
官网链接