简介
监控是运维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根据自己集群替换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。
