k8s初面考点ReplicaSet副本集极限9连击你懂了吗？

k8s考点灵魂拷问9连击

考点之简单描述一下k8s副本集ReplicaSet有什么作用？

考点之为什么ReplicaSet将取代ReplicationController控制器？

考点之编写 ReplicaSet 的 spec 有什么需要注意的点？

考点之k8s集群中创建非模板 Pod 为什么可能会被副本集自动收纳？

考点之线上预警k8s集群循环创建、删除Pod副本，一直无法稳定指定目标副本数量?

如果排除了是Pod内部发生了故障，从RS角度你猜测可能是什么原因？

考点之标签Pod和可识别标签副本集ReplicaSet 先后创建顺序不同，会造成什么影响？

考点之生产环境想要对某个Pod排错、数据恢复、故障复盘有什么办法？

考点之缩放 RepliaSet 有哪些算法策略？

考点之如何去影响淘汰策略，设置单独偏好？

囧么肥事-胡说八道

考点之k8s副本集ReplicaSet有什么作用？

ReplicaSet的主要作用是控制副本数量的，这里的每一个副本就是一个Pod，ReplicaSet它是用来确保我们有指定数量的Pod副本正在运行的Kubernetes控制器，这里为了方便后面统一把ReplicaSet简称 RS。

进一步说什么是控制副本数量？

RS确保Pod以你指定的副本数运行，即如果有容器异常退出，会自动创建新的 Pod 来替代，而异常多出来的容器也会自动回收。

假设k8s集群中，你想要运行10个Pod，如果这时候有4个Pod发生故障，异常退出，那么RS会自动创建新的4个Pod来替代发生故障的4个Pod。

RS尽力保证系统当前正在运行的Pod数等于期望状态里指定的Pod数目。

你想要10个，那么RS就尽可能保证在任何时候都给你提供10个，没有就创建，多了就删除。

总之，ReplicaSet 尽可能确保任何时间都有指定数量的 Pod 副本在运行。

考点之为什么ReplicaSet将取代ReplicationController控制器？

ReplicationController控制器（简称为RC）。

在之前旧版本的k8s中，使用的是RC控制器实现了k8s集群的高可用性，它跟现在的RS控制器作用类似，作用是，确保Pod以指定的副本数运行。

ReplicaSet继承了RC的功能，并实现了扩展，主要突出扩展是更强大的标签选择能力 ，即selector。

进一步说什么是标签选择能力？

ReplicaSet会通过标签选择器（Label-Selector）管理所有被打上与选择器匹配的标签的容器。

下面通过一段拟人对白，来理解什么是标签选择：

RS说：”嘿嘿，我要管理被打上 A，AA，AAA标签的Pod，都不许跑，听我指挥，排队站好，立正，向前看！“

Pod-001说：”我被打上了BBB标签，我才不归你管呢！“

Pod-002说：”我被打上了AA标签，快来接管我吧，我准备好了“

Pod-003说：”呜呜，我想独立，我不想被RS管，我要做一个自由自在的孩子，但是不幸的是，我被打上了A标签，RS给我管的紧紧的，我失去了自由，我好可怜呀“

ReplicationController自己也有标签选择能力，但是它只能选择包含某个标签的匹配Pod；

ReplicaSet的选择器在基础上增加了允许匹配缺少某个标签的pod，或包含特定标签名的Pod；

举个例子

两组Pod，env标签分别是production和devel

Pod-A env=production

Pod-B env=devel

RC 只能匹配其中的Pod-A或者Pod-B中的一个；

RS 则可以同时可以匹配并将它们视为一个大组，无论标签env的值具体是什么（env=*）,都可以标签名来进行匹配；

考点之编写 ReplicaSet 的 spec 有什么需要注意的点？

类似其他Kubernetes API 对象，RS也需要指定 apiVersion、kind、和 metadata 字段。

对于 ReplicaSets 而言，其 kind 始终是 ReplicaSet。
ReplicaSet 对象的名称必须是合法的 DNS 子域名
属性.spec.template 是一个Pod 模版，要求设置标签，注意不要将标签与其他控制器的标签选择器重叠
属性.spec.template.spec.restartPolicy 指定模板的重启策略，允许的取值是 Always
属性.spec.selector 字段是一个标签选择器 用来筛选匹配标签的Pod归属
在 ReplicaSet 中，.spec.template.metadata.labels 的值必须与 spec.selector 值相匹配，否则该配置会被 API 拒绝。

