本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前篇文章探讨了 Rancher 丛集的基本使用方式，包含透过取得 KUBECONFIG 以及使用 Rancher 提供的网页来观察与操作 Rancher 丛集。
除了基本丛集的状态显示外， Rancher 也有整合一些常用的应用程序到 Rancher 管理的丛集中，而其中有一个功能基本上是所有 Kubernetes 丛集都需要的功能，也就是 Monitoring。
Monitoring 可以使用的专案非常多，有免费开源也有付费服务，免费开源最知名的组合技大概就属 Prometheus + Grafana 两套功能。
Rancher 所提供的 Monitoring 功能就是基於 Prometheus + Grafana 来使用的，本篇文章就来介绍一下这个功能到底该怎麽使用。

Rancher

Rancher 从 v2.5 开始正式推行 Monitoring v2 的架构，并且淘汰过往的 Monitoring v1 的版本。
从使用者的角度来看，从 Cluster Manager 页面中透过 Monitoring 安装的都会是 Monitoring v1 的架构，而透过 Cluster Explorer 中 App & Marketplace 安装的 Monitoring 则会是 Monitoring v2 的架构。

探讨 Monitoring v1与v2 的差异前，先来了解一下 Rancher 希望提供什麽样的 Monitoring 功能给使用者。
从使用者角度出发来看，大部分人都会希望可以有下列的功能

1. 安装 Prometheus 到丛集中，能够有机会去听取所有资讯
2. 安装 Grafana 到丛集中，同时该 Grafana 能够跟 Prometheus 直接整合，能够透过 Grafana 去打造出一个适合团队用的监控面板
3. 能够使用 Alert 的相关功能，不论是由 Prometheus 或是 Grafana 提供的。
4. 对於使用者所部署的应用程序也能够整合到 Prometheus 中，一旦能够整合到 Prometheus，就有办法透过 Grafana 去处理。
5. 对於 Prometheus 与 Grafana，能够提供一个有效简单的方式去存取这两个服务的网页

上述五点的前两点比较偏向安装 Prometheus/Grafana 的问题，第三与第四点相对麻烦，毕竟使用者如果已经习惯 Prometheus/Grafana 本来的设定与玩法，这时候要是 Rancher 本身的介面弄得太复杂，可能会让使用者要重新学习如何修改，这点对使用者体验来说是一个很大的考量。
最後一点也是最麻烦的一点，因为 Rancher 所管理的 Kubernetes 丛集不一定都有对外 IP 可以被直接存取，同时每个环境也不一定有合法的 SSL 凭证可以让使用者以 HTTPS 的方式去存取这些网页。

但是对於使用者来说，如果安装完毕後还要去担心烦恼这些 IP, Domain Name, SSL 等相关问题，这样的使用者体验就不会太好，为了解决这个问题， Rancher 特别针对这一块进行了所谓的 Proxy 存取。
由於 Rancher 有办法跟管理的 Kubernetes 丛集沟通，而通常 Rancher 本身安装时都有准备好 HTTPS 与相关的 domain。所以使用方式就会变成，使用者存取 Rancher 本身， Rancher 作为一个 Proxy 帮忙转发所有跟 Prometheus/Grafana 网页有关的存取，让使用者可以更为轻松地去存取封闭式网路的 Monitoring 相关页面。
这部分之後的实验就可以更加清楚理解到底是什麽意思。

V1/V2

上述提到的五个概念中，v1 的版本会於 Rancher 中安装相关的 Controller，如果使用者想要自己的应用程序可以被 Prometheus 去抓资料的话，就要於自己的部署 YAML 中去撰写是先定义好的 Annotation，Controller 判别到有这个 Annotation 後就会将自动产生一个关於 Prometheus 的物件来提供此功能。

v1 的这种设计对於不熟悉 Prometheus 的使用者来说很便利，可以轻松地处理，但是其提供的变数过少，没有办法太有效的客制化，因此如果是熟悉 Prometheus 的使用者则会觉得绑手绑脚，没有办法发挥全部功能。
再来其实 Monitoring v1 底层也是基於 Prometheus Operator 这套框架去实作的，Rancher 基於这个框架再去实作一个 Controller 帮助使用者转换各种规则，这层规则对於已经习惯使用 Prometheus Operator 的使用者来说也是绑手绑脚，因为本来就很习惯直接操作 Prometheus Operator 的物件去操作。

因此 Monitoring v2 的最大进展就是， Rancher 将让 Prometheus Operator 尽可能地浮出来，减少 Rancher 的抽象层。使用者有任何的客制化需求都直接使用 Prometheus Operator 的方式去管理，譬如可以直接创造如 ServiceMonitor, PrometheusRule 等物件来管理丛集中的 Prometheus。

