带你读《云原生应用开发 Operator原理与实践》第三章 Kubebuilder 原理3.3 Controller-runtime 模块分析(七)

简介: 带你读《云原生应用开发 Operator原理与实践》第三章 Kubebuilder 原理3.3 Controller-runtime 模块分析

1. EventHandler

 

EventHandler(事件句柄)Controller.Watch的参数,当事件产生时,EventHandler将返回对象的 NameNamespace,作为 Request被添加到待处理事件队列中。例如,将来自 SourcePodCreate事件提供给 EnqueueHandler,EventHandler将生成一个Request 添加到队列中,这个 Request包含该 PodNameNamespace。EventHandler的接口定义在目录 pkg/handler/eventhandler.go下,分别定义了 4类事件加入队列的方式(见代码清单3-38

typeEventHandlerinterface{

//定义如何响应Create事件

Create(event.CreateEvent,workqueue.RateLimitingInterface)


//定义如何响应 Update事件

Update(event.UpdateEvent,workqueue.RateLimitingInterface)

 

//定义如何响应Delete事件

Delete(event.DeleteEvent,workqueue.RateLimitingInterface)

 

//定义如何响应Generic事件

Generic(event.GenericEvent,workqueue.RateLimitingInterface)


}

 

在目录pkg/handler/eventhandlergo下,提供了内置的3EventHandler接口的实现。

(1)   Funcs:包含4个函数对象类型的成员,分别实现了EventHandler接口的4个方法,开发者根据需要设置 4 个成员,如果某个成员未设置,默认将对对应的事件不进行反应。

(2)  EnqueueRequestForOwner:将事件中资源对象的Owner加入队列。例如, 因ReplicaSet而创建的 Pod,发送过来的Pod事件被 EnqueueRequestForOwner处理后,加入相应的 ReplicaSet资源队列。

(3)  EnqueueRequestsFromMapFunc:用于自定义资源的映射,是一个私有类,需要通过 EnqueueRequestsFromMapFunc(fnMapFunc)EventHandler方法创建。其中MapFunc是一个函数对象,将一个资源对象映射为多个 reconcile.Request,定义见代码清3-39


typeMapFuncfunc(client.Object)[]reconcile.Request

 

EnqueueRequestsFromMapFunc对应 4类事件, 它会将事件中的资源对象取出

Update会同时取出更改前、更改后的两个资源对象,用MapFunc进行映射,将映射的所有 reconcile.Request加入队列。例如,当集群规模发生变动,导致 Node资源变化时,需要触发 Service进行同步的场景。

EventHandler可以通过 Builder.Watches()方法在创建 Controller时设置,也可以在ControllerController.Watch()方法中传入设置。但最终都会传入Source.Start()方法中,用于设置 Source处理事件的逻辑。

EventHandler 主要有以下特性。

(1)  通过将 Request加入队列处理一个或多个对象的事件。

(2)  可以将一个事件映射为另一个相同类型对象的 Request。

(3)  可以将一个事件映射为另一个不同类型对象的 Request例如,将一个 Pod事件映射为一个纳管这个 PodReplicaSet类型 Request。

(4)  用户应该只使用提供的 Eventhandler实现,而不是使用自定义 Eventhandler实现。

 

2. Source

 

resource.Source(事件源)Controller.Watch的参数。它提供了一个事件流。事件通常来自WatchKubernetesAPI  PodCreate、Update、Delete。例如,source.Kind

GroupVersionKind使用了 KubernetesAPIWatch端点,以提供 Create、Update、Delete事件。

Source接口定义在目录 pkg/source/source.go下,见代码清单 3-40。

typeSourceinterface{

//Start() Controller-runtime的内部⽅法,应该仅由Controller调⽤,⽤于在Informer

中注册EventHandler,将reconcile.Requests加⼊⼯作队列workqueue.RateLimitingInterface

Start(context.Context,handler.EventHandler,workqueue.RateLimitingInterface,

...predicate.Predicate)error

}

 

Source的实现在 pkg/source/source.go下,主要包括 3种。

(1)  Informer:用于提供来自集群内部的事件,例如,PodCreate事件。

(2)   Kind:与 Informer类似 ,也用于提供来自集群内部的事件。不同的是 Informer结构直接继承 cache.Informer,需要开发者自己设置;而 Kind 会根据设置的资源对象类型,自动生成 cache.Informer。

Builder创建 Controller时, 会根据 Builder.For()、Builder.Owns()、Builder.Watches()方法中设置的资源对象类型在Builder.Build() 中创建相应的 Kind,并调用 Controller.Watch()方法将 Kind传入 Controller。

(3)  Channel:用于提供集群外部的事件,例如,GitHubWebHook回调。Channel要求用户连接外部的源HttpHandler,以便将GenericEvents写入底层的Channel结构中。

除了以上 3种事件源外,用户还可以实现自己的 Source,如果用户自己实现相应的 Inject接口,Controller会在调用 Watch()方法时, 将依赖注入。其中 Inject接口是ManagerController传递依赖的方式,主要定义在目录 pkg/runtime/inject/inject.go下。

 

事件源主要有以下特性。

(1)一般通过 WatchAPIKubernetes对象提供事件流(例如,对象创建、更新和删除

(2)用户应该只使用提供的事件源实现,而非使用自定义实现。

相关文章
|
6月前
|
运维 监控 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
国诚投顾携手阿里云,依托Serverless架构实现技术全面升级,构建高弹性、智能化技术底座,提升业务稳定性与运行效率。通过云原生API网关、微服务治理与智能监控,实现流量精细化管理与系统可观测性增强,打造安全、敏捷的智能投顾平台,助力行业数字化变革。
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
|
8月前
|
Kubernetes Cloud Native 安全
云原生机密计算新范式 PeerPods技术方案在阿里云上的落地和实践
PeerPods 技术价值已在阿里云实际场景中深度落地。
|
6月前
|
运维 监控 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生 Serverless 实践
通过与阿里云深度合作,国诚投顾完成了从传统 ECS 架构向云原生 Serverless 架构的全面转型。新的技术架构不仅解决了原有系统在稳定性、弹性、运维效率等方面的痛点,还在成本控制、API 治理、可观测性、DevOps 自动化等方面实现了全方位升级。
|
8月前
|
Kubernetes Cloud Native 安全
云原生机密计算新范式 PeerPods 技术方案在阿里云上的落地和实践
PeerPods 技术价值已在阿里云实际场景中深度落地。
|
4月前
|
人工智能 Cloud Native 算法
拔俗云原生 AI 临床大数据平台:赋能医学科研的开发者实践
AI临床大数据科研平台依托阿里云、腾讯云,打通医疗数据孤岛,提供从数据治理到模型落地的全链路支持。通过联邦学习、弹性算力与安全合规技术,实现跨机构协作与高效训练,助力开发者提升科研效率,推动医学AI创新落地。(238字)
310 7
|
10月前
|
运维 Cloud Native 测试技术
极氪汽车云原生架构落地实践
随着极氪数字业务的飞速发展,背后的 IT 技术也在不断更新迭代。极氪极为重视客户对服务的体验,并将系统稳定性、业务功能的迭代效率、问题的快速定位和解决视为构建核心竞争力的基石。
|
6月前
|
弹性计算 运维 Cloud Native
【云故事探索】NO.17:国诚投顾的云原生Serverless实践
简介: 通过与阿里云深度合作,国诚投顾完成了从传统 ECS 架构向云原生 Serverless 架构的全面转型。新的技术架构不仅解决了原有系统在稳定性、弹性、运维效率等方面的痛点,还在成本控制、API 治理、可观测性、DevOps 自动化等方面实现了全方位升级。
178 1
|
5月前
|
存储 弹性计算 Cloud Native
云原生数据库的演进与应用实践
随着企业业务扩展,传统数据库难以应对高并发与弹性需求。云原生数据库应运而生,具备计算存储分离、弹性伸缩、高可用等核心特性,广泛应用于电商、金融、物联网等场景。阿里云PolarDB、Lindorm等产品已形成完善生态,助力企业高效处理数据。未来,AI驱动、Serverless与多云兼容将推动其进一步发展。
271 8
|
7月前
|
Cloud Native 中间件 调度
云原生信息提取系统:容器化流程与CI/CD集成实践
本文介绍如何通过工程化手段解决数据提取任务中的稳定性与部署难题。结合 Scrapy、Docker、代理中间件与 CI/CD 工具,构建可自动运行、持续迭代的云原生信息提取系统,实现结构化数据采集与标准化交付。
379 1
云原生信息提取系统:容器化流程与CI/CD集成实践

热门文章

最新文章