Kubernetes ReplicaSet 和 HPA 介绍
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,让这个社区更强大。
Kubernetes 的详细介绍:请点这里
Kubernetes 的下载地址:请点这里