自己的 Kubernetes 控制器（2）——用 Java 开发

最近更新于 2020 年 4 月 24 日 3 分钟阅读时长译文

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

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

watcher

实际实现代码：

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。