共计 12057 个字符，预计需要花费 31 分钟才能阅读完成。
本文依据我在〖deeplus 直播第 247 期〗线上分享演讲内容整顿而成。
明天将分享的内容分为以下 4 个方面：
- 一、缘起
- 二、介绍多样的容器化技术
- 三、Redis 介绍
- 四、Redis 容器化计划的比照
一、缘起
首先咱们先聊一下为什么明天我会分享这个主题。我和敌人一起组织了一个 Redis 技术交换群，到当初曾经经营了 6 年左右的工夫，其中某一天在群里有一个小伙伴就抛出来一个问题：
他问大家线上的 Redis 有没有应用 Docker 装置？Docker 应用 Host 的网络模式、磁盘应用本地挂载模式这种计划怎么样？这里的话咱们临时先不说这个计划如何，因为在明天的分享之后，我置信大家对于这个计划应该会有一个更清晰的意识和评估。
二、介绍多样的容器化技术
1、chroot 和 jails
在容器化技术方面，其实历史很长远了。尽管咱们当初用的容器化技术，或者说 k8s，还有云原生的概念是近几年才火起来的，然而实际上就容器化技术的倒退来说，其实是很早的了。比如说最早的时候来自 chroot，chroot 大家可能都用过，或者都有理解过，在 1979 年的时候它是来自 Unix，它次要的性能是能够批改过程和子过程的 /。
通过应用 chroot 达到什么样成果呢？应用 chroot 加某一个目录，而后再启动一个过程，那么这个过程本人所看到的 / , 就是咱们平时所说的 / 目录，这个 / 就会是咱们方才指定的文件夹，或者说方才指定的门路。这样子的话能够无效的爱护咱们操作系统下面的一些文件，或者说权限和平安相干的货色。
在 2000 年的时候，呈现了一个新的技术，叫做 jails，其实它曾经具备了 sandbox，就是沙箱环境的雏形。应用 jails 的话，能够让一个过程或者说创立的环境领有独立的网络接口和 IP 地址，而当咱们提到应用 jails 的话，咱们必定会想到一个问题，就是如果你有了独立的网络接口和 IP 地址，这样的话就不能发原始的套接字，通常跟原始的套接字接触得比拟多的就是咱们应用的 Ping 命令。默认的状况下，这样子是不容许应用原始的套接字的，而有本人的网络接口和 IP 地址，这个感觉上就像是咱们罕用的虚拟机。
2、Linux VServer 和 OpenVZ
接下来在 2001 年的时候，在 Linux 社区当中就呈现了一个新的技术叫做 Linux VServer。Linux VServer 有时候能够简写成 lvs，然而和咱们平时用到的 4 层的代理 lvs 其实是不一样的。它其实是对 Linux 内核的一种 Patch，它是须要批改 Linux 内核，批改实现之后，咱们能够让它支持系统级的虚拟化，同时应用 Linux VServer 的话，它能够共享零碎调用，它是没有仿真开销的，也就是说咱们罕用的一些零碎调用、零碎调用的一些函数都是能够共享的。
在 2005 年的时候，呈现的一个新的技术—OpenVZ。OpenVZ 其实和 Linux VServer 有很大的类似点，它也是对内核的一种 Patch，这两种技术最大的变动就是它对 Linux 打了很多的 Patch，加了很多新的性能，然而在 2005 年的时候，没有把这些全副都合并到 Linux 的骨干当中，而且在应用 OpenVZ 的时候，它能够容许每个过程能够有本人的 /proc 或者说本人的 /sys。
其实咱们大家都晓得在 Linux 当中，比如说启动一个过程，你在他的 /proc/self 上面，你就能够看到过程相干的信息。如果你有了本人独立的 /proc，其实你就能够达到和其余的过程隔离开的成果。
接下来另外一个显著的特点就是它有独立的 users 和 groups，也就是说你能够有独立的用户或者独立的组，而且这个是能够和零碎当中其余的用户或者组独立开的。
其次的话 OpenVZ 是有商业应用的，就是有很多国外的主机和各种 VPS 都是用 OpenVZ 这种技术计划。
3、namespace 和 cgroups
到了 2002 年的时候，新的技术是 namespace。在 Linux 当中咱们有了新的技术叫做 namespace，namespace 能够达到过程组内的特定资源的隔离。因为咱们平时用到的 namespace 其实有很多种，比如说有 PID、net 等，而且如果你不在雷同的 namespace 上面的话，是看不到其余过程特定的资源的。
到了 2013 年的时候，产生了一个新的 namespace 的个性，就是 user namespace。其实当有了 user namespace，就和上文提到的 OpenVZ 实现的独立用户和组的性能是比拟像的。
对于 namespace 的操作当中，通常会有三种。
1）Clone
能够指定子过程在什么 namespace 上面。
2）Unshare
它是与其余过程不共享的，unshare 再加一个 -net，就能够与其余的过程独立开，不共享本人的 net，不共享本人的网络的 namespace。
3）Setns
就是为过程设置 namespace。
到了 2008 年，cgroups 开始被引入到 Linux 内核当中，它能够用于隔离过程组的资源应用，比如说能够隔离 CPU、内存、磁盘，还有网络，尤其是他在 2013 年和 user namespace 进行了一次组合之后，并且进行了从新的设计，这个时候，就变得更现代化了，就像咱们当初常常应用到的 Docker 的相干个性，其实都来自于这个时候。所以说 cgroups 和 namespace 形成古代容器技术的根底。
4、LXC 和 CloudFoundry
在 2008 年的时候，新的一项技术叫做 LXC, 咱们也会叫他 Linux Container（以下均简称 LXC）。上文咱们提到了很多容器化的技术，比方 Linux VServer、OpenVZ，然而这些都是通过打 Patch 来实现的，而 LXC 是首个能够间接和上游的 Linux 内核独特工作的。
LXC 是能够反对特权容器的，意思就是说能够在机器下面去做 uid map、gid map，去做映射，而且不须要都拿 root 用户去启动，这样子就具备了很大的便利性。而且这种形式能够让你的被攻击面大大放大。LXC 反对的这几种比拟惯例的操作，就是 LXC-start，能够用来启动 container，LXC-attach 就能够进入 container 当中。
到 2011 年的时候，CloudFoundry 开始呈现了，他实际上是应用了 LXC 和 Warden 这两项技术的组合，在这个时候不得不提到的，就是他的技术架构是 CS 的模式，也就是说还有一个客户端和 server 端，而 Warden 容器，它通常是有两层，一层是只读 os 的，就是只读的操作系统的文件系统，另外一层是用于应用程序和其依赖的非长久化的读写层，就是这两层的组合。
咱们之前提到的技术，大多数都是针对于某一台机器的，就是对于单机的。CloudFoundry 它最大的不同就是它能够治理跨计算机的容器集群，这其实就曾经有了古代容器技术的相干个性了。
5、LMCTFY 和 systemd-nspawn
在 2013 年的时候，Google 开源了本人的容器化的解决方案，叫做 LMCTFY。这个计划是能够反对 CPU、内存还有设施的隔离。而且它是反对子容器的，能够让应用程序去感知到本人以后是处在容器当中的。另外还能够再为本人创立一个子容器，然而随着 2013 年倒退之后，它逐步发现只依附本人不停的做这些技术，就相当于单打独斗，倒退始终是无限的，所以它逐渐的将本人的次要精力放在形象和移植上，把本人的外围个性都移植到了 libcontainer。而 libcontainer 之后就是 Docker 的运行时的一个外围，再之后就是被 Docker 捐到了 OCI，再而后就倒退到了 runC。这部分内容咱们稍后再具体解说。
大家都晓得服务器它必定是有一个 PID 为 1 的过程。就是它的初始过程、守护过程，而古代的操作系统的话，大多数大家都应用的是 systemd，同样 systemd 它也提供了一种容器化的解决方案，叫做 systemd-nspawn。这个技术的话，它是能够和 systemd 相干的工具链进行联合的。
systemd 除了有咱们平时用到的 systemctl 之类的，还有 systemd machine ctl，它能够去治理机器，这个机器反对两种次要的接口，一种是治理容器相干的接口，另外一种是治理虚拟机相干的接口。
而咱们通常来讲，就是说 systemd 提供的容器技术解决方案，它是容许咱们通过 machine ctl 去容器去进行交互的，比如说你能够通过 machine ctl start，去启动一个 systemd 反对的容器，或者通过 machine ctl stop，去关掉它，而在这种技术下，它是反对资源还有网络等隔离的，其实它最次要的是 systemd ns，它其实是应用 namespace 去做隔离。对于资源方面是来自于 systemd，systemd 是能够应用 cgroups 去做资源隔离的，其实这也是这两种两种技术计划的组合。
6、Docker
而在 2013 年 Docker 也呈现了。通常来讲，Docker 是容器时代的引领者，为什么这么说呢？因为 Docker 在 2013 年呈现的时候，他首先提到了标准化的部署单元，就是 Docker image。同时它还推出了 DockerHub，就是地方镜像仓库。容许所有人通过 DockerHub 去下载事后曾经构建好的 Docker image，并且通过一行 Docker run 就能够启动这个容器。
在泛滥应用起来比拟繁琐、比较复杂的技术下，Docker 这时提出来，你只须要一行 Docker run，就能够启动一个容器，它大大简化了大家启动容器的复杂度，晋升了便捷性。
所以 Docker 这项技术就开始风靡寰球。而 Docker 它次要提供的一些性能是什么呢？比如说资源的隔离和治理。而且 Docker 在 0.9 之前，它的容器运行时是 LXC，在 0.9 之后，他就开始把 LXC 替换掉，替换成了 libcontainer，而这个 libcontainer 其实就是咱们在上文提到的 Google 的 LMCTFY。再之后 libcontainer 捐给了 OCI。而那之后 Docker 当初的容器运行时是什么呢？是 containerd。containerd 的更上层是 runc，runc 的外围其实就是 libcontainer。
而到了 2014 年的时候，Google 发现大多数的容器化解决方案，其实都只提供了单机的解决方案，同时因为 Docker 也是 CS 架构的，所以它须要有一个 Docker demand，它是须要有守护过程存在的，而这个守护过程的话，是须要用 root 用户去启动的，而 root 用户启动的守护过程，其实是减少了被攻击面，所以 Docker 的平安问题也被很多人诟病。
在这个时候 Google 就发现了这个点，并且把本人的 Borg 零碎去做了开源，开源版本就是 Kubernetes。Google 还联结了一些公司，组建了一个云原生基金会（CNCF）。
7、Kubernetes
通常来讲 Kubernetes 是云原生利用的基石，也就是说在 Kubernetes 呈现之后，咱们的云原生技术开始逐渐地倒退起来，逐渐地引领了潮流，Kubernetes 提供了一些次要的个性。
它能够反对比拟灵便的调度、管制和治理，而这个调度程序的话，除了它默认的以外，也能够比拟不便的去对它做扩大，比如说咱们能够本人去写本人的调度程序，或者说亲和性、反亲和性，这些其实都是咱们比拟罕用到的一些个性。
还有包含他提供的一些服务，比如说内置的 DNS、kube-DNS 或者说当初的 CoreDNS，通过域名的形式去做服务发现，以及 Kubernetes 当中有很多的控制器。它能够将集群的状态调整至咱们预期的状态，就比如说有一个 pod 挂掉了，它能够主动的把它再复原到咱们预期想要的样子。
另外就是它反对丰盛的资源品种，比如说几个次要的层级，最小的是 pod，再往上有 deployment，或者有 StatefulSets，相似于这样子的资源。
最初一点是它让咱们更加喜爱它的因素，就是它有丰盛的 CRD 的拓展，即能够通过本人去写一些自定义的资源，而后对它进行扩大，比方 CRD。
8、更多的容器化技术
除了方才咱们提到的这些次要的技术以外，其实还有很多咱们没有提到的一些容器化的技术，比如说像 runc，上文咱们没有太多的介绍，还有 containerd。containerd 其实也是 Docker 开源进去的本人的外围，他的指标是做一个标准化工业可用的容器运行时，还有 CoreOS 开源进去的解决方案叫做 rkt。而 rkt 瞄准的点就是上文提到的 Docker 相干的平安问题。然而 rkt 当初我的项目曾经终止了。
还有红帽 (Red Hat) 开源进去的 podman，podman 是一种能够用它来启动容器，能够用它去治理容器，而且没有守护过程，所以就安全性来讲的话，podman 能够说比 Docker 的安全性直观上来看的话会好一些，然而它的便捷性来讲的话，就要大打折扣了。比如说容器的重启、开机起之类的，然而咱们都是有一些不同的解决方案的。
在 2017 年的时候，这个时候有一个 Kata Container，而这个 Kata Container 它有一段倒退过程，最开始是英特尔，英特尔在搞本人的容器运行时，还有一家初创公司叫做 hyper.sh，这家公司也在搞本人的容器运行时，这两家公司瞄准的都是做更平安的容器，他们应用的底层的技术都是基于 K8S。而之后这两家公司做了合并，hyper.sh 它开源进去的一个解决方案是 runv，被英特尔看上了之后就诞生了 Kata Container。在 2018 年的时候，AWS 开源进去本人的 Firecracker。
这两项技术和咱们上文提到的机器上的容器化技术其实大有不同，因为它的底层其实相当于是虚拟机，而咱们通常来讲，都认为它是轻量级虚拟机的一种容器化的技术。以上就是对于多样的容器化技术的介绍。
三、Redis 介绍
接下来进入对于 Redis 相干的介绍，以下是从 Redis 的官网下面摘抄的一段介绍。
1、Redis 应用的次要场景
其实 Redis 当初是应用最宽泛的一种 KV 型数据库。而咱们在应用它的时候，次要的应用场景可能有以下几种：
- 把它当缓存应用，把它放在数据库之前，把它当做缓存去应用；
- 把它当 DB 来用，这种就是须要把真正的拿它来存数据做长久化。
- 做音讯队列，它反对的数据类型也比拟多，这里就不再做介绍了。
2、Redis 的特点
- 它是一个单线程的模型，它其实是能够有多个线程的，然而它的 worker 线程只有一个，在 Redis6.0 开始，它反对了 io 多线程，但 io 多线程只是能够有多线程去解决有网络相干的局部，实际上你真正去解决数据还是单线程，所以整体而言，咱们依然把它叫做单线程模型。
- Redis 的数据其实都在内存外头，它是一个内存型的数据库。
- 与 HA 相干，Redis 想要做 HA，咱们以前在做 Redis 的 HA 次要靠 Redis sentinel，而前面在 Redis 进去 cluster 之后，咱们次要靠 Redis cluster 去做 HA, 这是两种次要 HA 的解决方案。
四、Redis 容器化计划的比照
当咱们提到做 Redis 运维相干的时候，咱们有哪些须要思考的点：
- 部署，如何疾速的部署，如何可能疾速的部署，而且还要去治理监听的端口，让端口不起抵触, 还有日志和长久化文件之类的, 这部分都属于部署相干的内容；
- 扩 / 缩容，也是咱们常常会遇到的问题；
- 监控和报警；
- 故障和复原。
以上都是咱们最关注的几个方面。我接下来就对这几个方面去做一些介绍。
1、部署
当咱们提到去做单机多实例的时候，Redis 作单机多实例去部署的时候，首先第一点就是咱们心愿可能有过程级别的资源隔离，咱们某一个节点下面所有部署的 Redis 实例，能够有本人的资源，能够不受别的实例的影响，这就是对于过程级别的资源隔离。
过程级别的资源隔离，它其实次要分为两个方面，一方面是 CPU，另一方面是内存，其次的话咱们心愿在单机下面咱们也能够有本人的端口治理，或者说咱们能够有独立的网络资源隔离的相干的技术。
在这种状况下，首先咱们提到说过程级别的资源隔离，咱们介绍了那么多的容器化相干技术，咱们曾经晓得了，反对过程级别的资源隔离的话，有最简略的一种计划就是用 cgroups，如果想要去做网络资源隔离的话，咱们有 namespace，也就是说所有反对 cgroups 和 namespace 的这种打算的解决方案，都能够满足咱们这个中央的需要。
再有一种计划就是虚拟化的计划，也就是咱们上文提到比如说 Kata Container，Kata Container 这种基于虚拟化的形式，因为虚拟化的计划其实大家都有所接触，大家都晓得就是虚拟化的这种技术，其实默认状况下，刚开始全副都做隔离。
所以对于部署而言，如果你应用的是比如说像 Docker，比如说你想应用的像 systemd-nspawn 这些它都能够既用到 cgroups，又用到了 namespace，是都能够去用的，只不过是你须要思考一些便捷性，比如说你如果是应用 Docker 的话，进行一个 Docker 命令跑过来，而后只有让它映射到不同的端口，其实就完结了。
如果你应用是 systemd-nspawn，这样子的话，你须要去写一些配置文件。如果你要是去用一些虚拟化的解决方案的话，同样的也须要去筹备一些镜像。
2、扩 / 缩容
对于扩 / 缩容，其实会有两种最次要的场景，一种场景就是单实例 maxmemory 调整，就是咱们最大内存的调整。还有一种是对于咱们的集群化的集群解决方案，就是 Redis Cluster。对于这种集群规模，咱们有扩 / 缩容的话，会有两方面的变动。
一方面是 Node，就是咱们的节点的变更，如果会新增节点，也可能会去移除节点。
另外一种就是 Slot 的变更，就是心愿把我的 slot 去做一些迁徙，当然这些和 Node 节点会是相干的，因为当咱们去做扩容的时候，咱们把 Redis Cluster 当中的一些 Node 节点增多，增多了之后，就能够不给他调配 Slot，或者说我想要让某些 Slot 集中到某些节点下面，其实这些需要也是同样存在的。
那咱们来看一下，如果你过后想要去做 maxmemory 的调整，如果咱们是前提曾经做了容器化，想通过 cgroups 去对它做资源的限度，就须要有一个能够反对动静调整 cgroups 配额的解决方案。
比如说咱们用到 Docker update，它是能够间接批改某个实例，或者说其中的某一个容器的 cgroups 资源的一些限度，比如说咱们能够 Docker update，给它指定新的内存，能够限度它最大可用内存，当你把它的可用内存数调大，接下来你就能够对实例去调整它的 maxmemory，也就是说对于单实例 maxmemory，其实最次要的就是须要有 cgroups 的技术，向 cgroups 的技术提供一些反对。
对于集群节点的变更的话，这个局部稍后再做具体介绍。
3、监控报警
第三点就是监控报警，不论是应用物理机也好，或者应用云环境也好，或者应用任何解决方案都好，监控报警咱们最想要失去的成果就是，它能够主动发现。
咱们心愿当启动一个实例之后，咱们就能够立马晓得这个实例 A 他曾经起来了，并且晓得他的状态是什么，而监控报警的话，这部分其实是不依赖于特定的容器化技术的，就即便是在纯正的物理机上部署，也能够通过一些解决方案主动的发现它，主动的把它注册到咱们的监控零碎当中去，所以它是属于监控报警的这部分，其实它是不依赖于特定的容器技术的，但惟一的一个问题就是说如果说应用了容器化的计划，能够让罕用的 Redis exporter，配合 Prometheus 去做监控，能够让 Redis exporter 和 Redis server，这两个过程能够处于同一个网络的命名空间。
如果他们两个处于同一个网络的命名空间的话，能够间接通过 127.0.0.1:6379，而后间接去联通它, 如果咱们应用的是 k8s 的话，能够间接把它俩放到一个 pod 当中，然而这些都无关紧要，因为它是不依赖于特定的容器化技术的，你能够应用任何你想要用的技术，都能够去做监控和报警。
4、故障复原
最初咱们提到的局部是故障和复原。在这个局部我认为最次要的有三个方面：
- 第一个是实例的重启。
有可能在某些状况下，某些场景下，你的实例在运行过程当中它可能会宕掉，如果你想让他主动重启的话，你须要有一个过程治理的工具。对于咱们而言，上文咱们提到了 systemd，systemd 是能够反对对于某一个过程的主动拉起的，还能够反对过程挂掉之后主动拉起，能够 restart，或者你应用 Docker，它也有一个 restart policy，能够指定他为 always 或者指定为 on-failure，而后让它在挂掉的时候再把它给拉起来。
如果你应用的是 k8s，那么就更简略了，能够主动拉起来。
- 第二个是主从切换。
主从切换相对来说是一个常态，但在这里我也把它列到故障复原当中，是因为可能在主从切换的过程当中，有可能你的集群情况曾经不衰弱了，是会有这种状况存在的。那主从切换的时候咱们须要做什么？第一方面，须要让他可能有数据的长久化，另一方面在主从切换的时候，有可能会遇到一种状况，就是资源不够，导致主从切换失败，在这种状况下，其实和咱们上文后面提到的扩 / 缩容其实是相干的，所以在这种状况下就必须得给他加资源，而最好的方法是能够主动给他加资源。
在 k8s 当中，想要让它主动加资源，咱们通常会给他设置它的 request 和 limit，就是资源的配额，心愿它能主动的加起来，咱们通常把他叫做 vpa。
- 第三个是数据恢复。
通常来讲，比如说咱们开了 RDB 和 AOF，而且心愿咱们的数据能够保留下来，以便于在咱们数据恢复的时候能够间接开始应用。所以数据长久化也是一方面。
咱们去做容器化的时候，咱们须要思考哪些点？如果说你是应用 Docker 的话，你须要去挂一个券，而后你能够把这个数据去做长久化，比如说你应用 systemd-nspawn 也须要有一个文件目录去把这个数据做继续化。
如果你应用的是 k8s 的话，在挂券的时候，你会有各种各样的抉择，比如说你能够去挂 ceph 的 RDB、s3 或者一个本地的某一个文件目录。然而为了更高的可靠性，可能会应用正本数更多的分布式存储。
5、Node 节点变更
接下来，咱们来聊一下上文咱们在提到服务扩 / 缩容的时候，提到的对于 Node 节点变更，比如说我想要让我的某一个 Redis cluster，去裁减一些节点，裁减节点的时候，那就意味着你必须可能退出集群，可能和集群失常通信，这才阐明你真正的退出到了集群当中。
而咱们也晓得在 Redis cluster 当中，你要去做集群，最大的一个问题就是 k8s，k8s 当中做服务发现其实它都是大多数通过一个域名，而咱们的 Redis 当中，比如说咱们的 NodeIP，它其实只反对 IP，它并不反对咱们的域名。
所以如果说 Node 节点变更，须要做的事件就是容许咱们动静地去把 NodeIP 写到咱们的集群配置当中。
如果想要让它有一个残缺的生命周期，以下截图是来自于一个叫 Kubedb 的 operator，在下图中能够看到，Redis 这个中央提供了最次要的三个局部：
- PVCs，PVCs 就是做数据的长久化。
- Services，Services 就是做服务发现。
- StatefulSets，StatefulSets 其实就是 k8s 当中的一种资源，而这资源它对于咱们的有状态利用会更敌对一些。
其实在整个内容当中还有一点没有介绍的是什么呢？就是 Redis 背地的公司叫做 Redis Labs，它提供了一种商业化的计划，就是 Redis Enterprise 一种解决方案。其实也是在 k8s 的解决方案之上的，也是用了 Redis operator。他的计划和 Kubedb 这种计划根本相似，因为外围还都是用的 StatefulSets，而后再加上本人的 Controller，去实现这个事件。
五、总结
咱们来看一下明天的总结。如果是咱们单机应用的话，咱们能够交给 Docker 或者其余反对 cgroups 或者 namespace 资源管理的工具。因为当你应用了 cgroups、namespace 的话，你能够做到资源的隔离，能够防止网络的端口的抵触之类的事件都能够实现。
而如果是像我在上文提到的小伙伴提到的那个问题：他打算应用主机的网络，仅仅是想让 Docker 去做一个过程治理，而且你也不心愿引入新的内容。那么 systemd 或者 systemd-nspawn 都是能够思考的，因为这也是容器化的解决方案。
如果是在简单场景下的调度和治理的话，比方想要有很大的规模，并且想要有更灵便的调度和治理，我举荐你应用的是 Kubernetes operator，比如说 Kubedb，其实也是一种解决方案。如果你的场景没有那么简单，比较简单，其实原生的 Kubernetes StatefulSets 略微做一些调整和批改，也是能够满足你的需要。
以上就是我明天分享的次要内容了，感激大家的参加。
>>>>
Q&A
Q1：请问 Redis 集群如果用三台物理机做，每台运行 2 个实例，如何保障每台物理机的实例不是互为主从的？
A1： 这个问题其实咱们通常状况下大家也都会遇到。第一点如果你是应用物理机来做，并且你每台机器下面运行两个实例，三台机器每个机器下面运行 2 个实例，一共有 6 个实例。这 6 个实例你是否能够保障它每个相互都不为主从的，其实是能够间接保障。
惟一的问题就是如果说这是一个集群，而后产生故障转移，产生节点的被动切换，就十分有可能存在你的主从产生了变更。其实这个中央的话其实我更加倡议，如果你发现了这种问题的话，你手动去做切换，因为物理机环境去做这个事件，目前我还没看到有什么特地好的解决办法。
Q2 : 请问 k8s 中扩容时，如何减少新节点。扩容和调配 slot 的步骤如何自动化的进行？
A2： 咱们离开两步来讲，第一局部是减少新节点，减少新节点的话，方才我其实在过程外头曾经提到了，减少完新的节点之后，首先你肯定要让它可能和集群去做通信，然而这个中央就是须要你去批改集群的配置文件，而后你须要他有一个 NodeIP，因为之间是通过 IP 去做通信的，所以你须要去批改它的配置文件，把它的 NodeIP 加进去，这样子他才能够和集群当中的其余节点去做通信，然而这个局部的话，我更举荐的是用 operator 去做。
Q3 : 请问如果不必 Redis operator，也不应用分布式存储，k8s 如何部署 cluster 集群呢？
A3： 不必 Redis operator 其实也是能够的，方才我也介绍过，有两种模式，一种模式就是用 StatefulSets，这种模式的话相对来说会比拟稳当一些。同时它的最次要的局部依然是批改配置，你须要在你的 Redis 的容器镜像当中，你能够给它加一个 init 容器，而后能够在这个局部先给他做一次批改配置的操作，这是能够的。批改完配置的操作之后，再把它给拉起来，这样子他才能够退出到集群当中。
Q4 : 请问网络提早在不同网络模型下有什么区别？
A4： 如果咱们间接应用物理机的网络，通常来讲，咱们不认为这种形式有提早，就是主机网络个别状况下咱们会疏忽掉它的提早，然而如果你应用的是 overlay 的这种网络模型的话，因为它是覆盖层的网络，所以你在去做发包解包的时候，当然是会有不同的资源的损耗，性能的损耗都是有的。
Q5 : 请问个别倡议公司专用一个 Redis 集群，还是各零碎独立集群？
A5： 这个问题当然是倡议各个系统独立集群了，咱们来举一个最简略的例子，比如说你在其中用到了 list，咱们都晓得 Redis 就有一个 ziplist 的配置项，他其实跟你的存储和你的性能是有关系的。如果你是公司的所有的货色都用同一个集群，那你批改了 Redis 集群的配置的话，很可能会影响到所有的服务。但如果你是每个零碎独立用一个 Redis 群的话，彼此之间互不影响，也不会呈现某一个利用不小心把集群给打挂了，而后造成连锁反应的状况。
Q6 : 请问 Redis 长久化，在生产中如何思考呢？
A6： 这部分货色我是这样想的。如果你真的须要去做长久化，一方面 Redis 提供了两种外围，一种是 RDB，另外一种是 AOF，如果说你的数据很多的话，相应你的 RDB 可能会变得很大。如果你是去做长久化，我通常倡议就是两个外头去做一次衡量。因为通常来讲，即便你是应用物理机的环境，我也倡议你的存储目录能够放到一个独立的盘外头，或者说你能够去挂在一个分布式的存储，然而前提是你须要保障它的性能，因为你不能因为它的写入性能而连累你的集群，所以更加举荐的就是你能够全都把它们关上，然而如果你数据其实没那么重要，你能够你只开 AOF。
Q7 : 请问生产级别的 ceph 牢靠不？
A7： 其实 ceph 的可靠性这个问题，很多人都探讨过，就我集体而言，ceph 的可靠性是有保障的。我这边在用的 ceph 很多，并且存了很多比拟外围的数据，ceph 的可靠性是 ok 的。
重点在于说你能不能搞得定他，而且有一家公司其实大家可能有所理解，叫做 SUSE，就是一个 Linux 的一个发行版，这家公司其实提供了一个企业级的存储解决方案，并且它的底层其实还是用的 ceph，其实这也是失常的，只有有专人去搞这个事件，而后把它解决掉，我感觉 ceph 足够稳固的。
顺便提一下，如果你应用的是 k8s 的话，当初有一个我的项目叫做 rook，它其实提供了一个 ceph 的 operator，这种计划其实当初曾经算是相对来说比拟很稳固的了，举荐大家尝试一下。
Q8: 请问申请内存、限度内存、还有自身 Redis 内存怎么配置比拟好？
A8： 这里须要思考几个问题，首先咱们先说 Redis 自身的内存，其实要看你的理论业务的应用场景，或者说你业务的理论需要，你必定不可能让你的 Redis 的实例或者 Redis 集群的内存都占满。
如果是占满的话，你就须要开启 lru 去做驱赶之类的事件，这是一方面。另一方面就是申请内存，其实我了解你这个中央要问的问题应该是指，在 k8s 环境上面，在 k8s 上面一个是 request 的，一个是 limit，limit 必定是你的可用限度的内存，限度内存你肯定须要思考到 Redis 自身还要用到的一些内存。
欢送订阅我的文章公众号【MoeLove】
