【重识云原生】第六章容器6.4.4节——ReplicaSet组件

  《重识云原生系列》专题索引：

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
4. 第二章计算第3节——主流虚拟化技术之Xen
5. 第二章计算第4节——主流虚拟化技术之KVM
6. 第二章计算第5节——商用云主机方案
7. 第二章计算第6节——裸金属方案
8. 第三章云存储第1节——分布式云存储总述
9. 第三章云存储第2节——SPDK方案综述
10. 第三章云存储第3节——Ceph统一存储方案
11. 第三章云存储第4节——OpenStack Swift 对象存储方案
12. 第三章云存储第5节——商用分布式云存储方案
13. 第四章云网络第一节——云网络技术发展简述
14. 第四章云网络4.2节——相关基础知识准备
15. 第四章云网络4.3节——重要网络协议
16. 第四章云网络4.3.1节——路由技术简述
17. 第四章云网络4.3.2节——VLAN技术
18. 第四章云网络4.3.3节——RIP协议
19. 第四章云网络4.3.4节——OSPF协议
20. 第四章云网络4.3.5节——EIGRP协议
21. 第四章云网络4.3.6节——IS-IS协议
22. 第四章云网络4.3.7节——BGP协议
23. 第四章云网络4.3.7.2节——BGP协议概述
24. 第四章云网络4.3.7.3节——BGP协议实现原理
25. 第四章云网络4.3.7.4节——高级特性
26. 第四章云网络4.3.7.5节——实操
27. 第四章云网络4.3.7.6节——MP-BGP协议
28. 第四章云网络4.3.8节——策略路由
29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
30. 第四章云网络4.3.10节——VXLAN技术
31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
32. 第四章云网络4.3.10.3节——VXLAN隧道机制
33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
34. 第四章云网络4.3.10.5节——VXlan组网架构
35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
36. 第四章云网络4.4节——Spine-Leaf网络架构
37. 第四章云网络4.5节——大二层网络
38. 第四章云网络4.6节——Underlay 和 Overlay概念
39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
41. 第四章云网络4.7.3节——Vhost-net方案
42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
45. 第四章云网络4.7.8节——SR-IOV方案
46. 第四章云网络4.7.9节——NFV
47. 第四章云网络4.8.1节——SDN总述
48. 第四章云网络4.8.2.1节——OpenFlow概述
49. 第四章云网络4.8.2.2节——OpenFlow协议详解
50. 第四章云网络4.8.2.3节——OpenFlow运行机制
51. 第四章云网络4.8.3.1节——Open vSwitch简介
52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
53. 第四章云网络4.8.4节——OpenStack与SDN的集成
54. 第四章云网络4.8.5节——OpenDayLight
55. 第四章云网络4.8.6节——Dragonflow

56.  第四章云网络4.9.1节——网络卸载加速技术综述

57. 第四章云网络4.9.2节——传统网络卸载技术

58. 第四章云网络4.9.3.1节——DPDK技术综述

59. 第四章云网络4.9.3.2节——DPDK原理详解

60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

61. 第四章云网络4.9.4.2节——智能网卡实现

62. 第六章容器6.1.1节——容器综述

63. 第六章容器6.1.2节——容器安装部署

64. 第六章容器6.1.3节——Docker常用命令

65. 第六章容器6.1.4节——Docker核心技术LXC

66. 第六章容器6.1.5节——Docker核心技术Namespace

67. 第六章容器6.1.6节—— Docker核心技术Chroot

68. 第六章容器6.1.7.1节——Docker核心技术cgroups综述

69. 第六章容器6.1.7.2节——cgroups原理剖析

70. 第六章容器6.1.7.3节——cgroups数据结构剖析

71. 第六章容器6.1.7.4节——cgroups使用

72. 第六章容器6.1.8节——Docker核心技术UnionFS

73. 第六章容器6.1.9节——Docker镜像技术剖析

74. 第六章容器6.1.10节——DockerFile解析

75. 第六章容器6.1.11节——docker-compose容器编排

76. 第六章容器6.1.12节——Docker网络模型设计

