liukuan73
liukuan73

Kubernetes平台监控方案之：Exporters+Prometheus+Grafana

1. 概述

1.1 总体目标

从监控平台本身的业务需求来看，至少应该通过平台获取到以下的监控数据：

  • 性能指标(如：CPU、Memory、Load、磁盘、网络等）

    • 容器、Pod相关的性能指标数据
    • 主机节点相关的性能指标数据
    • 容器内进程自己主动暴露的指标数据
    • k8s上应用的网络性能，如http、tcp等数据

  • 状态指标

    • k8s资源对象（Deployment、Daemonset、Pod等）的运行状态指标
    • k8s平台组件（如kube-apiserver、kube-scheduler等）的运行状态指标

获取监控数据之后，还需要对监控进行可视化展示，以及对监控中出现的异常情况进行告警。

本文旨在实践一整套监控方案，篇幅限制，不会对Prometheus等组件的基础原理做具体介绍。Prometheus的基本原理可以参考此书：prometheus-book

1.2 主流监控方案

目前对于kubernetes的主流监控方案主要有以下几种：

  • Heapster+InfluxDB+Grafana
    每个K8S节点的Kubelet内含cAdvisor，暴露出API，Heapster通过访问这些端点得到容器监控数据。它支持多种储存方式，常用的是InfluxDB。这套方案的缺点是数据来源单一、缺乏报警功能以及InfluxDB的单点问题，而且Heapster也已经在新版本中被deprecated(被metrics server取代)了。这种实现方案的详细介绍请见这篇文章。
  • Metrics-Server+InfluxDB+Grafana
    k8s从1.8版本开始，CPU、内存等资源的metrics信息可以通过 Metrics API来获取，用户还可以通过kubectl top直接获取这些metrics信息。Metrics API需要部署Metrics-Server。
  • 各种Exporter+Prometheus+Grafana
    通过各种export采集不同维度的监控指标，并通过Prometheus支持的数据格式暴露出来，Prometheus定期pull数据并用Grafana展示，异常情况使用AlertManager告警。本方案下文详细叙述。

2. 架构

2.1 实现思路

总体实现思路如下：

  • 采集
    • 通过cadvisor采集容器、Pod相关的性能指标数据，并通过暴露的/metrics接口用prometheus抓取
    • 通过prometheus-node-exporter采集主机的性能指标数据，并通过暴露的/metrics接口用prometheus抓取
    • 应用侧自己采集容器中进程主动暴露的指标数据（暴露指标的功能由应用自己实现，并添加平台侧约定的annotation，平台侧负责根据annotation实现通过Prometheus的抓取）
    • 通过blackbox-exporter采集应用的网络性能(http、tcp、icmp等)数据，并通过暴露的/metrics接口用prometheus抓取
    • 通过kube-state-metrics采集k8s资源对象的状态指标数据，并通过暴露的/metrics接口用prometheus抓取
    • 通过etcd、kubelet、kube-apiserver、kube-controller-manager、kube-scheduler自身暴露的/metrics获取节点上与k8s集群相关的一些特征指标数据。
  • 存储（汇聚），通过prometheus pull并汇聚各种exporter的监控数据
  • 展示，通过grafana展示监控信息
  • 告警，通过alertmanager进行告警

2.2 总体架构图

总体架构如下图：
Kubernetes平台监控方案之：Exporters+Prometheus+Grafana_第1张图片

3.监控指标采集实现

3.1 容器、Pod相关的性能指标数据—cAdvisor

cAdvisor是谷歌开源的一个容器监控工具，cadvisor采集了主机上容器相关的性能指标数据，通过容器的指标还可进一步计算出pod的指标。

cadvisor提供的一些主要指标有：

container_cpu_*	
container_fs_*	
container_memory_*	
container_network_*	
container_spec_*(cpu/memory)		
container_start_time_*	
container_tasks_state_*

可以看到基本都是容器相关的一些资源使用情况。

3.1.1 cadvisor接口

目前cAdvisor集成到了kubelet组件内，可以在kubernetes集群中每个启动了kubelet的节点使用cAdvisor提供的metrics接口获取该节点所有容器相关的性能指标数据。1.7.3版本以前，cadvisor的metrics数据集成在kubelet的metrics中，在1.7.3以后版本中cadvisor的metrics被从kubelet的metrics独立出来了，在prometheus采集的时候变成两个scrape的job。

cAdvisor对外提供服务的默认端口为***4194***，主要提供两种接口:

  • Prometheus格式指标接口：nodeIP:4194/metrics(或者通过kubelet暴露的cadvisor接口nodeIP:10255/metrics/cadvisor);
  • WebUI界面接口：nodeIP:4194/containers/

Prometheus作为一个时间序列数据收集，处理，存储的服务，能够监控的对象必须通过http api暴露出基于Prometheus认可的数据模型的监控数据，cAdvisor接口（nodeIP:4194/metrics）暴露的监控指标数据如下所示：

# HELP cadvisor_version_info A metric with a constant '1' value labeled by kernel version, OS version, docker version, cadvisor version & cadvisor revision.
# TYPE cadvisor_version_info gauge
cadvisor_version_info{cadvisorRevision="",cadvisorVersion="",dockerVersion="1.12.6",kernelVersion="4.9.0-1.2.el7.bclinux.x86_64",osVersion="CentOS Linux 7 (Core)"} 1
# HELP container_cpu_cfs_periods_total Number of elapsed enforcement period intervals.
# TYPE container_cpu_cfs_periods_total counter
container_cpu_cfs_periods_total{container_name="",id="/kubepods/burstable/pod1b0c1f83322defae700f33b1b8b7f572",image="",name="",namespace="",pod_name=""} 7.062239e+06
container_cpu_cfs_periods_total{container_name="",id="/kubepods/burstable/pod7f86ba308f28df9915b802bc48cfee3a",image="",name="",namespace="",pod_name=""} 1.574206e+06
container_cpu_cfs_periods_total{container_name="",id="/kubepods/burstable/podb0c8f695146fe62856bc23709a3e056b",image="",name="",namespace="",pod_name=""} 7.107043e+06
container_cpu_cfs_periods_total{container_name="",id="/kubepods/burstable/podc8cf73836b3caba7bf952ce1ac5a5934",image="",name="",namespace="",pod_name=""} 5.932159e+06
container_cpu_cfs_periods_total{container_name="",id="/kubepods/burstable/podfaa9db59-64b7-11e8-8792-00505694eb6a",image="",name="",namespace="",pod_name=""} 6.979547e+06
container_cpu_cfs_periods_total{container_name="calico-node",id="/kubepods/burstable/podfaa9db59-64b7-11e8-8792-
...

可以看到以上接口的数据是按prometheus的格式输出的。

3.1.2 Prometheus配置

如下配置Prometheus来定期拉取cAdvisor的metrics：

      - job_name: 'cadvisor'
        # 通过https访问apiserver，通过apiserver的api获取数据
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
              
        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等 
        kubernetes_sd_configs:
        # 从k8s的node对象获取数据
        - role: node
      
        relabel_configs:
        # 用新的前缀代替原label name前缀，没有replacement的话功能就是去掉label name前缀
        # 例如：以下两句的功能就是将__meta_kubernetes_node_label_kubernetes_io_hostname
        # 变为kubernetes_io_hostname
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)
          
        # replacement中的值将会覆盖target_label中指定的label name的值,
        # 即__address__的值会被替换为kubernetes.default.svc:443
        - target_label: __address__
          replacement: kubernetes.default.svc:443
          
        # 获取__meta_kubernetes_node_name的值
        - source_labels: [__meta_kubernetes_node_name]
          #匹配一个或多个任意字符，将上述source_labels的值生成变量
          regex: (.+)
          # replacement中的值将会覆盖target_label中指定的label name的值,
          # 即__metrics_path__的值会被替换为/api/v1/nodes/${1}/proxy/metrics,
          # 其中${1}的值会被替换为__meta_kubernetes_node_name的值
          target_label: __metrics_path__
          replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
          
        metric_relabel_configs:
          - action: replace
            source_labels: [id]
            regex: '^/machine\.slice/machine-rkt\\x2d([^\\]+)\\.+/([^/]+)\.service$'
            target_label: rkt_container_name
            replacement: '${2}-${1}'
          - action: replace
            source_labels: [id]
            regex: '^/system\.slice/(.+)\.service$'
            target_label: systemd_service_name
            replacement: '${1}'

之后，在prometheus的target(IP:Port/targets)中可以看到cadvisor相应的target：

备注

关于配置文件的一些说明：

  1. 以上配置遵照官方example配置，通过apiserver提供的api做代理获取cAdvisor（ https://kubernetes.default.svc:443/api/v1/nodes/k8smaster01/proxy/metrics/cadvisor ）的监控指标(和从nodeIP:4194/metrics获取到的内容是一样的)，而不是直接从node上获取。为什么这样做，官方这样解释的：This means it will work if Prometheus is running out of cluster, or can’t connect to nodes for some other reason (e.g. because of firewalling)。
  2. Promethues在K8S集群内通过DNS地址 https://kubernetes.default.svc访问apiserver来scrape数据
  3. Prometheus配置文件的语法规则较复杂，为便于理解，我加了一些注释；更多语法规则请见Prometheus官方文档。

关于target中label的一些说明，target中必有的几个source label有：

  1. __address__(当static_configs时通过targets手工配置，当kubernetes_sd_configs时，值从apiserver中获取)、
  2. __metrics_path__(默认值是/metrics)、
  3. __scheme__(默认值http)
  4. job

其他source label则是根据kubernetes_sd_configs时设置的- role(如endpoints、nodes、service、pod等)从k8s资源对象的label、annotation及其他一些信息中提取的。

3.2 主机节点性能指标数据—node-exporter

Prometheus社区提供的NodeExporter项目可以对主机的关键度量指标进行监控，通过Kubernetes的DeamonSet可以在各个主机节点上部署有且仅有一个NodeExporter实例，实现对主机性能指标数据的监控。node-exporter所采集的指标主要有:

 node_cpu_*		
 node_disk_*	
 node_entropy_*		
 node_filefd_*
 node_filesystem_*	
 node_forks_*	
 node_intr_total_*
 node_ipvs_*	
 node_load_*	
 node_memory_*		
 node_netstat_*		
 node_network_*		
 node_nf_conntrack_*		
 node_scrape_*		
 node_sockstat_*		
 node_time_seconds_*
 node_timex	_*
 node_xfs_*

可以看到全是节点相关的一些资源使用情况。

3.2.1 prometheus-node-exporter部署

我的NodeExporter部署文件node-exporter-daemonset.yaml如下，可从github下载。

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: prometheus-node-exporter
  namespace: kube-system
  labels:
    app: prometheus-node-exporter
spec:
  template:
    metadata:
      name: prometheus-node-exporter
      labels:
        app: prometheus-node-exporter
    spec:
      containers:
      - image: prom/node-exporter:v0.16.0
        imagePullPolicy: IfNotPresent
        name: prometheus-node-exporter
        ports:
        - name: prom-node-exp
          #^ must be an IANA_SVC_NAME (at most 15 characters, ..)
          containerPort: 9100
          hostPort: 9100
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
      hostNetwork: true
      hostPID: true
      hostIPC: true
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/app-metrics: 'true'
    prometheus.io/app-metrics-path: '/metrics'
  name: prometheus-node-exporter
  namespace: kube-system
  labels:
    app: prometheus-node-exporter
spec:
  clusterIP: None
  ports:
    - name: prometheus-node-exporter
      port: 9100
      protocol: TCP
  selector:
    app: prometheus-node-exporter
  type: ClusterIP

备注：

1.为了让容器里的node-exporter获取到主机上的网络、PID、IPC指标，这里设置了hostNetwork: true、hostPID: true、hostIPC: true，来与主机共用网络、PID、IPC这三个namespace。
2.为了
2.此处在Service的annotations中定义标注prometheus.io/scrape: 'true'，表明该Service需要被Promethues发现并采集数据。

通过NodeExporter暴露的metrics接口(nodeIP:9100/metrics)查看采集到的数据，可以看到是按Prometheus的格式输出的数据：

# HELP node_arp_entries ARP entries by device
# TYPE node_arp_entries gauge
node_arp_entries{device="calid63983a5754"} 1
node_arp_entries{device="calid67ce395c9e"} 1
node_arp_entries{device="calid857f2bf9d5"} 1
node_arp_entries{device="calief3a4b64165"} 1
node_arp_entries{device="eno16777984"} 9
# HELP node_boot_time Node boot time, in unixtime.
# TYPE node_boot_time gauge
node_boot_time 1.527752719e+09
# HELP node_context_switches Total number of context switches.
# TYPE node_context_switches counter
node_context_switches 3.1425612674e+10
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="guest"} 0
node_cpu{cpu="cpu0",mode="guest_nice"} 0
node_cpu{cpu="cpu0",mode="idle"} 2.38051096e+06
node_cpu{cpu="cpu0",mode="iowait"} 11904.19
node_cpu{cpu="cpu0",mode="irq"} 0
node_cpu{cpu="cpu0",mode="nice"} 2990.94
node_cpu{cpu="cpu0",mode="softirq"} 8038.3
...

