Pod的副本控制器，通过资源文件管理控制Pod资源，使Pod副本数量始终维持在资源文件预设的数量上。并且能够监控Pod资源的运行状态，在Pod发生故障时重启pod，pod数量减少时重新运行新的 Pod副本。
Replicaset控制器主要由三个部分组成：1、用户期望的pod副本数：用来定义由这个控制器管控的pod副本有几个
2、标签选择器：选定哪些pod是自己管理的，如果通过标签选择器选到的pod副本数量少于我们指定的数量，需要用到下面的组件
3、pod资源模板：如果集群中现存的pod数量不够我们定义的副本中期望的数量怎么办，需要新建pod，这就需要pod模板，新建的pod是基于模板来创建的。
# kubectl explain rs apiVersion示例：部署一个前端程序#当前资源使用的api版本，跟VERSION: apps/v1保持一致 kind #资源类型，跟KIND: ReplicaSet保持一致 metadata
vim rs-test-frontend.yaml kubectl apply -f rs-test-frontend.yaml kubectl get rs # pod的名字是由控制器的名字-随机数组成的 kubectl get pods
资源文件如下：
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: demo-docker
labels:
app: hello-world
tier: demo-docker
spec:
replicas: 3
selector:
matchLabels:
tier: demo-docker
template:
metadata:
labels:
tier: demo-docker
spec:
containers:
- name: springboot-demo
image: algebra/docker-demo:1.1-SNAPSHOT
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
字段解释
apiVersion: apps/v1 #ReplicaSet 这个控制器属于的核心群组
kind: ReplicaSet #创建的资源类型
metadata:
name: frontend #控制器的名字
labels:
app: guestbook
tier: frontend
spec:
replicas: 3 #管理的pod副本数量
selector:
matchLabels:
tier: frontend #管理带有tier=frontend标签的pod
template: #定义pod的模板
metadata:
labels:
tier: frontend
#pod标签，一定要有，这样上面控制器就能找到它要管理的pod是哪些了
spec:
containers: #定义pod里运行的容器
- name: php-redis #定义容器的名字
image: yecc/gcr.io-google_samples-gb-frontend:v3
ports: #定义端口
- name: http #定义容器的名字
containerPort: 80 #定义容器暴露的端口
扩容/缩容/更新
## 扩容/缩容 # 修改资源文件后更新文件，修改replicas字段 vim rs-test-frontend.yaml kubectl apply -f rs-test-frontend.yaml # 直接编辑资源文件后保存 kubectl edit rs frontend更新升级
修改资源文件后更新文件，修改image字段，更换升级版本
但是更换之后，发现工作节点上依旧跑着旧的镜像对应的Pod。所以，更新需要人工干预，手动删除旧的Pod资源副本。
删除之后，重新启动的Pod资源就是新版本的了。【不会自动升级版本！！】
生产环境如果升级，可以删除一个pod，观察一段时间之后没问题再删除另一个pod，但是这样需要人工干预多次；
实际生产环境一般采用蓝绿发布，原来有一个rs1，再创建一个rs2，通过修改service标签，修改service可以匹配到rs2的控制器，这样才是蓝绿发布，这个也需要我们精心的部署规划，我们有一个控制器就是建立在rs之上完成的，叫做Deployment
