共计 2768 个字符，预计需要花费 7 分钟才能阅读完成。
1. 前言
在 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. 总结
Kubernetes 有很多有意思的特性值得去发掘，社区也有很多有意思的事情值得去做，希望大家多了解 kubernetes，一起完善 kubernetes，让这个社区更强大。
Docker 中部署 Kubernetes http://www.linuxidc.com/Linux/2016-07/133020.htm
Kubernetes 集群部署 http://www.linuxidc.com/Linux/2015-12/125770.htm
OpenStack, Kubernetes, Mesos 谁主沉浮 http://www.linuxidc.com/Linux/2015-09/122696.htm
Kubernetes 集群搭建过程中遇到的问题及解决 http://www.linuxidc.com/Linux/2015-12/125735.htm
在 Ubuntu 下部署 Kubernetes 集群 http://www.linuxidc.com/Linux/2016-09/135018.htm
Kubernetes 的详细介绍 ：请点这里
Kubernetes 的下载地址 ：请点这里
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-10/136043.htm
