ReplicaSet
的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合
Pod
的可用性打一个比方
我们以前进行 Deployment
部署的时候,存在这个字段信息:
replicas: 5 ## 5个副本
selector:
matchLabels:
app: nginx
上面就意味着我们要部署的副本数是5
通过以下字段来进行一个定义:
Pod
的集合的选择算符,这个选择算符是可以写复杂表达式的replicas: 5
Pod
的模板每个 ReplicaSet
都通过根据需要创建和删除 Pod
以使得副本个数达到期望值
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而,Deployment 是一个更高级的概念,它管理 ReplicaSet,并向 Pod 提供声明式的更新以及许多其他有用的功能。 因此,建议使用 Deployment 而不是直接使用 ReplicaSet, 除非你需要自定义更新业务流程或根本不需要更新。
怎么写还是直接使用 kubectl explain rs
这是一个测试用例
###rs-demo.yaml
apiVersion: apps/v1
kind: ReplicaSet ##资源类型
metadata: ## 元数据信息
name: nginx
labels:
app: nginx
tier: frontend
spec: ## RS期望状态
replicas: 3 ## 副本数
selector:
matchLabels: ##标签选择算符
app: nginx
template: ##pod模块
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
启动测试
一些便捷的查询
##当前被部署的 ReplicaSet
kubectl get rs
##查看 ReplicaSet 的状态
kubectl describe rs nginx
##查看Pod的属主引用(信息被设置在 metadata 的 ownerReferences 字段中)
kubectl get pods nginx-klt65 -o yaml
RS 也不会局限于拥有在其模板(.spec.template)设置的 Pod
,它也可以管理创建的裸 Pod
我先创建了一个 rs
apiVersion: apps/v1
kind: ReplicaSet ##资源类型
metadata: ## 元数据信息
name: nginx
labels:
tier: frontend
spec: ## RS期望状态
replicas: 5 ## 副本数
selector:
matchLabels: ##标签选择算符
app: nginx
template: ##pod模块
metadata:
labels:
app: nginx
spec:
containers:
- name: pod1
image: nginx
我这里运行了一个裸的 pod
###pod1.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod
labels:
app: nginx
spec:
containers:
- name: pod
image: 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
集合我们一般不会在实际工作直接编写 RS
资源,而是编写 Deploment
资源来替代 RS
,但是实际副本数控制依然是 RS
编写清单参考:
https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/replicaset/#how-a-replicaset-works
删除 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 是可用的和可操作的。
在缩的时候,一般性算法:
controller.kubernetes.io/pod-deletion-cost
注解,则注解值较小的优先被裁减掉**RS 可被用于 HPA **
上面已经说过很多次了,我们一般不直接使用 RS,而是推荐使用 Deploy
Deployment
是一个可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pod 滚动更新的对象。 尽管 ReplicaSet 可以独立使用,目前它们的主要用途是提供给 Deployment 作为编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时,你不必关心如何管理它所创建的 ReplicaSet,Deployment 拥有并管理其 ReplicaSet。 因此,建议在需要 ReplicaSet 时使用 Deployment
RC(ReplicationController):副本控制器
RS(ReplicaSet):副本集
RC:老版
RS:新版
ReplicaSet 是 ReplicationController 的后继者。二者目的相同且行为类似,只是 ReplicationController 不支持标签用户指南中讨论的基于集合的选择算符需求。 因此,相比于 ReplicationController,应优先考虑 ReplicaSet
对于RS
kubectl explain rs.spec.selector
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
相对就单一了撒
虽然 RS 强大,但是我们也不直接写 RS;而是使用更多特性的 Deployment,Deployment 会自动产生 RS