3.2.2 Prometheus配置

配置Prometheus来scrape node-exporter的metrics：

      - job_name: 'prometheus-node-exporter'
        
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
        #The endpoints role discovers targets from listed endpoints of a service. For each
        #endpoint address one target is discovered per port. If the endpoint is backed by
        #a pod, all additional container ports of the pod, not bound to an endpoint port,
        #are discovered as targets as well
        - role: endpoints
        relabel_configs:
        # 只保留endpoints的annotations中含有prometheus.io/scrape: 'true'和port的name为prometheus-node-exporter的endpoint
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_endpoint_port_name]
          regex: true;prometheus-node-exporter
          action: keep
        # Match regex against the concatenated source_labels. Then, set target_label to replacement, 
        # with match group references (${1}, ${2}, ...) in replacement substituted by their value. 
        # If regex does not match, no replacement takes place.
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
          action: replace
          target_label: __scheme__
          regex: (https?)
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
          action: replace
          target_label: __address__
          regex: (.+)(?::\d+);(\d+)
          replacement: $1:$2
        # 去掉label name中的前缀__meta_kubernetes_service_label_
        - action: labelmap
          regex: __meta_kubernetes_service_label_(.+)
        # 将__meta_kubernetes_namespace重命名为kubernetes_namespace
        - source_labels: [__meta_kubernetes_namespace]
          action: replace
          target_label: kubernetes_namespace
        # 将__meta_kubernetes_service_name重命名为kubernetes_name
        - source_labels: [__meta_kubernetes_service_name]
          action: replace
          target_label: kubernetes_name

在Prometheus中可以看到相应的target：

3.3 采集应用实例中某个进程自己暴露的指标数据

有的应用具有暴露容器内具体进程性能指标的需求，这些指标由应用侧实现采集并暴露，平台侧做汇聚。

3.3.1 如何标识哪些是主动暴露监控指标的应用并获取指标

平台侧可以约定好带哪些annotation前缀的服务是自主暴露监控指标的服务。应用添加平台侧约定的这些annotations，平台侧可以根据这些annotations实现Prometheus的scrape。

例如，应用侧为自己的服务添加如下平台侧约定约定的annotation：

prometheus.io/scrape: 'true'
prometheus.io/app-metrics: 'true'
prometheus.io/app-metrics-port: '8080'
prometheus.io/app-metrics-path: '/metrics'

Prometheus可以：

  • 根据prometheus.io/scrape: 'true'获知对应的endpoint是需要被scrape的
  • 根据prometheus.io/app-metrics: 'true'获知对应的endpoint中有应用进程暴露的metrics
  • 根据prometheus.io/app-metrics-port: '8080'获知进程暴露的metrics的端口号
  • 根据prometheus.io/app-metrics-path: '/metrics'获知进程暴露的metrics的具体路径

3.3.2 如何给应用加一些标志信息，并带到Prometheus侧

可能还需要根据平台和业务的需求添加其他一些以prometheus.io/app-info-为前缀的annotation，Prometheus截取下前缀，保留后半部分做key，连同value保留下来。这样满足在平台对应用做其他一些标识的需求。比如加入如下annotation来标识应用所属的的环境、租户以及应用名称：

prometheus.io/app-info-env: 'test'
prometheus.io/app-info-tenant: 'test-tenant'
prometheus.io/app-info-name: 'test-app'

Prometheus的config配置如下：

      - job_name: 'kubernetes-app-metrics'
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
        #The endpoints role discovers targets from listed endpoints of a service. For each
        #endpoint address one target is discovered per port. If the endpoint is backed by
        #a pod, all additional container ports of the pod, not bound to an endpoint port,
        #are discovered as targets as well
        - role: endpoints
        relabel_configs:
        # 只保留endpoint中含有prometheus.io/scrape: 'true'的annotation的endpoint
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_service_annotation_prometheus_io_app_metrics]
          regex: true;true
          action: keep
        # 将用户指定的进程的metrics_path替换默认的metrics_path
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_app_metrics_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        # 用pod_ip和用户指定的进程的metrics端口组合成真正的可以拿到数据的地址来替换原始__address__
        - source_labels: [__meta_kubernetes_pod_ip, __meta_kubernetes_service_annotation_prometheus_io_app_metrics_port]
          action: replace
          target_label: __address__
          regex: (.+);(.+)
          replacement: $1:$2
        # 去掉label name中的前缀__meta_kubernetes_service_annotation_prometheus_io_app_info_
        - action: labelmap
          regex: __meta_kubernetes_service_annotation_prometheus_io_app_info_(.+)

备注：

最后两行的作用是将例如prometheus.io/app-info-tenant的annotation名切割成名为tenant的label。

在Prometheus中可以获取到对应的应用进程targets：

3.4 通过blackbox-exporter采集应用的网络性能数据

blackbox-exporter是一个黑盒探测工具，可以对服务的http、tcp、icmp等进行网络探测。

3.4.1 blackbox-exporter部署

我的blackbox-exporter部署文件如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prometheus-blackbox-exporter
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: prometheus-blackbox-exporter
  replicas: 1
  template:
    metadata:
      labels:
        app: prometheus-blackbox-exporter
    spec:
      restartPolicy: Always
      containers:
      - name: prometheus-blackbox-exporter
        image: prom/blackbox-exporter:v0.12.0
        imagePullPolicy: IfNotPresent
        ports:
        - name: blackbox-port
          containerPort: 9115
        readinessProbe:
          tcpSocket:
            port: 9115
          initialDelaySeconds: 5
          timeoutSeconds: 5
        resources:
          requests:
            memory: 50Mi
            cpu: 100m
          limits:
            memory: 60Mi
            cpu: 200m
        volumeMounts:
        - name: config
          mountPath: /etc/blackbox_exporter
        args:
        - --config.file=/etc/blackbox_exporter/blackbox.yml
        - --log.level=debug
        - --web.listen-address=:9115
      volumes:
      - name: config
        configMap:
          name: prometheus-blackbox-exporter
      nodeSelector:
        node-role.kubernetes.io/master: "true"
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: prometheus-blackbox-exporter
  name: prometheus-blackbox-exporter
  namespace: kube-system
  annotations:
    prometheus.io/scrape: 'true'
spec:
  type: NodePort
  selector:
    app: prometheus-blackbox-exporter
  ports:
  - name: blackbox
    port: 9115
    targetPort: 9115
    nodePort: 30009
    protocol: TCP

对应的configmap如下：

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: prometheus-blackbox-exporter
  name: prometheus-blackbox-exporter
  namespace: kube-system
data:
  blackbox.yml: |-
    modules:
      http_2xx:
        prober: http
        timeout: 10s
        http:
          valid_http_versions: ["HTTP/1.1", "HTTP/2"]
          valid_status_codes: []
          method: GET
          preferred_ip_protocol: "ip4"
      http_post_2xx: # http post 监测模块
        prober: http
        timeout: 10s
        http:
          valid_http_versions: ["HTTP/1.1", "HTTP/2"]
          method: POST
          preferred_ip_protocol: "ip4"
      tcp_connect:
        prober: tcp
        timeout: 10s
      icmp:
        prober: icmp
        timeout: 10s
        icmp:
          preferred_ip_protocol: "ip4"

备注：

blackbox-exporter的配置文件为/etc/blackbox_exporter/blackbox.yml，可以运行时动态的重新加载配置文件，当重新加载配置文件失败时，不影响在运行的配置。重载方式：curl -XPOST http://IP:9115/-/reload

3.4.2 Prometheus配置

