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；）：

在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