接下来我们就直接使用 DEV 丛集作为示范，如何安装 Monitoring v2，并且最後使用 https://github.com/bashofmann/rancher-2.5-monitoring 这个专案内的介绍来尝试部署应用程序以及相关的 Prometheus/Grafana 资讯到丛集中。

环境

前述提到，要安装 Monitoring v2 要切换到 Cluster Explorer 中的 App & Marketplace 去安装，切换到该页面找到相关的 App 就点选安装。
结果示范的丛集显示下列警告，告知丛集内可被预订的 CPU 数量低於需求，该 App 需要 4.5 颗 CPU而系统内不够

由於 DEV 丛集是透过 Azure 动态创建 VM 而搭建出来的丛集，所以切换到 Cluster Manager 去修改节点数量，将 worker 节点从一个增加到三个，如下

这边等待数分钟，让 Rancher 去处理 VM 的创建并且将这两个节点安装到 Rancher 中。一切准备後就绪後就可以回到 Cluster Explorer 去安装 Monitoring v2 整合功能。
安装完毕後，可以从左上方的清单中找到 Monitoring 的页面，点击进去会看到类似下面的画面。

该画面中呈现了五个不同的功能，熟悉 Prometheus Operator 功能的读者一定对这些名称不陌生，随便点选一个 Grafana 试试看。
点选 Grafana 後会得到一个新的页面，效果如下。

该画面呈现的是一个 Grafana 的资讯面板，值得注意的是其 URL 的组成。
前面是由 Rancher Server 本身的位置，後面紧接者该 DEV Cluster 於 Rancher 中的 ID，最後就是对应服务的 namespace 与 service。
透过这种方式使用者就可以继续使用 Rancher Server 的 HTTPS 与名称来顺利的存取不同丛集上的 Prometheus/Grafana 服务。
而这个服务实际上并不是全部都由 Rancher 所完成的，而是 Kubernetes API Server 本身就有提供这样的功能，详细的可以参阅官方的教学文件
Access Services Running on Clusters

预设情况下，该 Grafana 内会已经创造好非常多的 dashboard，譬如下图所示

除了 Grafana 之外， Prometheus 的相关网页也都有，譬如点选 Prometheus Targets 就可以看到如下的画面

此外当系统安装了 Monitoring 的整合功能後， Cluster Explorer 的首页也会自动地被加上相关监控资讯，如下所示

可以直接於首页观察到基本资讯的过往状态，这边提供的是非常基础的效能指标，如果想要看到详细的指标甚至是客制化，都还是要到 Grafana 的页面去存取。

实验

透过上述的介绍，基本上已经有一个简单的 Prometheus + Grafana 的 Monitoring 功能到目标丛集中，接下来要示范如何透过 https://github.com/bashofmann/rancher-2.5-monitoring 这个开源专案来帮我们自己的应用程序加上 Prometheus 与 Grafana 的设定，最重要的是这些设定都是由 YAML 去组成的，意味者这些设定都可以透过 Git 保存与控管，可以避免任何线上修改会因为重启而消失。

该专案的介面页面有提供非常清楚的使用流程，这边针对这些流程重新介绍

1. 安装一个示范的 Redis 应用程序
2. 帮该 Redis 应用程序安装一个 sidecar 服务，该服务有实作 Prometheus 介面，可以让 Prometheus 来抓不同的指标
3. 安装 ServiceMonitor 到丛集中，让 Prometheus Operator 知道要怎麽去跟(2)安装的服务去要 Redis 的资料
4. 安装一个事先准备好的 Grfana json 描述档案，能够让 Grafana 自动地去产生一个针对 Redis 的监控面板

第一点非常简单，就是基本的 Kubernetes 服务，这边就不探讨这个 Redis 应用程序到底如何组成，其安装指令也非常简单

$ kubectl -n default apply -f scrape-custom-service/01-demo-shop.yaml

安装完毕後可以透过下列指令打开 port-forward 并且於浏览器打开 http://localhost:8000

$ kubectl port-forward svc/frontend 8000:80

可以看到画面基本上就代表这个示范用的应用程序已经顺利安装完成。

接下来帮 Redis 安装一个 sidecar 的服务来提供 Prometheus 的介面

$ kubectl -n default apply -f scrape-custom-service/02-redis-prometheus-exporter.yaml

最後则是最重要的两点，这两点是最主要跟 Prometheus/Grafana 沟通用的物件。

