K8s控制器---Replicaset(7)

一、Replicaset(目前少用了)

1.1 控制器管理pod

什么是控制器？
前面我们学习了 Pod，那我们在定义 pod 资源时，可以直接创建一个 kind：Pod 类型的自主式 pod，但是这存在一个问题，假如 pod 被删除了，那这个 pod 就不能自我恢复，就会彻底被删除，线上这种情况非常危险，
所以今天就给大家讲解下 pod 的控制器，所谓控制器就是能够管理 pod，监测 pod 运行状况，当 pod 发生故障，可以自动恢复 pod。也就是说能够代我们去管理 pod 中间层，并帮助我们确保每一个 pod 资源始终处于我们所定义
或者我们所期望的目标状态，一旦 pod 资源出现故障，那么控制器会尝试重启 pod 或者里面的容器，如果一直重启有问题的话那么它可能会基于某种策略来进行重新布派或者重新编排；如果 pod 副本数量低于用户所定义的目标数量，
它也会自动补全；如果多余，也会自动终止pod 资源。 

1.2 Replicaset概述

ReplicaSet 是 kubernetes 中的一种副本控制器，简称 rs，主要作用是控制由其管理的 pod，使 pod副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的 Pod 能够在集群中正常运行，它会持续监听这些 Pod 的运行状态，
在 Pod 发生故障时重启 pod，pod 数量减少时重新运行新的 Pod 副本。官方推荐不要直接使用 ReplicaSet，用 Deployments 取而代之，Deployments 是比 ReplicaSet 更高级的概念，
它会管理 ReplicaSet 并提供很多其它有用的特性，最重要的是 Deployments 支持声明式更新，声明式更新的好处是不会丢失历史变更。所以 Deployment 控制器不直接管理 Pod 对象，而是由 Deployment 管理 ReplicaSet，
再由 ReplicaSet 负责管理 Pod 对象。

1.3 Replicaset 工作原理：如何管理Pod?

     Replicaset 核心作用在于代用户创建指定数量的 pod 副本，并确保 pod 副本一直处于满足用户期望的数量， 起到多退少补的作用，并且还具有自动扩容缩容等机制。

Replicaset 控制器主要由三个部分组成： 
1、用户期望的 pod 副本数：用来定义由这个控制器管控的 pod 副本有几个
 
2、标签选择器：选定哪些 pod 是自己管理的，如果通过标签选择器选到的 pod 副本数量少于我们指定的数量，需要用到下面的组件
 
3、pod 资源模板：如果集群中现存的 pod 数量不够我们定义的副本中期望的数量怎么办，需要新建 pod，这就需要 pod 模板，新建的 pod 是基于模板来创建的。

1.4 Replicaset资源清单文件编写技巧

[root@master ~]# kubectl explain replicaset
KIND:     ReplicaSet
VERSION:  apps/v1

DESCRIPTION:
     ReplicaSet ensures that a specified number of pod replicas are running at
     any given time.

FIELDS:
   apiVersion    <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind    <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata    <Object>
     If the Labels of a ReplicaSet are empty, they are defaulted to be the same
     as the Pod(s) that the ReplicaSet manages. Standard object's metadata. More
     info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec    <Object>
     Spec defines the specification of the desired behavior of the ReplicaSet.
     More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

   status    <Object>
     Status is the most recently observed status of the ReplicaSet. This data
     may be out of date by some window of time. Populated by the system.
     Read-only. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

#查看定义 Replicaset 资源需要的字段有哪些？
[root@master ~]# kubectl explain rs
KIND:     ReplicaSet
VERSION:  apps/v1

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

#查看 replicaset 的 spec 字段如何定义？
[root@master ~]# kubectl explain replicaset.spec
FIELDS: 
 minReadySeconds <integer> 
 replicas <integer> #定义的 pod 副本数，根据我们指定的值创建对应数量的 pod 
 selector <Object> -required- #用于匹配 pod 的标签选择器 
 template <Object> #定义 Pod 的模板，基于这个模板定义的所有 pod 是一样的

# 查看 replicaset 的 spec.template 字段如何定义？ 
#对于 template 而言，其内部定义的就是 pod，pod 模板是一个独立的对象
[root@master ~]# kubectl explain replicaset.spec.template
FIELDS:
   metadata <Object>
   spec <Object>
[root@master ~]# kubectl explain replicaset.spec.template.spec


通过上面可以看到，ReplicaSet 资源中有两个 spec 字段。第一个 spec 声明的是 ReplicaSet 定义多少个 Pod 副本（默认将仅部署 1 个 Pod）、匹配 Pod 标签的选择器、创建 pod 的模板。第二个 spec 是
spec.template.spec：主要用于 Pod 里的容器属性等配置。 

.spec.template 里的内容是声明 Pod 对象时要定义的各种属性，所以这部分也叫做 PodTemplate（Pod 模板）。还有一个值得注意的地方是：
在.spec.selector 中定义的标签选择器必须能够匹配到spec.template.metadata.labels 里定义的 Pod 标签，否则 Kubernetes 将不允许创建 ReplicaSet。

1.5 Replicaset使用案例：部署Guestbook留言板

