用来管理pod的一种抽象，一般很少单独创建，多数情况下是deployment来自动创建和维护。
与RC不同的是，RS的selector支持 set-based，而不是RC简单的等于这样的匹配。
RS的spec.selector必须等于spec.template.labels.
spec.template中的内容和一个普通的pod 定义无区别，这是没有了API和kind。
RS会根据replicas的设定维护pods的数量，但是RS与pods的唯一关系就是label selector，它甚至不知道被匹配的pod是不是自己创建的，也就是说任何其它资源创建的pod，只要labels被匹配，就会被认为需要来管理。因此k8s中必须要人工保证不要有错误的label重叠。将RS创建的pod的标签修改为其它标签会导致该pod脱离管理，RS将会认为replicas减少从而重新再起一个。已通过其它方式创建的pods只要label匹配，就会被认为与该RS有关，但是RS不保证刷新所有pod来符合其template中的定义。
RS本身不能rolling update，RC可以（但是是申明式）
删除RS但不删除相关pod的方式是加--cascade=false 参数
RS可以被HPA(Horizontal pod autoscaler)管理
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: frontend-scaler spec: scaleTargetRef: kind: ReplicaSet name: frontend minReplicas: 3 maxReplicas: 10 targetCPUUtilizationPercentage: 50 |
RC主要是能支持kubectl rollingupdate来操作
只要编辑一个新的yaml，包含不同的selector标签或使用不同版本的image（修改image也可以通过命令），然后使用kubectl rollingupdate命令即可进行
|
1 2 3 4 5 6 7 8 9 10 11 |
[root@k8s-master cka]# kubectl rolling-update nginx-rc -f rc-rollingupdate.yaml Created nginx-rc-rolling Scaling up nginx-rc-rolling from 0 to 3, scaling down nginx-rc from 3 to 0 (keep 3 pods available, don't exceed 4 pods) Scaling nginx-rc-rolling up to 1 Scaling nginx-rc down to 2 Scaling nginx-rc-rolling up to 2 Scaling nginx-rc down to 1 Scaling nginx-rc-rolling up to 3 Scaling nginx-rc down to 0 Update succeeded. Deleting nginx-rc replicationcontroller "nginx-rc-rolling" rolling updated to "nginx-rc-rolling" |
在整个过程中，rc会先用新的yaml创建1个pod，运行成功后，再主动减少一个旧的rc的pod。这样反复，最终达成新的rc所要求的，并删除掉了旧rc的所有pod以及旧rc
文章评论