伴随着5000多次的提交，以及大约350位贡献者在社区以及该行业的贡献，Kubernetes现在已经到1.3版本了，已于上周发布！
Kubernetes的首次发布要追溯到两年前。这个项目的社区参与度和创新度都达到了惊人的地步，有个人参与合作，也有行业领导者（谷歌，红帽等等）来推进，并且给所有人带来生产级容器集群管理。这篇博客就是来探究Kubernetes1.3中的一些隐藏功能的。

Kubernetes1.3中的新功能

Kubernetes1.3已经把重点放到了跨集群、跨区域和跨云边界上的部署和扩容服务，运行稍大范围的工作（包括有状态服务，比如说数据库），增加规模和自动化，并且支持rkt，OCI&CNI容器标准。

PetSet

到现在为止，部署有状态应用（比如分布式数据库）已经是一个棘手的问题，但是其实也不是做不到。Jetstack在伦敦的KubeCon上演讲描述了这些挑战，同样也描述了解决方案的普通模式。

社区引进的alpha版本中的“PetSet”对象来描述这样的系统。kubernetes现在有一个功能，可以用来部署Pods，这些Pods的功能是保障网络和存储身份。它甚至还可以动态规定云端的按需存储（目前只能用在AWS EBS和GCE PD上）。

集群联盟（“Ubernetes”）

Kubernetes1.3令运行在多个集群上的服务发现成为可能，可能会让跨区域，或者跨云提供商来供容器或者外部客户使用。这个“Ubernetes”联盟可以被用来增加HA，地理分配和混合云/多云端，是令人兴奋的第一阶段，并会在1.4及之后的版本中继续开发和完善。

Rktnetes 1.0

Kubernetes创建之初就没有与特定容器运行环境绑定。Kubernetes1.3版本是第一个整合rkt运行环境的稳定版本，可以用来替换Docker（目前为止的默认运行环境）。是的，这就是rktnetes。
rkt是Core OS一个快速成熟的项目，现在已经是1.10.0版本了。它实现了应用程序容器规范，还拥有很多可以完美取代Docker的功能。比如，兼容初始化系统（如systemd，nspawn），确保有更大的隔离（使用LKVM stage1）。
在最近的博客中从CoreOS团队那里了解更多关于rktnetes的信息。

可扩展性

Kubernetes现在支持2000个节点的集群，同时还减少了端对端Pod启动时间。在这样的情况下，最后造成了可扩展性的改进的挑战就是使用基于Protocol Buffer系列化的API，而不是JSON，最后对可扩展性的做了改进。
最近的博客帖子描述了一些改进的细节，以及项目使用的Kubemark性能测试工具。
在几周或几个月后，Jetstack将会在博客中更加细致地讲述这些新的用户面对的功能，重点是，他们还会解释如何开启，如何将他们用到实践中去。比如，我会展示如何处理使用Kubernetes多区/多云。我们也会展示如何在本地更加轻松地部署分布式数据库——在我们与客户目前正在积极处理的区域内。

Kubernetes1.3隐藏的新功能

这篇帖子中除了主要的部分，我们还想要引出一些我们十分喜欢的，但是知道的人还很少的功能，但是这些功能也同样有用，同样十分重要。要注意的是，一些功能和增强功能都还是alpha版本。

Kubectl Deployment

Deployment是一个提供声明式，服务端更新Pod和ReplicaSets的API。虽然它还是个测试版功能，但是它现在已经被广泛接受和使用了，并处于活跃开发期，包括计划和进行中的新功能（具体请参阅路线部署图）。在Kubernetes1.3中，新的命令已经被添加到kubectl使管理和监控部署更新更加便利。

更新Deployment的容器镜像

以前，如果你想要在ReplicaSet中为Pods更新容器镜像，通过Deployment管理，你可以使用kubectl并且直接编辑Deployment的YAML。
新的命令kubectl设置现在允许容器镜像在单行命令行上设置。

监控deployment rollout

