现状
在dhorse 1.4.0 版本之前，一直使用 k8s 官方提供的 sdk 与 k8s 集群交互，官方 sdk 的 Maven 坐标如下：
<dependency> <groupId>io.kubernetes</groupId> <artifactId>client-java</artifactId> <version>18.0.0</version></dependency>
复制代码
但是自从 1.4.0 版本以后，dhorse 开始支持 fabric8 的 sdk，fabric8 的 sdk 的 Maven 坐标如下：
<dependency> <groupId>io.fabric8</groupId> <artifactId>kubernetes-client</artifactId> <version>6.9.0</version></dependency>
复制代码
那么，为什么要替换为 fabric8 的 sdk 与 k8s 交互呢？
k8s 官方与 fabric8 的对比
1.社区方面
两者的关注度上，都差不多，没有太大差别；
但是，fabric8 的 sdk 提供的文档和示例更加完善，而 k8s 官方提供的示例较少；
2.功能方面
fabric8 不仅支持 k8s，同时也支持 OpenShift，而官方 sdk 支持 k8s；
3.包大小
k8s 官方 sdk 依赖的 sdk 过大，有 30M 左右，而 fabric8 只有不到 10M；
使用官方的 sdk 也会导致 dhorse 的安装包过大。
4.API 使用方面
举个例子，以查询 k8s 集群的命名空间列表为例，说明代码如下。
官方：
ApiClient apiClient = this.apiClient(clusterPO.getClusterUrl(), clusterPO.getAuthToken());CoreV1Api coreApi = new CoreV1Api(apiClient);List<ClusterNamespace> namespaces = new ArrayList<>();String labelSelector = null;if(pageParam != null && !StringUtils.isBlank(pageParam.getNamespaceName())) { labelSelector = "kubernetes.io/metadata.name=" + pageParam.getNamespaceName();}try { V1NamespaceList namespaceList = coreApi.listNamespace(null, null, null, null, labelSelector, null, null, null, null, null);} catch (ApiException e) { String message = e.getResponseBody() == null ? e.getMessage() : e.getResponseBody(); LogUtils.throwException(logger, message, MessageCodeEnum.CLUSTER_NAMESPACE_FAILURE);}
复制代码
fabric8:
try(KubernetesClient client = client(clusterPO.getClusterUrl(), clusterPO.getAuthToken())){ ListOptions o = new ListOptions(); if(pageParam != null && !StringUtils.isBlank(pageParam.getNamespaceName())) { o.setLabelSelector("kubernetes.io/metadata.name=" + pageParam.getNamespaceName()); } namespaceList = client.namespaces().list(o);}
复制代码
可以看出，官方提供的 API 接口不够简洁，而且抛出了不必要的异常。
结论
综上，dhorse 后续版本会默认选择 fabric8 的 sdk 与 k8s 器群交互，并计划在 v1.6 的版本里下掉 k8s 官方的 sdk。
评论