在Prometheus的config文件中分别配置对http和tcp的探测：

      - job_name: 'kubernetes-service-http-probe'
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
        - role: service
        # 将metrics_path由默认的/metrics改为/probe
        metrics_path: /probe
        # Optional HTTP URL parameters.
        # 生成__param_module="http_2xx"的label
        params:
          module: [http_2xx]
        relabel_configs:
        # 只保留含有label为prometheus/io=scrape的service
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_service_annotation_prometheus_io_http_probe]
          regex: true;true
          action: keep
        - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_namespace, __meta_kubernetes_service_annotation_prometheus_io_http_probe_port, __meta_kubernetes_service_annotation_prometheus_io_http_probe_path]
          action: replace
          target_label: __param_target
          regex: (.+);(.+);(.+);(.+)
          replacement: $1.$2:$3$4
        # 用__address__这个label的值创建一个名为__param_target的label为blackbox-exporter,值为内部service的访问地址，作为blackbox-exporter采集用
        #- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_http_probe_path]
        #  action: replace
        #  target_label: __param_target
        #  regex: (.+);(.+)
        #  replacement: $1$2
        # 用blackbox-exporter的service地址值”prometheus-blackbox-exporter:9115"替换原__address__的值
        - target_label: __address__
          replacement: prometheus-blackbox-exporter:9115
        - source_labels: [__param_target]
          target_label: instance
        # 去掉label name中的前缀__meta_kubernetes_service_annotation_prometheus_io_app_info_
        - action: labelmap
          regex: __meta_kubernetes_service_annotation_prometheus_io_app_info_(.+)
        #- source_labels: [__meta_kubernetes_namespace]
        #  target_label: kubernetes_namespace
        #- source_labels: [__meta_kubernetes_service_name]
        #  target_label: kubernetes_name
      ## kubernetes-services and kubernetes-ingresses are blackbox_exporter related
      
      # Example scrape config for probing services via the Blackbox Exporter.
      # 
      # The relabeling allows the actual service scrape endpoint to be configured
      # for all or only some services.
      - job_name: 'kubernetes-service-tcp-probe'
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:
        - role: service
        # 将metrics_path由默认的/metrics改为/probe
        metrics_path: /probe
        # Optional HTTP URL parameters.
        # 生成__param_module="tcp_connect"的label
        params:
          module: [tcp_connect]
        relabel_configs:
        # 只保留含有label为prometheus/io=scrape的service
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_service_annotation_prometheus_io_tcp_probe]
          regex: true;true
          action: keep
        - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_namespace, __meta_kubernetes_service_annotation_prometheus_io_tcp_probe_port]
          action: replace
          target_label: __param_target
          regex: (.+);(.+);(.+)
          replacement: $1.$2:$3
        # 用__address__这个label的值创建一个名为__param_target的label为blackbox-exporter,值为内部service的访问地址，作为blackbox-exporter采集用
        #- source_labels: [__address__]
        #  target_label: __param_target
        # 用blackbox-exporter的service地址值”prometheus-blackbox-exporter:9115"替换原__address__的值
        - target_label: __address__
          replacement: prometheus-blackbox-exporter:9115
        - source_labels: [__param_target]
          target_label: instance
        # 去掉label name中的前缀__meta_kubernetes_service_annotation_prometheus_io_app_info_
        - action: labelmap
          regex: __meta_kubernetes_service_annotation_prometheus_io_app_info_(.+)

3.4.3 应用侧配置

应用可以在service中指定平台侧约定的annotation，实现监控平台对该应用的网络服务进行探测：

  • http探测
   prometheus.io/scrape: 'true'
   prometheus.io/http-probe: 'true'
   prometheus.io/http-probe-port: '8080'
   prometheus.io/http-probe-path: '/healthz'
  • tcp探测
   prometheus.io/scrape: 'true'
   prometheus.io/tcp-probe: 'true'
   prometheus.io/tcp-probe-port: '80'

Prometheus根据这些annotation可以获知相应service是需要被探测的，探测的具体网络协议是http还是tcp或其他，以及具体的探测端口。http探测的话还要知道探测的具体url。

在Prometheus中可以获取到对应的targets：

3.5 资源对象(Deployment、Pod等)的状态—kube-state-metrics

kube-state-metrics采集了k8s中各种资源对象的状态信息：

kube_daemonset_*（创建时间、所处的阶段、期望跑在几台节点上、应当正在运行的节点数量、不应该跑却跑了daemon pod的节点数、跑好了pod(ready)的节点数）	
kube_deployment_*（创建时间、是否将k8s的label转化为prometheus的label、所处的阶段、是不是以处于paused状态并不再被dp controller处理、期望副本数、rolling update时最多不可用副本数、dp controller观察到的阶段、实际副本数、availabel副本数、unavailabel副本数、updated副本数)
kube_job_*（是否执行完成、创建时间戳...)
kube_namespace_*
kube_node_*
kube_persistentvolumeclaim_*
kube_pod_container_*
kube_pod_*
kube_replicaset_*
kube_service_*
kube_statefulset_*

查看数据(IP:Port/metrics)，可以看到是以prometheus的格式输出：

3.5.1 kube-state-metrics部署

我的kube-state-metrics部署文件kube-state-metrics-deployment.yaml如下，可以直接从github下载。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-state-metrics
  namespace: kube-system
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: kube-state-metrics
  namespace: kube-system
  labels:
    app: kube-state-metrics
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kube-state-metrics
    spec:
      serviceAccountName: kube-state-metrics
      containers:
      - name: kube-state-metrics
        image: daocloud.io/liukuan73/kube-state-metrics:v1.1.0
        ports:
        - containerPort: 8080
      restartPolicy: Always
      nodeSelector:
        node-role.kubernetes.io/master: "true"
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/http-probe: 'true'
    prometheus.io/http-probe-path: '/healthz'
    prometheus.io/http-probe-port: '8080'
  name: kube-state-metrics
  namespace: kube-system
  labels:
    app: kube-state-metrics
spec:
  type: NodePort
  ports:
  - name: kube-state-metrics
    port: 8080
    targetPort: 8080
    nodePort: 30005
  selector:
    app: kube-state-metrics

3.5.2 Prometheus配置

配置Prometheus来scrape来自kube-state-metrics的metrics：

      - job_name: 'kube-state-metrics'
        
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        kubernetes_sd_configs:

        #The endpoints role discovers targets from listed endpoints of a service. For each
        #endpoint address one target is discovered per port. If the endpoint is backed by
        #a pod, all additional container ports of the pod, not bound to an endpoint port,
        #are discovered as targets as well
        - role: endpoints
        relabel_configs:
        # 只保留endpoint中的annotations含有prometheus.io/scrape: 'true'和port的name为prometheus-node-exporter的endpoint
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape,__meta_kubernetes_endpoint_port_name]
          regex: true;kube-state-metrics
          action: keep
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
          action: replace
          target_label: __scheme__
          regex: (https?)
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
          action: replace
          target_label: __address__
          regex: (.+)(?::\d+);(\d+)
          replacement: $1:$2
        # 去掉label name中的前缀__meta_kubernetes_service_label_
        - action: labelmap
          regex: __meta_kubernetes_service_label_(.+)
        # 将__meta_kubernetes_namespace重命名为kubernetes_namespace
        - source_labels: [__meta_kubernetes_namespace]
          action: replace
          target_label: kubernetes_namespace
        # 将__meta_kubernetes_service_name重命名为kubernetes_name
        - source_labels: [__meta_kubernetes_service_name]
          action: replace
          target_label: kubernetes_name

在prometheus中可以看到相应的target：

3.6 k8s集群组件的状态指标采集

etcd、kube-controller-manager、kube-scheduler、kube-proxy、kube-apiserver、kubelet这几个k8d平台组件分别向外暴露了prometheus标准的指标接口/metrics。可通过配置prometheus来进行读取。

3.6.1 etcd指标获取

以kubeadm启动的k8s集群中，etcd是以static pod的形式启动的，默认没有service及对应的endpoint可供集群内的prometheus访问。所以首先创建一个用来为prometheus提供接口的service（endpoint），etcd-svc.yaml文件如下：

apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: etcd-prometheus-discovery
  labels:
    component: etcd
  annotations:
    prometheus.io/scrape: 'true'
spec:
  selector:
    component: etcd
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 2379
    targetPort: 2379
    protocol: TCP

prometheus配置抓取的文件加入如下配置：

      - job_name: 'etcd'

        # 通过https访问apiserver
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等
        kubernetes_sd_configs:
        # 从endpoints获取apiserver数据
        - role: endpoints

        #relabel_configs允许在抓取之前对任何目标及其标签进行修改。
        relabel_configs:
        # 选择哪些label
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_namespace, __meta_kubernetes_service_name]
          # 上述选择的label的值需要与下述对应
          regex: true;kube-system;etcd-prometheus-discovery
          # 含有符合regex的source_label的endpoints进行保留
          action: keep

3.6.2 kube-proxy指标获取

kube-proxy通过10249端口暴露/metrics指标。与3.6.1同理，kube-proxy-svc.yaml如下：

apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-proxy-prometheus-discovery
  labels:
    k8s-app: kube-proxy
  annotations:
    prometheus.io/scrape: 'true'
spec:
  selector:
    k8s-app: kube-proxy
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10249
    targetPort: 10249
    protocol: TCP

prometheus配置抓取的文件加入如下配置：

        - job_name: 'kube-proxy'

        # 通过https访问apiserver
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等
        kubernetes_sd_configs:
        # 从endpoints获取apiserver数据
        - role: endpoints

        #relabel_configs允许在抓取之前对任何目标及其标签进行修改。
        relabel_configs:
        # 选择哪些label
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_namespace, __meta_kubernetes_service_name]
          # 上述选择的label的值需要与下述对应
          regex: true;kube-system;kube-proxy-prometheus-discovery
          # 含有符合regex的source_label的endpoints进行保留
          action: keep

3.6.3 kube-scheduler指标获取

kube-scheduler通过10251端口暴露/metrics指标。与3.6.1同理，kube-scheduler-svc.yaml如下：

apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-scheduler-prometheus-discovery
  labels:
    k8s-app: kube-scheduler
  annotations:
    prometheus.io/scrape: 'true'
spec:
  selector:
    component: kube-scheduler
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10251
    targetPort: 10251
    protocol: TCP

prometheus对应的配置如下：

      - job_name: 'kube-scheduler'

        # 通过https访问apiserver
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等
        kubernetes_sd_configs:
        # 从endpoints获取apiserver数据
        - role: endpoints

        #relabel_configs允许在抓取之前对任何目标及其标签进行修改。
        relabel_configs:
        # 选择哪些label
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_namespace, __meta_kubernetes_service_name]
          # 上述选择的label的值需要与下述对应
          regex: true;kube-system;kube-scheduler-prometheus-discovery
          # 含有符合regex的source_label的endpoints进行保留
          action: keep

3.6.4 kube-controller-manager指标获取

kube-controller-manager通过10252端口暴露/metrics指标。与3.6.1同理，kube-controller-manager-svc.yaml如下：

apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager-prometheus-discovery
  labels:
    k8s-app: kube-controller-manager
  annotations:
    prometheus.io/scrape: 'true'
spec:
  selector:
    component: kube-controller-manager
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http-metrics
    port: 10252
    targetPort: 10252
    protocol: TCP

prometheus配置抓取的文件加入如下配置：

      - job_name: 'kube-controller-manager'

        # 通过https访问apiserver
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等
        kubernetes_sd_configs:
        # 从endpoints获取apiserver数据
        - role: endpoints

        #relabel_configs允许在抓取之前对任何目标及其标签进行修改。
        relabel_configs:
        # 选择哪些label
        - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape, __meta_kubernetes_namespace, __meta_kubernetes_service_name]
          # 上述选择的label的值需要与下述对应
          regex: true;kube-system;kube-controller-manager-prometheus-discovery
          # 含有符合regex的source_label的endpoints进行保留
          action: keep

以上四步配置好后可以看到分别增加了etcd-prometheus-discovery、kube-controller-manager-prometheus-discovery、kube-scheduler-prometheus-discovery和kube-proxy四个endpints:

