AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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:054954

评论 1 条评论

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

首批!青藤通过信通院CWPP能力评估检验

青藤云安全

网络安全 主机安全 信通院

【愚公系列】2022年06月 面向对象设计原则(五)-接口隔离原则

愚公搬代码

6月月更

Android原生TabLayout使用全解析,看这篇就够了

yechaoa

android TabLayout 6月月更 material design

数据库每日一题---第8天:超过5名学生的课

知心宝贝

数据库 程序员 前端 后端 6月月更

Sealem Finance打造Web3去中心化金融平台基础设施

BlockChain先知

线程池的创建

急需上岸的小谢

6月月更

【Spring 学习笔记(九)】Spring IoC/DI注解开发之纯注解开发

倔强的牛角

Java spring Java EE 6月月更

Java—基础容器

武师叔

6月月更

vue指令-6

小恺

6月月更

快手处置超过5.4万个违规账号:如何打击平台上的违规账号

石头IT视角

细数十大信息安全原则

阿泽🧸

信息安全 6月月更

ServerLess Aws Lambda攻击与横向方法研究

火线安全

云安全

Vue-5-模板语法-2

Python研究所

前端 6月月更

很流行的状态管理库 MobX 是怎么回事?

岛上码农

flutter ios 安卓开发 跨平台开发 6月月更

Redis stream Java API实践

FunTester

Tornado简介&&本专栏搭建tornado项目简介

孤寒者

Python tornado 6月月更

curl导入postman报错小记

红毛丹

Postman 6月月更

数的奥秘之幂数与完全平方数

未见花闻

6月月更

自动化测试系列

IT蜗壳-Tango

6月日更 6月月更

如何使用物联网低代码平台进行工作表管理?

AIRIOT

低代码 物联网 低代码开发平台

leetcode 130. Surrounded Regions 被围绕的区域(中等)

okokabcd

LeetCode 搜索 数据结构与算法

【sql语句基础】——增(insert)

写代码两年半

数据库 sql MySQL 数据库 6月月更

Sealem Finance-基于Web3的全新去中心化金融平台

小哈区块

ConcurrentHashMap 源码分析-ConcurrentHashMap与HashMap的异同

zarmnosaj

6月月更

存储引擎分析

工程师日月

6月月更

盲盒商城APP系统开发的软件特点和盲盒功能介绍

WDL22119

盲盒商城 盲盒开发 盲盒源码 盲盒H5开发 盲盒APP系统开发

Web3生态去中心化金融平台——Sealem Finance

西柚子

锁机制

卢卡多多

锁机制 6月月更

云数据中心中的SDN/NFV应用

穿过生命散发芬芳

SDN网络 6月月更

react管理渲染问题详解【王道react】

恒山其若陋兮

React 6月月更

学习笔记:插件化Activity之Hook点位

北洋

插件化 Andriod 6月月更

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