Kubernetes在Hazelcast平台上的原生云部署(概述)

Kubernetes在Hazelcast平台上的原生云部署(概述)

我们一说到原生云就意味着我们当前的应用程序时运行在一个集群之上,同时使用这个集群的基础设施实现这个应用程序.一个定制化的Hazelcast引导程序被用来使Hazelcast可以动态的发现已经加入集群的Hazelcast节点.当拓扑结构发生变化时,需要Hazelcast节点自身进行交流和处理.

 

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

 

在k8s中,最小的应用单元就是pod,一个pod就是同一个主机调度下的一个或者多个容器.在一个Pod中的所有容器共享同一个网络命名空间,同时可以有选择行的共享同一个数据卷.这种情况下,我们不能单独运行一个Hazelcast pod,因为他的发现机制依赖于Service的定义.

 

添加一个Hazelcast服务

 

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

apiVersion: v1
kind: Service
metadata:
  labels:
    name: hazelcast
  name: hazelcast
spec:
  ports:
    - port: 5701
  selector:
    name: hazelcast

这里值得注意的是selector(选择器).在标签的上层有一个查询器,它标示了被service所覆盖的pods集合.这种情况下,selector就是代码中的name:hazelcast.在接下来的Repication Controller说明书中,你会看到Pods中有对应的标签,那么它就会被这个Service中对应的成员变量所选中.创建该Serviced的命令如下:

$ kubectl create -f examples/hazelcast/hazelcast-service.yaml

添加一个拷贝节点

k8s和Hazelcast真正强大的地方在于他们可以轻松的构建一个可拷贝的,大小可调节的Hazelcast集群.在K8s中,存在一个Replication Controller的管理器,专门用来管理相同的Pods拷贝集合.和service一样,它也存在一个在集合成员变量中定义的选择查询器.和service不同的是,它对拷贝的个数有要求,会通过创建或者删除Pods来确保当前Pods的数量符合要求.Replication Controllers会通过匹配相应的选择查询器来确认要接受的Pods.

 

说了这么多,Hazelcast是一个高度可扩展的数据分发和集群平台.Hazelcast是基于java的.

 

hazelcast支持分布式队列,集合,map,线程池,锁,支持事务处理,分布式的监听和事件,总之就是支持很多东西,用起来很简单,速度快.依赖小,效率高,对CPU和内存友好.

 

hazelcast对数据几乎是均匀的分布在每一个节点的,每个节点上有(1/n*总数据量)+备份的数据量(n是集群中的节点).如果一个节点宕机了,他的备份副本也拥有相同的数据,将会动态的将数据包括所有权和锁分配到依然活着的节点,所以数据不会丢失.当一个新的节点加入的时候,新的节点会加载集群中的数据量,减少其他节点的压力.

 

没有单一的集群主机或者其他东西会导致单点故障,集群中的每个节点具有相同的权利和责任,没有节点是超级权限,也不需要额外的依赖其他的机器.

 

咱们接着说回K8s,K8s一共有三个重要的东西,分别是pod,service,RC.k8s中,所有的容器都运行在pod中,一个pod中有一个容器或者多个合作的容器.在后一种情况,pod中的容器被保证保证放置在同一个机器上,可以共享资源.一个pod也能包含零个或者更多的volume,volume是对一个容器私有的目录或者可以在pod中的容器间共享.对于用户每个创建的pod,系统会找一个健康运转并且有足够的容量的机器,然后开始将相应的容器在那里启动.如果一个容器失败,它会找到k8s的node agent自动重启,这个node agent被称为kubelet.但是如果pod或者其他的机器出现故障,他不会被自动转移或者重启,除非用户定义了一个RC.

 

用户可以自己创建并管理pod,但是k8s极大的简化了系统管理,它能让用户指派两个常见的跟pod相关的活动:基于相同的pod配置部署多个pod副本(类似于复制);当一个pod或者它所在的机器发生故障创建一个可用来替换的pod.

K8s有专门的一套API对象来管理上面的这些行为,这些API就是RC,它用模板的形式定义了pod,然后系统根据模板实例化出一些pod(特别是由用户).pod的副本集合可以共同组成一整个应用,一个微服务,或者在一个多层应用的一层.一旦pod创建好,系统会持续的监控他们的健康状态,和他们运行时所在的机器的健康状态.如果一个pod因为软件问题或者所在机器出现故障,Relication控制器会自动在健康的机器上创建一个新的pod,来保证pod的集合处于一个期望的冗余水平.一个或者多个应用的多个pod能共享一个机器.k8s不会动态的分批额端口,而是采用用户可以选择任意合适自己的端口,为了实现这点,他给每个pod分配了一个ip地址.

 

每个k8s中的资源,例如pod,都通过一个URL来被识别,并且有一个UID.URL中一些重要的组件是,对象的类型(如:pod),对象的名字,和对象的命名空间(namespace).对于一个特定的对象类型,每一个名字在其命名空间都是独一无二的.在一个对象的名字没有带着命名空间的形式给出,那就是默认的命名空间.UID在时间和空间的反问都是唯一的.

 

下一次咱们说一些关于搭建一个k8s集群的东西!!当然了,楼主实践不太会,还是单纯的说点纸上谈兵的问题.