今天我们很高兴地宣布Kubernetes 1.5发布了。这次发布紧随KubeCon/CloudNativeCon之后。大会上用户云集，对他们如何在Kubernetes上运行应用做了精彩的分享。你们很多人曾表达过在容器中运行有状态应用的兴趣，和最终让所有应用运行在Kubernetes上的愿望。如果你一直等待在Kubernetes中尝试运行某分布式数据库，或者在寻找能让有状态和无状态应用的应用中断SLO（服务等级指标）得到保障的途径，那这次发布有你想要的解决方案。
StatefulSet（有状态集合）和PodDisruptionBudget（Pod中断预算）推进到beta版了。这些特性能简化有状态应用的部署和伸缩，并让一些集群操作，如不违背应用中断SLO的节点降级成为可能。
同时你会发现这次发布中包含各种易用性方面的提升，首先你能感受到的就是经常用到的kubectl命令行。对于那些感到要配置好一个多集群联合有诸多困难的用户，现在有一个新的kubefed命令能帮到你。同时一个呼声最高的用来配置跨多可用区的高可用Master配置脚本已经加入到了kube-up中。
你是否知道Kubernetes社区正在为支持Windows容器而努力呢？如果你的团队有.NET开发者，欢迎关注下这次发布中有关Windows容器的部分。相关工作都还处于早期的alpha阶段，我们期待得到你们的反馈。
最后，对于那些对Kubernetes内核感兴趣的用户，1.5引入了容器运行时接口，简称CRI。它提供了一个内部的接口，将容器运行时从kubelet中抽象并分离出来。这种解耦运行时的设计，能让用户自由选择最能满足自身需求的运行时。这次发布同时引入了容器化的节点一致性测试（node conformance test），能验证节点的软件是否满足加入Kubernetes集群的最小化要求。
最新功能
StatefulSet beta版（之前被叫做PetSet）能让那些需要有一致性标识符或者持久化存储的工作负载，能在Kubernetes上进行创建，伸缩，删除或者修复。你可以使用StatefulSet来简化任何有状态服务的部署，相关教程和示例能在代码仓库中找到。为了保证一个标识符永远不同一时间被两个Pod使用，Kubernetes的节点控制器不再强制删除一个不响应节点上的Pod，相反的它会等待老的Pod以如下几种方式挂掉：当kubelet报告并确认老的Pod已经生命结束而自动地挂掉；当集群管理员删除了该节点而自动地挂掉；或者当数据库管理员通过强制删除老的Pod并确认可以继续操作。现在用户若通过命令行试着强制删除Pod会收到警告。对于那些要从PetSet迁移到StatefulSet的用户，请遵循升级指南（http://kubernetes.io/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set）。
PodDisruptionBudget beta版是一个API对象，能指定一个Pod集合在任何时候处于运行状态的副本的最小数量或者最小百分比。有了PodDisruptionBudget，应用部署者可以保证那些会主动移除Pod的集群操作永远不会同一时间放倒太多Pod，从而导致数据丢失，服务中断或者无法接受的服务降级等后果。在Kubernetes 1.5中，kubectl drain命令支持PodDisruptionBudget，能允许在维护型操作中节点以安全的方式进行削减。同时这个特性很快也会在节点升级和集群自动伸缩器（在删除节点的时候）中采用。这对于那些基于quorum的应用的来说非常有用，能确保运行的副本数目永远不低于足以满足quorum的数目，或者对于一个WEB前端型应用，保证提供负载服务的副本数量永远不低于一个百分比。
Kubefed alpha版是一个新的帮助管理联合集群的命令行工具，能轻易部署新的联合控制面板，执行集群联合中的集群添加和集群删除操作。集群联合中的另外一个更新是，fedoration API新增了ConfigMap beta版、DaemonSet alpha版和deployments alpha版，能让你通过一个端点跨集群地对这些对象进行创建，更新和删除操作。
高可用Master alpha版允许在GCE上使用kube-up/kube-down脚本来创建或者删除有高可用（复制的）master的集群。能允许配置跨可用区分布式的高可用master，指定每个可用区至少有一个etcd副本，指定每个可用区至少有一个API服务器，以及配置选主式的组件如scheduler和controller-manager跨可用区分布。
Windows Server容器 alpha版本提供了对Windows Server 2016节点和调度Windows Server Container的一些起始支持。
容器运行时接口（CRI） alpha版引入了v1版本的 CRI API，支持可插拔式的容器运行时；一个试验性的docker-CRI集成已经做好了接受测试和反馈的准备。
节点一致性测试 beta版是一个容器化的测试框架，能为节点提供了系统校验和功能测试。该测试会验证节点是否满足Kubernetes的最低要求；通过了测试的节点被认定有资格加入Kubernetes。节点一致性测试可以在gcr.io/google_containers/node-test:0.2获取到，方便用户可以验证自己节点的设置。
这些我们最新发布中的一些值得重点关注的地方。完整的更新列表请查看发布日志（https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v150）。
获取方式
Kubernetes 1.5能通过GitHub（https://github.com/kubernetes/kubernetes/releases/tag/v1.5.0）上下载或者通过get.k8s.io获得。要上手Kubernetes，可以试试最新的互动式教程（http://kubernetes.io/docs/tutorials/kubernetes-basics/）。别忘了在圣诞假期之前试试1.5版本。
用户采用
从GA发布以来已经过去一年半了，Kubernetes的用户采纳情况持续超乎预期。在Kubernetes上运行生产环境工作负载的机构已经囊括了世界上最大的公司，年轻的创业公司，和介于两者之前的所有其他公司。因为Kubernetes是开放的，并能在任何地方运行，我们已经看到它被用在各种平台上：Pokémon Go（Google Cloud），Ticketmaster（AWS），SAP（OpenStack），Box（实体机），以及对上面这些环境混合搭配的混杂环境。下面是一些精选的用户示例：
-
Yahoo！ JAPAN——构建了一个自动化的工具链，简化了从代码提交到部署流程，与此同时将OpenStack运行在Kubernetes上。
-
Walmart——将会使用Kubernetes和OneOps来管理它强大的配送中心，以帮组团队提升交付速度，提升系统在线时长和优化资产利用率。
-
Monzo——是一家欧洲的创业公司，正致力构建一个移动为先的银行，正使用Kubernetes来支撑其能够应付极端的性能和一致性需求的核心业务平台。
Kubernetes生态系统
Kuberete的生态系统正在讯速的壮大，这包括微软在Azure Container Service中对Kubernetes的支持，VMWare在它的Photon Platform与Kubernetes的集成，和Canonical对于Kubernetes的商业化支持。除此之外还有已经为Kubernetes用户提供商业化服务的三十多家技术和服务合作伙伴。
CNCF最近宣布了KMSP（Kubernetes管理服务提供商）计划，为那些有帮助企业成功采用Kubernetes的服务提供商提供了一个资格预获的平台。在加深了对Kubernetes的认识和了解后，Linux基金将会和CNCF一起开发和运营Kubernetes的培训和认证项目——第一个设计的课程是Kubernetes基础（http://sep9.cn/1rcery）。
社区速度
在过去的三个月里我们看到有超过100名新的贡献者加入项目，推送了约5000次提交，从而让项目完成了新的里程碑，核心项目1000+贡献者，4000+次提交。之所以能拥有如此强大的推动力，只因采用的开放设计，对新理念持有的开放态度，以及使开放社区能对新老贡献者兼收并蓄。在此由衷感谢1.5的发布团队——来自Google的Saad Ali，来自Mirantis的Davanum Srinivas和来自CoreOS的Caleb Miles，感谢他们的辛勤劳动让1.5与大家见面。
原文链接：Kubernetes 1.5：支撑生产环境工作负载，转载请注明来源！