我们通过Fabric8调用k8s的功能接口，从而实现k8s的控制台开发，虽然k8s以及提供了控制台，但是本身的控制台已经不怎么更新，为了使用更方便，我们决定自己搭建控制台并结合之前的项目完成一个叠加融合。

展示一下官方的控制台：

image.png

废话少说，我们来看看如何使用Fabric8。

要使用Fabric8我们就要调用其中的方法，找不到对应的方法在哪个类下是使用Fabric8的难题。这次我们就来解析一下我们Fabric8的那些方法藏在哪。

1.首先要说一个很重要的对象----client

在每次操作集群前都需要先连接到k8s集群，通过连接方法获得的就是KubernetesClient接口下的client对象。之后的所有针对k8s集群的操作都无一例外地要传入这个参数，所以KubernetesClient接口自然成为了我们一窥Fabric8源码的突破口。

image.png

可以看到，这个接口下定义了很多方法，如果细心一点，你会在其中发现很多熟悉的面孔。

比如：

NonNamespaceOperation< Namespace, NamespaceList, DoneableNamespace, Resource> namespaces();

NonNamespaceOperation> nodes();

是不是方法名很熟悉，就是k8s里基本的概念，命名空间和节点，后面还有pods、services这些。找到这些我们就有感觉大致方向没问题了，然后我们继续看这些方法的返回类型。

2.发现操作的集合

可以看到他们的返回类型分为两类，一类是MixedOperation、一类是NonNamespaceOperation，根据名称我们猜测这两个都是操作的集合，我们之后对pod、service的操作都应该是定义在这里面的。我们点进MixedOperation发现MixedOperation继承了NonNamespaceOperation接口，这就有意思了，说明MixedOperation很可能包含的操作要多于NonNamespaceOperation。这个时候我们已经有了很多猜测，是到了证实一波的时候了，打开关系图表，我们可以看到MixedOperation和NonNamespaceOperation所有的继承关系。如下图：

MixedOperation.png

NonNamespaceOperation.png

这样一对比MixedOperation多了哪些功能是不是就一目了然了？

比如MixedOperation多继承了Namespaceable接口，所以会多一个Namespaceable接口下定义的inNamespace方法，也就是说MixedOperation下的删除查找可以根据namespace也就是命名空间来操作，而NonNamespaceOperation下就没有这个方法。再回顾一下这两个操作集合的名字，是不是就明白了，一个是可以根据命名空间操作的方法集，一个是不能根据命名空间操作的方法集。我们再去看看KubernetesClient下的哪些方法返回的是NonNamespaceOperation，是namespaces和nodes，这两个当然不能根据命名空间进行操作，所以是不是更加明白整个Fabric8的架构了？

3.知道了去哪里找方法，还得之道去哪找操作对象吧

我们之前在KubernetesClient下找到了很多，但是这下面并不是全部呀，虽然pods、service、namespaces等等都有了，但像deployments就没有呀，这些在哪呢？瞎找吗？是的，瞎找总是能找到的，但是我们先不急着瞎找，我们先分析一波，说不定就能找到了呢？

还记不记得我们用yaml文件创建pod、service这些时候填的apiVersion？

pod、service、namespace这些的apiVersion是v1，而deployment和daemonSet的apiVersion是apps/v1，我们再看下里的方法，是不是有一个就很显眼了。

image.png

点进去它返回的接口，果不其然，我们的daemonSet和deployment就静静地躺在这里。

image.png

相信通过带领大家进行此次浅析，大家对整个Fabric8的结构都有了一定的了解，也对进一步该如何探索有了自己的理解，剩下的就只能等大家自己进一步实践了。