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

在之前的哈希算法(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

欢迎关注译者微信公众号

欢迎关注译者微信公众号