Kubernetes1.2新特性分析（一）

本次分析的kubernetes版本号：v1.2.1-beta.0，将此版本同v1.1.8-beta.0版本进行比较，得出下面1.2新特性分析结果。

1、scheduler模块

v1.2比v1.1去掉了bind-pods-qps参数和bind-pods-burst参数，取而代之的是kube-api-qps参数和kube-api-burst参数，v1.2比v1.1多了scheduler-name参数，这个参数代表用来给POD指定使用哪个调度器，对应到POD的annotation中就是 “scheduler.alpha.kubernetes.io/name”参数，从名字可以看出来这个功能还处在alpha阶段，以后有可能进行较大变化，以后也有可能被删除掉。
在v1.1中QPS和Burst两个参数是hardcode的，分别是50和100，在v1.2中这两个参数是可以通过上面提到了两个参数配置的，这两个参数用于限制向api-server每秒发送请求数。
在v1.2中新增加了用于选举的结构体LeaderElector，通过这个结构体用来实现scheduler模块多节点部署，目前还处在alpha阶段，以后有可能进行较大变化，以后也有可能被删除掉。
在v1.2中取消了访问api-server时用于设置NODE同POD对应关系的速率限制参数。
在kubernetes调度算法部分有个核心的结构体，叫做genericScheduler，这个结构体中v1.2比v1.1多了两个变量，分别是变量extenders和变量lastNodeIndex。变量extenders用于扩展调度功能，可以配置哪些POD需要运行在哪些NODE上面，这样调度就可以针对POD和NODE在可以被控制的范围内进行自动调度。v1.1中对于满足条件的NODE节点进行随机选择，v1.2中改变了通过引入变量lastNodeIndex改变了v1.1中的随机算法，让POD在NODE节点上的分配更加均衡。
在v1.2中也把docker镜像是否在NODE节点中作为调度所考虑的因素了，另外还把NODE节点affinity作为调度所考虑的另外一个因素了，通过计算NODE节点中多个affinity表达式，获取最匹配的NODE节点。在v1.2中还把持久卷也作为调度所考虑的因素了，有些POD如果对持久卷有要求，那么kubernetes会将对持久卷有要求的POD开在可以挂载这些持久卷的NODE节点上，也就是说保持持久卷作用域同POD作用域的一致，另外kubernetes还新增了对AWS的EBS或者GCE的PD挂载最大数量的设计。

2、api-server模块

在v1.2中没有什么变化。只是将v1.1中一些不建议在生产环境中运行功能对应的API转正了，比如Autoscaling API和JOB API，另外增加了configMaps API，以及configMaps数据持久化存储。

3、controller-manager模块

在v1.2中新增了参数kube-api-qps和kube-api-burst，这两个参数用于限制向api-server每秒发送请求数，默认值分别是20和30，这两个默认值同v1.1中设置的值是一致的。
在v1.2中新增加了用于选举的结构体LeaderElector，通过这个结构体用来实现controller-manager模块多节点部署，目前还处在alpha阶段，以后有可能进行较大变化，以后也有可能被删除掉。

3.1、EndpointController

在v1.2中没有什么变化。

3.2、ReplicationManager

在v1.2中ReplicationManager结构体增加了一个变量lookupCache，这个变量的作用在于缓存label和selector的对应关系，这样就可以根据POD的label信息快速返回对应的ReplicationController信息，在v1.1中是需要查询整个ReplicationController列表的。

3.3、GCController

在v1.2中没有什么变化。

3.4、NodeController

在v1.2中NodeController结构体中增加了三个变量，其中最重要的是DaemonSet相关的两个变量daemonSetController和daemonSetStore，另外一个新增的变量是nodeExistsInCloudProvider，这个变量相当于把v1.1中一些代码进行重写。
DaemonSet在v1.1中处于beta阶段，在v1.2中已经可以在生产环境中使用了，所以在NodeController中也增加了对DaemonSet的检查和同步操作。

3.5、ServiceController

在v1.2中没有什么变化。只是把原先hardcode的TCP load balancers改成了load balancers，在cloudprovider中队load balancers进行了TCP限制，这样方便以后对load balancers支持的协议进行扩展。

3.6、RouteController

在v1.2中没有什么变化。

3.7、ResourceQuotaController

在v1.2中结构体ResourceQuotaController变化比较大，整个结构体同v1.1相比基本上都变化了，可以说ResourceQuotaController控制器基本上都被重新写了，重写后的ResourceQuotaController控制器更利于扩展。

type ResourceQuotaController struct { kubeClient clientset.Interface rqIndexer cache.Indexer rqController *framework.Controller queue *workqueue.Type syncHandler func(key string) error resyncPeriod controller.ResyncPeriodFunc registry quota.Registry replenishmentControllers []*framework.Controller }

3.8、HorizontalController

v1.2中HorizontalPodAutoscalers自动伸缩功能可以在生产环境中使用，而在v1.1中建议在实验环境中使用，并且在v1.1CPU使用率指标基础上增加了客户自定义指标，还将处理逻辑重新编写了。
v1.2中结构体HorizontalController也进行了比较大的变化，这是一个POD自动伸缩控制器结构体，变量store是个Store接口，表示HorizontalPodAutoscalers的本地缓存，变量controller是个控制器，用于对本地缓存进行处理，变量metricsClient表示用于获取自动伸缩指标的客户端。

