将Rancher Catalog的Prometheus模板从Cattle环境转换到Kubernetes环境

Prometheus是现代广泛使用的监控警报系统，它诞生于SoundCloud，最终在2012年实现开源。它能够很好地处理多维时序数据，并且InfinityWorks上的开发者已经开发出了Rancher模板，凭此你只需点击按钮，就能够部署Prometheus了。

在混合云环境中，用户很有可能会使用多个编排引擎，比如Kubernetes和Mesos，在这种情况下，让stack或者应用在各环境中具有可移动性会大有用处。在这个简短的教程中，我们将把Prometheus的模板从Cattle格式转变成能在Kubernetes环境中使用的格式。并且我们假设读者已经对Kubernetes的概念有了基本的了解，比如pods、replication controller (RC)、services等，如果你需要学习这些基本概念，那么Kubernetes 101和 concept guide 会是个很好的起点。

Prometheus Cattle 模板组件

如果你看过最新版的Prometheus模板，你会注意到以下文件：

• docker-compose.yml – 以docker compose格式来定义容器
• rancher-compose.yml – 添加额外的Rancher功能来管理容器的生命周期

以下是各个组件作用的概览：

• Prometheus：核心组件，收集并存储数据
• Prometheus node exporter：获取主机级别的标量信息，并将标量信息暴露给Prometheus
• Ranch-eye：一个haproxy，可将cAdvisor的数据暴露给Prometheus
• Grafana:实现数据可视化
• InfluxDB:时序数据库，该数据库特别用于存储来自于Rancher服务器的数据，数据可通过Graphite connector 进行导出
• Prom-ranch-exporter：一个简单的node.js应用，能够向rancher服务器查询stack或服务的状态

你可能也注意到了，模板使用两种数据容器：prom-conf和graf-db， 他们分别包含了配置和数据，并将配置和数据作为卷提供给各自的应用容器。一些额外的功能，比如缩放、健康检查和更新策略等，都定义在rancher-compose.yml文件中。

设计Kubernetes模板

我们要为每一个使用了replication controllers的组件定义一个Pod，并使用Kubernetes的服务对象来暴露这些pod。让我们从Prometheus服务开始：

apiVersion: v1
 kind: Service
 metadata:
 name: prometheus
 namespace: "default"
 spec:
 type: NodePort
 ports:
 - name: "prometheus"
 port: 9090
 protocol: TCP
 selector:
 name: prometheus

我们定义了一项服务并暴露9090端口，通过它们，我们就可以构造其他组件。在最后面，将selector设置为Prometheus，这使得服务会选取带有Prometheus标签的pod。

数据容器和卷

现在让我们为Prometheus创建replication controller。或许你已注意到了，此处我们需要处理两个容器，其一是应用容器，另一个是用于Prometheus配置文件的数据容器。然而，Prometheus不支持数据容器（详见此处），Docker也是如此。

我们如何解决这个问题呢？Kubernetes有不同类型的卷，要解决我们的问题，可以选择EBS
(Kubernetes的awsElasticBlockStore)或者Google Cloud disk (Kubernetes的gcePersistentDisk 类型)，并将他们动态地映射到Prometheus pod上。就本文而言，假设我们在既没有使用公共云提供商也没有云盘的情况下要实现上述的操作，我们有两种选择：

• hostPath：通过把hostPath映射到容器路径上，可以从hostPath中获取数据。但是，如果在重启期间pod移动到另一个节点上而且主机没有可用的hostPath文件时，就会引发问题。另外，当容器移动到另一个节点上时，需要将hostPath里的文件清理掉。所以该选择虽看似可行，却在设计上存在缺陷。我们来看另一个选择。
• gitRepo：这是另一种Kubernetes所支持的卷。你只须将Git repo作为一个容器的卷进行映射，那么这个容器将会在运行前获取该卷：

volumes:
 - name: git-volume
 gitRepo:
 repository: "git@somewhere:me/my-git-repository.git"
 revision: "22f1d8406d464b0c0874075539c1f2e96c253775"

Kubernetes环境下的Rancher尚未支持 gitRepo（详见此处）。让我们继续，在不使用gitRepo的情况下完成下面的任务。我们要为Prometheus 和 Grafana容器搭建镜像（因为Grafana也需要数据容器）。我们将简单地拓展官方镜像，并向镜像本身添加额外的文件。当环境支持gitRepo时，我们只须切换到官方的Docker镜像并使用gitRepo即可。Prometheus的Dockerfile示例如下：

