Kubernetes 1.3 中一些隐藏的功能

伴随着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；）：

在连接里了解更多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

原文连接