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 有哪些算法策略？
考点之如何去影响淘汰策略，设置单独偏好？