考点之k8s集群中创建非模板 Pod 为什么可能会被副本集自动收纳？

前面提到了，RS采用了最新的标签选择能力，通过指定.spec.selector标签选择器，不仅可根据标签值，甚至连标签名一致都可以进行匹配。

首先如果采用Pod模板创建Pod，会被指定标签，RS会根据标签自动接管Pod。

再来看看非模板

非模板创建，其实就是直接创建裸的 Pods。

为什么可能会被副本集RS自动接管？

除非在创建裸Pod的时候，你确保这些裸的 Pods 并不包含可能与你的某个 ReplicaSet 的.spec.selector相匹配的标签。

在创建裸Pods前，必须完全排除跟任何RS有可能相同的标签，否则，RS认为你创建的Pod 就是要指定给自己接管的。

考点之线上预警k8s集群循环创建、删除Pod副本，一直无法稳定指定目标副本数量，排除了是Pod内部发生了故障，从RS角度你猜测可能是什么原因？

首先理解一下问题，循环创建Pod副本？

RS一直在正常工作，维持Pod副本数量，缺少就创建，多了就删除。问题来了，一直创建，然后又删除，却不能稳定Pod副本数量？

看下这个循环过程

RS指定Pod副本数量10个

当前副本7个

RS检测不够10个

RS开启平衡机制，创建2个维持稳定

再检测发现 15个

RS开启平衡机制，删除5个维持稳定

再检测发现13个

RS开启平衡机制，删除3个维持稳定

再检测发现9个

RS开启平衡机制，增加1个维持稳定

再检测发现10个

无需稳定

再检测发现8个...

再检测发现18个...

总之，RS检测副本数量，不是比10个多，就是比10少，一直难以维持10个有效副本。

既然排除了是Pod内部故障问题，那么从RS角度进行可能分析，可以初步判定是多个RS标签选择器规则重复导致的。

分析初步判定原因

ReplicaSet会通过标签选择器（Label-Selector）管理所有带有与选择器匹配的标签的容器。

创建Pod时，它会认为所有Pod 是一样的，是无状态的，所以在创建顺序上不会有先后之分。

使用相同的标签选择器创建多个ReplicaSet，则多个RS无法识别哪个Pod是自己创建的，都会认为是归属于自己管理的Pod。

例如

第一个 RS-A，指定副本数量 10

标签选择器可以匹配 env=xxx

RS-A生成10个Pod标签为 env=xxx

一组Pod：

Pod-1(env=xxx)

Pod-2(env=xxx)

Pod-3(env=xxx)

...

...

Pod-10(env=xxx)

这时候创建了一个RS-B

第二个 RS-B，指定副本数量 25

标签选择器和 RS-A 相同

标签选择器可以匹配 env=xxx

因为选择器匹配一样

RS-B 匹配到了RS-A创建的10个Pod

RS-B 发现Pod-x（env=xxx）数量不够25

RS-B 继续创建额外的10个

Pod-11(env=xxx)

Pod-12(env=xxx)

Pod-13(env=xxx)

...

...

此时RS-A 发现自己匹配的Pod > 10

它认为是自己创建多了

启动平衡机制

删除超过 10 个的额外Pod

删除 Pod-Xi(env=xxx)

而RS-B 发现自己匹配的Pod < 25

就启动平衡机制

创建 Pod-Xi(env=xxx)

就这样

一个不停的创建

一个不停的删除

最终总是无法满足稳定数量的 10 和 25

双方的当前状态始终不等于期望状态，这就会引发问题，因此确保ReplicaSet标签选择器的唯一性这一点很重要。

本期暂时讨论上述5点，下期完成下面4点

考点之标签Pod和可识别标签副本集ReplicaSet 先后创建顺序不同，会造成什么影响？

考点之生产环境想要对某个Pod排错、数据恢复、故障复盘有什么办法？

考点之缩放 RepliaSet 有哪些算法策略？

考点之如何去影响淘汰策略，设置单独偏好？