前面我们分享很多关于 K8S 的内容，有没有发现 pod 都是无状态，RS / RC 管理的 pod 也是无状态的，我们可以任意删除一个 pod，副本管理器又会马上给我们创建一个 pod
那么如果咱们的这个 pod 是有挂载持久卷的，那么我们用老方法可还行？
[图片上传失败...(image-e17388-1690517009860)]
有状态和无状态
简单说明一下，什么是有状态的服务，什么是无状态的服务：
有状态服务
- 服务本身依赖于环境中的状态，可能需要数据库来持久化状态数据
- 某一个时刻，一个请求只能被服务的某个实例处理
- 会存储状态数据，若需要扩展实例，可能整个系统都进行变动
无状态服务
- 服务本身不依赖自身的状态
- 外部的任何请求到服务的任何一个实例都是可以得到正确的期望的响应
- 可以横向扩展，能做负载均衡，自身不会存储状态机
回顾 ReplicaSet
咱们回顾一下 RS / RC ，他们都是管理的 pod 的控制器，创建出来的 pod 也都是通过预设好的模板创建出来的，这些 pod 也没有什么区别
我们上面有提到数据，如果我们在 RS 中加入一个声明的持久卷会是什么样的效果呢？
会是像这样所有 pod 共享一个持久卷声明？
[图片上传失败...(image-14d64b-1690517009860)]
还是会向这样每一个 pod 有一个独立的持久卷声明呢？
[图片上传失败...(image-17b923-1690517009860)]
答案当然是前者
这个点可以在强调一下，感兴趣的小伙伴可以尝试一下，我们创建的是一个 RS，RS 里面会根据 pod 的副本数，来创建和删除多个 pod，若我们指定了持久卷，那么是多个 pod 共享同一个卷的
因为咱们的 pod 都是从 pod 模板生成的， pod 的模板早已指定好具体的持久卷是哪一个，无论生成多少个 pod ，都是共享一个持久卷
除非咱们创建多个 RS
那么如果我们需要就 1 个 RS 就能做到创建的每一个 pod 都可以享受独立的持久卷声明呢？
那么就抱歉了，K8S 暂时还不支持，没准后续可以支持也说不一定
回过头来看，如果我们需要 一个 pod 对应一个持久卷声明，一个持久卷，那么就得一个 RS 创建 一个 pod 才能实现了
[图片上传失败...(image-d763dd-1690517009860)]
那么我们如何进行扩容和缩容呢？
这又是一个麻烦事，这种做法不能自动的动态进行扩缩容，只能我们手动去删除 RS 或者修改 RS 的副本个数 ，而且对于以后横向扩展的时候，我们无限的改动 RS ，这真的太笨重了，云原生的做法绝对不能是这个样子的，肯定有好方法
多个 pod 共享一个持久化卷，但是使用不同的目录？
[图片上传失败...(image-d845c6-1690517009860)]
看上去感觉还不错，我们是不是就可以让多个 pod 共享一个持久化卷，但是使用不同的目录，类似于下面这种呢？
[图片上传失败...(image-a21387-1690517009860)]
根据示意图来看，感觉可行对吧
咱们细想一下的时候，我们就知道这样子不太行嘞
对于不同的 pod ，需要动态的去指定持久卷的不同目录，那么如何做到呢？这些 pod 都是通过同一个模板创建出来的，如何动态的去改变呢？
思来想去，还是需要多个 RS，不同的 RS 指定同一个持久化卷，不同的 pod 模板指定自己需要使用的挂载路径
那么 RS 是不是就真的搞不定上面的需求呢？ 创建一个 RS ，让多个 pod 有自己独立的持久化卷
是的，就是搞不定，咱们看看 K8S 还有没有其他的处理方式来处理这种需求，放心，肯定可以解决，下回见
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
[图片上传失败...(image-978055-1690517009860)]
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
网友评论