k8s生产环境想要对某个Pod排错、数据恢复、故障复盘有什么方法？
k8s考点灵魂拷问9连击之5
考点之简略形容一下k8s正本集ReplicaSet有什么作用？考点之为什么ReplicaSet将取代ReplicationController控制器？考点之编写 ReplicaSet 的 spec 有什么须要留神的点？考点之k8s集群中创立非模板 Pod 为什么可能会被正本集主动收纳？考点之线上预警k8s集群循环创立、删除Pod正本，始终无奈稳固指定指标正本数量?如果排除了是Pod外部产生了故障，从RS角度你猜想可能是什么起因？上一期，探讨了后面五个考点，感兴趣去能够看一看【点我进入传送门】，好了，接下来持续看本期4个考点!
考点之标签Pod和可辨认标签正本集ReplicaSet 先后创立程序不同，会造成什么影响？考点之生产环境想要对某个Pod排错、数据恢复、故障复盘有什么方法？考点之缩放 RepliaSet 有哪些算法策略？考点之如何去影响淘汰策略，设置独自偏好？囧么肥事-胡言乱语
考点之标签Pod和可辨认标签正本集ReplicaSet 先后创立程序不同，会造成什么影响？
假如给Pod打上的标签是 AA，同时RS标签选择器设置匹配 AA。
分为两种状况
### 预设RS标签和正本数量RS-AA 标签选择器可辨认 AA 标签设置正本15个### 预设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被收纳接管。
考点之生产环境想要对某个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只认标签），不认人。如果改了标签，就认不出了，本人也不会再去接管了。
考点之缩放 RepliaSet 有哪些算法策略？
通过更新 .spec.replicas 字段，指定指标Pod正本数量，ReplicaSet 能够很轻松的实现缩放。
而且，ReplicaSet 控制器能确保通过缩放实现留下来的Pod数量不仅符合要求正本数量，而且Pod是可用，可操作的。
RS扩容不用说，必定创立新的Pod正本，纳入治理。
至于缩容，升高汇合规模时ReplicaSet 控制器会对所有可用的Pods 进行一次权重排序，剔除最不利于零碎高可用，持重运行的Pod。
其一般性算法如下：
- 首先优先选择剔除阻塞（Pending）且不可调度的 Pods。
- 如果设置了
controller.kubernetes.io/pod-deletion-cost注解，则注解值较小的优先被剔除。 - 所处节点上正本个数较多的 Pod 优先于所处节点上正本较少者被剔除。
- 如果 Pod 的创立工夫不同，最近创立的 Pod 优先于早前创立的 Pod 被剔除。
如果以上比拟后果都雷同，则随机剔除。
考点之如何去影响淘汰策略，设置独自偏好？
前说了，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 开启性能。Kubernetes 举荐学习书
Kubernetes权威指南PDF
链接:https://pan.baidu.com/s/11huL... 提取码:sa88
k8s系列所有问题更新记录：GitHub Gitee