77. 第六章容器6.2.1节——Kubernetes概述

78. 第六章容器6.2.2节——K8S架构剖析

79. 第六章容器6.3.1节——K8S核心组件总述

80. 第六章容器6.3.2节——API Server组件

81. 第六章容器6.3.3节——Kube-Scheduler使用篇

82. 第六章容器6.3.4节——etcd组件

83. 第六章容器6.3.5节——Controller Manager概述

84. 第六章容器6.3.6节——kubelet组件

85. 第六章容器6.3.7节——命令行工具kubectl

86. 第六章容器6.3.8节——kube-proxy

87. 第六章容器6.4.1节——K8S资源对象总览

88. 第六章容器6.4.2.1节——pod详解

89. 第六章容器6.4.2.2节——Pod使用(上)

90. 第六章容器6.4.2.3节——Pod使用(下)

91. 第六章容器6.4.3节——ReplicationController

92. 第六章容器6.4.4节——ReplicaSet组件

93. 第六章容器基础6.4.5.1节——Deployment概述

94. 第六章容器基础6.4.5.2节——Deployment配置详细说明

95. 第六章容器基础6.4.5.3节——Deployment实现原理解析

96. 第六章容器基础6.4.6节——Daemonset

97. 第六章容器基础6.4.7节——Job

98. 第六章容器基础6.4.8节——CronJob

1 ReplicaSet简介

1.1 ReplicaSet是什么？

        ReplicaSet（简称RS）是Pod控制器类型的一种实现，用于确保由其管控的Pod对象副本数在任一时刻都能精确满足期望的数量。Kubernetes中还有一个类似功能的控制器：Replication Controller。ReplicaSet是Replication Controller的下一代副本控制器，目前两者只在标签选择器支持的查找方式有区别，ReplicaSet支持等式查找与集合查找两种方式，Replication Controller只支持等式查找。

        实现上kubernetes官方推荐不要直接使用ReplicaSet，用Deployments取而代之，Deployments是比ReplicaSet更高级的概念，它会管理ReplicaSet并提供很多其它有用的特性，最重要的是Deployments支持声明式更新，声明式更好相比于命令式更新的好处是不会丢失历史变更。总结起来就是：不要再直接使用ReplicaSet。

1.2 比较ReplicaSet和ReplicationController

        ReplicaSet的行为与ReplicationController完全相同，但pod选择器的表达能力更强。虽然ReplicationController的标签选择器只允许包含某个标签的匹配pod，但ReplicaSet的选择器还允许匹配缺少某个标签的pod，或包含特定标签名的pod，不管其值如何。

        kubectl命令同时支持ReplicaSet与Replication Controller两种副本控制器，但是kubectl rolling-update只支持Replication Controller类型的副本控制器，也就是说ReplicaSet无法通过kubectl rolling-update命令滚动升级。如果想要使用rolling-update功能的话，kubernetes官方推荐使用Deployments，并且因为Deployments是声明式的而rolling-update是命令式，所以推荐使用rollout命令实现滚动升级（kubectl管理对象的方式大体上分成两种，一种是命令式，另一种是声明式，声明式又细分成命令声明式与对角声明式，三种方式不能混用，所以才有此说）。

        另外，举个例子，单个ReplicationController无法将pod与标签env=production和env=devel同时匹配。它只能匹配带有env=devel标签的pod或带有env=devel标签的pod。但是一个ReplicaSet可以匹配两组pod并将它们视为一个大组。

        同样，无论ReplicationController的值如何，ReplicationController都无法仅基于标签名的存在来匹配pod，而ReplicaSet则可以。例如，ReplicaSet可匹配所有包含名为env的标签的pod，无论ReplicaSet的实际值是什么（可以理解为env=*）。