FROM prom/prometheus:0.18.0
 ADD prometheus.yml /etc/prometheus/prometheus.yml
 ENTRYPOINT [ "/bin/prometheus" ]
 CMD [ "-config.file=/etc/prometheus/prometheus.yml", \
 "-storage.local.path=/prometheus", \
 "-web.console.libraries=/etc/prometheus/console_libraries", \
 "-web.console.templates=/etc/prometheus/consoles" ]

Prometheus镜像和Grafana镜像都可以在Docker Hub上找到。

回到 Kubernetes模板

通过使用模板，我们最终的Prometheus replication controller 如下所示：

apiVersion: v1
 kind: ReplicationController
 metadata:
 name: prometheus-rc
 namespace: default
 spec:
 replicas: 1
 selector:
 template:
 metadata:
 labels:
 name: prometheus
 spec:
 restartPolicy: Always
 containers:
 - image: infracloud/prometheus
 command:
 - /bin/prometheus
 --alertmanager.url=http://alertmanager:9093
 --config.file=/etc/prometheus/prometheus.yml
 --storage.local.path=/prometheus -web.console.libraries=/etc/prometheus/console_libraries
 --web.console.templates=/etc/prometheus/consoles
 imagePullPolicy: Always
 name: prometheus
 ports:
 - containerPort: 9090

你可以在GitHub repo上查看关于其他服务和replication controller的定义。

神奇的标签

若仔细观察，你会注意到Prometheus-rancher-exporter的Cattle模板使用了Rancher标签：

prometheus-rancher-exporter:
 tty: true
 labels:
 io.rancher.container.create_agent: true
 io.rancher.container.agent.role: environment

标签会创建临时的Rancher API key并将环境变量公开给容器。在使用Kubernetes模板时，CATTLE_URL、CATTLE_ACCESS_KEY 和 CATTLE_SECRET_KEY都能作为配置选项。要获取API keys，请点击Rancher UI页面最右边的“API”选项卡，直接复制列出的Endpoint URL，它会随着环境的不同而改变。同时，应创建一个API key ，然后复制access key 和 secret key。当你启动catalog时，你必须要用到这些key，截图如下：

如果你已经将repo添加至你的目录，你就可以点击“Launch”按钮，稍等片刻后就能为你创建集群了。

现在让我们使用Grafana UI并查看它的数据，它能测试什么在运行或什么已损坏。
Grafana有5个dashboard，你会看到到Rancher Stats还没有显示任何数据：

Kubernetes Network 和 Graphite Port

此处有个问题。Rancher Statistics 仪表板从InfluxDB获取数据，而InfluxDB通过Graphite connector从Rancher server得到数据。因为Kubernetes集群会创建属于它自己的网络并为容器动态地分配IP和端口，且该网络与Rancher所在网络不同。我们必须在Prometheus群集启用后去配置该网络。InfluxDB运行在私有网络中，但它将端口作为NodePort类型在主机网络上进行开放。

spec:
 type: NodePort
 ports:
 - port: 2003
 protocol: TCP
 name: idb-4

你可以点击“Service: InfluxDB”并切换到“Ports”选项卡进行查看。本质上，我们要配置主机的 IP 和开放端口以使Rancher 服务器能与InfluxDB graphite connector对话。

访问http://:8080/v1/settings/graphite.host，点击右上角的edit按钮。页面会给你一个值域，此时输入正运行着InfluxDB 容器的主机IP后发送请求。如果你刷新上面的URL你会看到新的IP。现在前往KUBERNETES控制台中的“Services”，点击“InfluxDB service”查找对应2003的主机端口号(本例中对应端口号为32435)，在http://:8080/v1/settings/graphite.port中替换相应的端口号。

须重启Rancher-server容器使以上设置生效。一旦完成，当你查询InfluxDB UI时你就能在Grafana UI中看到数据了：

总结

本文中，我们看到了如何将Prometheus模板从Cattle格式转换为 Kubernetes 格式。在Kubernetes中，数据卷的网络模型、容器和语义都与在Docker中的不一样。因此，当转换原生Docker格式的Cattle模板时，我们需要应用这些 Kubernetes 语义并且重新设计模板。