prometheus中也可以看到抓取到了相应target:

3.6.5 kube-apiserver数据获取

kube-apiserver与上面四个组件不同的是，部署好后集群中默认会有一个名为kubernetes的service和对应的名为kubernetes的endpoint，这个endpoint就是集群内的kube-apiserver的访问入口。可以如下配置prometheus抓取数据：

      - job_name: 'kube-apiservers'

        # 通过https访问apiserver
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等
        kubernetes_sd_configs:
        # 从endpoints获取apiserver数据
        - role: endpoints

        #relabel_configs允许在抓取之前对任何目标及其标签进行修改。
        relabel_configs:
        # 选择哪些label
        - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
          # 上述选择的label的值需要与下述对应
          regex: default;kubernetes;https
          # 含有符合regex的source_label的endpoints进行保留
          action: keep

之后就可以看到prometheus多了一个kube-apiserver的target：

3.6.6 kubelet数据获取

kubelet暴露的metrics端口默认为 10255：

  • 提供的prometheus格式指标接口：nodeIP:10255/metrics，使用Prometheus从这里取数据
  • kubelet提供的stats/summary接口：nodeIP:10255/stats/summary，heapster和最新的metrics-server从这里获取数据

kubelet采集的指标主要有：

apiserver_client_certificate_expiration_seconds_bucket
apiserver_client_certificate_expiration_seconds_sum
apiserver_client_certificate_expiration_seconds_count
etcd_helper_cache_entry_count
etcd_helper_cache_hit_count
etcd_helper_cache_miss_count
etcd_request_cache_add_latencies_summary
etcd_request_cache_add_latencies_summary_sum
etcd_request_cache_add_latencies_summary_count
etcd_request_cache_get_latencies_summary
etcd_request_cache_get_latencies_summary_sum
etcd_request_cache_get_latencies_summary_count
kubelet_cgroup_manager_latency_microseconds
kubelet_containers_per_pod_count
kubelet_docker_operations
kubelet_network_plugin_operations_latency_microseconds
kubelet_pleg_relist_interval_microseconds
kubelet_pleg_relist_latency_microseconds
kubelet_pod_start_latency_microseconds
kubelet_pod_worker_latency_microseconds
kubelet_running_container_count
kubelet_running_pod_count
kubelet_runtime_operations*
kubernetes_build_info
process_cpu_seconds_total
reflector*
rest_client_request_*
storage_operation_duration_seconds_*

查看kubelet监控指标数据（nodeIP:10255/metrics）：

# HELP apiserver_audit_event_total Counter of audit events generated and sent to the audit backend.
# TYPE apiserver_audit_event_total counter
apiserver_audit_event_total 0
# HELP apiserver_client_certificate_expiration_seconds Distribution of the remaining lifetime on the certificate used to authenticate a request.
# TYPE apiserver_client_certificate_expiration_seconds histogram
apiserver_client_certificate_expiration_seconds_bucket{le="0"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="21600"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="43200"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="86400"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="172800"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="345600"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="604800"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="2.592e+06"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="7.776e+06"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="1.5552e+07"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="3.1104e+07"} 0
apiserver_client_certificate_expiration_seconds_bucket{le="+Inf"} 4161
apiserver_client_certificate_expiration_seconds_sum 1.3091542942737878e+12
apiserver_client_certificate_expiration_seconds_count 4161
...

kubelet由于在每个节点上都有且仅有一个，所以可以通过k8s的node对象找到kubelet的指标，prometheus配置如下：

      - job_name: 'kubelet'
        # 通过https访问apiserver，通过apiserver的api获取数据
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
                
        #以k8s的角色(role)来定义收集，比如node,service,pod,endpoints,ingress等等 
        kubernetes_sd_configs:
        # 从k8s的node对象获取数据
        - role: node
        relabel_configs:
        # 用新的前缀代替原label name前缀，没有replacement的话功能就是去掉label_name前缀
        # 例如：以下两句的功能就是将__meta_kubernetes_node_label_kubernetes_io_hostname
        # 变为kubernetes_io_hostname
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)
        # replacement中的值将会覆盖target_label中指定的label name的值,
        # 即__address__的值会被替换为kubernetes.default.svc:443
        - target_label: __address__
          replacement: kubernetes.default.svc:443
          #replacement: 10.142.21.21:6443
        # 获取__meta_kubernetes_node_name的值
        - source_labels: [__meta_kubernetes_node_name]
          #匹配一个或多个任意字符，将上述source_labels的值生成变量
          regex: (.+)
          # 将# replacement中的值将会覆盖target_label中指定的label name的值,
          # 即__metrics_path__的值会被替换为/api/v1/nodes/${1}/proxy/metrics,
          # 其中${1}的值会被替换为__meta_kubernetes_node_name的值
          target_label: __metrics_path__
          replacement: /api/v1/nodes/${1}/proxy/metrics
        #or:
        #- source_labels: [__address__]
        #  regex: '(.*):10250'
        #  replacement: '${1}:4194'
        #  target_label: __address__
        #- source_labels: [__meta_kubernetes_node_label_role]
        #  action: replace
        #  target_label: role

4. 数据汇聚层—Prometheus部署和配置

前面介绍了K8S平台的监控数据怎么采集出来，接下来介绍怎么用prometheus收集和处理。

4.1 prometheus全局配置文件

configmap-prom-config.yaml，这个是我改写的prometheus全局配置的configmap文件，我参考的Github官方示例，然后做适当改动并增加了一些注释。prometheus的config文件的更详细语法请见官网

4.2 prometheus告警规则配置文件

Prometheus中的告警规则允许用户基于PromQL表达式定义告警触发条件，Prometheus后端对这些触发规则进行周期性的计算，当满足触发条件后会触发告警通知。用户可以通过Prometheus的Web界面查看这些告警规则(/rules)以及告警的触发状态(/alerts)。当Promthues与Alertmanager关联之后，可以将告警发送到外部服务如Alertmanager中并通过Alertmanager可以对这些告警进行进一步的处理。

在Prometheus全局配置文件中通过rule_files指定一组告警规则文件的路径。Prometheus启动后会自动扫描这些路径下规则文件中定义的内容，并且根据这些规则计算是否向外部发送通知。计算告警触发条件的周期可以通过global下的evaluation_interval进行配置：

global:
  [ evaluation_interval:  | default = 1m ]
rule_files:
  [ -  ... ]

4.2.1 定义告警规则

告警规则文件使用yaml格式进行定义，一个典型的告警配置如下：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency
      description: description info

在告警规则文件中，我们可以将一组相关的规则设置定义在一个group下。在每一个group中我们可以定义多个告警规则(rule)。一条告警规则主要由以下几部分组成：

  • alert：告警规则的名称。
  • expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
  • for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
  • labels：自定义标签，允许用户指定要附加到告警上的一组附加标签。
  • annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字等。

Prometheus根据global.evaluation_interval定义的周期计算PromQL表达式。如果PromQL表达式能够找到匹配的时间序列则会为每一条时间序列产生一个告警实例。

rules的config文件的详细语法请见官网

4.2.2 模板化

一般来说，在告警规则文件的annotations中使用summary描述告警的概要信息，description用于描述告警的详细信息。同时Alertmanager的UI也会根据这两个标签值，显示告警信息。为了让告警信息具有更好的可读性，Prometheus支持模板化label和annotations的中标签的值。

通过$labels.变量可以访问当前告警实例中指定标签的值。$value则可以获取当前PromQL表达式计算的样本值。

