Kubernetes有状态应用管理——PetSet

小灰灰 2021-11-01 06:38 257阅读 0赞

## 目录贴：[Kubernetes学习系列][Kubernetes] ##

## 1、介绍 ##

在Kubernetes中，大多数的Pod管理都是基于无状态、一次性的理念。例如Replication Controller，它只是简单的保证可提供服务的Pod数量。如果一个Pod被认定为不健康的，Kubernetes就会以对待牲畜的态度对待这个Pod——删掉、重建。相比于牲畜应用，PetSet（宠物应用），是由一组有状态的Pod组成，每个Pod有自己特殊且不可改变的ID，且每个Pod中都有自己独一无二、不能删除的数据。

众所周知，相比于无状态应用的管理，有状态应用的管理是非常困难的。有状态的应用需要固定的ID、有自己内部可不见的通信逻辑、特别容器出现剧烈波动等。传统意义上，对有状态应用的管理一般思路都是：固定机器、静态IP、持久化存储等。Kubernetes利用PetSet这个资源，弱化有状态Pet与具体物理设施之间的关联。一个PetSet能够保证在任意时刻，都有固定数量的Pet在运行，且每个Pet都有自己唯一的身份。一个“有身份”的Pet指的是该Pet中的Pod包含如下特性：

1)        静态存储；

2)        有固定的主机名，且DNS可寻址（稳定的网络身份，这是通过一种叫 Headless Service 的特殊Service来实现的。 和普通Service相比，Headless Service没有Cluster IP，用于为一个集群内部的每个成员提供一个唯一的DNS名字，用于集群内部成员之间通信 。）;

3)        一个有序的index（比如PetSet的名字叫mysql，那么第一个启起来的Pet就叫mysql-0，第二个叫mysql-1，如此下去。当一个Pet down掉后，新创建的Pet会被赋予跟原来Pet一样的名字，通过这个名字就能匹配到原来的存储，实现状态保存。）

应用举例：

1)        数据库应用，如Mysql、PostgreSQL，需要一个固定的ID（用于数据同步）以及外挂一块NFS Volume（持久化存储）。

2)        集群软件，如zookeeper、Etcd，需要固定的成员关系。

## 2、使用限制 ##

1)        1.4新加功能，1.3及之前版本不可用；

2)        DNS，要求使用1.4或1.4之后的DNS插件，1.4之前的插件只能解析Service对应的IP，无法解析Pod（HostName）对应的域名；

3)        日常运维，对于PetSet，唯一能够更改的就是replicas；

4)        需要持久化数据卷（PV，若为nfs这种无法通过调用API来创建存储的网络存储，数据卷要在创建PetSet之前静态创建；若为aws-ebs、vSphere、openstack Cinder这种可以通过API调用来动态创建存储的虚拟存储，数据卷除了可以通过静态的方式创建以外，还可以通过StorageClass进行动态创建。需要注意的是，动态创建出来的PV，默认的回收策略是delete，及在删除数据的同时，还会把虚拟存储卷删除）；

5)        删除或缩容PetSet不会删除对应的持久化数据卷，这么做是处于数据安全性的考虑；

6)        只能通过手动的方式升级PetSet。

## 3、PetSet示例 ##

以下示例演示了创建两个PV，创建两个PetSet的过程。在PetSet创建完成之后，验证了其hostName及直接Pod访问。

### 3.1 创建PV ###

创建PV的时候，我两个PV选择了同一个NFS server，创建也是成功的。Kubernetes在创建PV的时候并不会校验NFS server是否存在，是否能够连接成功，也不会校验storage设置的大小是否真实。所以说，PV的创建需要管理员在一开始就设置好，依赖人为的校验。