这篇文档主要是描述Kubernetes在Hazelcast平台上部署原生云应用的方法。当我们提到原生云应用时，意味着我们的应用程序是运行在一个集群之上，同时使用这个集群的基础设施实现这个应用程序。值得注意的是，在此情况下，一个定制化的Hazelcast引导程序被用来使Hazelcast可以动态的发现已经加入集群的Hazelcast节点。

当拓扑结构发生变化时，需要Hazelcast节点自身进行交流和处理。

本文档同样也尝试去解释Kubernetes的核心组件：Pods、Service和ReplicationController。

前提

下面的例子假定你已经安装了Kubernetes集群并且可以运行。同时你也已经在你的路径下安装了kubectl命令行工具。

给急性子的备注

下面的介绍会有点长，如果你想跳过直接开始的话，请看结尾处的“太长不读版”。

资源

免费的资源如下：

Hazelcast节点发现 – https://github.com/pires/hazelcast-kubernetes-bootstrapper

Dockerfile文件 –https://github.com/pires/hazelcast-kubernetes

官方的Docker镜像 – https://quay.io/repository/pires/hazelcast-kubernetes

简单的单调度单元的Hazelcast节点

在Kubernetes中，最小的应用单元就是Pod。一个Pod就是同一个主机调度下的一个或者多个容器。在一个Pod中的所有容器共享同一个网络命名空间，同时可以有选择性的共享同一个数据卷。

在这种情况下，我们不能单独运行一个Hazelcast Pod，因为它的发现机制依赖于Service的定义。

添加一个Hazelcast 服务

在Hazelcast中，一个Service被描述为执行同一任务的Pods集合。比如，一个Hazelcast集群中的节点集合。Service的一个重要用途就是通过建立一个均衡负载器将流量均匀的分到集合中的每一个成员。此外，Service还可以作为一个标准的查询器，使动态变化的Pod集合提供有效通过Kubernetes的API。实际上，这个就是探索机制的工作原理，就是在service的基础上去发现Hazelcast Pods。 下面是对Service的描述：

这里值得注意的是selector（选择器）。在标签的上层有一个查询器，它标识了被Service所覆盖的Pods集合。在这种情况下，selector就是代码中name: hazelcast。在接下来的 Replication Controller说明书中，你会看到Pods中有对应的标签，那么它就会被这个Service中对应的成员变量所选中。

创建该Serviced的命令如下：

添加一个拷贝节点

Kubernetes和Hazelcast真正强大的地方在于它们可以轻松的建立一个可拷贝的、大小可调的Hazelcast集群。

在Kubernetes中，存在一个叫做Replication Controller的管理器，专门用来管理相同Pods的拷贝集合。和Service一样，它也存在一个在集合成员变量中定义的选择查询器。和Service不同的是，它对拷贝的个数有要求，会通过创建或者删除Pods来确保当前Pods的数量符合要求。

Replication Controllers会通过匹配响应的选择查询器来确认要接收的Pods，下面我们将创建一个单拷贝的Replication Controller去接收已经存在的Hazelcast Pod。

在这段代码中，有一些需要注意的东西。首先要注意的是，我们运行的是quay.io/pires/hazelcast-kubernetes image, tag 0.5。这个busybox安装在JRE8上。尽管如此，它还是添加了一个用户端的应用程序，从而可以发现集群中的Hazelcast节点并且引导一个Hazelcast实例。HazelcastDiscoveryController通过内置的搜索服务器来探索Kubernetes API Server，之后用Kubernetes API来发现新的节点。

你可能已经注意到了，我们会告知Kubernetes，容器会暴露Hazelcast端口。最终，我们需要告诉集群的管理器，我们需要一个CPU核。

对于Hazelcast Pod而言，Replication Controller块的配置基本相同，以上就是声明，它只是给管理器提供一种简单的建立新节点的方法。其它的部分就是包含了Controller选择条件的selector，以及配置Pod数量的replicas，在这个例子中数量为1。

最后，我们需要根据你的Kubernetes集群的DNS配置来设置DNS_DOMAIN的环境变量。

创建该控制器的命令：

当控制器成功的准备好后，你就可以查询服务端点：

你可以看到Service发现那些被Replication Controller建立的Pods。

这下变的更加有趣了。让我们把集群提高到2个Pod。

现在，如果你去列出集群中的Pods,你应该会看到2个Hazelcast Pods:

如果想确保每一个Pods都在工作，你可以通过log命令来进行日志检查，如下：

接着是4个Pods:

然后通过刚才的操作去检查这4个成员是否连接。

太长不读版

对于那些急性子，下面是这一章所用到的所有命令：