k8s-ReplicaSet副本集考点有哪些？生产环境想要对某个

作者: Chris0Yang | 来源:发表于2022-07-26 16:48 被阅读0次

1.简单描述一下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 副本在运行。

2.为什么ReplicaSet将取代ReplicationController控制器？

ReplicationController控制器（简称为RC）。

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

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

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

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

举个例子

两组Pod，env标签分别是production和devel
  Pod-A     env=production
  Pod-B     env=devel
 
RC 只能匹配其中的Pod-A或者Pod-B中的一个；

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

3.编写 ReplicaSet 的 spec 有什么需要注意的点？

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

1.对于 ReplicaSets 而言，其 kind 始终是 ReplicaSet。

2.ReplicaSet 对象的名称必须是合法的 DNS 子域名

3.属性.spec.template 是一个Pod 模版， 要求设置标签，注意不要将标签与其他控制器的标签选择器重叠

4.属性.spec.template.spec.restartPolicy 指定模板的重启策略 ，允许的取值是 Always

5.属性.spec.selector 字段是一个标签选择器 用来筛选匹配标签的Pod归属

6.在ReplicaSet中.spec.template.metadata.labels的值必须与spec.selector值相匹配，否则该配置
会被API拒绝。

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

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

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

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

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

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

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

5.线上预警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标签选择器的唯一性这一点很重要

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

假设给Pod打上的标签是 AA，同时RS标签选择器设置匹配 AA

分为两种情况

1) 预设RS标签和副本数量
RS-AA 标签选择器可识别 AA 标签
设置副本15个

2) 预设Pod标签
裸Pod-AA 标志标签 AA  
##第一种：RS已经创建，裸Pod随后创建  
  情况一：
      副本等于15个，此时创建 Pod-AA
  结果：
      新的 裸Pod-AA 会被该 RS-AA 识别
      副本数 > 15，开启平衡机制
      新Pod立即被 RS 终止并实行删除操作
  
  情况二：
      副本小于15个，此时创建 Pod-AA
  结果：
      裸Pod-AA 创建后立即被 RS-AA识别
      副本数 <= 15，开启平衡机制，收管裸Pod 
    
    
##第二种：裸Pod先创建，随后创建RS  
  情况一：
      创建了小于等与15个裸Pod-AA，此时创建 RS-AA
  结果：
      RS-AA 创建成功后
      发现存在有AA标签的Pod
      将所有的Pod-AA纳入自己管辖范围
      副本数 < 15，开启平衡机制
      由RS-AA继续创建剩余Pod-AA补充够15个
  
  
  情况二：
      创建了大于15个裸Pod-AA，此时创建 RS-AA
  结果：
      RS-AA 创建成功后
      发现存在有AA标签的Pod
      将所有的Pod-AA纳入自己管辖范围
      副本数 > 15，开启平衡机制
      RS-AA实行删除多余Pod操作
      直到副本数维持在15个

结论：无论RS何时创建，一旦创建，会将自己标签选择器能识别到的所有Pod纳入麾下，接管生存权，遵循RS规约定义的有效副本数，去开启平衡机制，维持有效标签Pod的副本数

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

如果想要独立创建可生存的裸Pod，一定要检查所有的RS标签选择器的可识别范围，避免自己创建的裸Pod被收纳接管

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

如果线上发现有些Pod没有按照我们期望的状态来进行运行，发生了某些故障，但是其他同类型Pod却没有发生

这种故障一般属于不易复现的故障，只会在某些偶然性的条件下触发故障，但是这个触发条件我们又不清楚，所以我们要专门针对这个故障进行问题排查

这个时候又不希望在排查过程中影响服务的正常响应，那该怎么办呢？

隔离法，所谓隔离法，就是将 Pod 从 ReplicaSet 集合中隔离出来，让Pod脱离RS的管控范围，额有点类似赎身。

可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。

这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。

以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。

通过隔离这个目标Pod，RS会自动补充副本Pod去保证集群的高可用，我们不必担心影响到服务线的正常响应。这时候就可以针对这个目标Pod做排查，研究，里里外外的想干啥，就干啥

  班级（标签666班）
  老师（RS-666）
  学生15个（学生证标签666班）
  -----------------------------
  
  每天上课，老师都检查学生证入班
  学生1号：学生证-666班，进去
  学生2号：学生证-666班，进去
  ...
  学生20号：学生证-666班，进去
  
  
  某天，学生9号的学生证被人改了999班
  学生1号：学生证-666班，进去
  学生2号：学生证-666班，进去
  ...
  学生9号：学生证-999班，老师拦住了9号，不许进
  ...
  学生20号：学生证-666班，进去  
  
这个老师跟RS一样，很偏激，只认学生证（RS只认标签），不认人。
如果改了标签，就认不出了，自己也不会再去接管了

8.缩放 RepliaSet 有哪些算法策略？

通过更新 .spec.replicas 字段，指定目标Pod副本数量，ReplicaSet 可以很轻松的实现缩放。

而且，ReplicaSet 控制器能确保经过缩放完成留下来的Pod数量不仅符合要求副本数量，而且Pod是可用，可操作的。

RS扩容不必说，肯定创建新的Pod副本，纳入管理。

至于缩容，降低集合规模时ReplicaSet 控制器会对所有可用的Pods 进行一次权重排序，剔除最不利于系统高可用，稳健运行的Pod。

其一般性算法如下：

1.首先优先选择剔除阻塞（Pending）且不可调度的 Pods。
2.如果设置了controller.kubernetes.io/pod-deletion-cost注解，则注解值较小的优先被剔除。
3.所处节点上副本个数较多的 Pod 优先于所处节点上副本较少者被剔除。
4.如果 Pod 的创建时间不同，最近创建的 Pod 优先于早前创建的 Pod 被剔除。

如果以上比较结果都相同，则随机剔除。

9.如何去影响淘汰策略，设置单独偏好？

RS在进行缩容操作时，有自己的一套淘汰策略。根据四种淘汰策略进行权重排序，去剔除RS认为不利于系统稳健运行的Pod。

同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能希望移除利用率较低的 Pods。

那么我们怎么做，才能去影响到RS的淘汰机制，保留我们自己认为需要保留的Pod呢？

前面提到了controller.kubernetes.io/pod-deletion-cost 注解值较小的Pod会优先被剔除。

我们可以通过这个注解去影响RS淘汰机制，设置个人保留偏好。

那么什么是controller.kubernetes.io/pod-deletion-cost 注解？

此注解设置到 Pod 上，取值范围为 [-2147483647, 2147483647]，如果注解值非法，API 服务器会拒绝对应的 Pod。
表示从RS中删除Pod所需要花费的开销

RS认为删除开销较小的 Pods 比删除开销较高的 Pods 更容易被删除，更有利于系统的稳健运行。

不过此机制实施仅是尽力而为，并不能保证一定会影响 Pod 的删除顺序。只能说是爱妃给皇上吹枕边风，真正做出决定的还是皇上。

注意：
此功能特性处于 Beta 阶段，默认被禁用。
通过为 kube-apiserver 和 kube-controller-manager 设置特性门控 PodDeletionCost 开启功能。