OpenShift 4 监控技术栈解析

2022-04-21 14:47:35 浏览数 (1)

概述

红帽OpenShift 4.6最新版刚出来, 最新的监控技术栈经过了较大的调整并且GA(生产可用)了.

架构长这样, 我们来看一下:

看起来还是非常复杂的, 第一次看到这个架构可能一脸懵逼.

之所以要做这么复杂, 我能理解的核心原因就1个:

  • 在产品标准化和交付定制化之间找到平衡

这就包括:

  1. 方便实施: 安装部署;
  2. 方便升级
  3. 方便撇清权责(非贬义)

下面我们来一起看一下.

了解 红帽OpenShift 4监控技术栈

概述

默认平台监控级别

OpenShift 4 包括一个预配置、预安装和自我更新的监控技术栈，用于监控核心平台组件。OpenShift 4 提供了与监控相关的现成的最佳实践。其中默认包括一组警报，可立即就集群问题通知集群管理员。OpenShift 4 控制台中的默认仪表板包括集群指标的直观表示，以帮助快速了解集群状态。

用户自定义级别

安装 OpenShift Container Platform 4.6 后，集群管理员可以选择性地为用户定义的项目启用监控。通过使用此功能，集群管理员、开发人员和其他用户可以指定在其自己的项目中如何监控服务和 Pod。然后，您可以在 OpenShift Container Platform web 控制台中查询指标、查看仪表板，并管理您自己的项目的警报规则和静默。

监控技术栈

OpenShift 4 监控堆栈基于 Prometheus 开源项目及其更广的生态系统。监控堆栈包括以下组件：

  • 默认平台监控组件。在 OpenShift 4 安装过程中，默认会在 openshift-monitoring namespace(租户) 中安装一组平台监控组件。这为包括 Kubernetes 服务在内的 OpenShift 4 核心组件提供了监控。默认监控堆栈还为集群启用远程健康状态监控。上图中的默认安装部分说明了这些组件。
  • 用于监控用户定义项目的组件。在选择性地为用户定义的项目启用监控后，会在 openshift-user-workload-monitoring 项目中安装其他监控组件。这为用户定义的项目提供了监控。上图中的用户部分说明了这些组件。
默认平台监控组件

默认情况下，OpenShift Container Platform 4.6 监控堆栈包括以下组件：

组件

描述

Cluster Monitoring Operator

Cluster Monitoring Operator (CMO) 是监控堆栈的核心组件。它负责部署和管理 Prometheus 实例、Thanos Querier、Telemeter 客户端和指标目标，并确保它们保持最新状态。CMO 由 Cluster Version Operator (CVO) 部署。

Prometheus Operator

openshift-monitoring 项目中的 Prometheus Operator (PO) 负责创建、配置和管理平台 Prometheus 实例和 Alertmanager 实例。它还会根据 Kubernetes 标签查询来自动生成监控目标配置。

Prometheus

Prometheus 是 OpenShift Container Platform 监控堆栈所依据的监控系统。Prometheus 是一个时间序列数据库和用于指标的规则评估引擎。Prometheus 将警报发送到 Alertmanager 进行处理。

Prometheus Adapter

Prometheus Adapter（上图中的 PA）负责转换 Kubernetes 节点和 Pod 查询以便在 Prometheus 中使用。转换的资源指标包括 CPU 和内存使用率指标。Prometheus Adapter 会公开用于 Pod 横向自动扩展的集群资源指标 API。Prometheus Adapter 也用于 oc adm top nodes 和 oc adm top pods 命令。

Alertmanager

Alertmanager 服务处理从 Prometheus 接收的警报。Alertmanager 还负责将警报发送到外部通知系统。

kube-state-metrics 代理

kube-state-metrics 导出器代理（上图中的 KSM）将 Kubernetes 对象转换为 Prometheus 可使用的指标。

openshift-state-metrics 代理

openshift-state-metrics 导出器（上图中的 OSM）通过添加了对特定 OpenShift Container Platform 资源的指标数据扩展了 kube-state-metrics。

node-exporter 代理

node-exporter 代理（上图中的 NE）负责收集有关集群中每个节点的指标。node-exporter 代理部署在每个节点上。

Thanos querier

Thanos Querier 将 OpenShift 核心指标和用于用户定义项目的指标聚合在单个多租户接口下，并选择性地进行重复数据删除。

Grafana

