LOADING

Follow me

【转载】Kubernetes 1.6 正式发布:大规模处理多用户多工作负载!
三月 29, 2017|DockerPaaS

【转载】Kubernetes 1.6 正式发布:大规模处理多用户多工作负载!

【转载】Kubernetes 1.6 正式发布:大规模处理多用户多工作负载!

作者简介:Aparna Sinha是谷歌Kubernetes的高级产品经理。

今天,我们很高兴地宣布发布Kubernetes 1.6。

Kubernetes社区将该版本的重心放在了规模和自动化上,帮助你们将多种工作负载部署到一个集群上的多个用户。我们宣布,支持5000个节点的集群。动态存储配置成为稳定版,基于角色的访问控制(RBAC)、kubefed、kubeadm以及几项调度功能成为beta测试版。我们还全面增添了智能默认值,从而在默认情况下提高了自动化程度。

有何新颖之处?


规模和联合:追求大规模性能的大企业用户会高兴地知道,Kubernetes严格的可扩展性服务级别目标(SLO)现在支持5000个节点(150000个pod)的集群。如果你在部署搜索或游戏之类的应用(规模扩大后可能要使用更庞大的集群),总的集群规模加大150%是个好消息,这得益于CoreOS推出了新版本的etcd v3。

如果用户想要扩大到比5000个节点更多的环境,或者散布于多个地区或多个云,联合(federation)让你可以结合多个Kubernetes集群,并通过单一的API端点来处理它们。在这个版本中,kubefed命令行实用工具成为了beta测试版,改进了支持本地集群的功能。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的规则。

节点亲和性/反亲和性(node affinity/anti-affinity):该功能现是beta测试版,让你可以限制pod,以便基于节点标签,只在某些节点上进行调度。使用内置或自定义的节点标签来选择特定的区域、主机名称、硬件架构、操作系统版本和专用硬件等。可能需要或优选调度规则,这取决于你希望调度程序执行这些规则有多严格。

一项相关的功能名为taints和tolerations,有了这种机制,就可以紧凑地表示将pod排除在某些节点之外的规则。这项功能现在也是beta测试版,比如说它让用户很容易将一组组节点专门分配给一组组特定的用户,或者让拥有特殊硬件的节点可以被需要该特殊硬件的pod使用,只需将不需要特殊硬件的pod排除在外。

有时候,你想要共同调度服务、服务里面的pod,或者从拓扑结构上来看彼此靠近的pod,比如说为了优化南北通信或东西通信。或者你想要分布服务的pod,以实现故障容错,或者让对立的pod分离开来,或者确保独自租用节点。pod亲和性与反亲和性现在是beta测试版,它就能够支持这类使用场合,因为让你可以设置严格或宽松的要求,以便相对任意拓扑结构(节点和区域等)里面的其他pod,分布和包装pod。

最后,为了获得最高的调度灵活性,可以与默认的Kubernetes调度程序一起运行自己的一个或多个自定义调度程序,也可以用自定义调度程序取代Kubernetes调度程序。每个调度程序负责几组不同的pod。在这个版本中,多个调度程序是beta测试版。

动态存储配置:如果用户部署了有状态的应用程序(stateful application),将得益于Kubernetes的这个版本中全面的存储自动化功能。

自一开始,Kubernetes就能够自动连接和拆卸存储资源、格式化磁盘、按照pod的规格挂载和卸载卷,而且在pod在节点之间移动的过程中,无缝地执行这类操作。此外,PersistentVolumeClaim(PVC)和PersistentVolume(PV)对象将存储请求与特定的存储实现分离开来,因而让pod规格可以跨一系列广泛的云和本地环境来移植。在这个版本中,StorageClass和动态卷配置已被提升为稳定版,可按照需要创建和删除存储资源,不需要预先配置,从而真正实现了自动化。

这种设计让集群管理员可以定义和公布一个集群里面多种形式的存储系统,每种存储系统都有一组自定义参数。最终用户不用再为资源配置方面的复杂性和微妙细节而操心,同时仍可以从多种存储方案中进行选择。

在版本1.6中,Kubernetes随带一组内置默认值,使存储配置生命周期完全自动化,让你得以一心开发应用程序。具体来说,Kubernetes如今在默认情况下,为AWS、Azure、GCP、OpenStack和VMware vSphere预先安装了系统定义的StorageClass对象。这让在这些提供商上的Kubernetes用户获得了这个好处:不必手动安装和设置StorageClass对象,就能实现存储动态配置。这是这些云上的PVC对象的默认行为出现的变化。请注意:默认行为是,动态配置的卷是使用“删除”回收策略而创建的。那意味着,一旦PVC被删除,动态配置的卷就自动被删除,那样用户没必要完成多余的步骤:“清理”。

