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

[Tenxcloud10]

主要变更（相对于 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 进行。