1.3 ReplicaSet 怎么管理Pod

        ReplicaSet会通过标签选择器（Label-Selector）管理所有带有与选择器匹配的标签的容器。创建Pod时，它会认为所有Pod 是一样的，是无状态的，所以在创建顺序上不会有先后之分。如果使用相同的标签选择器创建另一个ReplicaSet，则之前的ReplicaSet会认为是它创建了这些Pod，会触发控制循环里的逻辑删掉多余的Pod ，新的ReplicSet又会再次创建Pod。双方的当前状态始终不等于期望状态，这就会引发问题，因此确保ReplicaSet标签选择器的唯一性这一点很重要。

        如上图所示，ReplicaSet控制器资源启动后会查找集群中匹配其标签选择器的Pod资源对象，当前活动对象的数量与期望的数量不吻合时，多则删除，少则通过Pod模板创建以补足，等Pod资源副本数量符合期望值后即进入下一轮和解循环。

        ReplicaSet的副本数量、标签选择器甚至是Pod模板都可以随时按需进行修改，不过仅改动期望的副本数量会对现存的Pod副本产生直接影响。修改标签选择器可能会使得现有的Pod副本的标签变得不再匹配，此时ReplicaSet控制器要做的不过是不再计入它们而已。另外，在创建完成后，ReplicaSet也不会再关注Pod对象中的实际内容，因此Pod模板的改动也只会对后来新建的Pod副本产生影响。

        相比较于手动创建和管理Pod资源来说，ReplicaSet能够实现以下功能。

• 确保Pod资源对象的数量精确反映期望值：ReplicaSet需要确保由其控制运行的Pod副本数量精确吻合配置中定义的期望值，否则就会自动补足所缺或终止所余。
• 确保Pod健康运行：探测到由其管控的Pod对象因其所在的工作节点故障而不可用时，自动请求由调度器于其他工作节点创建缺失的Pod副本。
• 弹性伸缩：业务规模因各种原因时常存在明显波动，在波峰或波谷期间，可以通过ReplicaSet控制器动态调整相关Pod资源对象的数量。

        此外，在必要时还可以通过HPA（HroizontalPodAutoscaler）控制器实现Pod资源规模的自动伸缩。

2 ReplicaSet使用

2.1 ReplicaSet 的YAML文件定义

        下面这个配置文件的模板里罗列了定义ReplicaSet对象的YAML文件内容的主要组成部分：

apiVersion: apps/v1 
kind: ReplicaSet 
metadata: 
  name: some-name 
  labels: 
    app: some-App 
    tier: some-Tier 
spec: 
  replicas: 3  # 告诉k8s需要多少副本 
  Selector: # 用于匹配Pod的标签选择器 
    matchLabels: 
      tier: someTier 
  template: 
    metadata: 
      labels: 
        app: some-App 
        tier: someTier 
    spec: # 与Pod对象的spec定义类似 
      Containers: ...

        Kubernetes里所有的API对象都由四部分组成：

• apiVersion -- 当前使用的Kubernetes的API版本。
• kind -- 你想创建的对象的种类，当前自然是ReplicaSet。
• metadata -- 元数据，用于唯一表示当前的对象，比如name、namespace等。
• spec -- 当前对象的指定配置。

        但是ReplicaSet的spec部分的定义看起来与其他对象的spec定义略有不同。上面的示例中有两个spec字段。第一个spec声明的是ReplicaSet的属性--定义有多少个Pod副本（默认将仅部署1个Pod）、匹配Pod标签的选择器等。第二个spec用于Pod里的容器属性等配置。

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

2.2 ReplicaSet使用案例

        了解了什么是副本集，以及如何编写副本集的声明文件后，接下来我们动手创建一个副本集。在此示例中，我们将通过replica.yaml文件创建一个具有3个Pod副本的nginx应用。

# replica.yaml 
apiVersion: apps/v1 
kind: ReplicaSet 
metadata: 
  name: myapp-replicas 
  labels: 
    app: myapp 
    tier: frontend 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      tier: frontend 
    matchExpressions: 
      - {key: tier, operator: In, values: [frontend]} 
  template: 
    metadata: 
      labels: 
        app: myapp 
        tier: frontend 
    spec: 
      containers: 
        - name: nginx 
          image: nginx 
          ports: 
            - containerPort: 80

        首先我们运行kubectl create命令使用上面定义的声明文件创建对象。

