Kubernetes v1.7 即将发布

按照发布计划，Kubernetes 1.7版本将于6月28日（周三）正式发布。本次版本更新共包含26个Feature，其中Alpha版本16个，Beta版本6个，Stable版本4个。

1、Alpha Features

• Kubernetes应该更容易添加策略控制

场景：

• 作为一名Kubernetes系统管理员，需要添加一些个人的安全策略来控制集群信息的显示。
• 作为一名Kubernetes开发者，在核心代码仓库外开发某种新特性，并以一种解耦、去中心化的方式将其合并到Pod生命周期中。

我们计划为Kubernetes添加一项功能，比如向远程服务器发出请求执行检查，以及向资源对像添加一个“initializer”，允许Pod在被别的客户端发现之前执行某些操作。最后我们还希望找到一个可用来动态选择运行系统配置的方法，来选择添加或移除这些集成。

原名：Kubernetes should be able to easily integrate external policy control
链接：https://github.com/kubernetes/features/issues/209

• Deployment的哈希碰撞避免机制

在之前的哈希算法（adler）中确实存在哈希碰撞。考虑过fnv算法，更稳定但更慢。另外，对资源对象进行哈希会受到API版本的影响，同一个ReplicaSet的名字在不同的Kubernetes版本里会不一样。

处于上面的考虑，决定在Deployment的Status结构里引入新的域：collisionCount，在发生哈希碰撞时计算一个唯一的哈希值。Deployment Controller会根据PodTemplate和CollisionCount一起计算哈希值，并将计算结果用于ReplicaSet命名等。

原名：Hashing collision avoidance mechanism of Deployments
链接：https://github.com/kubernetes/features/issues/287

• StatefulSets通过Burst模式支持更快的扩展

现在的StatefulSets实现中，只有当前序Pod都运行起来才能创建后面的Pod。虽然一个Pod挂掉不会死锁，但如果是Unhealthy状态会卡住这个过程。尤其是，如果pod-0和pod-4都挂了，当前的实现会试着重启pod-0，而pod-4只有pod-0起来后才能启动。这样的表现很安全。对于另外一些有状态应用，不需要考虑已经部署的Pod的顺序，那么上面的规则会带来一些约束，造成不必要的不可用现象。所以需要指定一个注解(annotation)来与StatefulSetController进行通信，让它可以同时多个Pod。

原名：StatefulSets should support a burst mode for faster scale up / down
链接：https://github.com/kubernetes/features/issues/272

• Kubelet服务器TLS证书循环

原名：Kubelet Server TLS Certificate Rotation
链接：https://github.com/kubernetes/features/issues/267

• 在etcd里加密Secrets

现如今Secret类型的对象按照base64的编码后存储在etcd集群里，通过给这些secrets进一步加密可以让Kubernetes变得更加安全。在Secret被写入etcd和被读取之前，它的数据将被加密，加密器可以根据用户需求进行调整，并提供一个抽象的加密接口，允许接入多种加密方法。

一般而言，更愿意选择将存储etcd数据的存储卷全盘加密。这个特性的场景包括对etcd API的非法访问等。

原名：Encrypt secrets in etcd
链接：https://github.com/kubernetes/features/issues/92

• HPA状态

本特性将为HPA的Status添加用来描述某一时刻HPA状态的字段HorizontalPodAutoscalerCondition，定义为：

type HorizontalPodAutoscalerCondition struct {
    // Type声明了当前状态
    Type HorizontalPodAutoScalerConditionType
    // Status是该状态的“状态”，True，False，Unknown
    Status ConditionStatus
    // LastTransitionTime是最后一次状态迁移的时间
    LastTransitionTime metav1.Time
    // Reason是最后一次状态迁移的原因
    Reason string
    // Message是人类可读的状态迁移细节
    Message string
}

原名：HPA Status Conditions
链接：https://github.com/kubernetes/features/issues/264

• Kubelet客户端TLS证书循环

