写点什么

Kubernetes Operator 基础入门

  • 2020-08-28
  • 本文字数:2907 字

    阅读完需:约 10 分钟

Kubernetes Operator基础入门

你是否曾经想过 SRE 团队是如何有效地成功管理复杂的应用?在 Kubernetes 生态系统中,Kubernetes Operator 可以给你答案。在本文中,我们将研究 Operator 是什么以及它们如何工作。


Kubernetes Operator 这一概念是由 CoreOS 的工程师于 2016 年提出的,这是一种原生的方式来构建和驱动 Kubernetes 集群上的每一个应用,它需要特定领域的知识。它提供了一种一致的方法,通过与 Kubernetes API 的紧密合作,自动处理所有应用操作过程,而不需要任何人工干预。换句话说,Operator 是一种包装、运行和管理 Kubernetes 应用的方式。


Kubernetes Operator 模式遵循 Kubernetes 的核心原则之一:控制理论(control theory)。在机器人和自动化领域,它是一种持续运行动态系统的机制。它依赖于一种快速调整工作负载需求的能力,进而能够尽可能准确地适应现有资源。其目标是开发一个具有必要逻辑的控制模型,以帮助应用程序或系统保持稳定。在 Kubernetes 世界中,这部分由 controller 处理。


在循环中,Controller 是个特殊的软件,它可以对集群的变化做出响应,并执行适应动作。第一个 Kubernetes controller 是一个 kube-controller-manager。它被认为是所有 Operator 的前身,Operator 是后来建立的。

什么是 Controller Loop?

简单来说,Controller Loop 是 Controller 动作的基础。想象一下,有一个非终止的进程(在 Kubernetes 中称为和解循环)在不断地发生,如下图所示:



这个过程至少观察一个 Kubernetes 对象,该对象包含有关所需状态的信息。比如:


  • Deployment

  • Services

  • Secrets

  • Ingress

  • Config Maps


这些对象由 JSON 或 YAML 中的 manifest 组成的配置文件定义。然后 controller 根据内置逻辑,通过 Kubernetes API 进行持续调整,模仿所需状态,直到当前状态变成所需状态。


通过这种方式,Kubernetes 通过处理不断的更改来处理 Cloud Native 系统的动态性质。为达到预期状态而执行的修改实例包括:


  • 注意到节点宕机时,要求更换新的节点。

  • 检查是否需要复制 pods。

  • 如果需要,创建一个新的负载均衡器。

Kubernetes Operator 如何工作?

Operator 是一个特定应用程序的 controller,它扩展了一个 Kubernetes API,替代运维工程师或 SRE 工程师来创建、配置和管理复杂的应用程序。在 Kubernetes 官方文档中对此有以下描述:


Operator 是 Kubernetes 的软件拓展,它利用自定义资源来管理应用程序及其组件。Operator 遵循 Kubernetes 的原则,尤其遵循 control loop。


到目前为止,你已经了解 Operator 会利用观察 Kubernetes 对象的 controller。这些 controller 有点不同,因为它们正在追踪自定义对象,通常称为自定义资源(CR)。CR 是 Kubernetes API 的扩展,它提供了一个可以存储和检索结构化数据的地方——你的应用程序的期望状态。整个操作原理如下图所示:



Operator 会持续跟踪与特定类型的自定义资源相关的集群事件。可以跟踪的关于这些自定义资源的事件类型有:


  • Add

  • Update

  • Delete


当 Operator 接收任何信息时,它将采取行动将 Kubernetes 集群或外部系统调整到所需的状态,作为其在自定义 controller 中的和解循环(reconciliation loop)的一部分。

如何添加一个自定义资源

自定义资源通过添加对你的应用有帮助的新型对象来扩展 Kubernetes 功能。Kubernetes 提供了两种向集群添加自定义资源的方法:


  • 通过 API Aggregation 添加,这是一种高级方法,需要你建立自己的 API 服务器,但你有更多的控制权限。

  • 通过自定义资源定义(CRD)添加,一种不需要复杂编程知识就可以创建的简单方式,作为 Kubernetes API 服务器的扩展。


这两种方案满足了不同用户的需求,他们可以在灵活性和易用性之间进行选择。Kubernetes 社区对两者进行了比较,将帮助你决定哪种方法适合你,但目前最受欢迎的选项是 CRD:


https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources

自定义资源定义(CRD)

自定义资源定义(CRD)的出现已经有一段时间了,第一个主要的 API 规范是与 Kubernetes 1.16.0 一起发布的。下面的 manifest 介绍了一个例子:


apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinitionmetadata:  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 和你要创建的对象种类。


Metadata 描述了资源名称,但这里最重要的部分是“spec”字段。它让你可以指定组、版本以及可见性范围——命名空间或集群范围。


然后,你可以用多种格式定义名称,并创建一个方便的缩写,让你执行命令 kubectl get app 来获取现有的 CR。

自定义资源

以上 CRD 可以让你创建以下自定义资源的 manifest。


apiVersion: stable.example.com/v1 kind: Applicationmetadata:  name: application-configspec:  image: container-registry-image:v1.0.0  domain: teamx.yoursaas.io  plan: premium
复制代码


