我们prometheus采用nfs挂载方式来存储数据，同时使用configMap管理配置文件。并且我们将所有的prometheus存储在kube-system

配置文件创建完成，如果以后我们有新的资源需要被监控，我们只需要将ConfigMap对象更新即可，现在我们开始创建prometheus的Pod资源

我们在启动程序的时候，除了指定prometheus.yaml(configmap)以外，还通过storage.tsdb.path指定了TSDB数据的存储路径、通过storage.tsdb.rentention设置了保留多长时间的数据，还有下面的web.enable-admin-api参数可以用来开启对admin api的访问权限，参数web.enable-lifecyle用来开启支持热更新，有了这个参数之后，prometheus.yaml(configmap)文件只要更新了，通过执行localhost:9090/-/reload就会立即生效

我们添加了一行securityContext，，其中runAsUser设置为0，这是因为prometheus运行过程中使用的用户是nobody，如果不配置可能会出现权限问题

prometheus.yaml文件对应的ConfigMap对象通过volume的形式挂载进Pod，这样ConfigMap更新后，对应的pod也会热更新，然后我们在执行上面的reload请求，prometheus配置就生效了。除此之外，对了将时间数据进行持久化，我们将数据目录和一个pvc对象进行了绑定，所以我们需要提前创建pvc对象

我们这里还需要创建rbac认证，因为prometheus需要访问k8s集群内部的资源

由于我们要获取的资源，在每一个namespace下面都有可能存在，所以我们这里使用的是ClusterRole的资源对象，nonResourceURLs是用来对非资源型metrics进行操作的权限声明

我们将ConfigMap volume rbac 创建完毕后，就可以创建prometheus.deploy.yaml了，运行prometheus服务

现在我们prometheus服务状态是已经正常了，但是我们在浏览器是无法访问prometheus的 webui服务。那么我们还需要创建一个service

这里定义的端口为3xxxx,我们直接在浏览器上任意节点输入ip+端口即可

Prometheus监控Kubernetes 集群节点及应用

监控方案

Kubelet/cAdvisor之外，我们还可以向Heapster添加其他指标源数据，比如kube-state-metrics

不过kube-state-metrics和metrics-server之前还有很大不同的，二者主要区别如下

监控集群节点

首先需要我们监控集群的节点，要监控节点其实我们已经有很多非常成熟的方案了，比如Nagios、Zabbix，甚至可以我们自己收集数据，这里我们通过prometheus来采集节点的监控指标，可以通过node_exporter获取，node_exporter就是抓取用于采集服务器节点的各种运行指标，目前node_exporter几乎支持所有常见的监控点，比如cpu、distats、loadavg、meminfo、netstat等，详细的监控列表可以参考github repo

这里使用DeamonSet控制器来部署该服务，这样每一个节点都会运行一个Pod，如果我们从集群中删除或添加节点后，也会进行自动扩展

由于我们要获取的数据是主机的监控指标数据，而我们的node-exporter是运行在容器中的，所以我们在Pod中需要配置一些Pod的安全策略

另外我们还需要将主机/dev、/proc、/sys这些目录挂在到容器中，这些因为我们采集的很多节点数据都是通过这些文件来获取系统信息

另外如果是使用kubeadm搭建的，同时需要监控master节点的，则需要添加下方的相应容忍

在我们的yaml文件中加入了hostNetwork:true会直接将我们的宿主机的9100端口映射出来，从而不需要创建service 在我们的宿主机上就会有一个9100的端口

上面我们检查了Pod的运行状态都是正常的，接下来我们要查看一下Pod日志，以及node-exporter中的metrics

使用命令kubectl logs -n 命名空间 node-exporter中Pod名称检查Pod日志是否有额外报错

服务发现

我们这里三个节点都运行了node-exporter程序，如果我们通过一个Server来将数据收集在一起，用静态的方式配置到prometheus就会显示一条数据，我们得自己在指标中过滤每个节点的数据，配置比较麻烦。这里就采用服务发现