Grafana 分析平台提供用于分析和直观呈现指标的仪表板。由监控堆栈提供的 Grafana 实例及其仪表板是只读的。

Telemeter Client

Telemeter Client 将数据的子部分从平台 Prometheus 实例发送到红帽，以便为集群提供远程健康状态监控。

监控技术栈中的所有组件都由技术栈自监控，并在 OpenShift 更新时自动更新。

默认监控目标

除了监控技术栈本身的组件外，默认监控堆栈还监控：

  • CoreDNS
  • Elasticsearch（如果安装了 Logging 组件, 配置了日志监控全套.）
  • etcd
  • Fluentd（如果安装了 Logging）
  • HAProxy (openshift 使用HAProxy作为 ingress)
  • 镜像 registry
  • Kubelets
  • Kubernetes apiserver
  • Kubernetes 控制器管理器
  • Kubernetes 调度程序
  • Metering（如果安装了 Metering）
  • OpenShift apiserver (openshift 出了k8s api server, 还有openshift apiserver. 用于处理如ImageStream, BuildConfig, DeploymentConfig等openshift特有resources)
  • OpenShift 控制器管理器
  • Operator Lifecycle Manager (OLM)

对于默认的监控目标, 如果有bug, 是可以提的. 其他 OpenShift 框架组件也可能会公开指标, 这里不详细介绍。

用于监控用户定义的项目的组件

OpenShift 4.6 包括对监控堆栈的可选功能增强，已用于监控用户定义的项目中的服务和 Pod。此功能包括以下组件：

组件

描述

Prometheus Operator

openshift-user-workload-monitoring 项目(即租户)中的 Prometheus Operator (PO) 在同一项目中创建、配置和管理 Prometheus 和 Thanos Ruler 实例。

Prometheus

Prometheus 是为用户定义的项目提供监控的监控系统。Prometheus 将警报发送到 Alertmanager 进行处理。

Thanos Ruler

Thanos Ruler 是 Prometheus 的一个规则评估引擎，作为一个独立的进程来部署。在 OpenShift 4.6 中，Thanos Ruler 为监控用户定义的项目提供规则和警报评估。

用户定义的项目的监控目标

为用户定义的项目启用监控后，您可以监控：

  • 通过用户定义的项目中的服务端点提供的指标。
  • 在用户定义的项目中运行的 Pod。

对于我这边来说, openshift-user-workload-monitoring自带的组件还不够. 还通过Operator或其他手段额外部署了以下组件:

  1. Prometheus Adapter -- 公开用于 Pod 横向自动扩展的集群资源指标 API。比如: mq的队列排队数, java应用的jdbc pending数等;
  2. Grafana -- openshift4是严禁你乱动openshift-monitoring 这个租户的, 否则可能无法升级, 出问题不负责. 所以, 需要再在openshift-user-workload-monitoring中部署一个Grafana. 这个Grafana就是给容器平台的使用人员看的. 有2个选择: 我这边选择对接 Thanos querier. 因为可以通过这一个Grafana给到使用人员完整的监控信息.
    1. 对接openshift-user-workload-monitoring的prometheus;
    2. 对接 Thanos querier.

我这边, 生产通过openshift-user-workload-monitoring, 各类Exporter, 以及Prometheus Operator的以下CustomeResources

  • ServiceMonitor
  • PodMonitor
  • PrometheusRule

实现了对我们公司以下技术栈的监控:

  • JAVA
  • Python
  • Nodejs
  • Golang
  • NGINX
  • RabbitMQ
  • Redis
  • Kafka

总结

OpenShift 4的监控技术栈, 说实话, 站在用户的角度来看: 1套容器集群而已, 还用2套共4个prometheus, 再加上Thanos. 纯属简单事情复杂化. 秀技术.

但如果站在实施经理 交付角度来看, 确实较好地 在产品标准化和交付定制化之间找到平衡. 在不同国家, 不同行业, 各种各样复杂多变的用户环境下, 交付起来就很简单:

  1. 默认平台监控给你备齐, 开箱即用, 都是最佳实践; 如果这能满足用户那就最好了. 万事大吉.
  2. 什么? 还需要自定义的监控? 好, 几个yaml 自定义的监控技术栈搭建好了. 接下来用嘛, 就是用户这边的事情了, 用户用崩了, 也没关系, 默认平台监控还是岁月静好, 在那里工作.
云计算 kubernetes

0 人点赞