如你所见,在这里包含了运行特定情况下的应用程序所需的所有必要信息。这个自定义资源将被我们的 Operator 观察到——准确地说,是被 Operator 的自定义 controller 观察到。根据 controller 中的内置逻辑,将模仿所需的状态。它可以为我们的应用程序创建部署、服务和必要的 ConfigMaps。运行它,并在特定的域上通过 ingress 暴露它。这只是一个简单的用例,但你可以根据自己的需求对它进行任何设计。


Operator 还可以配置在 Kubernetes 之外的资源。你可以在不离开 Kubernetes 平台的情况下控制外部路由器的配置或在云中创建数据库。

Kubernetes Operators:案例研究

为了对 Kubernetes Operator 有一个整体清晰的认识,我们来看看 Prometheus Operator,它是最早也是最流行的 Operator 之一。它简化了 Prometheus、Alertmanager 以及相关监控组件的部署和配置。


Prometheus Operator 的核心功能是监控 Kubernetes API 服务器上指定对象的变化,并确保当前的 Prometheus 部署与这些对象相匹配。Operator 作用于以下自定义资源定义(CRD):


  • Prometheus: 定义了所需 Prometheus 部署

  • Alertmanager: 定义了所需的 Alertmanager 部署

  • ServiceMonitor: 它声明性地指定了应该如何监控 Kubernetes 服务的组。Operator 会根据 API 服务器中对象的当前状态自动生成 Prometheus scrape 配置。

  • PodMonitor: 声明性地指定了应如何监控一组 pod。Operator 会根据 API 服务器中对象的当前状态自动生成 Prometheus scrape 配置。

  • PrometheusRule: 定义了一组所需的 Prometheus 告警和/或记录规则。Operator 会生成一个规则文件,可供 Prometheus 实例使用。


Prometheus Operator 会自动检测 Kubernetes API 服务器中对上述任何对象的更改,并确保匹配的部署和配置保持同步。


原文链接:


https://blog.container-solutions.com/kubernetes-operators-explained


本文转载自公众号 RancherLabs(ID:RancherLabs)。


原文链接


Kubernetes Operator基础入门


2020-08-28 10:054743

评论 1 条评论

发布
用户头像
2022-12-14 19:37 · 北京
回复
没有更多了
发现更多内容

外行如何速成专家?Embedding之BM25、splade稀疏向量解读

Zilliz

Milvus embedding向量 BM25 稀疏向量 splade

Python随机抽取Excel数据并在处理后整合为一个文件

不在线第一只蜗牛

Python Excel

【NeurIPS'24】阿里云 PAI 团队论文被收录为 Spotlight,并完成主题演讲分享

阿里云大数据AI技术

人工智能 阿里云 论文 NeurlPS

融合创新,智领未来 | 华为云云原生精彩亮相2024华为云开源开发者论坛

华为云开源

云原生 开发者大会 华为云开源

CAD测坐标功能常见问题集锦

在路上

cad cad看图 CAD测量

多功能代码编辑器BBEdit for Mac 激活版

小玖_苹果Mac软件

用腾讯云AI代码助手开发一款数据库敏感信息检查工具

cloud studio AI应用

Java程序员如何高效学习Spring全家桶?

了不起的程序猿

spring 程序员 java程序员 java面试 八股文

Spring框架IoC核心详解

EquatorCoco

Java spring

利用淘宝1688 API接口,构建高效淘宝代购与集运解决方案

代码忍者

代购商城系统

荆门正规等保测评机构有吗?在哪里?

行云管家

等保 等保测评 荆门

数字孪生赋能BMS:开启电池管理新纪元

DevOps和数字孪生

签约快讯|天润融通签约问界

天润融通

技术揭秘:图形工作站、个人电脑和服务器的硬件差异

青椒云云电脑

图形工作站

HarmonyOS 5.0应用开发——属性动画

高心星

arkui HarmonyOS NEXT HarmonyOS5.0 属性动画

TiDB 优化器 | 执行计划管理及实践

PingCAP

数据库 TiDB 优化器

法国 mixtral一种具有开放权重的高质量稀疏专家混合模型

测试人

软件测试

英特尔携手行业合作伙伴,共拓医健融合之道

E科讯

阿里高工在“618,双11”总结的《百亿级并发系统设计》全彩小册,太全了!

架构师之道

编程 高并发 计算机

阿里巴巴内网“ Spring Cloud Alibaba 项目文档 ” 正式发布!

采菊东篱下

Java 编程 微服务

蛋糕、面包加工厂MES智能化生产管理

万界星空科技

mes 万界星空科技 面包行业 蛋糕行业 食品加工行业

BSC项目开发:构建区块链应用的全面指南

区块链软件开发推广运营

交易所开发 链游开发 公链开发 代币开发

【DevOps系列】企业度量难题破解:全面解析度量平台的核心能力

嘉为蓝鲸

DevOps 效能洞察 研发效能度量

比特币网络及其经济基础的演变:从零到十万美元的非凡历程

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 公链开发 代币开发

进大厂必备的Java面试八股文大全(2024最新精简易懂版,八股文中的八股文)

采菊东篱下

编程 计算机 java面试

会议通知:人工智能通识教育与实践发展暨和鲸科技AI通识课解决方案发布会

ModelWhale

人工智能 大数据 高校课改 通识课

垃圾清理应用卸载工具CleanMyMac X for Mac

小玖_苹果Mac软件

Kubernetes Operator基础入门_软件工程_Rancher_InfoQ精选文章