引言
Kafka和zookeeper是在两种典型的有状态的集群服务。首先kafka和zookeeper都需要存储盘来保存有状态信息，其次kafka和zookeeper每一个实例都需要有对应的实例Id(Kafka需要broker.id,zookeeper需要my.id)来作为集群内部每个成员的标识，集群内节点之间进行内部通信时需要用到这些标识。
对于这类服务的部署，需要解决两个大的问题，一个是状态保存，另一个是集群管理(多服务实例管理)。kubernetes中提的StatefulSet(1.5版本之前称为Petset)方便了有状态集群服务在上的部署和管理。具体来说是通过Init Container来做集群的初始化工 作，用 Headless Service来维持集群成员的稳定关系，用Persistent Volume和Persistent Volume Claim提供网络存储来持久化数据，从而支持有状态集群服务的部署。
本文将尝试根据社区提供的StatefulSet方案，对kafka和zookeeper服务进行部署。具体的部署过程包括以下几个部署： (1) Persistent Volume 存储的创建
(2) StatefulSet(Petset)资源的创建
(3) headless服务的创建
Persistent Volume存储的创建
PersistentVolume(PV)是集群之中的一块网络存储。跟 Node 一样，也是集群的资源，并且不属于特定的namespace。PV 跟 Volume (卷) 类似，不过会有独立于 Pod 的生命周期。
在有状态服务创建之前，需要先创建对应的PV存储。为了便于环境的搭建，本文PV存储的后端采用NFS。NFS服务的容器化部署，可以参考腾讯云容器服务帮助文档-搭建nfs服务器。
$ kubectl get serviceNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes 172.16.255.1 443/TCP 56mnfsserver0 172.16.255.44 20048/TCP,111/TCP,2049/TCP 40mnfsserver1 172.16.255.6 2049/TCP,20048/TCP,111/TCP 29mnfsserver2 172.16.255.131 2049/TCP,20048/TCP,111/TCP 14mnfsserver3 172.16.255.231 2049/TCP,20048/TCP,111/TCP 10mnfsserver4 172.16.255.12 2049/TCP,20048/TCP,111/TCP 7mnfsserver5 172.16.255.223 2049/TCP,20048/TCP,111/TCP 4m
基于NFS的PV创建示例如下：
apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 annotations: volume.beta.kubernetes.io/storage-class: "anything" spec: capacity: storage: 50Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Recycle nfs: path: /exports server: 172.16.255.44
其中172.16.255.44为对应的nfs服务的IP。对应创建多个PV，zookeeper服务和kafka服务各3个。
$ kubectl get pvNAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGEpv0001 50Gi RWO Recycle Available 5mpv0002 50Gi RWO Recycle Available 5mpv0003 50Gi RWO Recycle Available 5mpv0004 50Gi RWO Recycle Available 2mpv0005 50Gi RWO Recycle Available 2mpv0006 50Gi RWO Recycle Available 2m
上面通过手动的方式创建了一个NFS Volume，这在管理很多Volume的时候很方便。kubernetes还提供了StorageClass来动态创建PV，可以大大节省了管理员的时间。作者在这里就不做对应的测试了。
zookeeper中StatefulSet(Petset)资源和headless服务的创建
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计)，其应用场景包括
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service(即没有Cluster IP的Service)来实现
- 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依序进行(即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现
- 有序收缩，有序删除(即从N-1到0)
在创建好对应的PV后，需要创建对应的StatefulSet(Petset)资源。由于本文使用的kubernetes为1.4.6版本，所以示例中采用的名称仍然为Petset。具体创建新的nfsserver和pv
# kubectl get service -l qcloud-app=nfsserverNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEnfsserver 172.16.255.18 2049/TCP,20048/TCP,111/TCP 32m# kubectl get pv pv0007NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGEpv0007 50Gi RWO Recycle Available 14s
由于创建过程在前文已经描述过，这里不再进行详述创建过程。
kafka副本数修改
# kubectl scale petset kafka --replicas=4petset "kafka" scaled# kubectl get pod -l app=kafka -o wide NAME READY STATUS RESTARTS AGE IP NODEkafka-0 1/1 Running 0 1h 172.16.0.7 10.0.0.33kafka-1 1/1 Running 0 1h 172.16.2.5 10.0.0.40kafka-2 1/1 Running 0 1h 172.16.1.5 10.0.0.45kafka-3 1/1 Running 0 1m 172.16.0.8 10.0.0.33
总结
本文详细的介绍了基于Statefulset(PetSet)+Persistent Volume的方式，部署有状态的集群服务zookeeper和kafka。总体上看，基于Statefulset+PV的方式很好的解决了kafka和zookeeper服务需要存储盘来保存信息，同时每个实例需要特定的Id标记的问题。但目前PV的创建过程，以及Statefulset的启动过程，相对于来说还是比较复杂。另外基于StatefulSet(PetSet)的扩容和升级对于实例的变更顺序依然有比较大的依赖，kubernetes社区也在做进一步探索。
转播