# 节点导入镜像
docker load -i frontend.tar.gz
Loaded image: yecc/gcr.io-google_samples-gb-frontend:v3

# 编写replicaset资源清单
[root@master rs]# cat replicaset.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  namespace: default
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: yecc/gcr.io-google_samples-gb-frontend:v3
        imagePullPolicy: IfNotPresent

# frontend通过标签选择器关联到模板template
[root@master rs]# kubectl apply -f replicaset.yaml 
replicaset.apps/frontend created
[root@master rs]# kubectl get rs
NAME                                 DESIRED   CURRENT   READY   AGE
calico-kube-controllers-6949477b58   1         1         1       4d12h
coredns-7f89b7bc75                   2         2         2       13d
frontend                             3         3         3       6m30s
metrics-server-6595f875d6            1         1         1       4d12h

[root@master rs]# kubectl get pods
NAME                                       READY   STATUS    RESTARTS   AGE
frontend-hp986                             1/1     Running   0          3m32s
frontend-kkmsn                             1/1     Running   0          3m32s
frontend-p6xsm                             1/1     Running   0          3m32s

#资源清单详细说明 
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 #定义容器暴露的端口 

# 清理无用pod
[root@master rs]# kubectl get deployment -n default
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx        2/2     2            2           4d12h
nginx-test   2/2     2            2           4d8h
[root@master rs]# kubectl delete deployment -n default nginx
deployment.apps "nginx" deleted
# 强制删除命令--force --grace-period=0

[root@master rs]# kubectl delete pods tomcat-test --force --grace-period=0

1.6 通过Replicaset实现：扩容、缩容、更新

#Replicaset 实现 pod 的动态扩容 
ReplicaSet 最核心的功能是可以动态扩容和回缩，如果我们觉得两个副本太少了，想要增加，只需要修改配置文件 replicaset.yaml 里的 replicas 的值即可，原来 replicas: 3，现在变成 replicaset: 4，
修改之后，执行如下命令更新： 
# 扩容方法1:修改yaml文件中replicas: 3修改为4
[root@master rs]# kubectl apply -f replicaset.yaml
replicaset.apps/frontend configured
# 扩容方法2：
[root@master rs]# kubectl edit rs frontend

[root@master ~]# kubectl get pods -w   # 查看
NAME READY STATUS RESTARTS AGE

frontend-7j49d 0/1 Pending 0 0s
frontend-7j49d 0/1 Pending 0 0s
frontend-7j49d 0/1 ContainerCreating 0 0s
frontend-7j49d 0/1 ContainerCreating 0 1s
frontend-7j49d 1/1 Running 0 2s

# 缩容方法

# 和扩容方法一样，修改yaml文件中replicas: 4为2然后执行文件或者直接edit修改

[root@master rs]# kubectl apply -f replicaset.yaml
replicaset.apps/frontend configured

[root@master ~]# kubectl get pods -w

frontend-p6xsm 1/1 Terminating 0 24m
frontend-p6xsm 1/1 Terminating 0 24m
frontend-p6xsm 0/1 Terminating 0 24m
frontend-p6xsm 0/1 Terminating 0 24m
frontend-p6xsm 0/1 Terminating 0 24m

# 更新pod:

#replicaset实现业务更新
[root@master rs]# kubectl get pods -n default -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
frontend-sxqh7   1/1     Running   0          20s   10.244.75.215   monitor   <none>           <none>
frontend-vq7cb   1/1     Running   0          20s   10.244.135.23   node3     <none>           <none>
1. 所有node节点导入新版本镜像
docker load -i myapp-v2.tar.gz
Loaded image: ikubernetes/myapp:v2

2.master修改镜像配置image来源
kubectl edit rs -n default frontend
修改
- image: yecc/gcr.io-google_samples-gb-frontend:v3
为
- image: ikubernetes/myapp:v2

[root@master rs]# kubectl edit rs -n default frontend
replicaset.apps/frontend edited
[root@master ~]# kubectl get pods -n default -w
NAME             READY   STATUS    RESTARTS   AGE
frontend-sxqh7   1/1     Running   0          10m
frontend-vq7cb   1/1     Running   0          10m

# 发现新建的pod会更新，但是原来的pod不会更新
[root@master rs]# kubectl delete pods -n default frontend-sxqh7
pod "frontend-sxqh7" deleted
[root@master rs]# kubectl get pods -n default -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
frontend-jzx9h   1/1     Running   0          18s   10.244.75.216   monitor   <none>           <none>
frontend-vq7cb   1/1     Running   0          11m   10.244.135.23   node3     <none>           <none>
[root@master rs]# curl 10.244.75.216
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

# 直接修改yaml文件并执行，pods版本不会改变，都需要删除老的pod生成新的pod才能更新

生产环境如果升级，可以删除一个 pod，观察一段时间之后没问题再删除另一个 pod，但是这样需要 人工干预多次；实际生产环境一般采用蓝绿发布，原来有一个 rs1，再创建一个 rs2（控制器），通过修 改 service 标签，

修改 service 可以匹配到 rs2 的控制器，这样才是蓝绿发布，这个也需要我们精心的 部署规划，我们有一个控制器就是建立在 rs 之上完成的，叫做 Deployment