在kubernetes中，Pod是最基础的调度单位，多个pod 可以组成一个集合，这个集合向外提供服务。这时候，我们需要以下两种情形需要关注：
1）集合中的Pod可能会由于某种原因Fail，这时候需要某种机制能够创建新的Pod以确保有足够数量的Pod在运行。
2）Pod 的个数由访问请求决定。即当前实例个数不足以满足访问请求时，需要增加实例个数，反之，需要通过某种策略减少实例数。
如果人工来实时监控实例的运行状态，手动启动新的pod以替代fail的pod，监控实例的负载情况，手动创建或者删除pod，这个工作繁琐且工作量大，好在kubernetes已经有相应的机制来应对这种变化。
2.概要
声明： 这里的介绍主要基于kubernetes官网的内容，您可以选择 kubernetes 官网 阅读更加详细内容。
1）关于RelicationController 和 RelicaSet
简单来说，这两者的主要作用都是确保有指定的数量的Pod实例在运行，区别在于后者是前者的升级版。他们都会检测Pod的个数，一旦某个pod fail，则启动新的Pod，当然如果数量过多（fail的pod复活），则需要删除某些实例。
这里目前有两种常见的使用场景。第一，通过一个RC（或RS）部署一个Pod，这种情形下，一个Pod fail，RS 会主动创建新的Pod来替换旧的Pod，反之，会删除多余的Pod，这也是一种高可用的方案。第二种，通过RS部署多个Pod，这种情形下，一旦某个Pod fail 掉，RS同样会创建新的Pod来弥补，以确保总是有相同数目的pod在提供服务，不至于由于pod fail，应用的服务水平下降。
下面是一个RC的yaml定义文件：
apiVersion: v1 kind: ReplicationController metadata: name: nginx spec: replicas: 3 selector: app: nginx template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80这里的replicas即需要维持的Pod个数，值得一提的是，这个个数是可以改变的，只需要修改这个文件，然后执行替换操作即可，然后RS就会按照新的数量维护Pod个数。
这里的template即Pod的定义，这个与创建单个pod的定义是一致的，事实上，这个配置会传递下去，通过这个配置创建pod。
在创建RS后，Pod 与 RS 是关联到一起的。那么如果删除这个RS，Pod是否会存在呢? 默认是会删除的，但是可以传入参数加以控制。
You can delete a replication controller without affecting any of its pods. Using kubectl, specify the --cascade=false option to kubectl delete.最后，需要指出的是，RS 创建新的pod 依然会通过调度器来做调度，一旦调度失败，则无法完成这个过程，新创建的pod一直处于pending状态，直到有合适的Node供调度器调度。另外还有一种极特殊的情形，即创建RS的时候，在定义中指定了nodeName，这时候就不会经过调度器，这时候一旦这个Pod失败，那么RS不会通过调度器寻找合适的Node，依然会在当前的Pod上尝试创建Pod，当然结果是Fail，于是很快会出现很多Fail状态的Pod，这样死循环下去，将会导致资源耗尽。
2）Horizontal Pod Autoscaling
关于HPA，官方解释如下：
With Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization (or, with alpha support, on some other, application-provided metrics)相信这个已经解释非常清楚了，根据CPU的使用率来决定是否需要增加或减少实例。
插一句：据社区官方文档，社区正在积极寻求更多的方面考虑（如内存、I/O）与CPU一起决定增加或减少实例。官方已经给出了设计文档，这个设计文档涉及到相关的概念，算法等各个方面：https://github.com/kubernetes/kubernetes/blob/master/docs/design/horizontal-pod-autoscaler.md
这张图来自Kubernetes官方，形象地概括了通过HPA如何实现Auto Scale。这里涉及到Deployment，我们后面再讨论。HPA 最重要的使用场景在于Rolling Update。在虚拟化的时代，通常是多个虚拟机组成的集群，取出某个实例进行升级，然后放回集群，再升级另一个，直到集群中的所有实例升级完成才结束。我们的Pod与虚拟化中的虚拟机比较类似，那么HPA是如何升级的呢？
HPA会创建一个新的RS,原来的RS里面会减少一个Pod，新的RS会增加一个Pod，这样逐个Pod进行升级，直到所有的Pod都从原来的RS下升级到新的RS下，升级圆满结束。
3.总结