$ kubectl create -f replica.yaml replicaset.apps "myapp-replicas" created

        接下来通过命令确保副本集创建成功

$ kubectl get replicaset 
NAME             DESIRED CURRENT READY  AGE 
myapp-replicas     3        3     3     15s

        上面的命令返回显示了myapp-replicas副本集部署了三个副本，三个都是就绪状态。接下来我们再看一下每个Pod副本的运行状态：

$ kubectl get pod 
NAME                 READY STATUS     RESTARTS AGE 
myapp-replicas-67rkp 1/1   Running       0     33s 
myapp-replicas-6kfd8 1/1   Running       0     33s 
myapp-replicas-s96sg 1/1   Running       0     33s

        所有3个都处于运行状态，重启次数都是0，这意味着目前为止我们的应用程序没有崩溃过。我们还可以使用kubectl describe命令查询副本集对象的详细信息，信息里的Events部分详细显示了ReplicaSet控制器进行过哪些编排动作。

$ kubectl describe replicaset myapp-replicas 
Name: myapp-replicas 
Namespace: default 
Selector: tier=frontend,tier in (frontend) 
Labels: app=myapp 
        tier=frontend 
Annotations: 
  Replicas: 3 current / 3 desired 
  Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed 
  Pod Template: 
    Labels: app=myapp 
            tier=frontend 
    Containers: 
      nginx: 
        Image: nginx 
        Port: 80/TCP 
        Host Port: 0/TCP 
        Environment: 
          Mounts: 
            Volumes: 
Events: 
Type   Reason             Age     From                     Message 
----   ------             ----    ----                     ------- 
Normal SuccessfulCreate   12m     replicaset-controller    Created pod: myapp-replicas-6kfd8 
Normal SuccessfulCreate   12m     replicaset-controller    Created pod: myapp-replicas-67rkp 
Normal SuccessfulCreate   12m     replicaset-controller    Created pod: myapp-replicas-s96sg

2.3 ReplicaSet支持的操作

2.3.1 删除ReplicaSet与它控制下的pod

        kubectl delete命令将删除ReplicaSet及其pod。具体的过程是kubectl delete首先将副本的数量调整到0，然后等待kubernetes控制面将pod删除，再后再删除ReplicaSet，kubectl delete可以被中断，重新运行后继续删除处理。

2.3.2 只删除ReplicaSet

        只需要运行kubectl delete命令时加上--cascade=false选项，ReplicaSet被删除，其控制的pod不受影响。

2.3.3 从ReplicaSet隔离pod

        更改pod标签，使其无法与ReplicaSet标签选择器匹配就可以将pod从ReplicaSet隔离出来，这时pod副本个数变少，ReplicaSet自动补足。

2.3.4 ReplicaSet扩缩容

        只需简单的更新ReplicaSet spec中的.spec.replicas值就可实现。

2.3.5 ReplicaSet水平自动扩缩容器

        通过HPA控制ReplicaSet根据负荷如cpu使用情况自动扩缩容。HPA spec如下：

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
  name: frontend-scaler 
spec: 
  scaleTargetRef: 
    kind: ReplicaSet 
    name: frontend 
    minReplicas: 3 
    maxReplicas: 10 
    targetCPUUtilizationPercentage: 50

创建HPA对象：

kubectl create -f https://k8s.io/examples/controllers/hpa-rs.yaml

        以上根据CPU使用情况，在3到10之间动态的调整副本数量。

参考链接

kubernetes之ReplicaSet_五星上炕的博客-CSDN博客_replicaset

ReplicaSet_喝醉酒的小白的博客-CSDN博客_replicaset

k8s-Pod控制器之ReplicaSet

ReplicaSet

ReplicaSet - 浪漫De刺猬 - 博客园

详解Kubernetes控制器之副本集ReplicaSet - 知乎

4.3 使用ReplicaSet而不是ReplicationController - 知乎

K8S之ReplicaSet详解_Jeremy_Lee123的博客-CSDN博客_k8s replicaset

ReplicaSet | Kubernetes

ReplicaSet · Kubernetes指南