Kubernetes1.15.1对象ReplicationController与Replica Set详解

上次学习了k8s的init container，通过上次也了解了pod的生命周期（先执行init container，后面是主容器的生命周期（钩子函数2个post start，pre stop），健康检查的liveness，readiness），前面都是直接操作pod，加入有一个pod正在启动线上的服务，需要对pod进行操作，该怎么办。

（一）场景

使用场景

1.运营的pod，发展很好，网站访问量突然暴增

这种情况还比较好解决，运维的同事多开几个对应pod，挂了还有多个。访问量减少的时候在删除掉多余的pod，麻烦但是可以解决。

2.节点直接不能用了，pod都不提供服务了

运营中心同事打电话说你的服务挂了，打开电脑重启pod，问题解决。

上边场景分析

在现在讲究快速迭代的软件研究趋势下，长期这样手动重复的后果就是：

1.一直手工操作导致效率低下。

2.重复工作会扼杀人的创造性。

有没有一种工具能够自动的检测，自动的临时增加pod，删减pod，Pod挂了自动帮我在合适的节点上重新启动一个Pod，这样是不是遇到上面的问题我们都不需要手动去解决了。

Kubernetes就为我们提供了这样的资源对象

1.Replication Controller：用来部署、升级Pod

2.Replica Set：下一代的Replication Controller

3.Deployment：可以更加方便的管理Pod和Replica Set

（二）Replication Controller

介绍

Replication Controller简称RC，RC是Kubernetes系统中的核心概念之一，RC 就是Kubernetes上用来管理Pod的数量以及状态的controller。

能干啥

每个Replication Controller都有属于自己的 yaml 档。

在Replication Controller设定档中可以指定同时有多少个相同的Pods运行在Kubernetes Cluster上。

当某一Pod发生crash, failed，而终止运行时，Replication Controller会帮我们自动侦测，并且自动创建一个新的Pod，确保Pod运行的数量与设定档的指定的数量相同。

当机器重新开启时，之前在机器上运行的 Replication Controller 会自动被建立，确保pod随时都在运行。

看一手文档

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#replicationcontroller-v1-core

（二）使用RC来管理我们前面使用的Nginx的Pod

rc 是replicationController的缩写

创建yaml

spec.replicas & spec.selector

在spec.replicas中，我们必须定义Pod的数量，以及在spec.selector中指定我们要选择的Pod的条件(labels)。

spec.template

在spec.template中我们会去定义pod的资讯，包含Pod的labels以及Pod中要运行的container。

则是Pod的labels，metadata.labels必须被包含在select中，否则在创建Replication Controller物件时，会发生error。

创建rc

查看rc

删除rc中的pod

修改rc

查看已经变成了4个

在dashboard上查看，操作

rolling-update 滚动升级

传统的升级更新，是先将服务全部下线，业务停止后再更新版本和配置，然后重新启动并提供服务。这样的模式已经完全不能满足“时代的需要”了。在并发化、高可用系统普及的今天，服务的升级更新至少要做到“业务不中断”。而滚动更新(Rolling-update)恰是满足这一需求的一种系统更新升级方案。

简单来说，滚动更新就是针对多实例服务的一种不中断服务的更新升级方式。一般情况，对于多实例服务，滚动更新采用对各个实例逐个进行单独更新而非同一时刻对所有实例进行全部更新的方式。“滚动更新”的先进之处在于“滚动”这个概念的引入，笔者觉得它至少有以下两点含义：

a) “滚动”给人一种“圆”的映像，表意：持续，不中断。“滚动”的理念是一种趋势，我们常见的“滚动发布”、“持续交付”都是“滚动”理念的应用。与传统的大版本周期性发布/更新相比，”滚动”可以让用户更快、更及时地使用上新Feature，缩短市场反馈周期，同时滚动式的发布和更新又会将对用户体验的影响降到最小化。

b) “滚动”可向前，也可向后。我们可以在更新过程中及时发现“更新”存在的问题，并“向后滚动”，实现更新的回退，可以最大程度上降低每次更新升级的风险。

Rolling update就是指一次仅更新一个Pod，并逐个进行更新，而不是在同一时刻将该Service下面的所有Pod shutdown，避免将业务中断的尴尬。

（三）Replica Set

Replica Sets 可以说是进化版的 Replication Controller，与 Replication Controller最大的差异在于，Replica Sets 提供了更弹性的selector。

kubectl命令行工具中关于RC的大部分命令同样适用于我们的RS资源对象。不过我们也很少会去单独使用RS，它主要被Deployment这个更加高层的资源对象使用，除非用户需要自定义升级功能或根本不需要升级Pod，在一般情况下，我们推荐使用Deployment而不直接使用Replica Set。

PS：尽量不要使用edit和在dashboard上进行操作，因为他们没有备份，最好的方式是修改yaml的方式，有备份。而在 Kubernetes官方文件 中也提到，虽然Replica Set提供更弹性的selector，并不推荐开发者直接使用kubectl create等指令创建Replica Set 物件，而是透过 Deployment 来创建新的 Replica Set。