╰─$ kubectl -n default apply -f scrape-custom-service/03-redis-servicemonitor.yaml
╰─$ cat scrape-custom-service/03-redis-servicemonitor.yaml                                                                                                             130 ↵
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: redis-cart
spec:
  endpoints:
    - interval: 30s
      scrapeTimeout: 20s
      path: "/metrics"
      targetPort: metrics
  namespaceSelector:
    matchNames:
      - default
  selector:
    matchLabels:
      app: redis-cart

ServiceMonitor 是 Prometheus Operator 中定义的物件，透过这个方式就可以让 Prometheus 帮忙产生对应的物件与自定义的应用程序沟通，接者就可以到 Prometheus 的网页中找到这个新增资讯，如下图。

有了上述资源後，我们就可以透过 Prometheus 去问到 Redis 的相关资讯，为了让这些资讯更方便处理，接下来部署 Grafana 的相关物件

╰─$ kubectl apply -f scrape-custom-service/04-redis-grafana-dashboard.yaml
╰─$ cat scrape-custom-service/04-redis-grafana-dashboard.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-redis-cart
  namespace: cattle-dashboards
  labels:
    grafana_dashboard: "1"
data:
  redis.json: |
    {
      "__inputs": [
      ],
      "__requires": [
        {
          "type": "grafana",
          "id": "grafana",
          "name": "Grafana",
          "version": "3.1.1"

熟悉 Grafana 的读者都知道，每个 Grafana 的 dashboard 都可以透过 JSON 物件来描述，所以要新增一个 Grafana dashboard 就是准备一个相对应的 json 物件，使用 configMap 来描述，将该物件给部署到 cattle-dashboards 的 namespace 内即可。

╰─$ kc -n cattle-dashboards get cm
NAME                                                   DATA   AGE
grafana-redis-cart                                     1      51m
kube-root-ca.crt                                       1      144m
rancher-default-dashboards-cluster                     2      144m
rancher-default-dashboards-home                        1      144m
rancher-default-dashboards-k8s                         4      144m
rancher-default-dashboards-nodes                       2      144m
rancher-default-dashboards-pods                        2      144m
rancher-default-dashboards-workloads                   2      144m
rancher-monitoring-apiserver                           1      144m
rancher-monitoring-cluster-total                       1      144m
rancher-monitoring-controller-manager                  1      144m
rancher-monitoring-etcd                                1      144m
rancher-monitoring-ingress-nginx                       2      144m
rancher-monitoring-k8s-coredns                         1      144m
rancher-monitoring-k8s-resources-cluster               1      144m
rancher-monitoring-k8s-resources-namespace             1      144m
rancher-monitoring-k8s-resources-node                  1      144m
rancher-monitoring-k8s-resources-pod                   1      144m
rancher-monitoring-k8s-resources-workload              1      144m
rancher-monitoring-k8s-resources-workloads-namespace   1      144m
rancher-monitoring-kubelet                             1      144m
rancher-monitoring-namespace-by-pod                    1      144m
rancher-monitoring-namespace-by-workload               1      144m
rancher-monitoring-node-cluster-rsrc-use               1      144m
rancher-monitoring-node-rsrc-use                       1      144m
rancher-monitoring-nodes                               1      144m
rancher-monitoring-persistentvolumesusage              1      144m
rancher-monitoring-pod-total                           1      144m
rancher-monitoring-prometheus                          1      144m
rancher-monitoring-proxy                               1      144m
rancher-monitoring-scheduler                           1      144m
rancher-monitoring-statefulset                         1      144m
rancher-monitoring-workload-total                      1      144m

事实上也可观察到该 namespace 内有满满的 configmap，而每个 configmap 内的内容都会对应到一个专属的 Grafana Dashboard，因此如果想要客制化 Grafana 的资讯，常见的做法都是透过 UI 创造，创造完毕後复制 JSON 的格式，并且将该格式用 ConfigMap 给包装起来。
上述物件创建完毕後，就可以到 Grafana 的介面去重新整理，顺利的话可以看到一个名为 "Redis Dashboard for Prometheus Redis Exporter 1.x" 的 dashboard，如果没有看到的话就等待一点时间即可。

最後预设情况下， Grafana 都是基於匿名的唯独模式去存取的，想要拥有编辑权利的话可以尝试使用预设的帐号密码 admin/prom-operator 去登入这个系统来编辑，编辑後记得将 JSON 物件给汇出保存，透过这样的机制就可以方便的管理 Grafana。

本章简单探讨了一下关於 Rancher Monitoring v2 的用法，如果有需求的人甚至可以不需要到 Cluster Explorer 去安装，而是可以直接使用 Helm 的方式去安装相关物件，主要的物件内容是由 rancher-monitoring 这个 Helm Charts 去安装的，有兴趣尝试可以参考这个官方档案 rancher/charts