今天我们直奔主题。
Horizontal Pod Autoscaler(HPA):
通过手工执行kubectl scale命令，我们可以是实习Pod扩容或缩容。但不符合k8s的定位目标（自动化，智能化）HPA也属于一种k8s的资源对象，与RC 、Deployment一样。
HPA：通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。
HPA有以下两种方式作为Pod负载的度量指标。
◎ CPUUtilizationPercentage。（算术平均值，即目标Pod所有副本自身的CPU利用率的平均值。即：一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值）
◎ 应用程序自定义的度量指标，比如服务在每秒内的相应请求数（TPS或QPS）。
下面是一个不完整HPA的例子，后面会为大家带来一个完整的例子
2
3
4
5
6
7
8
9
10
11
12
13
2kind: HorizontalPodAutoscaler
3metadata:
4 name: php-apache
5 namespace: default
6spec:
7 maxReplicas: 10
8 minReplicas: 1
9 scaleTargetRef:
10 kind: Deployment
11 name: php-apache
12 targetCPUUtilizationPercentage: 90
13
根据上面的定义，我们可以知道这个HPA控制的目标对象为一个名为php-apache的Deployment里的Pod副本，当这些Pod副本的CPUUtilizationPercentage的值超过90%时会触发自动动态扩容行为，在扩容或缩容时必须满足的一个约束条件是Pod的副本数为1～10。
命令创建HPA
2
2
StatefulSet:
Kubernetes系统中，Pod的管理对象RC、Deployment、DaemonSet和Job都面向无状态的服务。但现实中有很多服务是有状态的，特别是一些复杂的中间件集群，例如MySQL集群、MongoDB集群、Akka集群、ZooKeeper集群等，这些应用集群有4个共同点如下：
（1）每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并通信。
（2）集群的规模是比较固定的，集群规模不能随意变动。
（3）集群中的每个节点都是有状态的，通常会持久化数据到永久存储中。
（4）如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损。
如果通过RC或Deployment控制Pod副本数量来实现上述有状态的集群，就会发现第1点是无法满足的，因为Pod的名称是随机产生的，Pod的IP地址也是在运行期才确定且可能有变动的，我们事先无法为每个Pod都确定唯一不变的ID。另外，为了能够在其他节点上恢复某个失败的节点，这种集群中的Pod需要挂接某种共享存储。
StatefulSet的三个特性如下：
◎ StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第1个Pod叫kafka-0，第2个叫kafka-1，以此类推。
◎ StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态。
◎ StatefulSet里的Pod采用稳定的持久化存储卷，通过PV或PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。
StatefulSet还需要与Headless Service配合使用，即在每个StatefulSet定义中都要声明它属于哪个Headless Service。Headless Service与普通Service的关键区别在于，它没有Cluster IP，如果解析Headless Service的DNS域名，则返回的是该Service对应的全部Pod的Endpoint列表。StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod实例都创建了一个DNS域名，
小结：
StatefulSet很重要，后面我会单独讲解并进行StatefulSet的示例操作。由于Service内容较多，实例较多，我明天来给大家讲解，明天可能会更新出两篇来哦。谢谢大家的支持！
