跳到主要内容

38.watchCache

PR #758*

Watch based client cache [开始实现客户端缓存]

“In preparation for moving the scheduler into its own plugin, these are some objects that make it really easy.

...of course this won't be useful without more advanced watching in the server. I'm working on that.”

fifo

这段代码定义了一个名为"FIFO"的数据结构,即"First-In-First-Out"(先入先出)队列,并实现了与之相关的一些操作。这种数据结构通常用于在并发环境中保持数据的处理顺序。

FIFO数据结构有以下字段:

  • lock:读写互斥锁,保证在并发环境中对FIFO数据结构的安全操作。

  • cond:条件变量,用于同步对队列的操作。

  • items:以字符串为键,任意类型为值的字典,存储队列中的元素。

  • queue:字符串切片,存储队列中元素的键,以保持元素的插入顺序。 以下是定义的一些方法:

  • Add:向队列中添加一个新的元素。

  • Update:更新队列中的一个元素,并将其放入队列中等待处理。

  • Delete:从队列中移除一个元素。

  • List:返回队列中所有元素的列表。

  • Get:获取队列中的一个元素。

  • Pop:从队列中取出一个元素进行处理,并将其从队列中移除。如果元素成功处理,则无需再次添加;如果处理失败,需要重新添加。 最后,NewFIFO函数返回一个新的FIFO实例。

这个FIFO数据结构在Kubernetes中可能被用于对API服务器产生的事件进行处理,如资源的创建、更新和删除等。这种处理模式能保证事件按照发生的顺序进行处理,并在并发环境中提供线程安全的操作。

reflector

这段代码定义了一个名为Reflector的类型,它用于监视特定的资源,并将所有更改反映到指定的存储中。Reflector是Kubernetes系统中的关键组件之一,它实现了对Kubernetes API的资源进行监视的功能,它的改变能被持久化到指定的Store中。

Reflector类型有以下字段:

  • kubeClient:一个Kubernetes的客户端,用于和Kubernetes API服务器进行通信。

  • resource:一个字符串,表示要监视的资源的类型。

  • expectedType:一个反射类型,表示期望存储的资源对象的类型。

  • store:一个Store接口,用于存储从API服务器获取的资源对象。 以下是一些关键的方法:

  • NewReflector:创建一个新的Reflector实例,该实例会保持与给定资源服务器的同步。

  • Run:开始运行Reflector,持续监视指定的资源。

  • startWatch:开始监视特定资源。

  • watchHandler:处理从监视通道获取的事件。 这段代码中的watchHandler方法对从Kubernetes API服务器获取的watch.Event进行处理,根据事件的类型(添加,修改,删除),更新store中的状态。如果监视通道被意外关闭,或者事件的类型不符合预期,该方法会记录错误并跳过该事件。

总的来说,这段代码定义了如何创建和运行一个Kubernetes资源监视器,以及如何处理从监视通道接收到的事件。这对于理解Kubernetes的资源监视和事件处理机制是非常有帮助的。

store

这段代码定义了一个名为cache的类型,它提供了一个并发安全的内存缓存实现。cache实现了Store接口,其中包含Add,Update,Delete,List和Get方法。

cache类型有以下字段:

  • lock:一个读写互斥锁,用于保证对缓存的并发访问是安全的。

  • items:一个键-值对映射,表示存储在缓存中的项。 以下是关键的方法:

  • Add:插入一个项到缓存中。

  • Update:更新缓存中的一个项。

  • Delete:从缓存中删除一个项。

  • List:返回所有缓存的项的列表。只要你把所有的项视为不可变的,这个方法就是线程安全的。

  • Get:返回请求的项,如果不存在,则返回exists=false。只要你把所有的项视为不可变的,这个方法就是线程安全的。 最后,NewStore函数返回一个实现了Store接口的cache实例。这个函数用于创建一个新的内存存储,可以被其他代码(如Reflector类型的代码)用来存储和检索数据。

总的来说,这段代码提供了一个简单、并发安全的内存缓存实现,可以用作Kubernetes API的本地缓存,或者其他需要在内存中存储和检索数据的场景。

PR #754

proxy: cleanup and minor refactor

PR #745

Evolve the api.Status object with Reason/Details

这段代码定义了在Kubernetes中表示操作结果状态的几种数据结构和常量。这些结构和常量在API操作中,如创建、更新或删除资源时,返回给调用者以表示操作的结果。

主要的数据结构是Status,它包含以下字段:

  • Status:状态字段,可能的值为"success"、"failure"、"working"。表示API操作的结果状态。
  • Message:人类可读的操作状态描述。
  • Reason:机器可读的操作状态原因,特别是在操作失败或正在进行中的情况下。如果此值为空,则没有可用的信息。
  • Details:与原因关联的扩展数据。这是一个StatusDetails类型的指针,可以提供有关API操作的额外信息。
  • Code:建议的HTTP返回码。
  • StatusDetails数据结构包含额外的属性,可能由服务器设置以提供有关响应的更多信息。其中包括资源的ID和种类。

ReasonType是一个枚举类型,表示可能的失败原因。每个ReasonType都映射到一个HTTP状态码。

StatusSuccess、StatusFailure、StatusWorking等常量表示Status字段可能的值。

这段代码对于理解Kubernetes API的操作响应以及错误处理非常重要

提示

作业:尝试基于客户端缓存的代码,试着写个单元测试,帮助自己理解 reflector , store ,fifo 分别是干嘛的