k8s学习之路 | k8s 工作负载 ReplicaSet

1. ReplicaSet 基础概念

1.1 RS 是什么？

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合

• 保证给定数量、完全相同的 Pod 的可用性

打一个比方

我们以前进行 Deployment 部署的时候，存在这个字段信息：

  replicas: 5  ## 5个副本selector:matchLabels:app: nginx

上面就意味着我们要部署的副本数是5

1.2 RS 工作原理

通过以下字段来进行一个定义：

• 用来识别可获取的 Pod 的集合的选择算符，这个选择算符是可以写复杂表达式的
• 用来标明应用维护的副本个数的数值：比如 replicas: 5
• 用来指定应该创建新 Pod 的模板

每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个数达到期望值

1.3 什么时候使用 RS

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。 因此，建议使用 Deployment 而不是直接使用 ReplicaSet， 除非你需要自定义更新业务流程或根本不需要更新。

1.4 RS 示例

怎么写还是直接使用 kubectl explain rs

这是一个测试用例

###rs-demo.yaml
apiVersion: apps/v1
kind: ReplicaSet  ##资源类型
metadata:  ## 元数据信息name: nginxlabels:app: nginxtier: frontend
spec:  ## RS期望状态replicas: 3  ## 副本数selector:matchLabels:  ##标签选择算符app: nginxtemplate:  ##pod模块metadata:labels:app: nginxspec:containers:- name: nginximage: nginx

启动测试

一些便捷的查询

##当前被部署的 ReplicaSet
kubectl get rs##查看 ReplicaSet 的状态
kubectl describe rs nginx##查看Pod的属主引用(信息被设置在 metadata 的 ownerReferences 字段中)
kubectl get pods nginx-klt65  -o yaml

1.5 非模板 Pod 的获得

RS 也不会局限于拥有在其模板（.spec.template）设置的 Pod，它也可以管理创建的裸 Pod

我先创建了一个 rs

apiVersion: apps/v1
kind: ReplicaSet  ##资源类型
metadata:  ## 元数据信息name: nginxlabels:tier: frontend
spec:  ## RS期望状态replicas: 5  ## 副本数selector:matchLabels:  ##标签选择算符app: nginxtemplate:  ##pod模块metadata:labels:app: nginxspec:containers:- name: pod1image: nginx

我这里运行了一个裸的 pod

###pod1.yaml
apiVersion: v1
kind: Pod
metadata:name: podlabels:app: nginx
spec:containers:- name: podimage: php:5-apache

我们查看一下状态

总结如下：

• 上面的 Pod，虽然没有控制器，但是标签与 RS 的选择算符匹配，它会立即被 RS 获取
• 新的 Pod 被 RS 获取，并立即被 RS 终止，因为它的存在会使得 RS 中超过期望值

如果先创建 Pod 再创建 RS 观察下

[root@k8s-01 k8s-yaml]# kubectl apply -f pod1.yaml
pod/pod created
[root@k8s-01 k8s-yaml]# kubectl apply -f  rs-demo.yaml
replicaset.apps/nginx created
[root@k8s-01 k8s-yaml]#

总结如下：

• RS 已经获得了该 Pod，并仅根据其规约创建新的 Pod， 直到新的 Pod 和原来的 Pod 的总数达到其预期个数。
• 采用这种方式，一个 RS 中可以包含异质的 Pod 集合

1.6 编写 RS

我们一般不会在实际工作直接编写 RS 资源，而是编写 Deploment 资源来替代 RS ,但是实际副本数控制依然是 RS

编写清单参考：

https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/#how-a-replicaset-works

1.7 使用 RS

删除 RS 和 其 Pod

##删除rs和pod
kubectl delete -f 

只是删除 RS

##只删除RS
kubectl delete -f  rs-demo.yaml --cascade=orphan

一旦删除了原来的 ReplicaSet，就可以创建一个新的来替换它。 由于新旧 ReplicaSet 的 .spec.selector 是相同的，新的 ReplicaSet 将接管老的 Pod。 但是，它不会努力使现有的 Pod 与新的、不同的 Pod 模板匹配。 若想要以可控的方式更新 Pod 的规约，可以使用 Deployment 资源，因为 ReplicaSet 并不直接支持滚动更新。

从 RS 中隔离 Pod

可以通过改变标签来从 ReplicaSet 中移除 Pod。 这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。 以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。

扩缩 RS

通过更新 .spec.replicas 字段，ReplicaSet 可以被轻松地进行扩缩。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。

在缩的时候，一般性算法：

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

**RS 可被用于 HPA **

1.8 RS 替代方案

上面已经说过很多次了，我们一般不直接使用 RS，而是推荐使用 Deploy

Deployment 是一个可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pod 滚动更新的对象。 尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心如何管理它所创建的 ReplicaSet，Deployment 拥有并管理其 ReplicaSet。 因此，建议在需要 ReplicaSet 时使用 Deployment

2. ReplicaSet 与 ReplicationController

2.1 关于 RS、RC

RC（ReplicationController）：副本控制器

RS（ReplicaSet）：副本集

RC：老版

RS：新版

ReplicaSet 是 ReplicationController 的后继者。二者目的相同且行为类似，只是 ReplicationController 不支持标签用户指南中讨论的基于集合的选择算符需求。 因此，相比于 ReplicationController，应优先考虑 ReplicaSet

2.2 两者的选择器区别

对于RS

kubectl explain rs.spec.selector

• matchLabels：匹配标签
• matchExpressions：匹配表达式

kubectl explain rs.spec.selector.matchExpressions

• 匹配复杂的表达式的场景来说
  • 我现在匹配了一个key-value形式为“app=nginx”
    • 如果 operator 值为 In：只要 Pod 标签的值有 nginx，就会被匹配
    • 如果 operator 值为 NotIn：只要 Pod 标签的值不是 nginx，就会被匹配
    • 如果 operator 值为 Exists：只要 Pod 标签能匹配到，不用管值多少，就会被匹配
    • 如果 operator 值为 DoesNotExist：只要 Pod 标签没有匹配到，不管值多少，就会被匹配

对于RC

kubectl explain rc.spec.selector

相对就单一了撒

2.3 总结

虽然 RS 强大，但是我们也不直接写 RS；而是使用更多特性的 Deployment，Deployment 会自动产生 RS