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 有哪些算法策略？考点之如何去影响淘汰策略，设置独自偏好？
举荐浏览：【探针配置失误，线上容器利用异样死锁后，kubernetes集群未及时响应自愈重启容器？】
举荐休闲浏览：【囧么肥事】
发表回复