此外,我们扩大了总体上支持的存储的范围,包括如下:

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

  • Portworx Kubernetes卷插件增添了这项功能:使用Portworx,作为Kubernetes集群的存储提供者。Portworx将服务器容量汇集起来,把你的服务器或云实例变成融合的、高可用性的计算和存储节点。

  • 支持使用COS节点镜像的集群上的NFSv3、NFSv4和GlusterFS。

  • 支持用户编写/运行的动态PV配置工具。这里附有Golang库和示例(http://github.com/kubernetes-incubator/external-storage)。

  • 对持久卷中挂载选项的beta测试版支持。

容器运行时接口、etcd v3和守护进程组(daemon set)方面的更新:虽然用户可能并不直接面对容器运行时接口或API服务器数据存储,但是这些是Kubernetes中功能的用户不可忽视的基本组件。正因为如此,社区致力于扩展诸如此类的系统组件的功能。

  • Docker-CRI实现是beta测试版,默认情况下在kubelet中启用。针对其他运行时环境、cri-o、frakti和rkt的alpha测试版支持也得到了实施。

  • 针对API服务器的默认后端存储已得到了升级,可在默认情况下使用tcd v3,用于新集群。如果你从1.5集群升级过来,就要小心行事,规划好数据迁移窗口,确保连续性。

  • 节点可靠性得到了增强,因为Kubelet公布了管理员可配置的Node Allocatable功能,为系统守护进程预留了计算资源。

  • 守护进程组方面的更新让你可以对守护进程组执行滚动更新。

alpha测试版功能:然而,该版本主要专注于让功能成熟,增添了几项alpha测试版功能,以支持路线图。

  • 树外(Out-of-tree)云提供商支持增添了新的云-控制器-管理器二进制代码,可用于测试新的核心外(out-of-core)云提供商流程。

  • 防止节点故障的Per-pod-eviction结合tolerationSeconds,让用户可以调整pod在出现问题的节点里面停留的持续时间。

  • Pod Injection Policy增添了新的API资源PodPreset,以便在创建时往pod里面注入密钥、卷、卷挂载和环境变量等信息。

  • 增添了对充分利用Horizontal Pod Autoscaler中自定义度量指标(custom metrics)的支持。

  • 支持多英伟达GPU的功能随Docker运行时环境一并推出。

这些只是我们今年发布的第一个版本拥有的部分重要功能。想了解完整功能,请参阅软件发布说明(https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v160)。

社区

这个版本的问世要感谢我们庞大的开源社区。我们总共发布了大约275位作者提交的近5000次代码。为了把我们的许多代言人召集起来,社区推出了一项名为K8sPort的新计划,社区成员可以在这个网上中心参与游戏化挑战,并且为作出的贡献获得积分。想进一步了解该计划,请参阅此处(http://blog.kubernetes.io/2017/03/k8sport-engaging-the-kubernetes-community.html)。

发布过程


特别感谢1.6的发布团队,团队的领导人是CoreOS的丹·吉莱斯皮(Dan Gillespie),1.6版本的发布离不开他们所做的工作。这个发布团队充分体现了Kubernetes社区致力于社区治理。丹是第一位非谷歌发布经理,他及团队的其余成员全程参与了这个版本的开发,还要感谢1.5版本发布经理萨德·阿里(Saad Ali)所做的杰出工作,发掘和整理部落知识,表明仍需要特别许可的工具和流程,确定工作的优先级,旨在改进Kubernetes发布过程。非常感谢这支团队。

用户采用

我们继续看到Kubernetes在各行各业、大大小小的公司迅速得到采用。此外,采用者来自全球各地,从美国田纳西州的初创公司,到中国的《财富》500强企业,不一而足。

  • 京东是中国最大的互联网公司之一,它就使用Kubernetes,同时还部署了OpenStack。迄今为止,京东已将20%的应用程序迁移到了Kubernetes上,已经每天在运行20000个pod。可在此进一步了解它的架构(http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html)。

  • Spire是总部位于田纳西州的一家初创公司,它亲眼目睹了公共云提供商遇到了故障,但是停运时间为零,这归功于Kubernetes能够将其工作负载迁移到不同的区域。可在此了解整个过程(https://medium.com/spire-labs/mitigating-an-aws-instance-failure-with-the-magic-of-kubernetes-128a44d44c14)。

“有了Kubernetes,根本就没有恐慌时刻,只要在一旁看着自动化迁移神奇地进行。”

交付情况


Kubernetes 1.6可以在此下载(https://github.com/kubernetes/kubernetes/releases/tag/v1.6.0)。想开始使用Kubernetes,请使用这其中一个交互式教程(https://kubernetes.io/docs/tutorials/kubernetes-basics/)。

云头条编译、未经授权谢绝转载

相关阅读:

中高端IT圈人群,欢迎加入!

赏金制:欢迎来爆料!长期有效!

Hypernetes联合Kubernetes和OpenStack,实现多租户容器管理

OpenStack的未来:Docker工作负载在Kubernetes上运行

Kubernetes 为何会赢得容器大战?

为什么说Kubernetes对亚马逊构成的威胁可能比谷歌云还要大?|「云头条」

Kubernetes的起源史

微软聘请谷歌的首席Kubernetes工程师,加强Azure中对容器编排的支持

百度研究院在 Kubernetes 上跑深度学习框架 PaddlePaddle

Google基础设施副总裁:容器是计算的未来

京东从 OpenStack 改用 Kubernetes 的始末

Kubernetes 1.6 正式发布:大规模处理多用户多工作负载!

no comments
Share

发表评论