2.2.3         Client-go架构

Client-go主要用在 Kubernetes控制器中，包括内置控制器（如 kube-controller-manager）和 CRD控制器，Client-go架构如图 2-6所示。根据图 2-6介绍 Client-go中的几个组件。

图 2—6Cient—go架构

 

（1）  Reflector：使用 List-Watch 的方法监控指定类型的资源对象，从 KubernetesAPIServer中 List该资源的所有实例，取得最新的ResourceVersion，然后使用 Watch方法监听该 resourceVersion之后的所有变化，若过程中出现异常，Reflector则会从断开的ResourceVersion处重现尝试监听所有变化，一旦该对象的实例有创建、删除、更新动作，Reflector 都会收到“事件通知”，并利用反射机制将监听的结果实例化成具体的对象。这时，该事件及它对应的实例对象的组合称为增量（Delta），之后会被存进 DeltaFIFO中。

（2） DeltaFIFO：作为一个增量队列，将 Reflector监控变化的对象形成一个 FIFO队列，此处的 Delta就是变化。

（3） LocalStore：Informer会不断地从 DeltaFIFO中读取增量，每出现一个对象，Informer就会判断这个增量的事件类型，然后创建或更新本地缓存，也就是 LocalStore。例如，如果事件类型是 Added（添加对象），那么 Informer 会把这个增量中的对象保存到本地缓存中，并为它创建索引；若为删除操作，则在本地缓存中删除该对象。此外，LocalStore   还利用索引提供快速查找的能力，当使用者需要查询（Get/List）Kubernetes对象时，可以直接请求 LocalStore，以此减轻 KubernetesAPIServer的压力。

（4） Workqueue：DeltaFIFO在同步完LocalStore后，会Pop这个事件到Controller中， Controller会调用事先注册的 ResourceEventHandler回调函数（如 OnAdd、OnUpdate、 OnDelete）进行处理，这些回调函数只做一些简单的过滤工作，最后将变更对象放入 Workqueue中，供 Worker中的业务逻辑处理。

（5） Clients：Client-go中的各类客户端，当 Worker中业务逻辑要操作 Kubernetes资源时，可以通过客户端实现。

2.2.4       Discovery原理

在分析 Discovery原理之前，首先介绍一下Kubernetes的资源模型，图 2-7是获取所有 Deployements资源的 RESTfulAPI，URL 中各字段含义如下。

（1）      apps是 Group 资源组，包含一组资源操作的集合。

（2）      v1是Version资源版本，用于区分不同 API 的稳定程度及兼容性。

（3）      Deployments是 Resource 资源信息，用于区分不同的资源 API。

图 2—7Depioyments 资原 URL

 

由于历史原因，Kubernetes中有两种资源组：有组名资源组和无组名资源组（也叫核心资源组，CoreGroups)。上面介绍的就是有组名资源组，而Pods、Services等资源属于无组名资源组，图 2-8是获取 Pods资源的 RESTfulAPI，其中未包含Group信息，但拥有 Version和 Resource信息。

图 2—8Pods资原 URL

 

常用的 Kubectl命令，当执行 kubectlapi-versions和 kubectlapi-resources命令时，返回的就是GVR（Group，Version，Resource）信息（见代码清单2-29）。

$kubectlapi-versionsadmissionregistration.k8s.io/v1admissionregistration.k8s.io/v1beta1apiextensions.k8s.io/v1apiextensions.k8s.io/v1beta1apiregistration.k8s.io/v1apiregistration.k8s.io/v1beta1apps/v1

...

 

componentstatuses          cs               falseComponentStatus

configmaps                cm                                  true