本文讲的是Kubernetes V1.3 预览-认证，伸缩和改进的安装方式【编者的话】本文为Core OS在其官方博客中发布的关于在Kubernetes 1.3的预览文章，介绍了目前Kubernetes新版本带来的新的引人入胜的特性和改进功能。本文作者为Mike Saparov，目前作为副总裁任职于CoreOS公司。
随着Kubernetes 1.3版本发布时间的临近，我们在这里分享一个关于CoreOS的文档，它可以帮助整个社区朝着这个重要的里程碑前进。Kubernetes是很多企业在早期环境中采用的并且能够持续推动其快速发展的一门技术。CoreOS团队选择专注于其在如下几个关键领域的发展，这将会进一步促进Kubernetes在世界各地的数据中心的使用：
- Kubernetes API的身份验证和授权；
- 改善了Kubernetes的安装和升级过程；
- 通过引入一个初步的etcd v3的集群元数据来优化其在scaling方面的改进；
- 最后但并不是最重要的：rktnetes，使用rkt容器运行Kubernetes的一个初始发行版本。
身份验证和授权的Kubernetes APIs
开发和运营人员喜欢Kubernetes能够仅仅通过一个API就可以为他们在集群环境中部署和管理容器。然而，在任何真实的环境中，访问控制是非常重要的。不是所有开发者都需要在CI集群上的超级用户权限。往往生产和部署需要更严格的权限控制，例如管理对单独的资源的访问，通过将用户分组在一起来简化管理，并且持续地审计用户的操作行为。Kubernetes需要一项新的验证（authN）和授权（authZ）机制以满足这些要求。
AuthN：连接的OpenID身份提供商（OpenID Connect Identity Providers）
随着1.3版本的发布，CoreOS开发了一个OpenID Connect（OIDC） AuthProvider插件作为该版本的一部分，它允许OIDC身份提供商（IdPs）代表API服务器去验证kubectl和其他客户端。该OIDC AuthProvider可用于认证Kubernetes连接到任何OIDC身份提供商（IdP）。目前在云端，流行的OIDC 身份提供商（IdPs）包括有Google Identity和Amazon Cognito。
另一个OIDC身份提供商则是CoreOS的开源项目Dex。Dex提供了一种灵活的方式来联合几个服务认证，包括现有的LDAP服务器和AD的LDAP接口。概括来讲，Kubernetes OIDC AuthProvider和Dex与企业现有的认证策略做了整合访问。
AuthZ：基于角色的访问控制（Role Based Access Control）
CoreOS的开发者们也一致努力将基于角色的控制访问（Role Based Access Control，RBAC）的工作整合进Kubernetes之中，这项功能也已经在v1.3中被引进并打上“alpha”标签了。该RBAC的实现是源于Red Hat的OepnShift项目。众所周知，基于用户角色的访问控制是大多数组织所熟悉的一种最佳实践，并且它允许管理员来规范用户根据其工作职能从而可以或者不可以做某些事。例如，属于“QA Team”角色的用户也许只有对于某一个生产集群中的节点的子集具有只读权限仅用于发布测试。
该RBAC系统建立于Kubernetes资源之上，可以让角色、权限和关系动态作用于first-class的API交互，将之前Kubernetes版本的authZ设施中的静态平面文件放置于其后面。该RBAC功能被添加进了Kubernetes 1.3中，简化了针对不同企业群体、团队或者会计制度的关于多租户环境中的创建情况。我们将在未来的某篇文章中进一步研究Kubernetes中的authN和authZ的原理以及特性。
简化Kubernetes安装和升级
Kubernetes可以被认为是整个集群中的一个操作系统，并且在有些时候，这种复杂性可以在通过安装和管理它的各种组件的过程中来展现。目前推荐的更新方法基本上是——“创建一个新的集群，迁移工作负载，销毁旧的集群”——然而这并不是理想的运营团队所需要的。
由于CoreOS是该社区的一部分，因此我们在持续的努力，使得它的这些过程变得简单，并且关于以下的改进计划将会在Kubernetes 1.3中被合并：
- 针对AWS Kubernetes上精美的安装工具的大量的升级和改进，kube-aws，为多种环境所写的手把手指南文档。
- 支持“self-hosted”Kubelet，由于该技术已经成熟了，这将支持通过Kubernetes API本身来控制Kubernetes的无缝升级。
- Kubelet现在可以在rkt的ACI（App container image）中运行了。这使得Kubelet部署新的容器镜像变得简单了。
etcd v3存储层
你可能已经知道，Kubernetes依赖于开源etcd的key-value store用于协调其群集状态。Kubernetes 1.3版本增加了对新的etcd v3后端的实验性支持。这些额外的etcd v3的设置为未来的Kubernetes可扩展性的工作打下了坚实的基础，例如运行更多的pods，更多的nodes并伴随着持续的高性能低负载特性。etcd的第三个版本同样带来了更多有用的功能集合，包括了多版本的并发控制（multi-version concurrency control，MVCC），高效率的多键交互（multiple key transactions），这将会有助于Kubernetes在未来的版本中达到甚至超越数千个节点。
在这个阶段，我们正在收集关于新的etcd的后端反馈，并且使用这些被分享的经验来推动并发布让其作为下一个生产环境的功能用于Kubernetes v1.4中。在接下来的几周中，我们将会逐步分享更多关于etcd v3的变化，从etcd v2迁移到v3，并且关于升级etcd v3和Kubernetes整合的系列的更多细节的文章。
rktnetes：在Kubernetes中的rkt容器引擎。
该项工作内容可以被简称为rktnetes，它介绍了在Kubernetes中的新的容器引擎。CoreOS的开源rkt容器runtime具有的一些有用的功能可以与Kubernetes和容器集群的整体理念保持一致，例如将pod作为控制单元，并采用了Container Network Interface（CNI）用于容器连接的简化。rktnetes可以让Kubernetes使用rkt于每个节点上取出并执行容器镜像。
在Kubernetes 1.3中，rktnetes是在“实验性”地追踪并准备在许多集群上运行。它的目标是在1.4版中变得“稳定”。在rktnetes上的工作有助于确保基本的Kubernetes界面的通用性，使得容器正常运行变得容易，这些容器都是专门用于交互的容器，并且不同的rumtime来适应某种架构、网站或者部署的特定需求。
Kubernetes 1.3及后期版本：加入确保互联网安全的使命
对于上文所强调的，我们已经通过努力的工作和结合整个社区的巧妙思维使其他一些的基本特征成为了可能，Kubernetes 1.3是一个很实在的版本，并且CoreOS团队很荣幸地能成为其中的一员。大家可以在未来的几周关注此空间和Kubernetes官方博客关于Kubernetes v1.3的官方发布的细节，并且开始试着尝试rktnetes, etcd v3 API和很多其他新的功能。 如果你在类似于Kubernetes或者etcd在生产分布式系统的前沿做工作，加入我们。如果你有兴趣了解更多关于CoreOS如何帮助企业环境的Kubernetes部署，联系我们，可以为你创建一个私人的Kubernetes培训课程或尝试Tectonic的Starter版本。
原文链接：Kubernetes v1.3 Preview - Auth, Scale, and Improved Install（翻译：薛开成）
原文发布时间为：2016-06-27
本文作者：薛开成
原文标题：Kubernetes V1.3 预览-认证，伸缩和改进的安装方式