专栏名称: 分布式实验室
最专业的Docker文章,最权威的Docker新闻。关注容器生态圈的发展。
目录
相关文章推荐
51好读  ›  专栏  ›  分布式实验室

Kubernetes 1.6:大规模的多用户、多负载支持

分布式实验室  · 公众号  · 后端  · 2017-03-30 07:43

正文

我们宣布Kubernetes 1.6于今天(3月28日)发布了。

在这个发布版本中,社区的焦点在于伸缩性和自动化,以便帮助你在一个集群中为多个用户部署多个负载。我们宣布,我们已经支持5000个节点的集群。我们将动态存储配备特性提升到了稳定版本。基于角色的访问控制,kubefed,kubeadm和其他一些调度特性提升到了beta版本。我们同时也添加了一些智能的默认吞吐量以便开箱即能够支持更大规模的自动化。

新特征

伸缩和联合:对于正在寻找在大规模场景下性能表现实例的大型企业用户,Kubernetes最严格的伸缩性SLO现在支持包含5千个节点(15万个Pod)的集群会是一个好消息。在CoreOS的etcd v3驱动下,集群的整个大小有1.5倍的提升,这对于需要部署如搜索或者游戏应用的用户来说是特大的好消息,在这些场景中随着业务发展从而需要更大集群的支持。

对于想要将集群伸缩到超过5千个单节点或者将节点跨多个区域或者云的用户来说,集群联合能让你将多个Kubernetes集群结合起来,并通过一个单独的API端点来使用。在这次发布版本中,kubefed命令行工具提升到了beta版,并改善了对本地部署(on-premise)集群的支持。kubefed现在能在加入集群的时候自动配置kube-dns,并能将参数传递给联合的组件。

