Kubernetes 1.2.0 携一大波新特性震撼发布！单集群可管理1000个节点

主要变更（相对于v1.1.1）

一、显著增加集群规模

支撑的集群规模增加400%，目前单个集群不损耗性能下，可支持1000个节点，运行30000个Pods。在单个节点上，Kubelet可支持100个Pod，并且性能是v1.1.1的四倍。

1. 简化应用部署和管理

a. a) Dynimic Configuration功能（动态配置，通过核心API中的ConfigMap API实现）。它使得应用配置可以作为Kubernetes API对象存储起来，在容器启动时从APIServer动态获取，可以替代通过命令行传入参数的方式。

b. TurnKey Deployments（通过Extensions API中的Deploy API实现，目前仍是Beta版）。预先声明以后，它可以实现应用部署和滚动升级的自动化，包括版本管理、多个副本同步升级、多Pod状态搜集和管理、管理应用的应用可用性管理和版本回滚。

2.   自动化集群管理

a. 在同一个云平台上实现跨区扩展。一个Service下的Pod会自动扩展到其它可用区，从而做到跨区容错。

b. 简化One-Pod-Per-Node应用的部署管理（通过Extensions API中的DaemonSet API实现）。Kubernetes的调度机制能够保证一个应用每个节点上运行同样的Pod，并且只运行一个，比如logging agent。

c. 支持TLS和7层网络（通过Extensions API中的ingress API实现，目前为Beta版）。基于TLS和基于HTTP的七层网络路由，Kubernetes可以更方便地集成到传统的网络环境中。

d. 支持Graceful Node Shutdown（及Node Drain）。新增的“kubelet drain”命令可以很优雅地将pod从某些节点驱逐出去，从而为节点维护做准备（比如升级kernel。

e. 支持自定义Autoscaling的指标（通过Autoscaling API中的HorizontalPodAutoscaler API实现）。Horizontal Pod Autoscaling支持自定义模版（目前为Alpha版），允许用户指定应用级别的指标和应用自动伸缩的阈值。

f. 新的控制台（dashboard）具备与kubelet commandline类似的功能，允许用户通过一种新方式与kubernetes集群交互。（@TODO，英文不完整）

其它重要的改进

●  Job在v1.1中为Beta版，在1.2中可以投入生产环境。1）目前API操作 apiVersion: batch/v1已经可以使用。需要注意的是，用户不需要指定.spec.selector字段，因为系统为自动生成一个唯一的selector（点击查看详情）。

2）上一个版本，即beta版的API（apiVersion: extensions/v1beta1）仍然支持。即便回滚到v1.1，使用新API创建的对象仍然可以采用旧版本的API去访问。在准备好迁移到batch/v1之前，仍然可以使用现有的JSON或YAML文件。当Kubernetesv1.3或v1.4发布时，我们可能会取消对apiVersion: extenstions/v1beta1 的支持。

●  HorizontalPodAutoscaler在v1.1中为Beta版，在1.2中可以投入生产化境。1）apiVersion: autoscaling/v1 现已可用。发生的变更有：

i. CPUUtilization在之前的版本中是HorizontalPodAutoscalerSpec中一个嵌套的结构体，类型为CPUTargetUtilization；在当前版本中被字段TargetCPUUtilizationPercentage所取代，该字段为integer类型。

ii. ScaleRef是类型SubresourceReference中的一个字段，SubresourceReference存在于结构体HorizontalPodAutoscalerSpec中。ScaleRef用来表示被调度资源的子资源。在当前版本中，该字段已被ScaleTargetRef所代替，ScaleTargetRef仅仅表示被调度的资源。

iii. 在 extensions/v1beta1中，如果不指定HorizontalPodAutoscalerSpec的CPUUtilization，则默认为80；然而在 autoscaling/v1中，未指定TargetCPUUtilizationPercentage的 HPA对象被认为是一个无效的对象。这种情况下，Pod autoscaler控制器会将采用默认的scaling policy（该policy与上一个对象的scaling policy一致，所以将来可能会发生变化）

2）上一个版本的 apiVersion:extensions/v1仍然支持。即便回滚到v1.1，使用新API创建的对象仍然可以采用旧版本的API去访问。在准备好迁移到autoscaling/v1之前，仍然可以使用现有的JSON或YAML文件。当Kubernetesv1.3或v1.4发布时，我们可能会取消对apiVersion: extenstions/v1beta1 的支持。

