前面文章中,我们大概描述了开发自定义 Kubernetes 控制器的基础内容。其中我们提到,只要能够使用 HTTP/JSON 就可以满足开发需求。本文中就言归正传开始开发。
开发使用的技术栈可以 Python、NodeJS 或者 Ruby。我的博客叫“Java Geek”,所以这里选择的是 Java。
这个案例中我们使用 Sidecar 模式:每次有 Pod 调度,就生成一个并行的 Pod;当前面的 Pod 被删除,后面的 Pod 也随之删除。
选择合适的工具
为了在 Java 中调用 REST 接口,就首先要生成绑定的结构。有几种方式可以完成这项工作:
- 最无聊的方式就是手工完成:
认真对待所有请求和响应的 JSON 数据,据此开发对应的 Java 对象,选择 JSON 序列化框架,以及 HTTP 客户端。 - 次选的方式是使用 Swagger 或者 APiary 这样的代码生成器:
API 提供者需要使用某种方式来提供对应的模型,开发者使用相应工具来生成代码。 - 最好的方式是,已经有客户端库提供了绑定结构。
Kubernetes 属于第三种——它已经为多种语言提供了绑定代码。只不过这种语言封装和 REST API 非常相近,不太符合我的习惯。例如获取所有命名空间下所有 Pod 的代码:
ApiClient client = Config.defaultClient();
CoreV1Api core = new CoreV1Api(client);
V1PodList pods =
core.listPodForAllNamespaces(null, null, null, null, null, null, null, null);
所有
null
都需要传递
这就是我所说的 和 REST API 非常相近
,幸运的是,还有其他选项:Fabric8 在 Github 上提供了 Java API。等价代码:
KubernetesClient client = new DefaultKubernetesClient();
PodList pods = client.pods().inAnyNamespace().list();
不再需要无用的
null
参数。
Fabric8 概述
简单说来,Fabric8 API 里面,在 KubernetesClient
示例中可以获取所有 Kubernetes 资源:
client.namespaces()
client.services()
client.nodes()
- 等等
根据资源的特性,可以使用命名空间进行过滤:
client.pods().inAnyNamespace()
client.pods().inNamespace("ns")
列出所有命名空间的所有 Pod:
client.pods().inAnyNamespace().list();
删除命名空间 ns
中的所有 Pod:
client.pods().delete(client.pods().inNamespace("ns").list().getItems());
创建一个名为 ns
的命名空间:
client.namespaces()
.createNew()
.withApiVersion("v1")
.withNewMetadata()
.withName("ns")
.endMetadata()
.done();
实现控制回路
Kubernetes 控制器只是一个控制回路,它会监视集群状态,并尝试将其调整为目标状态。为了跟进调度和删除事件,就需要实现观察者模式。应用订阅事件,在事件发生时,调用相关的回调。
下面是一个简化版的类图:
实际实现代码:
public class DummyWatcher implements Watcher<Pod> { @Override
public void eventReceived(Action action, Pod pod) { switch (action) { // 新 Pod
case ADDED: break; // Pod 修改
case MODIFIED: break; // Pod 删除
case DELETED: break; // Pod 出错
case ERROR: break;
}
} // 删除所有资源。如果客户端正确关闭,`cause` 为 `null`
@Override
public void onClose(KubernetesClientException cause) {
}
}
client.pods()
.inAnyNamespace()
.watch(DummyWatcher());
细枝末节
我们已经准备好实现 Sidecar 模式了。我不会贴出所有代码,毕竟有 Github,只会贴出一些必要内容。
标记 Sidecar
我们的控制器要在 Pod 新建世加入 Sidecar,并在 Pod 移除时也删除 Sidecar。这个逻辑有一点问题:如果 Sidecar pod 被调度,就会触发监控事件,就会加入新的 Sidecar,这个过程会不断重复下去。因此有必要对 Sidecar Pod 进行标记。在带有标记的 Pod 被创建时,不会触发创建逻辑。
有几种方式来对 Sidecar Pod 进行标记:
- 给 Pod 加入后缀,比如
sidecar
- 添加特定标签:
client.pods()
.inNamespace("ns")
.createNew()
.withNewMetadata()
.addToLabels("sidecar", "true")
.endMetadata()
.done();
和 Pod 一起删除 Sidecar
Pod 应该有且只有一个 Sidecar,并且随 Pod 的创建和销毁同步进行创建和销毁。
因此 Sidecar 数据结构中需要有一个指向主 Pod 的引用。这样在 Pod 删除时,如果它不是 Sidecar Pod,我们就能找到它的 Sidecar 并删除。
最直白的方式就是在住 Pod 删除时直接删除 Sidecar,不过这需要做不少事。Kubernetes 中可以把两个 Pod 的生命周期使用 ownerReference
关联起来。这样就可以让 Kubernetes 自行处理删除逻辑了。
用 API 实现非常直观:
client.pods()
.inNamespace("ns")
.createNew()
.withNewMetadata()
.addNewOwnerReference()
.withApiVersion("v1")
.withKind("Pod")
.withName(podName)
.withUid(pod.getMetadata().getUid())
.endOwnerReference()
.endMetadata()
.done();
保持 Sidecar
添加了 Sidecar 并不意味着他会永远保持。例如属于一个 Deployment 的 Pod 会被删除,Deployment 的核心功能就是保持副本数为期望值。
类似的,如果一个 Sidecar 被删除,并且主 Pod 还保持存活,就应该创建新的 Sidecar,并维持 ownerReference
。
结论
本文描述了用 Java 实现 Kubernetes 控制器的过程。有了 Fabric8 API,这个过程相当直接。主要需要解决的问题就是删除和创建逻辑。下一篇也就是最后一篇,会讲解部署和运行的过程。
本文涉及的完整代码保存在 Github。
相关链接
https://github.com/nfrankel/jvm-controller
https://github.com/fabric8io/kubernetes-client