原名：Kubelet Client TLS Certificate Rotation
链接：https://github.com/kubernetes/features/issues/266

• 支持多种云服务商

为了支持可插拔式架构，会引入一个名为cloud-controller-manager的二进制程序。

这样做的好处是：

• 使对于用到kubelet/kcm时需要一个cloud config选项的云服务商的配置更加简单，比如Azure。简化启动，并且让kubeadm减少承担处理这些选项的功能。
• 按需启用。比如用户希望运行他们自己的Overlay网络，仍使用提供的L4负载均衡器。这在现在是做不到的。
• 减少Kubernetes核心仓库的负担，提高云服务商相关功能的迭代。

原名：Support out-of-process and out-of-tree cloud providers
链接：https://github.com/kubernetes/features/issues/88

• Metrics服务器

提供对于Pod和Nodes使用资源的指标，用于HPA或者调度，以及自定义指标、kubectl top命令、Kubernetes Dashboard等场景。

比较有挑战的是，计划每个pod/node收集10个指标，而Kubernetes 1.6可以支持到5000个节点，每个节点30个Pod，那么在1分钟内平均每秒要采集25000个指标，后端的etcd无法承受这么大的负载。所以引入Metrics 服务器将它们存到内存里。

原名：Metrics Server (for resource metrics API)
链接：https://github.com/kubernetes/features/issues/271

• 容器运行时接口(CRI)集成

主要为了依据容器运行时接口（CRI）将containerd集成到Kubelet里。Containerd是用来管理容器生命周期的最小实现，包括容器运行、管理和镜像分发等。这样的好处是：

• 稳定性：Containerd更新慢，相对稳定
• 兼容性：Containerd与Kubernetes需求吻合
• 性能：比Docker消耗更少的资源、减少了一层技术栈
• 基金：CNCF

原名：Containerd CRI Integration
链接：https://github.com/kubernetes/features/issues/286

• CRI验证测试套件

这是用来验证Kubelet 运行时接口的命令行工具。

原名： CRI validation test suite
链接：https://github.com/kubernetes/features/issues/292

• Scheduler扩展的方法绑定

原名：Bind method in scheduler extender
链接：https://github.com/kubernetes/features/issues/270

• 本地短时存储支持

原名：Local Ephemeral Storage Support
链接：https://github.com/kubernetes/features/issues/245

• 增强CRI

为CRI添加获取容器状态统计信息的功能。

原名：Enhance the Container Runtime Interface
链接：https://github.com/kubernetes/features/issues/290

• 本地持久存储支持

原名：Local Persistent Storage Support
链接：https://github.com/kubernetes/features/issues/121

2、Beta Features

• 自定义资源定义

将ThirdPartyResource迁移到新的API组，以配合对extensions组的弃用和添加一些新的基础特性。在extensions/v1beta1现存的TPR已被弃用，但为了便于用户迁移，仍然活跃。在理想的情况下，将在一个独立的API Server中实现TPR，然后通过API Aggregation合并到kube-apiserver中。其他更新包括对TPR命名规范等。

原名：CustomResourceDefinitions, née Third Party Resources
链接：https://github.com/kubernetes/features/issues/95

• API 聚合

这个特性的主要目的是将单体的API Server划分为多个聚合的Server。每个人都可以编写自己的Server然后将API进行聚合。集群管理员应该可以在运行时启动一些聚合服务器并暴露新的API接口，实现无缝扩展。这样做可以：

• 提高扩展性
• 缓解新API在Kubernetes核心团队代码Review时的阻塞情况
• 可以用来实验测试性的API
• 保证新的API符合Kubernetes约定

原名：API Aggregation
链接：https://github.com/kubernetes/features/issues/263

• 为PodDisruptionBudget添加MaxUnavailable

原名：PodDisruptionBudget documentation Improvements
链接：https://github.com/kubernetes/features/issues/285

• 有状态应用的升级