为了监控更新的rollout，并且验证它是否成功，这里有个新的很方便的命令：rolloutstatus。比如，nginx/nginx:1.7.9中查看nginx/nginx:1.9.1 的rollout。

垃圾回收（测试版）

Kubernetes资源常常互相依赖。比如，ReplicaSets根据指定的模板创建Pods。如果你想要删除这个ReplicaSet，你就必须要找出跟选择器匹配的Pod，串联删除匹配的Pods。

以后在1.4版本或者更高版本中，这样的串联清理会由KCM（kube controller manager）来处理。在准备阶段，1.3为API对象引入了额外的元数据域ownerReferences。对于ReplicaSet/Pods的例子，Pods包含了到它们所有者的ReplicaSet的引用。一旦ReplicaSet被删除，garbage collector也会删除这个Pod。还有一个叫做orphanDependents的配置选项，可以禁用串联删除的功能。

垃圾回收在1.3中还是一个alpha功能，所以默认状态下，它是禁用的。要打开这个功能，你需要打开kube－apiserver和KCM，还有flag——启用garbage collector。

在用户指南那里了解更多关于garbage collector的功能，要注意的是，使用的时候要自己承担风险（毕竟是测试版）。

Shell补全整合到kubectl

作为资深kubectl用户，你可能已经知道这个补全脚本，保存在/contrib/completions核心项目的文件夹中。这不仅提供了kubectl的子命令和参数，还提供了像Namespace和Pods资源的名字。
像往常一样，对于Go语言二进制文件来说，kubectl的分布通常只包括单个文件。这就令保留兼容性的完整文件更加困难了。出于这个原因，这个脚本从1.3版本起就被整合到kubectl。现在加载补全性跟添加一行代码一样简单：

Init containers（测试版）

测试版本功能init containers允许在长期运行的主要Pod容器发布之前运行某一命令。这些命令按顺序执行，只有当这些命令成功运行，主容器才会开始运行。这就允许你能够下载特定的文件到数据卷，生成应用程序的配置文件，在这个过程中不需要再重新打包到容器镜像等等。
下面是Pod运行kubectl的特定版本的例子。在每次Pod发布的时候下载这个版本。为了演示，第二个init containers包括了一个执行kubectl二进制的命令。Pod说明书包括了必要的annotation，如下图所示：

Pod一旦在状态内运行，你就可以使用下载好的kubectl二版本－kubectl exec到Pod容器中来运行kubectl；）：

在http://kubernetes.io/docs/user-guide/production-pods/#handling-initialization了解更多init containers及其使用方法。

为pods/containers使用定制配置（测试版）

docker 从1.10版本开始支持配置Seccomp策略来初步限制容器执行特权。Seccomp通过拦截系统调用来实施这个沙箱机制。这个过滤器由BPF规则来定义。

要把特定配置文件绑定到Pod上，你可以使用以下alpha annotations：
为所有Pod的容器定义一个Seccomp：
seccomp.security.alpha.kubernete.io/pod

为单个容器定义一个Seccomp文件：
container.seccomp.security.alpha.kubernetes.io/${container_name}
对注释的值，你可以使用以下内容：

如果你想要使用定制配置（前缀是localhost/），你必须把这些复制到你集群中的每一个工作节点。文件的默认文件夹是/var/lib/kubelet/seccomp.

例子：如何阻止chmod 系统调用

在这个例子中，我们创建了两个Pods。都要尝试在文件上修改权限。当Pod chmod－unconfined用Docker的默认文件运行成功，在Pod chmod－prevented中同样的命令行运行失败，因为这是它的Seccomp文件所不允许的。
要清楚的是你必须满足以下要求才可以：

Docker版本必须1.10及以上
Kubernetes的版本要1.3.0-beta.2版本及以上
要复制prevent－chmod到所有的worker节点

Seccomp Profile/var/lib/kubelet/seccomp/prevent－chmod

Pod specification seccomp－pods.yaml

create pods

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/Wq7lCDGzZJMOWLNg5fIdLA

创作场景

Kubernetes 1.3 的蚌中之珠