按照发布计划,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的历史和回滚:
- 使用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

欢迎关注译者微信公众号
登录后评论
立即登录 注册