实现了对StatefulSet的滚动升级，以及它的Controller History，并使它的状态与DaemonSet和ReplicaSet的相一致。升级支持的策略有：

• RollingUpdate：升级改动会应用到StatefulSet的全部Pod，过程满足StatefulSet的一些约束
• Partitioned：升级改动只会应用到StatefulSet的一部分Pod，适用于Canary发布
• OnDelete：触发一个延迟表现，当Pod被手动删除时会重新创建，禁用版本追踪和按需滚动重启。

原名：StatefulSet Upgrades
链接：https://github.com/kubernetes/features/issues/188

• DaemonSet更新

实现DaemonSet的历史和回滚：

• 使用PodTemplate来存储DaemonSet历史
• 使用PodTemplateGeneration同时标识Pod和PodTemplate，因此DaemonSet Controller可以将Pod和对应的PodTemplate进行映射
• 每个PodTemlate是DaemonSet Template + Annotation + templateGeneration的快照。一个DaemonSet拥有多个PodTemplate
• DaemonSet历史的默认清理策略为2。只有没有Pods映射到PodTemplate的才会被清理。
• 在服务端实现回滚，利用RollbackConfig，就像Deployment一样

原名：DaemonSet updates
链接：https://github.com/kubernetes/features/issues/124

• 限制Node访问API

添加了一个新的Node授权模式，以及NodeRestriction管理插件，用于关联、限制Node对某些API的访问，这样它们只能修改自己的Node API对象，以及在它们之上的Pod对象，还有接收这些Pod上的Secrets和Configmaps

原名：Limit node access to API
链接：https://github.com/kubernetes/features/issues/279

3、Stable Features

• GA版本网络策略

NetworkPolicy资源更新为GA版本。

NetworkPolicy实现了对Ingress选择Pods的策略。NetworkPolicy的Spec字段定义如下：

type NetworkPolicySpec strut {
    // 为该NetworkPolicy选择对应的Pods，按照下面的IngressRule数组进行配置
    PodSelector unversioned.LabelSelector `json:"podSelector"`
    // 为选中的Pods设置规则，NetworkPolicyIngressRule描述了流量的端口和源头
    // 符合这两点的流量被认为匹配这个规则
    Ingress []NetworkPolicyIngressRule `json:"ingress,omitempty"`
}

原名：Bring Network Policy to GA
链接：https://github.com/kubernetes/features/issues/185

• GCP 为虚拟IP保留源IP

源IP保留——改变云上的负载均衡策略为健康检查，并且只对含有该服务Pods的节点响应。原来的实现里，云上的负载均衡器会把流量分发到Kubernetes的各个节点，然后等量地交给该服务的后端Pod进行处理。因为DNAT要求重定向流量到它的最终目的地，所以对每个会话返回的路径必须匹配包含相同节点的反向路径。为了实现它， 这些节点会使用SNAT，用它自己的IP替换掉源IP。这样导致服务的endpoints发现会话来自一个集群本地的IP地址，而外部的源IP就丢失了。在多数场景里，外部的IP必须保留起来。

原名：GCP Cloud Provider: Source IP preservation for Virtual IPs |
链接：https://github.com/kubernetes/features/issues/27

• 云服务商存储Metrics

Kubernetes 应该提供例如云服务商API的计数和延迟率等Metrics。在理想的情况下，希望能获取到对所有云服务商和所有Kubernetes API调用的Metrics。本特性只局限在GCE和AWS。这样做是为了:

• 集群管理员应该监控Kubernetes对云API的使用情况，以辅助排查那些破坏掉API配额的场景中的问题
• 集群管理员应该可以监控Kubernetes依赖的云API的健康情况和延迟

原名：Cloudprovider metrics for storage
链接： https://github.com/kubernetes/features/issues/182

• StorageOS 卷插件

StorageOS卷插件支持：

• 动态提供Storage Classes
• PV和PVC

原名：StorageOS Volume Plugin
链接： https://github.com/kubernetes/features/issues/190

欢迎关注译者微信公众号