在K8S上Redis群

问题分析

    基本上来说，上部署一个重新部署，但在 k 部署一个普通应用程序并没有什么区别，下面几个问题：

1、REDIS是一个有状态的应用

    这是redis集群时我们最需要注意的问题，当我们把redis以pod的形式部署在k8中的时候，每个pod缓存的数据都不一样，而且pod的IP是会变化的，这什么时候如果使用普通的部署和服务部署来redis-cluster经常出现很多问题，因此需要改用StatefulSet + Headless Service来解决。

2、数据持久化

    redis 虽然是内存的缓存，但需要依赖于磁盘数据进行显示的化，以便服务重启时可能已经恢复了缓存的数据表中，我们需要使用共享文件系统 + PV，在卷）方式来让整个集群中的所有豆荚都可以共享同一层化储存。

概念介绍

    在几个开始之前先来详细介绍一下概念和原理。

1、无头服务

    有句话说，Headless Service 没有指定Cluster 的Service，相应的，k8s 的简单映射在IP 里，Headless Service 的解析结果不是一个Cluster IP，而是它所关联的所有Pod 的IP 列表。

2、有状态集

  StatefulSet是几个地方用于解决应用部署的一种情况，8种情况可以认为这是一种Deployment/RC变化，它有以下特性：

    StatefulSet 管理的每个 Pod 都有唯一的文档/网络标识，按照规律生成，而不是像 Deployment 中的那个名称和 IP 都是经常的。（并且 StatefulSet 的名字是redis，那么pod的名字就是redis-0， redis-1 ...）

    StatefulSet中ReplicaSet的启停顺序是严格受控的，操作第一个pod一定要等前N-1个执行才可以。

    StatefulSet 的 Pod 的稳定化存储，并且采用了不同 Pod 的容量而不会被 PV 保留。

    另外，StatefulSet 要配合每个 Headless Service 使用，它会在 Headless Service 提供的 DNS 传输上，最终准确到 Pod 的域名格式需要说明，格式如下：

$(podname).$(headless service name)

    映射这个，备用集群时使用域名IP，实现有状态应用就可以在配置的管理。

方案