安全和设置:关注安全的用户会发现处于Beta版本的RBAC添加了一个重要安全增强功能,它对系统组件添加了作用域更紧的默认角色。1.6版本中默认的RBAC策略会为控制面板的组件、节点和控制器赋予带有作用域的权限。RBAC能让集群管理者在每个命令空间的基础上选择性地对特定用户或者服务账号赋予对特定资源更细粒度的访问权限。需要从1.5升级到1.6的RBAC用户请参考这里(https://kubernetes.io//docs/admin/authorization/rbac.md#upgrading-from-15)的指导文档。

正在寻找在物理或者云服务器上配备一个安全集群的简单途径的用户可以使用kubeadm,它现在处于Beta阶段。kubeadm的功能已经被增强,添加了一组命令行选项和一个包含RBAC设置的基础功能集,它使用了Bootstrap Token系统和功能改善了的Certificates API。

高级调度:这次发布添加了一组强大的全面的调度构建结构,能让你更好地控制Pod的调度方式,包括在一个异构集群中将一些Pod限制在某些节点上,也包括跨失效域如节点、机架和地区来分散或者聚拢Pod的规则。

节点亲和力/反亲和力提升到了Beta阶段,能允许你根据节点的标签将Pod的调度限制在某些节点上。你可以使用内置或自定义的标签来选择特定域(zone),主机名,硬件架构,操作系统版本,专用硬件等等。这个调度的规则可以是必需满足的或倾向偏好的,可以根据你想要调度器采用哪种严格程度的强制行为来进行选择。

有一个相关的特性叫做“污点和忍耐(taints and tolerations)”,使得可以精简地表达将Pod从特定节点排除的规则。这个也处于Beta阶段的特性,能让你很方便地将一组节点供某些用户群专用,或者通过将不需要某些特殊硬件的Pod排除来保持某些拥有特殊硬件的节点只供有特殊硬件需求的Pod使用。

有时候,你会有想一并调度某些服务,或者在一个服务中一并调度某些Pod,使它们在拓扑上相邻,从而达到如优化南北间或者东西间通讯的目的。或者你想分散一个服务的Pod来达到容忍失效的目的,或者让有冲突的Pod分开,又或者保证某些节点只供某单个租户使用。Pod的亲和力和反亲和力,目前提升到了Beta阶段,使得你可以应对上述场景,你可以在任意的拓扑(节点、域等)中设置分散或聚拢Pod的硬性或者软性的需求。

最后,为了达到极致的调度灵活性,你可以让自定义的调度器和默认的Kubernetes调度器一起运行,或者替换它。每一个调度器负责一组不同的Pod。在这个发布版本中,多调度器功能处于Beta版本。

动态存储配备:需要部署有状态应用的用户将会受益于这次发布的Kubernetes中全面的存储自动化能力。

从早期开始,Kubernetes已经能根据Pod的描述要求自动地连接和断开存储、格式化磁盘或挂载和卸载卷,而且当Pod在节点之间移动的时候也能无缝地进行这些操作。另外,PersistentVolumeClaim(PVC)和PersistentVolume(PV)对象将存储的请求和特定存储的实现解耦了开来,从而让Pod的描述规范在各种云和本地部署环境中具备了可移植性。在这次发布中,StorageClass和动态卷配备已经达到了稳定的状态,可以按需创建和删除存储,消除了预先配备的需求,并以此完善了自动化的故事。

它的设计能允许集群管理者定义并且暴露集群中多种存储,每一种选项都支持各自自定义的参数。当终端用户在多个存储选项中进行选择的时候,无需再操心存储配备过程中的复杂度和细微差异。

在Kubernetes 1.6中,包含一组默认的功能,能完全将存储配备生命周期自动化,从而让你腾出空来关心你的应用。特别值得一提的是,Kubernetes现在会默认为AWS、Azure、GCP、OpenStack和VMWare vSphere预安装系统定义的StorageClass对象。这让使用这些提供源的用户无需手动设置StorageClass对象就能受益于动态存储配备功能。这是PVC对象在这些云上默认的行为的一个改变。注意默认的行为是动态配备的卷使用“删除”回收策略。这意味着一旦PVC被删除,动态配备的卷也会被自动删除,从而让用户无须执行额外的“清理”步骤。

另外,我们扩展了存储的支持,包括:

  • ScaleIO Kubernetes卷插件能让Pod无缝地访问并使用存储在ScaleIO卷上的数据。

  • Portworx Kubernetes卷插件添加了把Portworx作为Kubernetes集群存储提供源的能力。Portworx能把你的服务器容量进行蓄积(pool),将你的服务器或者云实例变成一个聚合的高可用的计算和存储节点。

  • 使用COS节点镜像来支持NFSv3、NFSv4和GlusterFS。

  • 支持用户编写的/运行的动态PV配备者。这里(http://github.com/kubernetes-incubator/external-storage)有一个Golang库和相关例子。

  • 持久性卷的中挂载选项的支持,处于Beta阶段。

容器运行时接口,etcd v3和Daemon set(守护进程集合)的更新:尽管用户可能不会直接和容器运行时或者API服务器的数据存储进行交互,它们却是Kubernetes中面向用户的功能中的基础组件。因为这个原因,社区在增加这些和其他系统组件的功能方面投入做了努力:

  • Docker-CRI实现目前处于Beta阶段,并且在kubelet中默认情况下启用。对于其他运行时的支持,如cri-o、frakti、rtk已经实现完成,并且处于Alpha阶段。

  • API服务器的默认后端存储已经进行了升级,对于新的集群默认使用etcd v3。如果你正在从1.5版本的集群升级,你需要注意保持集群的持续性,预留好数据迁移的窗口期。

  • 集群的依赖度提升了,Kubelet暴露了一个管理员可以配置的Node Allocatable特性来为系统守护进程预留计算资源。

  • Daemon set updates(守护进程组更新)能让你在一个daemon set上执行滚动升级操作。

Alpha特性:这次发布绝大部分集中于已有的功能的成熟化,然而为了路线图的目标,也同时添加了不少alpha的特性:

  • Out-of-tree云提供者的支持添加了一个新的cloud-controller-manager二进制可以用来测试新的内核之外的云提供者流程

  • Per-pod-eviction,在节点出现问题的时候,结合tolerationSeconds,能让用户调整一个Pod在一个正发生故障的节点上的停留的时间

  • Pod Injection Policy添加了一个新的API资源即PodPresent从而可以在创建时向Pod注入如Secret、Volume、Volume mount和环境变量等信息

  • 在Horizontal Pod AutoScaler中对于自定义的度量的支持改成了使用

  • 引入了多Nvidia的GPU支持,仅对于Docker运行时

这就是我们今年第一个发布版本的一些重点。全部的发布内容请访问发布说明(https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v160)。

社区

感谢我们庞大和开放的社区让这次发布成为可能。我们和社区一起,推送了差不多5000此提交,贡献者有275位。为了将我们的拥护者聚集起来,社区启动了一个新的计划叫做K8sPort(http://k8sport.org/),这是一个在线的中心,社区可以参与游戏化的挑战并且因自己的贡献得到奖励。可以在这里(http://blog.kubernetes.io/2017/03/k8sport-engaging-the-kubernetes-community.html)阅读该计划更多的细节。

发布流程

非常感谢1.6的发布团队(由CoreOS的Dan Gillespie领导)的努力让这次发布与大家见面。这个发布团队是Kubernetes社区致力于社区管理的一个佐证。Dan是第一个不是来自于Google的发布经理,他和团队的其他成员一起,在整个发布过程做出了努力,挖掘并文档化了很多内部知识,对于仍然需要特别权限的工具和流程做了很好的见解,并且提升了能善Kubernetes发布流程的相关工作的优先级。非常感谢发布团队。

用户采用

我们不断地看到Kubernetes在所有的商业领域和所有规模的公司中得到了快速采用。另外,采用的用户来自全世界,从美国田纳西州的初创公司,到中国的世界五百强公司。

  • JD.com,是中国最大的互联网公司之一,他们将部署的Openstack和Kubernetes结合起来。目前为止,已经将他们20%的应用运行在Kubernetes上,并已经达到了每天运行2万Pod的规模。可以在这里(http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html)查看更多他们的搭建细节。

  • Spire,一个位于田纳西州的初创公司,目睹了他们的公有云提供商经历了一次中断事故,但是却依然零宕机时间因为Kubernetes能将他们的负载移动到不同的域。可以在这里(http://dwz.cn/5E5f2M)查看关于他们的完整的细节。

    使用Kubernetes后,在出现问题时,完全没有惊慌的一刻,唯有注视着自动应对措施运行时内心的一种敬畏感。

  • 和社区在这里(http://dwz.cn/5E5eZ8)分享你的Kubernetes使用经历。

获取

Kubernetes 1.6可以在GitHub这里(https://github.com/kubernetes/kubernetes/releases/tag/v1.6.0)下载到,或者访问get.k8s.io下载。如果你是新用户想知道如何上手Kubernetes,可以尝试这些交互式的教程(http://kubernetes.io/docs/tutorials/kubernetes-basics/)。

推荐一个培训


【3天烧脑式Spring Cloud训练营 | 上海站】本次培训涉及:DevOps?微服务?需要解决的问题、回归、微服务那些事儿、Spring Cloud简介、服务发现:Eureka、客户端负载均衡:Ribbon、声明式的客户端:Feign、使用断路器实现微服务容错:Hystrix、微服务网关:Zuul、统一配置管理:Spring Cloud Config、微服务跟踪:Spring Cloud Sleuth、Spring Cloud常见问题总结等,点击下面图片即可查看具体培训内容。


点击阅读原文链接可直接报名。