在Kubernetes下，Prometheus通过Kubernetes API基础，目前主要支持5种服务发现，分别是node、Server、Pod、Endpoints、Ingress

现在我们可以看到已经获取到我们的Node节点的IP，但是由于metrics监听的端口是10250而并不是我们设置的9100，所以提示我们节点属于Down的状态

这里我们就需要使用Prometheus提供的relabel_configs中的replace能力了，relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。这里使用__address__标签替换10250端口为9100

目前状态已经正常，但是还有一个问题就是我们的采集数据只显示了IP地址，对于我们监控分组分类不是很方便，这里可以通过labelmap这个属性来将Kubernetes的Label标签添加为Prometheus的指标标签

添加了一个action为labelmap，正则表达式是__meta_kubernetes_node(.+)的配置，这里的意思就是表达式中匹配的数据也添加到指标数据的Label标签中去。

容器监控

cAdvisor是一个容器资源监控工具，包括容器的内存，CPU，网络IO，资源IO等资源，同时提供了一个Web页面用于查看容器的实时运行状态。

cAvisor已经内置在了kubelet组件之中，所以我们不需要单独去安装，cAdvisor的数据路径为/api/v1/nodes//proxy/metrics

action 使用labelkeep或者labeldrop则可以对Target标签进行过滤，仅保留符合过滤条件的标签

ls_config配置的证书地址是每个Pod连接apiserver所使用的地址，基本上写死了。并且我们在配置文件添加了一个labelmap标签。在最下面使用了一个正则替换了cAdvisor的一个metrics地址

修改完成之后，我们需要configmap并且使用curl进行热更新(过程比较慢，需要等待会)

还可以使用sum函数,pod在1分钟内的使用率，同时将pod名称打印出来

Api-Service 监控

apiserver作为Kubernetes最核心的组件，它的监控也是非常有必要的，对于apiserver的监控，我们可以直接通过kubernetes的service来获取

上面的service是我们集群的apiserver内部的service的地址，要自动发现service类型的服务，需要使用role为Endpoints的kubernetes_sd_configs (自动发现)，我们只需要在configmap里面在添加Endpoints类型的服务发现

更新完成后，我们可以看到kubernetes-apiserver下面出现了很多实例，这是因为我们这里使用的Endpoints类型的服务发现，所以prometheus把所有的Endpoints服务都抓取过来了，同样的我们要监控的kubernetes也在列表中。

这里我们使用keep动作，将符合配置的保留下来，例如我们过滤default命名空间下服务名称为kubernetes的元数据，这里可以根据__meta_kubernetes_namespace和__mate_kubertnetes_service_name2个元数据进行relabel

如果我们要监控其他系统组件，比如kube-controller-manager、kube-scheduler的话就需要单独手动创建service，因为apiserver服务默认在default，而其他组件在kube-steam这个namespace下。其中kube-sheduler的指标数据端口为10251，kube-controller-manager对应端口为10252

Service 监控

apiserver实际上是一种特殊的Service，现在配置一个专门发现普通类型的Service

这里我们对service进行过滤，只有在service配置了prometheus.io/scrape: "true"过滤出来

Serivce自动发现参数说明（并不是所有创建的service都可以被prometheus发现）

我们可以看到这里的服务的core DNS,为什么那么多service只有coreDNS可以被收集到呢？

Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化的展示，并及时通知。

Grafana 安装并监控k8s集群

由于Prometheus自带的web Ui图标功能相对较弱，所以一般情况下我们会使用一个第三方的工具来展示这些数据

Grafana介绍

grafana 是一个可视化面包，有着非常漂亮的图片和布局展示，功能齐全的度量仪表盘和图形化编辑器，支持Graphite、Zabbix、InfluxDB、Prometheus、OpenTSDB、Elasticasearch等作为数据源，比Prometheus自带的图标展示功能强大很多，更加灵活，有丰富的插件

我们这里使用deployment持久化安装grafana

cat >>grafana_deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
    k8s-app: grafana