# To insert a firing element's label values:
{{ $labels. }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例如，可以通过模板化优化summary以及description的内容的可读性：

groups:
- name: example
  rules:
​
  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
​
  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

4.2.3 告警规则创建

configmap-prom-rule.yaml，这是我的prometheus配置告警规则的configmap文件。参考的这里
告警规则允许你定义基于Prometheus语言表达的报警条件，并发送报警通知到外部服务，如AlertManager。rules的config文件的详细语法请见官网

可以在Prometheus的alert界面看到告警规则：

可以在Prometheus的alert界面看到告警信息：

4.3 prometheus启动文件

prometheus.yaml是prometheus以deployment起在kubernetes上的部署文件，给出了两种部署方式，分别是集群开启和未开启rbac时的部署文件，以开启rbac时的为例，内容如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prometheus
  namespace: kube-system
  labels:
    app: prometheus
spec:
  replicas: 1
  template:
    metadata:
      name: prometheus
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
#      hostNetwork: true
      containers:
      - name: prometheus
        image: prom/prometheus:v2.3.2
        imagePullPolicy: IfNotPresent
        args:
          - '--storage.tsdb.path=/prometheus/data/'
          - '--storage.tsdb.retention=1d'
          - '--config.file=/etc/prometheus/prometheus.yaml'
          - '--web.enable-lifecycle'
        ports:
        - name: webui
          containerPort: 9090
        resources:
          requests:
            cpu: 500m
            memory: 500M
        #  limits:
        #    cpu: 500m
        #    memory: 500M
        volumeMounts:
        - name: config-volume
          mountPath: /etc/prometheus
        - name: rules-volume
          mountPath: /etc/prometheus-rules
      volumes:
      - name: config-volume
        configMap:
          name: prometheus
      - name: rules-volume
        configMap:
          name: prometheus-rules
      nodeSelector:
        node-role.kubernetes.io/master: "true"
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: kube-system
  labels:
    app: prometheus
  annotations:
    prometheus.io/scrape: 'true'
spec:
  type: NodePort
#  type: ClusterIP
  ports:
    - name: webui
      port: 9090
      protocol: TCP
      nodePort: 30006
  selector:
    app: prometheus

对args参数做几点说明:

  • --storage.tsdb.path：tsdb数据库存储路径
  • --storage.tsdb.retention：数据保留多久，可以看官方文档存储部分
  • --config.file：指定prometheus的config文件的路径
  • --web.enable-lifecycle：加上这个参数后可以向/-/reload(curl -XPOST 10.142.232.150:30006/-/reload)发送HTTP POST请求实现prometheus在config文件修改后的动态reload，更多信息请查看官方文档
  • --web.enable-admin-api：加上这个参数可以为一些高级用户暴露操作数据库功能的API，比如快照备份(curl -XPOST http://>/api/v2/admin/tsdb/snapshot)，更多信息请查看官方文档 TSDB Admin APIs部分

启动后可以(IP:Port/targets)查看所有targets:

更多告警规则用法请参考：https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/alert/prometheus-alert-rule

5.可视化展示

5.1安装grafana

rpm部署方式：

wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-5.0.4-1.x86_64.rpm
yum -y localinstall grafana-5.0.4-1.x86_64.rpm 
systemctl enable grafana-server
systemctl start grafana-server

docker部署方式：

docker run -d -p 3000:3000 --name=grafana -e "GF_SERVER_HTTP_PORT=3000" -e "GF_AUTH_BASIC_ENABLED=false" -e "GF_AUTH_ANONYMOUS_ENABLED=true" -e "GF_AUTH_ANONYMOUS_ORG_ROLE=Admin"  -e "GF_SERVER_ROOT_URL=/" daocloud.io/liukuan73/grafana:5.0.0

kubernetes部署方式（推荐）：
安装grafana，grafana.yaml如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: monitoring-grafana
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: grafana
    spec:
      containers:
      - name: grafana
        image: daocloud.io/liukuan73/grafana:5.0.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3000
          protocol: TCP
        volumeMounts:
        - mountPath: /var
          name: grafana-storage
        env:
        - name: INFLUXDB_HOST
          value: monitoring-influxdb
        - name: GF_SERVER_HTTP_PORT
          value: "3000"
          # The following env variables are required to make Grafana accessible via
          # the kubernetes api-server proxy. On production clusters, we recommend
          # removing these env variables, setup auth for grafana, and expose the grafana
          # service using a LoadBalancer or a public IP.
        - name: GF_AUTH_BASIC_ENABLED
          value: "false"
        - name: GF_AUTH_ANONYMOUS_ENABLED
          value: "true"
        - name: GF_AUTH_ANONYMOUS_ORG_ROLE
          value: Admin
        - name: GF_SERVER_ROOT_URL
          # If you're only using the API Server proxy, set this value instead:
          # value: /api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
          value: /
      volumes:
      - name: grafana-storage
        emptyDir: {}
      nodeSelector:
        node-role.kubernetes.io/master: "true"
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
---
apiVersion: v1
kind: Service
metadata:
  labels:
    # For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons)
    # If you are NOT using this as an addon, you should comment out this line.
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: monitoring-grafana
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/tcp-probe: 'true'
    prometheus.io/tcp-probe-port: '80'
  name: monitoring-grafana
  namespace: kube-system
spec:
  type: NodePort
  # In a production setup, we recommend accessing Grafana through an external Loadbalancer
  # or through a public IP.
  # type: LoadBalancer
  # You could also use NodePort to expose the service at a randomly-generated port
  # type: NodePort
  ports:
  - port: 80
    targetPort: 3000
    nodePort: 30007
  selector:
    k8s-app: grafana

5.2 grafana配置

配置prometheus数据源：
点击“Add data source”配置数据源：

配置dashboard：
可以手工配置dashboard，也可以如下图直接使用官网上别人分享的已配好的模板，直接输入需要import的模板号即可：
效果：

一些比较实用的模板：

  • 315这个模板是cadvisor采集的各种指标的图表
  • 1860这个模板是node-exporter采集的各种主机相关的指标的图表
  • 6417这个模板是kube-state-metrics采集的各种k8s资源对象的状态的图表
  • 4859和4865这两个模板是blackbox-exporter采集的服务的http状态指标的图表（两个效果基本一样，选择其一即可）
  • 5345这个模板是blackbox-exporter采集的服务的网络状态指标的图表

6. 告警

设置警报和通知的主要步骤：

  • 安装配置Alertmanager
  • 配置Prometheus与Alertmanager通信
  • 在Prometheus中创建告警规则

6.1 告警组件AlertManager部署

部署文件alertmanager.yaml如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: alertmanager
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      name: alertmanager
      labels:
        app: alertmanager
    spec:
      containers:
      - name: alertmanager
        image: prom/alertmanager:v0.11.0
        args
          - '-config.file=/etc/alertmanager/config.yml'
          - '-storage.path=/alertmanager'
          - '-web.external-url=http://alertmanager:9093'
        ports:
        - name: alertmanager
          containerPort: 9093
#        env:
#        - name: EXTERNAL_URL
#          valueFrom:
#            configMapKeyRef:
#              name: external-url
#              key: url
        volumeMounts:
        - name: config-volume
          mountPath: /etc/alertmanager
#        - name: templates-volume
#          mountPath: /etc/alertmanager-templates
        - name: alertmanager
          mountPath: /alertmanager
      volumes:
      - name: config-volume
        configMap:
          name: alertmanager
#      - name: templates-volume
#        configMap:
#          name: alertmanager-templates
      - name: alertmanager
        emptyDir: {}
      nodeSelector:
        node-role.kubernetes.io/master: "true"
      tolerations:
      - key: "node-role.kubernetes.io/master"
        effect: "NoSchedule"
---
apiVersion: v1
kind: Service
metadata:
  name: alertmanager
  namespace: kube-system
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/alertmanager/metrics'
  labels:
    name: alertmanager
spec:
  selector:
    app: alertmanager
  type: NodePort
  ports:
  - name: alertmanager
    protocol: TCP
    port: 9093
    targetPort: 9093
    nodePort: 30008

alertmanager的配置文件configmap-alertmanager.yaml如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager
  namespace: kube-system
data:
  config.yml: |-
    global:
      resolve_timeout: 5m
      smtp_smarthost: 'smtp.exmail.qq.com:25'
      smtp_from: '[email protected]'
      smtp_auth_username: '[email protected]'
      smtp_auth_password: 'yourpassword'
      slack_api_url: ''
    route:
      receiver: slack-notifications
      group_by: ['alertname', 'cluster', 'service']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 15m
      routes:
      - match:
          severity: email
        receiver: email_alert
    receivers:
    - name: 'email_alert'
      email_configs:
      - to: '[email protected]'
        from: 'test.com'
        smarthost: "smtp.163.com:25"
        auth_username: "liukuan73"
        auth_password: "123456"
        require_tls: true
    - name: 'slack-notifications'
      slack_configs:
      - channel: '#alerts'
    - name: 'test-webhook'
      webhook_configs:
      - url: 'alertmanager:9093/api/v1/monitor'
        send_resolved: true

可以在运行时动态的重新加载配置文件，当重新加载配置文件失败时，不影响在运行的配置。重载方式：curl -XPOST http://IP:9093/-/reload。告警部分的配置语法请见官网文档

6.2 关联Prometheus与Alertmanager

在Prometheus的架构中被划分成两个独立的部分。Prometheus负责产生告警，而Alertmanager负责告警产生后的后续处理。因此Alertmanager部署完成后，需要在Prometheus中设置Alertmanager相关的信息。

编辑Prometheus配置文件prometheus.yml,并添加以下内容

    alerting:
      alertmanagers:
        - static_configs:
          - targets: ['alertmanager:9093']

reload Prometheus后可以在AlertManager的webui上查看告警信息：http://IP:Port

6.3 Alertmanager配置

Alertmanager的配置主要包含两个部分：路由(route)以及接收器(receivers)。所有的告警信息都会从配置中的顶级路由(route)进入路由树，根据路由规则将告警信息发送给相应的接收器。

在Alertmanager中可以定义一组接收器，比如可以按照角色(比如系统运维，数据库管理员)来划分多个接收器。接收器可以关联邮件，Slack以及其它方式接收告警信息。

route:
  receiver: 'default-receiver'
receivers:
  - name: default-receiver

以上配置文件中定义了一个默认的接收者default-receiver，由于这里没有设置接收方式，目前只相当于一个占位符。

在配置文件中使用route定义了顶级的路由，路由是一个基于标签匹配规则的树状结构。所有的告警信息从顶级路由开始，根据标签匹配规则进入到不同的子路由，并且根据子路由设置的接收器发送告警。目前配置文件中只设置了一个顶级路由route并且定义的接收器为default-receiver。因此，所有的告警都会发送给default-receiver。

6.3.1 路由(route)配置基础介绍

路由的配置格式如下：

[ receiver:  ]
[ group_by: '[' , ... ']' ]
[ continue:  | default = false ]
​
match:
  [ : , ... ]
​
match_re:
  [ : , ... ]
​
[ group_wait:  | default = 30s ]
​
[ group_interval:  | default = 5m ]
​
[ repeat_interval:  | default = 4h ]
​
routes:
  [ -  ... ]

首先每一个告警都会从配置文件中顶级的route进入路由树，需要注意的是顶级的route必须匹配所有告警，即不能有任何的匹配设置（match/match_re），每一个路由都可以定义自己的接收器。告警进入到顶级路由后会遍历所有的子节点。如果设置了continue的值为false，则告警在匹配到第一个子节点之后就直接停止。如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那么该告警将会基于当前路由节点的接收器配置方式进行处理。

其中告警的匹配有两种方式可以选择。一种方式基于字符串验证，通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。

在之前的部分有讲过，Alertmanager可以对告警通知进行分组，将多条告警合合并为一个通知。这里我们可以使用group_by来定义分组规则。基于告警中包含的标签，如果满足group_by中定义标签名称，那么这些告警将会合并为一个通知发送给接收器。

有的时候为了能够一次性收集和发送更多的相关信息，可以通过group_wait参数设置等待时间，如果在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送。

而group_interval配置，则用于定义相同的Gourp之间发送告警通知的时间间隔。

如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间，则可以通过repeat_interval参数进行设置。

案例

例如，当使用Prometheus监控多个集群以及部署在集群中的应用和数据库服务，并且定义以下的告警处理路由规则来对集群中的异常进行通知。

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
  routes:
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

默认情况下所有的告警都会发送给集群管理员default-receiver，因此在Alertmanager的配置文件的根路由中，对告警信息按照集群以及告警的名称对告警进行分组。

如果告警时来源于数据库服务如MySQL或者Cassandra，此时则需要将告警发送给相应的数据库管理员(database-pager)。这里定义了一个单独子路由，如果告警中包含service标签，并且service为MySQL或者Cassandra,则向database-pager发送告警通知，由于这里没有定义group_by等属性，这些属性的配置信息将从上级路由继承，database-pager将会接收到按cluser和alertname进行分组的告警通知。

而某些告警规则来源可能来源于开发团队的定义，这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下，定义单独子路由用于处理这一类的告警通知，如果匹配到告警中包含标签team，并且team的值为frontend，Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常，开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题，可以快速对应用进行问题定位。

更多路由配置实例请参考：https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/alert/alert-manager-routes

6.3.2 接收器(receiver)配置基础介绍

告警接收器可以通过以下形式进行配置：

receivers:
  -  ...

每一个receiver具有一个全局唯一的名称，并且对应一个或者多个通知方式：

name: 
email_configs:
  [ - , ... ]
hipchat_configs:
  [ - , ... ]
pagerduty_configs:
  [ - , ... ]
pushover_configs:
  [ - , ... ]
slack_configs:
  [ - , ... ]
opsgenie_configs:
  [ - , ... ]
webhook_configs:
  [ - , ... ]
victorops_configs:
  [ - , ... ]

目前官方内置的第三方通知集成包括：

  • 邮件
  • 即时通讯软件（如Slack、Hipchat）
  • 移动应用消息推送(如Pushover)
  • 自动化运维工具（例如：Pagerduty、Opsgenie、Victorops）
  • webhook，通过这种方式开发者可以实现更多个性化的扩展支持。

与SMTP邮件集成

每一个receiver可以对应一组邮件通知配置email_configs，如下所示：

name: 
email_configs:
  [ - , ... ]

email_config配置:

# Whether or not to notify about resolved alerts.
[ send_resolved:  | default = false ]
​
# The email address to send notifications to.
to: 
​
# The sender address.
[ from:  | default = global.smtp_from ]
​
# The SMTP host through which emails are sent.
[ smarthost:  | default = global.smtp_smarthost ]
​
# SMTP authentication information.
[ auth_username:  | default = global.smtp_auth_username ]
[ auth_password:  | default = global.smtp_auth_password ]
[ auth_secret:  | default = global.smtp_auth_secret ]
[ auth_identity:  | default = global.smtp_auth_identity ]
​
# The SMTP TLS requirement.
[ require_tls:  | default = global.smtp_require_tls ]
​
# The HTML body of the email notification.
[ html:  | default = '{{ template "email.default.html" . }}' ]
​
# Further headers email header key/value pairs. Overrides any headers
# previously set by the notification implementation.
[ headers: { : , ... } ]

如果所有的邮件配置使用了相同的SMTP配置，则可以直接定义全局的SMTP配置。

global:
  [ smtp_from:  ]
  [ smtp_smarthost:  ]
  [ smtp_auth_username:  ]
  [ smtp_auth_password:  ]
  [ smtp_auth_secret:  ]
  [ smtp_auth_identity:  ]
  [ smtp_require_tls:  | default = true ]

以Gmail邮箱为例:

global:
  smtp_smarthost: smtp.gmail.com:587
  smtp_from: 
  smtp_auth_username: 
  smtp_auth_identity: 
  smtp_auth_password: 
​
receivers:
  - name: default-receiver
    email_configs:
      - to:

6.3.3 使用Webhook扩展Alertmanager

在某些情况下除了Alertmanager已经内置的集中告警通知方式以外，对于不同的用户和组织而言还需要一些自定义的告知方式支持。通过Alertmanager提供的webhook支持可以轻松实现这一类的扩展。除了用于支持额外的通知方式，webhook还可以与其他第三方系统集成实现运维自动化，或者弹性伸缩等。

在Alertmanager中可以使用如下配置定义基于webhook的告警接收器receiver。一个receiver可以对应一组webhook配置。

name: 
webhook_configs:
  [ - , ... ]

每一项webhook_config的具体配置格式如下：

# Whether or not to notify about resolved alerts.
[ send_resolved:  | default = true ]
​
# The endpoint to send HTTP POST requests to.
url: 
​
# The HTTP client's configuration.
[ http_config:  | default = global.http_config ]

send_resolved用于指定是否在告警消除时发送回执消息。url则是用于接收webhook请求的地址。http_configs则是在需要对请求进行SSL配置时使用。

当用户定义webhook用于接收告警信息后，当告警被触发时，Alertmanager会按照以下格式向这些url地址发送HTTP Post请求，请求内容如下：

{
  "version": "4",
  "groupKey": ,    // key identifying the group of alerts (e.g. to deduplicate)
  "status": "",
  "receiver": ,
  "groupLabels": ,
  "commonLabels": ,
  "commonAnnotations": ,
  "externalURL": ,  // backlink to the Alertmanager.
  "alerts": [
    {
      "labels": ,
      "annotations": ,
      "startsAt": "",
      "endsAt": ""
    }
  ]
}


更多webhook方式实例请参看：https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/alert/alert-manager-extension-with-webhook




更多K8S精彩内容，请订阅本人微信公众号：K8SPractice
 




如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！


支付宝：                                                      微信：
 Kubernetes平台监控方案之：Exporters+Prometheus+Grafana_第2张图片                       Kubernetes平台监控方案之：Exporters+Prometheus+Grafana_第3张图片

























你可能感兴趣的:(kubernetes,监控)






    

  • ES聚合分析原理与代码实例讲解
光剑书架上的书
大厂Offer收割机面试题简历程序员读书硅基计算碳基计算认知计算生物计算深度学习神经网络大数据AIGCAGILLMJavaPython架构设计Agent程序员实现财富自由

    ES聚合分析原理与代码实例讲解1.背景介绍1.1问题的由来在大规模数据分析场景中，特别是在使用Elasticsearch（ES）进行数据存储和检索时，聚合分析成为了一个至关重要的功能。聚合分析允许用户对数据集进行细分和分组，以便深入探索数据的结构和模式。这在诸如实时监控、日志分析、业务洞察等领域具有广泛的应用。1.2研究现状目前，ES聚合分析已经成为现代大数据平台的核心组件之一。它支持多种类型的聚
    

    • 

  • Java爬虫框架（一）--架构设计
狼图腾-狼之传说
java框架java任务html解析器存储电子商务

    一、架构图那里搜网络爬虫框架主要针对电子商务网站进行数据爬取，分析，存储，索引。爬虫：爬虫负责爬取，解析，处理电子商务网站的网页的内容数据库：存储商品信息索引：商品的全文搜索索引Task队列：需要爬取的网页列表Visited表：已经爬取过的网页列表爬虫监控平台：web平台可以启动，停止爬虫，管理爬虫，task队列，visited表。二、爬虫1.流程1)Scheduler启动爬虫器，TaskMast
    

    • 

  • react-intl——react国际化使用方案
苹果酱0567
面试题汇总与解析java开发语言中间件springboot后端

    国际化介绍i18n：internationalization国家化简称，首字母+首尾字母间隔的字母个数+尾字母，类似的还有k8s(Kubernetes)React-intl是React中最受欢迎的库。使用步骤安装#usenpmnpminstallreact-intl-D#useyarn项目入口文件配置//index.tsximportReactfrom"react";importReactDOMf
    

    • 

  • 基于STM32与Qt的自动平衡机器人：从控制到人机交互的的详细设计流程
极客小张
stm32qt机器人物联网人机交互毕业设计c语言

    一、项目概述目标和用途本项目旨在开发一款基于STM32控制的自动平衡机器人，结合步进电机和陀螺仪传感器，实现对平衡机器人的精确控制。该机器人可以用于教育、科研、娱乐等多个领域，帮助用户了解自动控制、机器人运动学等相关知识。技术栈关键词STM32单片机步进电机陀螺仪传感器AD采集电路Qt人机界面实时数据监控二、系统架构系统架构设计本项目的系统架构设计包括以下主要组件：控制单元:STM32单片机传感器
    

    • 

  • Kubernetes数据持久化
看清所苡看轻
kubernetes(k8s)emptyDirHostPathpvpvckubernetes

    在k8s中，Volume（数据卷）存在明确的生命周期（与包含该数据卷的容器组（pod）相同）。因此Volume的生命周期比同一容器组（pod）中任意容器的生命周期要更长，不管容器重启了多少次，数据都被保留下来。当然，如果pod不存在了，数据卷自然退出了。此时，根据pod所使用的数据卷类型不同，数据可能随着数据卷的退出而删除，也可能被真正持久化，并在下次容器组重启时仍然可以使用。从根本上来说，一个数
    

    • 

  • 如何在电商平台上使用API接口数据优化商品价格
weixin_43841111
api数据挖掘人工智能pythonjava大数据前端爬虫

    利用API接口数据来优化电商商品价格是一个涉及数据收集、分析、策略制定以及实时调整价格的过程。这不仅能提高市场竞争力，还能通过精准定价最大化利润。以下是一些关键步骤和策略，用于通过API接口数据优化电商商品价格：1.数据收集竞争对手价格监控：使用API接口（如Scrapy、BeautifulSoup等工具结合Python进行网页数据抓取，或使用专门的API服务如PriceIntelligence、
    

    • 

  • 网关gateway学习总结
猪猪365
学习总结学习总结

    一微服务概述:微服务网关就是一个系统!通过暴露该微服务的网关系统,方便我们进行相关的鉴权,安全控制,日志的统一处理,易于监控的相关功能!实现微服务网关技术都有哪些呢?1nginx:nginx是一个高性能的http和反向代理web的服务器,同事也提供了IMAP/POP3/SMTP服务.他可以支撑5万并发链接,并且cpu,内存等资源消耗非常的低,运行非常的稳定!2Zuul:Zuul是Netflix公司
    

    • 

  • Kubernetes部署MySQL数据持久化
沫殇-MS
KubernetesMySQL数据库kubernetesmysql容器

    一、安装配置NFS服务端1、安装nfs-kernel-server：sudoapt-yinstallnfs-kernel-server2、服务端创建共享目录#列出所有可用块设备的信息lsblk#格式化磁盘sudomkfs-text4/dev/sdb#创建一个目录：sudomkdir-p/data/nfs/mysql#更改目录权限：sudochown-Rnobody:nogroup/data/nfs
    

    • 

  • Kubernetes的3种数据持久化方式
Seal^_^
【云原生】容器化与编排技术持续集成#Kuberneteskubernetes容器云原生EmptyDir面试HostPath

    Kubernetes的3种数据持久化方式1.EmptyDir2.HostPath3.PersistentVolume(PV)TheBegin点点关注，收藏不迷路Kubernetes提供了几种数据持久化方式，以满足不同场景的需求：1.EmptyDir用途：临时数据存储，Pod内容器间共享。特点：生命周期与Pod相同，Pod删除时数据也删除。2.HostPath用途：访问宿主机特定文件或目录。特点：增
    

    • 

  • 【Kubernetes】常见面试题汇总（十一）
summer.335
Kuberneteskubernetes容器云原生

    目录33.简述Kubernetes外部如何访问集群内的服务？34.简述Kubernetesingress？35.简述Kubernetes镜像的下载策略？33.简述Kubernetes外部如何访问集群内的服务？（1）对于Kubernetes，集群外的客户端默认情况，无法通过Pod的IP地址或者Service的虚拟IP地址：虚拟端口号进行访问。（2）通常可以通过以下方式进行访问Kubernetes集群
    

    • 

  • k8s中Service暴露的种类以及用法
听说唐僧不吃肉
K8Skubernetes容器云原生

    一、说明在Kubernetes中，有几种不同的方式可以将服务（Service）暴露给外部流量。这些方式通过定义服务的spec.type字段来确定。二、详解1.ClusterIP定义：默认类型，服务只能在集群内部访问。作用：通过集群内部IP地址暴露服务。示例：spec:type:ClusterIPports:-port:80targetPo
    

    • 

  • Kubernetes 自定义控制器开发
IT回忆录
Kubeneteskubernetes

    目录前言一、CRD二、创建数据库表（Mysql）二、控制器开发1.使用kubernetes的examplecontroller模板2.在controller.go中新增数据表监听方法3.修改tools工具生成资源对象结构体定义这里记录开发k8s控制器的一般方式，controller开发主要使用k8s提供的client-go库进行。前言Controller监听集群内部资源对象的变化，编辑资源对象(增
    

    • 

  • 用kubedam搭建的k8s证书过期处理方法
我滴鬼鬼呀wks
k8s1024程序员节

    kubeadm部署的k8s证书过期1、查看证书过期时间kubeadmalphacertscheck-expiration若证书已经过期无法试用kubectl命令建议修改服务器时间到未过期的时间段2、配置kube-controller-manager.yaml文件cat/etc/kubernetes/manifests/kube-controller-manager.yamlapiVersion:v
    

    • 

  • k8s证书过期问题处理
olina_qin
kubernetes容器云原生

    k8s证书过期问题处理opensslx509-in/etc/kubernetes/pki/apiserver.crt-noout-dateskubeadmcertsrenewallsystemctlrestartkubeleopensslx509-in/etc/kubernetes/pki/apiserver.crt-noout-text|grep"NotAfter"cp/etc/kubernet
    

    • 

  • Kubernetes Ingress 控制器（Nginx）安装与使用教程
农优影

    KubernetesIngress控制器（Nginx）安装与使用教程kubernetes-ingressNGINXandNGINXPlusIngressControllersforKubernetes项目地址:https://gitcode.com/gh_mirrors/ku/kubernetes-ingress1.项目目录结构及介绍在nginxinc/kubernetes-ingress仓库中，
    

    • 

  • 【K8s】专题十一：Kubernetes 集群证书过期处理方法
行者Sun1989
Kuberneteskubernetes云原生容器

    本文内容均来自个人笔记并重新梳理，如有错误欢迎指正！如果对您有帮助，烦请点赞、关注、转发、订阅专栏！专栏订阅入口Linux专栏|Docker专栏|Kubernetes专栏往期精彩文章【Docker】（全网首发）KylinV10下MySQL容器内存占用异常的解决方法【Docker】（全网首发）KylinV10下MySQL容器内存占用异常的解决方法（续）【Docker】MySQL源码构建Docker镜
    

    • 

  • Java面试笔记记录6
今天背八股了吗
java面试笔记

    1.Spring是什么？特性？有哪些模块？Spring是一个轻量级、非入侵式的控制反转Ioc和面向切面AOP的框架。特性：1.Ioc和DISpring的核心就是一个大的工厂容器，可以维护所有对象的创建和依赖关系，Spring工厂用于生成Bean，并且管理Bean的生命周期，实现高内聚低耦合的设计理念。2.AOP编程Spring提供面向切面编程，可以方便实现对程序进行权限拦截、运行监控等切面功能。3
    

    • 

  • sentinel 不显示项目_Sentinel相关问题记录
weixin_39840606
sentinel不显示项目

    SentinelFAQ整理Sentinel承接阿里巴巴近10年双十一大促流量的核心场景，以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。其提供丰富的应用场景支持、完备的监控能力、易用的拓展点。Note:中文文档请见此处。热点问题1、Q:dashboard不展示监控问题如何排查？dashboard是一个单独启动的控制台，引入sentinel的应用是一个客户端。它们各自有
    

    • 

  • Sentinel
眼泪落在琴弦
springcloudjavajava

    Sentinel（服务熔断降级限流）1.引入spring-cloud-starter-alibaba-sentinel2.下载sentinel服务器3.配置application地址信息4.在控制台调整参数【默认所以流控设置保存在内存中，重启失效】5.想实时监控需每个微服务导入actuator，并配置application暴露所有端口6.自定义sentinel流控返回数据7.配置sentinel类
    

    • 

  • Sentinel实时监控不展示问题
朱杰jjj
sentinelsentinel

    问题官方插件Endpoint支持，可以实时统计出SpringBoot的健康状况和请求的调用信息在使用Endpoint特性之前需要在Maven中添加spring-boot-starter-actuator依赖，并在配置中允许Endpoints的访问。SpringBoot1.x中添加配置management.security.enabled=false。暴露的endpoint路径为/sentinelS
    

    • 

  • Docker学习十一：Kubernetes概述
爱打羽球的程序猿
Docker学习系列dockerkubernetes学习

    一、Kubernetes简介2006年，Google提出了云计算的概念，当时的云计算领域还是以虚拟机为代表的云平台。2013年，Docker横空出世，Docker提出了镜像、仓库等核心概念，规范了服务的交付标准，使得复杂服务的落地变得更加简单，之后Docker又定义了OCI标准，Docker在容器领域称为事实的标准。但是，Docker诞生只是帮助定义了开发和交付标准，如果想要在生产环境中大批量的使
    

    • 

  • Cloud Native Weekly | 华为云抢先发布Redis5.0，红帽宣布收购混合云提供商
weixin_34302561
数据库devops大数据

    1——华为云抢先发布Redis5.02——DigitalOceanK8s服务正式上线3——红帽宣布收购混合云提供商NooBaa4——微软发布多项AzureKubernetes服务更新1华为云抢先发布Redis5.012月17日，华为云在DCS2.0的基础上，快人一步，抢先推出了新的Redis5.0产品，这是一个崭新的突破。目前国内在缓存领域的发展普遍停留在Redis4.0阶段，华为云率先发布了Re
    

    • 

  • Python和MATLAB及C++信噪比导图(算法模型)
亚图跨际
算法交叉知识Python视频图像修复模数转换信号链噪音频谱计算量化周期性视觉刺激高斯噪声的矩形脉冲心率失常检测算法

    要点视频图像修复模数转换中混合信号链噪音测量频谱计算和量化周期性视觉刺激脑电图高斯噪声的矩形脉冲总谐波失真周期图功率谱密度各种心率失常检测算法胶体悬浮液跟踪检测计算交通监控摄像头图像噪音计算Python信噪比信噪比是科学和工程中使用的一种测量方法，用于比较所需信号水平与背景噪声水平。信噪比定义为信号功率与噪声功率之比，通常以分贝表示。高于1:1（大于0dB）的比率表示信号大于噪声。信噪比是影响处理
    

    • 

  • 华为云分布式缓存服务DCS与开源服务差异对比
hcinfo_18
redis使用华为云Redis5.0分布式缓存服务Redis客户端

    分布式缓存服务DCS提供单机、主备、集群等丰富的实例类型，满足用户高读写性能及快速数据访问的业务诉求。支持丰富的实例管理操作，帮助用户省去运维烦恼。用户可以聚焦于业务逻辑本身，而无需过多考虑部署、监控、扩容、安全、故障恢复等方面的问题。DCS基于开源Redis、Memcached向用户提供一定程度定制化的缓存服务，因此，除了拥有开源服务缓存数据库的优秀特性，DCS提供更多实用功能。一、与开源Red
    

    • 

  • php服务器状态监测,PHP网站状态在线监控源码
傲雪吟霜白如冰
php服务器状态监测

    在网上找的一个在线监控源码，比较简单，但是功能也略有不足，例如如果网站挂了就按照监控频率一直发邮件提示，网站恢复之后不会发邮件通知；不能直接填写要监控的网址或者某一页面，适合监控大量的网站或者vps、服务器。最新使用感受：没有发送邮件限制，我设置监控频率是一个小时，一天没管就把邮箱塞满了。如果服务器恢复的话不会专门发邮件提醒。如果只是监控几个站的话有很多免费的监控网站可以使用，只是使用数量上有限制
    

    • 

  • php状态监控源码,PHP服务器状态监控实现程序
江子星
php状态监控源码

    */header('Content-type:text/html;charset=utf-8');include'./smtp/class.smtp.php';include'./smtp/class.phpmailer.php';functionsendmail($subject='',$body=''){date_default_timezone_set('Asia/Shanghai');//
    

    • 

  • 服务器状态监控php源码,服务器状态监控_监控Linux服务器网站状态的SHELL脚本
温糯米
服务器状态监控php源码

    摘要腾兴网为您分享:监控Linux服务器网站状态的SHELL脚本，蜗牛集市，同花顺，探客宝，手柄助手等软件知识，以及日期倒计时插件，云南省教育资源公共，rui手机桌面，小屁孩桌面便签，合金装备崛起复仇，朝夕日历，photoshop图像处理软件,一年级学生每日计划表，悟空找房，饿了吗外卖商家版，逃生，中国民宿网，realpolitiks，交通安全知识竞赛，雅思流利说等软件it资讯，欢迎关注腾兴网。1
    

    • 

  • Dubbo架构概览：服务注册与发现、远程调用、监控与管理
木南曌
dubbo架构

    Dubbo是一个成熟的、高性能的、基于Java的微服务开发框架，它主要用于解决分布式系统中的服务治理问题，包括服务的注册与发现、远程过程调用（RPC）、服务监控与管理等多个关键环节。以下是Dubbo架构概览的详细介绍：服务注册与发现Dubbo的服务注册与发现机制是其核心功能之一，它依赖于注册中心来管理服务的生命周期和定位服务提供者。1.服务提供者（Provider）服务提供者是实际提供服务的节点，
    

    • 

  • STM32 如何生成随机数
千千道
STM32stm32单片机物联网

    目录一、引言二、STM32随机数发生器概述三、工作原理1.噪声源2.线性反馈移位寄存器（LFSR）3.数据寄存器（RNG_DR）4.监控和检测电路：5.控制和状态寄存器6.生成流程四、使用方法1.使能随机数发生器2.读取随机数3.错误处理五、注意事项1.随机数的质量2.安全性3.性能考虑六、总结一、引言在嵌入式系统开发中，随机数的生成常常是一个重要的需求。无论是用于加密、模拟、游戏还是其他需要不确
    

    • 

  • （k8s）Kubernetes 从0到1容器编排之旅
道不贱卖，法不轻传
kubernetskubernetes容器云原生

    一、引言在当今数字化的浪潮中，Kubernetes如同一艘强大的航船，引领着容器化应用的部署与管理。它以其卓越的灵活性、可扩展性和可靠性，成为众多企业和开发者的首选。然而，要真正发挥Kubernetes的强大威力，仅仅掌握基本操作是远远不够的。本文将带你深入探索Kubernetes使用过程中的奇技妙法，为你开启一段优雅的容器编排之旅。二、高级资源管理之精妙艺术1.资源配额与限制：雕琢资源之美•Ku
    

    • 

  • mysql主从数据同步
林鹤霄
mysql主从数据同步

    配置mysql5.5主从服务器(转)
教程开始：一、安装MySQL
说明：在两台MySQL服务器192.168.21.169和192.168.21.168上分别进行如下操作，安装MySQL 5.5.22
 二、配置MySQL主服务器（192.168.21.169）mysql  -uroot  -p   &nb
    

    • 

  • oracle学习笔记
caoyong
oracle

    1、ORACLE的安装
   a>、ORACLE的版本
   8i,9i :   i是internet
   10g,11g : grid (网格)
   12c : cloud (云计算)
  
   b>、10g不支持win7
&
    

    • 

  • 数据库，SQL零基础入门
天子之骄
sql数据库入门基本术语

    数据库，SQL零基础入门
       做网站肯定离不开数据库，本人之前没怎么具体接触SQL，这几天起早贪黑得各种入门，恶补脑洞。一些具体的知识点，可以让小白不再迷茫的术语，拿来与大家分享。
 
       数据库，永久数据的一个或多个大型结构化集合，通常与更新和查询数据的软件相关
    

    • 

  • pom.xml
一炮送你回车库
pom.xml

    1、一级元素dependencies是可以被子项目继承的
2、一级元素dependencyManagement是定义该项目群里jar包版本号的，通常和一级元素properties一起使用，既然有继承，也肯定有一级元素modules来定义子元素
3、父项目里的一级元素<modules>
<module>lcas-admin-war</module>
<
    

    • 

  • sql查地区省市县
3213213333332132
sqlmysql

    
-- db_yhm_city
SELECT * FROM db_yhm_city WHERE class_parent_id = 1 -- 海南 class_id = 9 港、奥、台 class_id = 33、34、35
SELECT * FROM db_yhm_city WHERE class_parent_id =169
SELECT d1.cla
    

    • 

  • 关于监听器那些让人头疼的事
宝剑锋梅花香
画图板监听器鼠标监听器

           本人初学JAVA，对于界面开发我只能说有点蛋疼，用JAVA来做界面的话确实需要一定的耐心（不使用插件，就算使用插件的话也没好多少）既然Java提供了界面开发，老师又要求做，只能硬着头皮上啦。但是监听器还真是个难懂的地方，我是上了几次课才略微搞懂了些。
      
    

    • 

  • JAVA的遍历MAP
darkranger
map

    Java Map遍历方式的选择
1. 阐述
　　对于Java中Map的遍历方式，很多文章都推荐使用entrySet，认为其比keySet的效率高很多。理由是：entrySet方法一次拿到所有key和value的集合；而keySet拿到的只是key的集合，针对每个key，都要去Map中额外查找一次value，从而降低了总体效率。那么实际情况如何呢？
　　为了解遍历性能的真实差距，包括在遍历ke
    

    • 

  • POJ 2312 Battle City 优先多列+bfs
aijuans
搜索

    来源：http://poj.org/problem?id=2312
题意：题目背景就是小时候玩的坦克大战，求从起点到终点最少需要多少步。已知S和R是不能走得，E是空的，可以走，B是砖，只有打掉后才可以通过。
思路：很容易看出来这是一道广搜的题目，但是因为走E和走B所需要的时间不一样，因此不能用普通的队列存点。因为对于走B来说，要先打掉砖才能通过，所以我们可以理解为走B需要两步，而走E是指需要1
    

    • 

  • Hibernate与Jpa的关系，终于弄懂
avords
javaHibernate数据库jpa

    我知道Jpa是一种规范，而Hibernate是它的一种实现。除了Hibernate，还有EclipseLink(曾经的toplink)，OpenJPA等可供选择，所以使用Jpa的一个好处是，可以更换实现而不必改动太多代码。
在play中定义Model时，使用的是jpa的annotations，比如javax.persistence.Entity, Table, Column, OneToMany
    

    • 

  • 酸爽的console.log
bee1314
console

    在前端的开发中，console.log那是开发必备啊，简直直观。通过写小函数，组合大功能。更容易测试。但是在打版本时，就要删除console.log，打完版本进入开发状态又要添加，真不够爽。重复劳动太多。所以可以做些简单地封装，方便开发和上线。
/**
* log.js hufeng
* The safe wrapper for `console.xxx` functions
* 
    

    • 

  • 哈佛教授：穷人和过于忙碌的人有一个共同思维特质
bijian1013
时间管理励志人生穷人过于忙碌

            一个跨学科团队今年完成了一项对资源稀缺状况下人的思维方式的研究，结论是：穷人和过于忙碌的人有一个共同思维特质，即注意力被稀缺资源过分占据，引起认知和判断力的全面下降。这项研究是心理学、行为经济学和政策研究学者协作的典范。
　　这个研究源于穆来纳森对自己拖延症的憎恨。他7岁从印度移民美国，很快就如鱼得水，哈佛毕业
    

    • 

  • other operate
征客丶
OSosx

    一、Mac Finder 设置排序方式，预览栏 在显示－》查看显示选项中
二、有时预览显示时，卡死在那，有可能是一些临时文件夹被删除了，如：/private/tmp[有待验证]
--------------------------------------------------------------------
若有其他凝问或文中有错误，请及时向我指出，
我好及时改正，同时也让我们一
    

    • 

  • 【Scala五】分析Spark源代码总结的Scala语法三
bit1129
scala

    1. If语句作为表达式
val properties = if (jobIdToActiveJob.contains(jobId)) {
jobIdToActiveJob(stage.jobId).properties
} else {
// this stage will be assigned to "default" po
    

    • 

  • ZooKeeper 入门
BlueSkator
中间件zk

    ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得ZooKeeper解决很多分布式问题。网上对ZK的应用场景也有不少介绍，本文将结合作者身边的项目例子，系统地对ZK的应用场景进行一个分门归类的介绍。
值得注意的是，ZK并非天生就是为这些应用场景设计的，都是后来众多开发者根据其框架的特性，利
    

    • 

  • MySQL取得当前时间的函数是什么 格式化日期的函数是什么
BreakingBad
mysqlDate

    取得当前时间用 now() 就行。
在数据库中格式化时间 用DATE_FORMA T(date, format) .
根据格式串format 格式化日期或日期和时间值date，返回结果串。
可用DATE_FORMAT( ) 来格式化DATE 或DATETIME 值，以便得到所希望的格式。根据format字符串格式化date值:
%S, %s 两位数字形式的秒（ 00,01,
    

    • 

  • 读《研磨设计模式》-代码笔记-组合模式
bylijinnan
java设计模式

    声明： 本文只为方便我个人查阅和理解，详细的分析以及源代码请移步 原作者的博客http://chjavach.iteye.com/
import java.util.ArrayList;
import java.util.List;
abstract class Component {
public abstract void printStruct(Str
    

    • 

  • 4_JAVA+Oracle面试题(有答案)
chenke
oracle

    基础测试题
卷面上不能出现任何的涂写文字，所有的答案要求写在答题纸上，考卷不得带走。
选择题
1、 What will happen when you attempt to compile and run the following code? （3）
public class Static {
static {
int x = 5; // 在static内有效
}
st
    

    • 

  • 新一代工作流系统设计目标
comsci
工作算法脚本

    
  用户只需要给工作流系统制定若干个需求，流程系统根据需求，并结合事先输入的组织机构和权限结构，调用若干算法，在流程展示版面上面显示出系统自动生成的流程图，然后由用户根据实际情况对该流程图进行微调，直到满意为止，流程在运行过程中，系统和用户可以根据情况对流程进行实时的调整，包括拓扑结构的调整，权限的调整，内置脚本的调整。。。。。
在这个设计中，最难的地方是系统根据什么来生成流
    

    • 

  • oracle 行链接与行迁移
daizj
oracle行迁移

    表里的一行对于一个数据块太大的情况有二种(一行在一个数据块里放不下)
第一种情况:
INSERT的时候，INSERT时候行的大小就超一个块的大小。Oracle把这行的数据存储在一连串的数据块里(Oracle Stores the data for the row in a chain of data blocks)，这种情况称为行链接(Row Chain)，一般不可避免(除非使用更大的数据
    

    • 

  • [JShop]开源电子商务系统jshop的系统缓存实现
dinguangx
jshop电子商务

    前言
jeeshop中通过SystemManager管理了大量的缓存数据，来提升系统的性能，但这些缓存数据全部都是存放于内存中的，无法满足特定场景的数据更新（如集群环境）。JShop对jeeshop的缓存机制进行了扩展，提供CacheProvider来辅助SystemManager管理这些缓存数据，通过CacheProvider,可以把缓存存放在内存,ehcache,redis，memcache
    

    • 

  • 初三全学年难记忆单词
dcj3sjt126com
englishword

    several 儿子；若干
shelf 架子
knowledge 知识；学问
librarian 图书管理员
abroad 到国外，在国外
surf 冲浪
wave 浪；波浪
twice 两次；两倍
describe 描写；叙述
especially 特别；尤其
attract 吸引
prize 奖品；奖赏
competition 比赛；竞争
event 大事；事件
O
    

    • 

  • sphinx实践
dcj3sjt126com
sphinx

     
安装参考地址:http://briansnelson.com/How_to_install_Sphinx_on_Centos_Server
 
yum install sphinx
如果失败的话使用下面的方式安装
wget http://sphinxsearch.com/files/sphinx-2.2.9-1.rhel6.x86_64.rpm
yum loca
    

    • 

  • JPA之JPQL（三）
frank1234
ormjpaJPQL

    1 什么是JPQL
JPQL是Java Persistence Query Language的简称，可以看成是JPA中的HQL， JPQL支持各种复杂查询。
2 检索单个对象
@Test
public  void querySingleObject1() {
    Query query = em.createQuery("sele
    

    • 

  • Remove Duplicates from Sorted Array II
hcx2013
remove

    Follow up for "Remove Duplicates":What if duplicates are allowed at most twice?
For example,Given sorted array nums = [1,1,1,2,2,3],
Your function should return length 
    

    • 

  • Spring4新特性——Groovy Bean定义DSL
jinnianshilongnian
spring 4

    Spring4新特性——泛型限定式依赖注入
Spring4新特性——核心容器的其他改进
Spring4新特性——Web开发的增强
Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC 
Spring4新特性——Groovy Bean定义DSL
Spring4新特性——更好的Java泛型操作API 
Spring4新
    

    • 

  • CentOS安装Mysql5.5
liuxingguome
centos

    CentOS下以RPM方式安装MySQL5.5
首先卸载系统自带Mysql：
yum remove mysql mysql-server mysql-libs compat-mysql51
rm -rf /var/lib/mysql
rm /etc/my.cnf
查看是否还有mysql软件：
rpm -qa|grep mysql
去http://dev.mysql.c
    

    • 

  • 第14章 工具函数（下）
onestopweb
函数

    index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/
    

    • 

  • POJ 1050
SaraWon
二维数组子矩阵最大和

    POJ ACM第1050题的详细描述，请参照
http://acm.pku.edu.cn/JudgeOnline/problem?id=1050
题目意思：
给定包含有正负整型的二维数组，找出所有子矩阵的和的最大值。
如二维数组
0 -2 -7 0
9 2 -6 2
-4 1 -4 1
-1 8 0 -2
中和最大的子矩阵是
9 2
-4 1
-1 8
且最大和是15
    

    • 

  • [5]设计模式——单例模式
tsface
java单例设计模式虚拟机

    单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点
 
安全的单例模式：
 
 
/*
* @(#)Singleton.java 2014-8-1
*
* Copyright 2014 XXXX, Inc. All rights reserved.
*/
package com.fiberhome.singleton;

    

    • 

  • Java8全新打造，英语学习supertool
yangshangchuan
javasuperword闭包java8函数式编程

    superword是一个Java实现的英文单词分析软件，主要研究英语单词音近形似转化规律、前缀后缀规律、词之间的相似性规律等等。Clean code、Fluent style、Java8 feature: Lambdas, Streams and Functional-style Programming。
 
升学考试、工作求职、充电提高，都少不了英语的身影，英语对我们来说实在太重要
    

    •