关键概念

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	<string>  #当前资源使用的api版本，跟VERSION:  apps/v1保持一致
kind	<string>      #资源类型，跟KIND: ReplicaSet保持一致
metadata	<Object>  #元数据，定义Replicaset名字的
spec	<Object>      #定义副本数、定义标签选择器、定义Pod模板
status	<Object>      #状态信息，不能改

# kubectl explain rs.spec
minReadySeconds	<integer>
replicas	<integer>            #定义的pod副本数，根据我们指定的值创建对应数量的pod
selector	<Object> -required-  #用于匹配pod的标签选择器
template	<Object>             #定义Pod的模板，基于这个模板定义的所有pod是一样的

# kubectl explain rs.spec.template
声明Pod对象时要定义的各种属性，所以这部分也叫做PodTemplate
metadata	<Object>
spec	<Object>

# kubectl explain rs.spec.template.spec
ReplicaSet资源中有两个spec字段。
第一个spec声明的是ReplicaSet定义多少个Pod副本（默认1个Pod）、匹配Pod标签的选择器、创建pod的模板。
第二个spec是spec.template.spec：主要用于Pod里的容器属性等配置。 （同Pod资源文件）

示例：部署一个前端程序

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