spec:
  selector:
    matchLabels:
      k8s-app: grafana
      app: grafana
  revisionHistoryLimit: 10
  template:
    metadata:
      labels:
        app: grafana
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:5.3.4
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          name: grafana
        env:
        - name: GF_SECURITY_ADMIN_USER
          value: admin
        - name: GF_SECURITY_ADMIN_PASSWORD
          value: jiangwenhui
        readinessProbe:
          failureThreshold: 10
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 30
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /api/health
            port: 3000
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 300m
            memory: 1024Mi
          requests:
            cpu: 300m
            memory: 1024Mi
        volumeMounts:
        - mountPath: /var/lib/grafana
          subPath: grafana
          name: storage
      securityContext:
        fsGroup: 472
        runAsUser: 472
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

这里使用了grafana 5.3.4的镜像，添加了监控检查、资源声明，比较重要的变量是GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD为grafana的账号和密码。

由于grafana将dashboard、插件这些数据保留在/var/lib/grafana目录下，所以我们这里需要做持久化，同时要针对这个目录做挂载声明，由于5.3.4版本用户的userid和groupid都有所变化，所以这里添加了一个securityContext设置用户ID

image_1ddnv749l17k7ucdel1m4v17jjea.png-56.5kB

现在我们添加一个pv和pvc用于绑定grafana

cat >>grafana_volume.yaml <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: 192.168.0.200
    path: /home/kvm/k8s-vloume
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana
  namespace: kube-system
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

EOF

这里配置依旧使用NFS进行挂载使用

现在我们还需要创建一个service，使用NodePort

cat >>grafana_svc.yaml<<EOF
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: kube-system
  labels:
    app: grafana
spec:
  type: NodePort
  ports:
    - port: 3000
  selector:
    app: grafana
EOF

由于5.1(可以选择5.1之前的docker镜像，可以避免此类错误)版本后groupid更改，同时我们将/var/lib/grafana挂载到pvc后，目录拥有者可能不是grafana用户，所以我们还需要添加一个Job用于授权目录

cat > grafana_job.yaml <<EOF
apiVersion: batch/v1
kind: Job
metadata:
  name: grafana-chown
  namespace: kube-system
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: grafana-chown
        command: ["chown", "-R", "472:472", "/var/lib/grafana"]
        image: busybox
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: storage
          subPath: grafana
          mountPath: /var/lib/grafana
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: grafana
EOF

这里使用一个busybox镜像将/var/lib/grafana目录修改为权限472

#需要先创建pv和pvc  (这里是需要安装顺序来创建)
[root@k8s-01 prometheus]# kubectl create -f grafana_volume.yaml
persistentvolume/grafana created
persistentvolumeclaim/grafana created
[root@k8s-01 prometheus]# kubectl create -f grafana_job.yaml
job.batch/grafana-chown created
[root@k8s-01 prometheus]# kubectl apply -f grafana_deployment.yaml
deployment.apps/grafana created
[root@k8s-01 prometheus]# kubectl create -f grafana_svc.yaml

创建完成后我们打开grafana的dashboard界面

