带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.1(一)-阿里云开发者社区

开发者社区> 人民邮电出版社> 正文

带你读《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.1(一)

简介: 《云原生应用开发 Operator原理与实践》第二章 Operator 原理2.1
+关注继续查看

Operator的概念是由 CoreOS公司的工程师于 2016 年提出的,它可以让工程师根据应用独有的领域逻辑编写自定义的控制器。我们通过一个简单的例子理解      Operator。假设有一个连接数据库的 GoWeb 程序,开发者想将其部署到 k8s集群。在理想情况下,你会希望用 Deployment部署应用,然后暴露给 Service,对于应用服务的后端则是使用StatuflSet部署数据库,所以需要完成两部分的部署才能完成整个应用服务部署,前提条件:

(1)无状态部分,部署GoWeb应用;(2)有状态部分,部署数据库。

在上面的例子中,我们可以应用自身对应用程序与数据库之间关系的了解创建一个控制器,该控制器将以某种特定方式运行时执行某些操作,比如备份、更新、数据还原这些任务该如何完成取决于应用程序本身和业务限制(领域知识)。这些与应用强相关的操作就是 KubernetesOperator 要实现的:代替原本需要由网站可靠性工程师(SRE,SiteReliabilityEnginner)和运维工程师来完成的操作。在 Kubernetes中Operator就是KubernetesAPI的客户端,扮演 Controller的角色管理CRD。

 

2.1      Operator简介

 

在介绍 Operator之前,我们先通过 Kubeclt命令行创建 Kubernetes的 Namespace,那么,从发送一条创建命令到被 Kubernetes执行完成这一过程发生了什么。

首先通过执行以下命令创建一个 Namespace。

kubecltcreate-fnamespace-nginx.yaml

Yaml文件见代码清单 2-1

apiVersion:v1kind:Namespacemetadata:

name:nginx 

这时 Kubectl会向 API服务器发送一个 POST请求,API请求格式见代码清单 2-2。

curl--requestPOST\

--urlhttp://${k8s.host}:${k8s.port}/api/v1/namespaces\

--header'content-type:application/json'\


--data'{"apiVersion":"v1",

"kind":"Namespace","metadata":{

"name":"nginx"


}

从中可以看出 Kubernetes集群的组件交互都是通过RESTfulAPI 的形式完成的。流程如图 2-1所示。

 

                                 image.png

图 2—1Namespace 资原创建流程

 

从上面的 cURL指令可以看出,尽管我们编写的是 Yaml文件格式,但是 KubernetesAPIServer接收的是 JSON数据类型, 而并非用户编写的 Yaml, 然后创建的所有资源的请求都通过Kube-APIServer预处理、检测处理后持久化到ETCD组件中。其中 APIServer也是 Kubernetes集群中与 ETCD交互的唯一一个组件。如果 Namespace资源被创建在 ETCD之后,Kubernetes事件监听机制就会将 Namespace资源的变化情况发送给监听Namespaces资源的 Namespace控制器,最后由 Namespace控制器执行创建 Nginx 命名空间的具体操作。同理,Kubernetes中的其他资源操作类似,都会存在对应的资源控制器来处理响应的资源请求。这些控制器共同组成了KubernetesAPI控制器集合。

我们不难发现,实现 Kubernetes中某一种资源类型,如 Namespace、ReplicaSet、Pod等,Kubernetes中的资源类型需要满足以下要求。

(1)        对该领域类型的模型抽象,如上面namespace-nginx.yaml文件描述的Yaml据结构,这个抽象决定了 KubernetesClient发送到 KubernetesAPIServer的 RESTfulAPI请求数据内容,也描述了这个领域类型本身。

(2)        实际去处理这个领域类型抽象的控制器,例如Namespace控制器、ReplicaSet控制器、Pod 控制器,这些控制器实现了这个抽象描述的具体业务逻辑,并通过 RESTfulAPI 提供这些服务。

我们将这种资源设计方式称为“声明式API。而当Kubernetes  开发者需要扩展 Kubernetes 能力时,也可以遵循这种模式,即提供一份对想要扩展的能力的抽象以及实现了这个抽象具体逻辑的控制器。前者称作 CRD,后者称作 Controller。

Operator就是通过这种方式实现 Kubernetes扩展性的一种模式,Operator模式可以将一个领域问题的解决办法想像成一个操作者,这个操作者在用户和集群之间,通过一份份订单去操作集群的API,来达到满足这个领域各种需求的目的。这里的订单就是CR(即CRD的一个实例),而操作者就是控制器,是具体逻辑的实现者。之所以强调是Operator,而不是计算机领域里传统的Server角色,是因为 Operator 本质上不创造和提供新的服务,它只是已有 KubernetesAPIServer的组合。下面将着重介绍这些基础概念,什么是CRD,什么是 Controller。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
DL之ANN/DNN: 人工神经网络ANN/DNN深度神经网络算法的简介、应用、经典案例之详细攻略
DL之ANN/DNN: 人工神经网络ANN/DNN深度神经网络算法的简介、应用、经典案例之详细攻略
23 0
数十万应用结点全息监控,ARMS新上线的应用监控神器到底有多牛?
就在不久前,2017年阿里双11刚刚创下电商史上的新销售奇迹,24小时交易金额达1682亿,每秒交易创建峰值325000,每秒支付峰值256000!在这个海量交易背后是数十万个结点规模的应用的高效运行。
6685 0
Elasticsearch Top5典型应用场景
题记 刚接触Elasticsearch的朋友,或多或少会遇到一个问题,Elasticsearch在实际公司应用中除了搜索到底能做什么? 本文给出了答案。 除了“You Know, for Search”,Elasticsearch的使用会不断增长和变化。ObjectRocket作为一家托管云计算公司,已经在ObjectRocket平台上提供托管Elasticsearch一段时间了,并且能够看到我们客户之间的一些明确趋势以及他们如何使用该产品。以下是我们在平台上看到的Top5场景用例:
8 0
这个云原生开发的痛点你遇到了吗?
上云从来都不是一片坦途,在此过程中我们总会遇到一些困难和挑战,得益于云原生技术的日益成熟,这些问题一定会有相应的解法。
8244 0
472
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载