K8s系列之:解释Kubernetes Operators
K8s系列之:解释Kubernetes Operators
- 什么是控制器循环?
- Kubernetes Operator是如何工作的?
- 如何添加自定义资源
- 自定义资源定义
- Kubernetes Operators:案例研究
你是否曾想过,Site Reliability Engineering(SRE)团队如何成功地管理复杂应用程序?在Kubernetes生态系统中,答案只有一个:Kubernetes Operators!在本文中,我们将探讨什么是Operators以及它们的工作原理。
Kubernetes Operator的概念是由CoreOS的工程师在2016年开发的,作为在Kubernetes集群上构建和驱动每个应用程序的高级和本地化方式,需要领域特定的知识。它提供了一种一致的方法来自动处理所有应用程序的运行过程,通过与Kubernetes API的密切协作,无需人工干预。换句话说,Operator是一种打包、运行和管理Kubernetes应用程序的方式。
Kubernetes Operator模式遵循了Kubernetes的核心原则之一:控制理论。在机器人技术和自动化中,控制理论是一种连续操作动态系统的机制。它依赖于将工作负载需求尽可能准确地适应可用资源的能力。其目标是开发一个带有必要逻辑的控制模型,以帮助应用程序或系统保持稳定。在Kubernetes世界中,这一部分由控制器来处理。
控制器是一种特殊的软件,在循环中响应变化并在集群中执行适应性操作。第一个Kubernetes控制器是kube-controller-manager。它被视为后来构建的所有Operator的祖先。
什么是控制器循环?
简单来说,控制器循环是控制器操作的基础。想象一下,有一个不终止的过程(在Kubernetes中称为调谐循环)一遍又一遍地进行,如下图所示:
该过程观察至少一个Kubernetes对象,该对象包含有关期望状态的信息。诸如
- 部署
- 服务
- 密钥
- 入口
- 配置映射
等对象由JSON或YAML格式的配置文件定义。然后,控制器通过Kubernetes API进行持续调整,以模拟期望状态,直到当前状态变为期望状态,根据内置的逻辑进行操作。
通过这种方式,Kubernetes处理了云原生系统的动态特性,处理不断变化的情况。实现期望状态的修改示例包括:
- 当节点下线时发出新节点的需求
- 检查是否需要复制Pod
- 根据请求创建新的负载均衡器。
Kubernetes Operator是如何工作的?
Operator是一个特定于应用程序的控制器。它扩展了Kubernetes API,代表人类(操作工程师或站点可靠性工程师)创建、配置和管理复杂的应用程序。让我们看看Kubernetes文档对此的解释。
“Operator是Kubernetes的软件扩展,利用自定义资源来管理应用程序及其组件。Operator遵循Kubernetes的原则,特别是控制循环。”
到目前为止,你已经知道Operator利用控制器观察Kubernetes对象。这些控制器有些不同,因为它们跟踪自定义对象,通常称为自定义资源(CR)。CR是Kubernetes API的扩展,提供了一个存储和检索结构化数据(即应用程序的期望状态)的位置。整个操作原理如下图所示。
Operator不断跟踪与特定类型的自定义资源相关的集群事件。可以跟踪的自定义资源上的事件类型包括:
- 添加
- 更新
- 删除
当Operator接收到任何信息时,它将采取行动,在自定义控制器的调谐循环中调整Kubernetes集群或外部系统以达到期望状态。
如何添加自定义资源
自定义资源通过添加新类型的对象来扩展Kubernetes的功能,这些对象对于您的应用程序可能很有帮助。Kubernetes提供了两种将自定义资源添加到集群的方法:
- 通过API聚合(API Aggregation):这是一种高级方法,需要您构建自己的API服务器,但可以给您更多的控制权。
- 通过自定义资源定义(Custom Resource Definitions,CRD):这是一种简单的方式,可以在不需要任何编程知识的情况下创建,作为对原始Kubernetes API服务器的扩展。
这两个选项满足了不同用户的需求,用户可以在灵活性和易用性之间进行选择。Kubernetes社区创建了一个指南,将帮助您决定哪种方法适合您,但最受欢迎的选择是CRD。
自定义资源定义
自定义资源定义已经存在一段时间了;第一个主要的API规范是在Kubernetes 1.16.0版本发布时引入的。下面的示例展示了一个清单:
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: application.stable.example.com
spec:
group: stable.example.com
version: v1
scope: Namespaced
names:
plural: application
singular: applications
kind: Application
shortNames:
- app
这个CRD将允许您创建一个名为"Application"的CR(我们将在下一节中使用它)。前两行定义了您要创建的对象的apiVersion apiextensions.k8s.io/v1beta1和kind CustomResourceDefinition。
元数据描述了资源的名称,但在这里最重要的地方是"spec"字段。它允许您指定组和版本以及可见性的范围 - 命名空间范围或集群范围。
然后,您可以以多种格式定义名称,并创建一个方便的缩写名称,这样您就可以执行"kubectl get app"命令来获取现有的CR。
Kubernetes Operators:案例研究
为了全面了解Kubernetes Operators,让我们来研究一个案例,即Prometheus Operator,它是最早也是最受欢迎的Operator之一。它简化了Prometheus、Alertmanager和相关监控组件的部署和配置。
Prometheus Operator的核心功能是监视Kubernetes API服务器对特定对象的更改,并确保当前的Prometheus部署与这些对象匹配。Operator对以下自定义资源定义(CRD)进行操作:
- Prometheus:定义了所需的Prometheus部署。
- Alertmanager:定义了所需的Alertmanager部署。
- ServiceMonitor:以声明方式指定应如何监控一组Kubernetes服务。Operator根据API服务器中对象的当前状态自动生成Prometheus抓取配置。
- PodMonitor:以声明方式指定应如何监控一组Pod。Operator根据API服务器中对象的当前状态自动生成Prometheus抓取配置。
- PrometheusRule:定义了一组所需的Prometheus警报和/或记录规则。Operator生成一个规则文件,可以供Prometheus实例使用。
Prometheus Operator会自动检测Kubernetes API服务器对上述任何对象的更改,并确保匹配的部署和配置保持同步。
致力于通过创建java-operator-sdk来简化使用Java创建Operator的过程。