[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# kubectl get pod,svc -n kube-system |grep grafana
pod/grafana-59bd6c446d-4jjnf         1/1     Running     0          7m39s
pod/grafana-chown-w562v              0/1     Completed   0          14m
service/grafana      NodePort    10.1.63.182    <none>        3000:30636/TCP           13m
[root@k8s-01 prometheus]#

然后我们在任意集群中的节点访问端口为30636

这里的集群密码就是上面我们创建deployment里面设置的变量，我这里用户设置为admin密码jiangwenhui

登陆到grafana就显示到了我们的引导界面

第一次创建grafana需要添加数据源

类型选择prometheus

这里的地址我们填写下面的url

http://prometheus.kube-system.svc.cluster.local:9090

这里的prometheus代表service名称

kube-system代表命名空间

数据源添加完毕后，接下来添加New dashboard

这里我们可以自定义模板，或者可以使用别人写好的模板（写好的模板后面是需要我们自己修改的）

grafana提供了很多模板，类似和docker镜像仓库一下。导入模板也极其简单。点击上方的Dashboard

这里面的模板都是公共的，可以免费使用

点进去任意一个模板后，我们可以看到ID，复制ID然后在返回grafana

我这里添加一个监控Kubernetes集群。显示整体群集CPU、内存、磁盘使用情况以及单个pod统计信息。

https://grafana.com/grafana/dashboards/8588

点击导入模板

在这里我们输入8588或者url，会自动跳转到配置页面

https://grafana.com/grafana/dashboards/8588

选择好数据源之后，我们在点击Import即可

这里就会将模板8588给我们导入进行

这里就会获取我们prometheus里面的数据了

现在的模板还没有进行保存，我们要点击保存一下

现在就保存下来了

目前我们导入模板之后是无法直接使用滴

这里无法显示是由于模板定义的标签，我们prometheus并没有这个数据元，所以说我们要对模板进行修改！

在修改之前我们先设置一下时区，grafana默认走的是浏览器时区，但是prometheus使用的是UTC时区

修改默认模板 (我这里使用的是8588模板，下面模板修改请根据我的操作步骤进行操作)

grafana模板修改

前面的步骤必须和我相同，否则这里可能会无法出现值

首先我们进行编辑 Cluster memory usage (集群内存使用率)

计算方式就是(整个集群的内存-(整个集群剩余的内存以及Buffer和Cached))/整

(sum(node_memory_MemTotal_bytes) - sum(node_memory_MemFree_bytes + node_memory_Buffers_bytes+node_memory_Cached_bytes)) / sum(node_memory_MemTotal_bytes) * 100

这里要说明一点，这里填写的是PromSQL，也就是说是可以在prometheus查询到的。如果查询不到grafana也是会获取不到数据的

这里在prometheus是可以获取到的

Cluster memory usage 配置如下 (集群内存使用率)

sum(sum by (container_name)( rate(container_cpu_usage_seconds_total{image!=""}[1m] ) )) / count(node_cpu_seconds_total{mode="system"}) * 100

Cluster filesystem usage 集群文件系统使用率

(sum(node_filesystem_size_bytes{device="tmpfs"}) - sum(node_filesystem_free_bytes{device="tmpfs"}) ) / sum(node_filesystem_size_bytes{device="tmpfs"}) * 100

这里我们就获取到数据了

接下来我们配置集群中Pod cpu使用率

sum by (pod)(rate(container_cpu_usage_seconds_total{image!=" ", pod_name!=" "}[1m]))

下面显示的地方配置

{{ pod }}

集群pod 内存使用率

sort_desc(sum (container_memory_usage_bytes{image!=" ", pod_name!=" "}) by(pod))

下面显示的名称同样也是{{ pod }}

最后我们配置一下Pod 网络监控

1.入口流量
sort_desc(sum by (pod) (rate (container_network_receive_bytes_total{name!=""}[1m]) ))

2.出口流量
sort_desc(sum by (pod) (rate (container_network_transmit_bytes_total{name!=""}[1m]) ))

#监控时间为1分钟

效果图如下 记得点击保存

所有的PromSQL都是可以在prometheus获取到数据的！

Prometheus AlertManager 实战

AlerManager 简介

Prometheus包含了一个报警模块，那就是AlertManager，主要用于接受Prometheus发送的告警信息，它支持丰富的告警通知渠道，而且很容易做到告警信息进行去重，降噪，分组等，是一个前卫的告警通知系统

prometheus-architecture.png-94.6kB

安装 AlerManager

prometheus配置文件官方文档

https://prometheus.io/docs/alerting/configuration/

首先，我们需要先指定配置文件，这里我们还是创建一个ConfigMap资源对象

[root@k8s-01 prometheus]# cat >> prometheus-alert-conf.yaml <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: alert-config
  namespace: kube-system
data:
  config.yml: |-
    global:
      # 在没有报警的情况下声明为已解决的时间
      resolve_timeout: 5m
      # 配置邮件发送信息
      smtp_smarthost: 'smtp.163.com:465'
      smtp_from: '18676791057@163.com'
      smtp_auth_username: '18676791057@163.com'
      smtp_auth_password: '授权密码'
      smtp_hello: '163.com'
      smtp_require_tls: false
    # 所有报警信息进入后的根路由，用来设置报警的分发策略
    route:
      # 这里的标签列表是接收到报警信息后的重新分组标签，例如，接收到的报警信息里面有许多具有 cluster=A 和 alertname=LatncyHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
      group_by: ['alertname', 'cluster']
      # 当一个新的报警分组被创建后，需要等待至少group_wait时间来初始化通知，这种方式可以确保您能有足够的时间为同一分组来获取多个警报，然后一起触发这个报警信息。
      group_wait: 30s

      # 当第一个报警发送后，等待'group_interval'时间来发送新的一组报警信息。
      group_interval: 5m

      # 如果一个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们
      repeat_interval: 5m

      # 默认的receiver：如果一个报警没有被一个route匹配，则发送给默认的接收器
      receiver: default

      # 上面所有的属性都由所有子路由继承，并且可以在每个子路由上进行覆盖。
      routes:
      - receiver: email
        group_wait: 10s
        match:
          team: node
    receivers:
    - name: 'default'
      email_configs:
      - to: '290070744@qq.com'
        send_resolved: true
    - name: 'email'
      email_configs:
      - to: '290070744@qq.com'
        send_resolved: true

EOF

授权密码申请，这里以163邮箱为例

我们现在创建alertmanager的配置文件

[root@k8s-01 prometheus]# kubectl create -f prometheus-alert-conf.yaml
configmap/alert-config created
[root@k8s-01 prometheus]#  kubectl get cm -n kube-system
NAME                                 DATA   AGE
alert-config                         1      8s
coredns                              1      37d
extension-apiserver-authentication   6      37d
kube-flannel-cfg                     2      37d
kube-proxy                           2      37d
kubeadm-config                       2      37d
kubelet-config-1.16                  1      37d
prometheus-config                    1      6d21h
[root@k8s-01 prometheus]# 
#这里已经显示我们创建好的alert-config

现在我们在之前的prometheus pod的yaml文件中添加这个容器

这里我们将上面创建的aler-config这个configmap资源对象volume的形式挂载到/etc/alertmanager目录下去，然后在启动参数中指定--config.file=/etc/alertmanager/config.yml

      - name: alermanager
        image: prom/alertmanager:v0.15.3
        imagePullPolicy: IfNotPresent
        args:
        - "--config.file=/etc/alertmanager/config.yml"
        - "--storage.path=/alertmanager/data"
        ports:
        - containerPort: 9093
          name: http
        volumeMounts:
        - mountPath: "/etc/alertmanager"
          name: alertcfg
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 200m
            memory: 1024Mi
  ...
      - name: alertcfg
        configMap:
          name: alert-config

在0.15版本，alertmanager的WORKDIR发生了变化，变成/etc/alertmanager默认情况下存储路径--storage.path是相对目录data/，因此alertmanager会在我们上面挂载的ConfigMap中去创建这个目录，所以会报错，这里通过--storage.path参数来解决

[root@k8s-01 prometheus]# kubectl apply -f  prometheus.deploy.yaml
deployment.apps/prometheus configured
#更新deployment

查看一下pod启动状态

[root@k8s-01 prometheus]# kubectl get pod -n kube-system |grep prometheus
prometheus-65856969cd-29rqf      2/2     Running     1          49s

AlertManager容器启动之后，我们还需要在Prometheus中配置下AlertManager的地址，让Prometheus能够访问AlertManager

    alerting:
      alertmanagers:
        - static_configs:
          - targets: ["localhost:9093"]

接下来更新一下Prometheus配置文件

[root@k8s-01 prometheus]# 
[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml
configmap/prometheus-config configured
[root@k8s-01 prometheus]# kubectl get pod -n kube-system -o wide |grep prometheus 
prometheus-65856969cd-29rqf      2/2     Running     1          3m58s   10.244.1.70       k8s-02   <none>           <none>
[root@k8s-01 prometheus]# curl -X POST http://10.244.1.70:9090/-/reload

#确保更新配置没有报错（刷新比较慢可以等等）
现在prometheus alertmanager并没有告警的规则，还需要我们添加报警规则

Prometheus 报警规则

上面我们将prometheus和alertmanager进行了关联，但是现在并没有报警规则，所以这里还需要配置一些报警规则。让prometheus触发报警

#首先在prometheus.configmap.yaml文件中添加报警规则，下面的文件就是prometheus报警的规则文件
    rule_files:
    - /etc/prometheus/rules.yml

报警规则允许基于Prometheus表达式语言来定义报警规则条件，并在出发报警时发送给外部

我们上面已经将/etc/promtehus进行挂载了，所以这里只需要修改prometheus-configmap就可以了。

  rules.yml: |
    groups:
    - name: test-rule
      rules:
      - alert: NodeMemoryUsage
        expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes+node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 50
        for: 1m
        labels:
          team: node
        annotations:
          summary: "{{ $labels.instance }}：High Memory Usage detected"
          description: "{{ $labels.instance }}: Memory usage us avive 50% (current value is :: {{ $value }})"



#配置相关参数说明
  rules.yml: |
    groups:
    - name: test-rule
      rules:  #规则
      - alert: NodeMemoryUsage #报警名称(内存报警)
        expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 50 #规则表达式
        for: 1m  #等待1分钟执行查询条件
        labels:
          team: node   #当我们触发报警后，带有team=node的标签，并且这里走的是我们alertmanager node标签，这里对应的就是我们的email接收器
        annotations:  #指定另外一组标签，不会将这个标签当做我们告警的身份标示（不会在我们报警信息里操作）这里主要是用于额外的展示，例如发送给邮件里面>的报警信息
          summary: "{{ $labels.instance }}：High Memory Usage detected"   #label标签，instance代表节点名称
          description: "{{ $labels.instance }}: Memory usage us avive 50% (current value is :: {{ $value }})" #描述：相当于报警信息 $value代表当前值

expr所执行的命令是可以在prometheus上获取到数据的

[root@k8s-01 prometheus]# kubectl apply -f prometheus.configmap.yaml 
configmap/prometheus-config configured
[root@k8s-01 prometheus]# kubectl get pod -n kube-system -o wide |grep prometheus 
prometheus-65856969cd-29rqf      2/2     Running     1          14m     10.244.1.70       k8s-02   <none>           <none>
[root@k8s-01 prometheus]# curl -X POST http://10.244.1.70:9090/-/reload
[root@k8s-01 prometheus]# curl -X POST http://10.244.1.70:9090/-/reload

报警说明

本次报警大概意思是当服务器内存百分比大于80的时候，就进行报警，并且通过labels标签关联team:node (这里team=node是在我们alertmanager里面配置的接收器，默认是default)，并且报警内容添加主机和当前内存使用率

接下来我们访问prometheus，点击alerts，就可以看到我们添加的NodeMemoryUsage

我这里将脚本改成>50

当前值已经大于我们设置的50%，现在已经出发报警

邮件内容如下

alertManager Ui界面

我们可以在邮件内容中看到包含View in AlertManager的链接，这是alertmanager自带的Ui界面。我们可以使用NodePort进行访问

这里需要修改一下prometheus的service

cat >>prometeheus-svc.yaml <<EOF
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: kube-system
  labels:
    app: prometheus
spec:
  selector:
    app: prometheus
  type: NodePort
  ports:
    - name: web
      port: 9090
      targetPort: http
    - name: alertmanager
      port: 9093
      targetPort: 9093
EOF

我们查看一下node-port端口

[root@k8s-01 prometheus]# kubectl get svc -n kube-system |grep prometheus
prometheus   NodePort    10.1.183.250   <none>        9090:30129/TCP,9093:31882/TCP   6d23h

访问alertmanager端口为9093=31882 (集群任一节点访问即可)