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

简介

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

容器监控的难点

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

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

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

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

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

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

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

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

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

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

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

老集群升级

阿里云容器服务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

        

          
        
        
        

          

          AI 代码解读
        
      
      

根据自己集群替换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

        

          
        
        
        

          

          AI 代码解读
        
      
      

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