●   Kube-Proxy默认采用基于iptables的方式。如果启动kube-proxy（不管采用userspace还是iptables）时，设置了—proxy-mode参数，将采用该字段设置的值。如果不指定改字段，kube-proxy将采用Node struct的annotation：”net.beta.kubernetes.io/proxy-mode”。如果没有指定annotation，那么默认采用iptables。在iptables模式下，如果系统不满足要求（内核或Iptables版本号太低），kube-proxy才才用userspace模式。在iptables模式下，kube-proxy性能更高，并且对资源要求低。

●  可以在kubelet中设置系统保留资源来提高Node节点的稳定性。参数为 –system-reserved 和 –kube-reserved。

●  Liveness和readiness探针支持更多的参数选项，包括periodSeconds、successThreshold和failureThreshold。

●  新的ReplicaSet API（Extensions API中，目前处于Beta版）了私语ReplicationController，但是它的selector更为通用。ReplicationController的选择器只支持基于比较的选择，而ReplicaSet还支持基于集合（set-based）的选择器。

●  命令kubelet run默认产生Deployments（而不是ReplicationControllers）和Jobs（而不是Pods）对象。

●  Pods能够使用环境变量中的Secret数据，并将其作为commandline参数传递给container

●  产生Heapster的稳定版，并支持最多1000个节点：更多的监控指标、减少延迟、减少CPU和内存消耗（大约4M每个节点）。

●  允许用户指定Pod的SecurityContenxt，可以指定的参数包括：1）应用到pod的属性

User ID

是否将所有container运行在non-root下

Supplemental Groups

FSGroup－一种特殊的Supplemental Group

SELinux Options

2）如果定义了Pod的FSGroup，那么pod的系统卷（emptyDir、secret、

configMap等）和块存储设备卷（持久存储卷）都隶属于该FSGroup，pod

中的每个container在运行时也会将FSGroup设置为supplemental group。

●   如果指定了pod的SELinux选项，支持SELinux标签的存储卷将会被自动打上对应的label。

●  增加了稳定版的go client库 release_1_2，点击这里下载，点击这里查看文档。该client库的借口将会维持稳定不变。

●  增加了对Azure文件系统的支持，即可以将微软Azure文件存储卷（SMB 2.1和3.0）挂载到Pod中。点击查看示例。

实验中的新特性

1.持久存储卷的动态配置。Kubernetes中，所有的存储卷在使用之前，都需要管理员手动配置。有了这个特性以后，kubernetes支持的volume插件（GCE PD、AWS EBS、Cinder）允许自动将PersistentVolume绑定到一个未实现的PersistentVolumeClaim上。

2.并行运行多个调度起。比如多个自定义的调度器与kubernetes默认的调度器一起运行，使用pod的annotations为每个pod选择调度器。点击这里查看文档，点击这里查看设计文档。

3.节点亲和性的表现语法更具表达性，并且支持”soft”类型。目前Node Selectors（调度时将pod限定在指定的节点上）支持多种操作符（{In, NotIn, Exists, DoesNotExist, Gt, Lt}），而不限于对节点labels的精确匹配。另外，我们引入了一种新的节点选择器类型“soft”，它作为对调度器的提示。调度器会尽量但不保证满足NodeSelector的所有要求。“hard”和“soft”类型都可以采用新语法。点击这里查看文档（ “Alpha feature inKubernetes v1.2: Node Affinity“）；点击这里查看设计文档。

4.通过annotations，可以指定Pod的Hostname和Subdomain（pod.beta.kubernetes.io/hostname, pod.beta.kubernetes.io/subdomain）。如果Pod的Subdomain与同一个命名空间中的Headlessservice的名字相匹配，系统会为该Pod的FQDN创建一个DSN A记录。点击这里查看更多细节。该变更在PR #20688引入。

5.新的SchedulerExtender允许用户自定义out-of-(the-scheduler)-process调度预测，和实现优先级定义函数，比如，基于kubernetes不能直接管理的资源去调度Pods。该变更在PR #13580引入。点击这里查看示例配置和文档，该特性仍然处于Alpha版，在当前的beta或GA发布中可能不支持。

6.新增Flex Volume支持，它允许用户使用out-of-process存储卷插件，插件安装在每个节点的“/usr/libexec/kubernetes/kubelet-plugins/volume/exec/”目录下，而不是编译到二进制文件中。点击这里查看详情。

7.支持将存储提供商的存储卷挂载到pod中。希望存储提供商能够将自己的存储驱动安装到每个节点的存插件目录下。该特性仍然处于Alpha版，将来可能会改变。

8.Kubelet暴露新的metrics API（Alpha版），即 /stats/summary，以一种更为友好的方式，并且实现减少系统负载。该特性的评估在PR #22542进行。