前面文章中,我们大概描述了开发自定义 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 控制器只是一个控制回路,它会监视集群状态,并尝试将其调整为目标状态。为了跟进调度和删除事件,就需要实现观察者模式。应用订阅事件,在事件发生时,调用相关的回调。

下面是一个简化版的类图:

java操作kubernetes和prometheus java开发kubernetes_java逻辑删除

实际实现代码:

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