Kubernetes Scheduler 工作原理 kubernetes crd operator

转载

云端筑梦大师 2024-01-02 16:27:51

文章标签 kubernetes 自定义 Server API 文章分类 kubernetes 云计算

一、背景

随着云原生概念盛行，对于容器、服务、节点以及集群的监控变得越来越重要。Prometheus作为Kubernetes监控的事实标准，有着强大的功能和良好的生态。但是它不支持分布式，不支持数据导入、导出，不支持通过API修改监控目标和报警规则，所以在使用它时，通常需要写脚本和代码来简化操作。

二、Operator介绍

Operator是由CoreOS公司开发的用来扩展Kubernetes API的特定应用程序控制器，用来创建、配置和管理复杂的有状态应用，例如数据库、缓存和监控系统。Operator基于kubernetes的资源和控制器概念上构建，但同时又包含了应用程序特定的领域知识。创建Operator的关键是CRD（自定义资源）的设计。

Operator是将运维人员对软件操作的知识代码化，同时利用Kubernetes强大的抽象来管理大规模的软件应用。目前CoreOS官方提供了几种Operator的实现，其中就包括了Prometheus Operator。

Operator的核心实现是基于Kubernetes的以下两个概念：

资源：对象的状态定义
控制器：观测、分析和行动，以调节资源的分布

当前CoreOS提供了四种Operator：

etcd：创建etcd集群
Rook：云原生环境下的文件、块、对象存储服务
Prometheus：创建Prometheus监控实例
Tectonic：部署Kubernetes集群

三、Prometheus Operator介绍

Prometheus Operator为监控Kubernetes Service、Deployment和Prometheus实例的管理提供了简单的定义，简化在Kubernetes上部署、管理和运行Prometheus和Alertmanager集群。

Prometheus Operator作为一个控制器，他会去创建Prometheus、PodMonitor、ServiceMonitor、AlertManager以及PrometheusRule这5个CRD资源对象，然后会一直监控并维持这5个资源对象的状态。

Prometheus资源对象是作为Prometheus Service存在的
ServiceMonitor和PodMonitor资源对象是专门的提供metrics数据接口的exporter的抽象，Prometheus就是通过PodMonitor和ServiceMonitor提供的metrics数据接口去pull数据的
AlertManager资源对象对应的是alertmanager组件
PrometheusRule资源对象是被Prometheus实例使用的告警规则文件

ServiceMonitor和PodMonitor都是K8S集群的资源对象了，这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的资源对象了，非常方便。

以下是PrometheusRule案例（Prometheus Operator）：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus: k8s
    role: alert-rules
  name:  mimir-record-rule
  namespace: cnhb4-public-prod04-hubble
spec:
  groups:
  - name: mimir_api_1
    rules:
    - expr: histogram_quantile(0.99, sum(rate(cortex_request_duration_seconds_bucket[1m]))
        by (le, cluster, job))
      record: cluster_job:cortex_request_duration_seconds:99quantile
    - expr: histogram_quantile(0.50, sum(rate(cortex_request_duration_seconds_bucket[1m]))
        by (le, cluster, job))
      record: cluster_job:cortex_request_duration_seconds:50quantile
  - name: mimir_api_2
    rules:
    - expr: histogram_quantile(0.99, sum(rate(cortex_request_duration_seconds_bucket[1m]))
        by (le, cluster, job, route))
      record: cluster_job_route:cortex_request_duration_seconds:99quantile

以下是ServiceMonitor案例（Prometheus Operator）：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
    labels:
        cloud.xxx.domain/project-enName: hubble
        cloud.xxx.domain/project-id: "109772"
    name: mimir-alertmanager-sm
    namespace: iks-ns-hubble-mimir
spec:
    endpoints:
        - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
          path: /metrics
          port: http-metrics
          relabelings:
            - targetLabel: cluster
              replacement: cnhb4-public-prod04
            - targetLabel: job
              replacement: iks-ns-hubble-mimir/alertmanager
    namespaceSelector:
        matchNames:
            - iks-ns-hubble-mimir
    selector:
        matchLabels:
            storage: hubble-mimir
            app: alertmanager

四、Prometheus Operator架构图

Kubernetes Scheduler 工作原理 kubernetes crd operator_自定义

上面架构图中，各组件以不同的方式运行在Kubernetes集群中：

Operator：根据自定义资源（Custom Resource Definition，CRD）来部署和管理Prometheus Server，同时监控这些自定义资源事件的变化来做相应的处理，是整个系统的控制中心。
Prometheus：Prometheus资源是声明性地描述Prometheus部署的期望状态。
Prometheus Server：Operator根据自定义资源Prometheus类型中定义的内容而部署的Prometheus Server集群，这些自定义资源可以看作用来管理Prometheus Server 集群的StatefulSets资源。
ServiceMonitor：声明指定监控的服务，描述了一组被Prometheus监控的目标列表。该资源通过标签来选取对应的Service Endpoint，让Prometheus Server通过选取的Service来获取Metrics信息。
Service：简单的说就是Prometheus监控的对象。提供给ServiceMonitor选取，让Prometheus Server来获取信息。
Alertmanager：Alertmanager也是一个自定义资源类型，由Operator根据资源描述内容来部署Alertmanager集群。

参考：https://github.com/prometheus-operator/kube-prometheus

hub基于Kube-Prometheus实现，对prometheus-operator做了二次开发，支持跨集群部署监控服务。

目前已支持：

api接口创建/更新/删除 IKS集群监控及Grafana
api接口创建/更新/删除 Prometheus告警规则
默认对集群核心组件进行监控：apiserver，pod，container, node等
通过在业务集群内定义ServiceMonitor/PodMonitor等，自动添加监控目标

五、CRD简介

全称CustomResourceDefinition，在Kubernetes中一切都可视为资源，在Kubernetes1.7之后增加对CRD自定义资源二次开发能力扩展Kubernetes API，当我们创建一个新的CRD时，Kubernetes API服务将为你制定的每个版本创建一个新的RESTful资源路径，我们可以根据该API路径来创建一些我们自己定义的类型资源。CRD可以是命名空间，也可以是集群范围。由CRD的作用于scpoe字段中所制定的，与现有的内置对象一样，删除命名空间将删除该命名空间下的所有自定义对象。