type HorizontalController struct { scaleNamespacer unversionedextensions.ScalesGetter hpaNamespacer unversionedextensions.HorizontalPodAutoscalersGetter metricsClient metrics.MetricsClient eventRecorder record.EventRecorder store cache.Store controller *framework.Controller }

controller manager初始化结构体HorizontalController，然后根据CPU使用率指标和客户指定的自动伸缩指标开始对horizontalPodAutoscalers进行监控，当满足自动伸缩条件时通知api-server，Kubernetes默认伸展冷却时间是3分钟，默认收缩冷却时间是5分钟。如果配置了启用horizontalPodAutoscalers，但是却没有配置自动伸缩条件，那么系统会按照默认条件执行自动伸缩操作，默认条件是按照CPU使用率执行自动伸缩。
对POD上多种自动伸缩策略，包括按照CPU使用率自动伸缩和客户自定义指标自动伸缩，在满足条件的所有策略中，按照策略中最大的POD副本数来进行处理。举例来说，当满足条件的所有策略中最大副本数是10，而当前副本数是2，并且上一次伸展策略执行时间超过了冷却时间3分钟，那么触发伸展策略；当满足条件的所有策略中最大副本数是3，而当前副本数是10，并且上一次收缩策略执行时间超过了冷却时间5分钟，那么触发收缩策略。

3.9、DaemonSetsController

在v1.2中这个功能并不建议使用在生产环境中，结构体DaemonSetsController中增加了两个变量，一个是burstReplicas，一个是lookupCache，这个变量的作用在于缓存label和selector的对应关系，这样就可以根据POD的label信息快速返回对应的DaemonSetsController信息，在v1.1中是需要查询整个DaemonSetsController列表的。变量burstReplicas是出于对性能的考虑，用于控制每次处理最大数，默认是500。
controller manager利用这个结构体来保证每个指定的NODE节点上面只存在一个POD，典型用例是cAdvisor，在每个NODE节点上上只需要启动一个就可以了。

3.10、JobController

在v1.2中没有太大变化，在v1.2中这个功能可以在生产环境中使用了。

3.11、DeploymentController

在v1.2中有很大变化，在v1.2中这个功能已经可以在实验环境中使用了，但是不建议在生产环境中使用。
DeploymentController主要做的作用就是用新部署的POD替换旧的POD。在kubernetes里面是有DeploymentController来实现替换POD有两种方式，一种是重新创建机制，也就是将旧的POD全部销毁，之后创建新的POD，这样会导致POD上面运行业务的中断；还有一种是RollingUpdate机制,逐渐的减少旧的POD，增加新的POD，直到使用新的POD完全替换旧的POD。
对于RollingUpdate机制，有两种实现方式，一种方式是先删除一部分旧POD，当新POD准备好之后在继续删除旧POD，使用这种方式的话，在处理过程中POD数量始终会小于预定POD数量；还有一种方式是先创建新POD，创建成功后在删除旧POD，然后继续创建新POD，使用这种方式的话，在处理过程中POD数量始终会大于预定POD数量。在v1.2版本中，只是按照第一种实现方式来做的。
在v1.2中没有太大变化，在v1.2中这个功能可以在生产环境中使用了。

3.12、ReplicaSetController

在v1.2中新增了ReplicaSetController，功能上是同ReplicationManager一样的，用来对POD进行多副本控制，只是在查询POD列表的时候新写了一个查询实现方法。

3.13、PersistentVolumeProvisionerController

在v1.2中新增了PersistentVolumeProvisionerController，用来实现持久卷的auto-provisioning功能，也就是将一个旧的持久卷进行扩容操作。这个功能只能在开发环境中使用，不建议在实验环境和生产环境中使用。

4、Kubelet模块

在v1.2中新增了VolumePluginDir参数，表示用于存放第三方卷管理插件的目录，默认路径是是”/usr/libexec/kubernetes/kubelet-plugins/volume/exec/”，这个功能还只能在开发环境中使用。
在v1.2中新增了system-reserved参数和kube-reserved参数，system-reserved表示给kubernetes以外程序预留的CPU和内存资源，kube-reserved表示给kubernetes程序预留的CPU和内存资源。
在v1.2中修改了MaxPods参数默认值，这个参数用来控制kubelet在NODE节点上可以管理的POD数量，在v1.1中默认是32，在v1.2中默认值变成了110，从这里可以看到kubelet在性能上已经提高了很多倍。
在v1.2中创建容器的时候使用了在api-server定义的configMaps，通过这种方法，在容器中就可以使用configMaps里面定义的内容了。这种方式最大的用法是通过kubenetes设置容器所使用的环境变量和配置，在容器中可以使用这些环境变量和配置。在v1.2中创建容器的时候还向容器中传入了secrets内容。

5、Kube-proxy模块

在v1.2增加了对api-server访问流量控制的参数，修改了对proxy-mode参数的推荐值，在v1.1中iptables模式不推荐在生产环境中使用，在v1.2中iptables是可以在生产环境中使用的，而且效率会更高。