# Kubernetes 1.11：Google 内部怎么看

原文：[Kubernetes 1.11: a look from inside Google](https://cloudplatform.googleblog.com/2018/07/kubernetes-1-11-a-look-from-inside-Google.html)

作者：[Craig Box](https://twitter.com/craigbox)

恭喜参与到近期 [Kubernetes 1.11 发布](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/)的所有人。现在 Kubernetes 核心已经稳定，在 Google，我们已经将焦点转移到上游——提高 Kubernetes 的扩展性，也就是说，要把更多组件转移到其他仓库之中。因为项目已经成熟，添加新插件已经不再意味着“给 [Tim Hockin](https://github.com/thockin) 提交一个 PR”了，而是意味着创建恰当的、具备良好规范的类似 CNI、CRI 以及 CSI 的接口了。实际上，成熟性和扩展性是帮助 [Kubernetes 成为企业平台](https://cloudplatform.googleblog.com/2018/05/Google-Kubernetes-Engine-1-10-is-generally-available-and-ready-for-the-enterprise.html)的重要助力。在三月，我们发表文章：[a look at what was new in Kubernetes 1.10](https://cloudplatform.googleblog.com/2018/03/Kubernetes-1-10-an-insider-take-on-whats-new.html)，现在来到 1.11 版本，我们来看看 Google 驱动的 Kubernetes 核心工作，以及近三个月来，我们在 Kubernetes 基础之上做出的一些创举。

## 1.11 的新特性

### 优先和抢占

Pod 的优先级和抢占能力是我们[内部调度系统](https://ai.google/research/pubs/pub43438)的主要功能之一，这一功能让我们的数据中心能在较高的资源利用率上运行。我们在 [Kubernetes 1.9](https://cloudplatform.googleblog.com/2018/02/get-the-most-out-of-Google-Kubernetes-Engine-with-Priority-and-Preemption.html) 作为 Alpha 特性引入了这一功能，现在我们增强了调度性能，并提高了对关键的系统 Pod 的支撑能力。现在我们放心的将其提升至 Beta 阶段，这表明在 Kubernetes 1.11 集群中，这一功能缺省已经开启。这是很多运行大规模集群用户所翘首以待的重要功能。

### CRD 的变化

CRD 是 Kubernetes 中最流行的扩展机制之一，1.11 中这方面提供了新的特性，对 CRD 进行了进一步的强化。CRD 现在在大量的 Kubernetes 扩展中得到了广泛应用，例如使用 Kubernetes API 调用 Spark 或 Functions。

Kubernetes 对象具备架构版本（例如 v1beta1 或者 v1）的支持，但是我们在 ETCD 数据库中只保存一个版本。如果对一个对象的某版本进行查询，服务端会进行一次转换，把对象转换为符合请求版本的对象返回给查询方。

从前 CRD 作者智能删除和重建资源来完成版本之间的迁移。在 1.11 中，可以[为 CRD 资源定义多个版本](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)。下一步会支持 CRD 的服务端转换，从在不破坏现有客户端的情况下，进行字段更名等结构变化。

### 云提供商插件

Google 在 Kubernetes 核心上持续投入，以期提高他的可持续性和对多云的移植性。[Cloud Provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) 接口让基础设施提供商在自己的平台上为用户负载提供开箱即用的体验，更方面的提供类似存储自动供给、以及外部负载均衡等基础服务。

这部分代码目前编译在 Kubernetes 核心中。Google [花了大力气](https://github.com/kubernetes/community/blob/master/keps/sig-cloud-provider/0002-cloud-controller-manager.md) 来把这些功能转移到云供应商相关的仓库之中，从而给 Kubernetes 核心减负。这也能让供应商们可以更快速的进行相关的增强和扩展，而不必受到 Kubernetes 的三个月发布周期的限制。作为这项工作的一部分，我们宣布创立了 SIG-CloudProvider，这个特别小组负责这方面的技术前瞻和监督工作。

### 1.11 中不包含的新特性

头条都不是这么写的对吧？

[服务端 Apply](https://github.com/kubernetes/features/issues/555) 没有出现在 1.11 中——一个字节都没，这个功能会把 `kubectl apply` 的逻辑从客户端移植到服务端，这样这一行为就更加清晰，并且允许更多客户端能够借助服务端的帮助进行处理，而无需借助 kubectl 作为外援工具了。

一般说来，这种功能完成之后就会提交给项目。但是如果发布已经到期，这个功能却尚未就绪，就需要大量的工作来进行恢复。Google 投入不少精力来进行 Kubernetes 的[特性分支](https://github.com/kubernetes/community/issues/566)的管理，这一举措使得长周期的功能分支和主分支可以并行前进，从而避免了发布前的混乱。这也从侧面印证了 Kubernetes 项目对项目稳定性的保障能力。

服务端 Apply 方面的工作正在他自己的[特性分支](https://github.com/kubernetes/kubernetes/tree/feature-serverside-apply)中公开进行，我们期待它准备就绪的时候加入 Kubernetes。

### Kustomize

我们思考了很多关于[应用配置的声明式管理](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md)方面的问题。一个常见的模式是 Helm（基于 Google Cloud 的 [部署管理器](https://cloud.google.com/deployment-manager/)）这样的模板方案，他需要用户学习一种不同的配置语言，而不是那种用户发起查询之后 API Server 返回的内容。模板的形式还意味着当用户下载一个 YAML 示例之后，还需要把它还原成一个模板，才能在自己的环境中应用。

[Kustomize](https://github.com/kubernetes-sigs/kustomize) 中，我们引入了一种新的定义应用的方式。Kustomize 允许用户在现有的 YAML 配置中加入层的概念，使得用户可以对 Fork 回来的仓库进行本地的变更，或者为生产和预发布环境设置不同的配置和副本数量等。

Kustomize 很适合 [GitOps 风格的工作流](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/workflows.md)，用一个通用配置作为基础，然后在各个方向使用层的方式来创建不同的变体。基础版本和层都可以被不同的团队在不同的仓库之间进行管理。

### 应用 API

应用是由多种服务和资源组成的。应用创建起来之后，并没有定义良好的方式在 Kubernetes 中定义一个应用的所有相关组件。我们希望集群用户能够在应用的角度上进行思考，允许工具和界面来定义、更新和展示一个以应用为中心的集群。

新的 [Application API](https://github.com/kubernetes-sigs/application) 提供了一个方式对 Kubernetes 组件进行聚合（例如 Service、Deployment、StatefulSet、Ingress 以及 CRD 等），并作为一个分组进行管理。

我们的朋友，包括三星、Bitnami、Heptio、Red Hat 都做出了很多贡献，我们希望有更多的贡献和反馈，来证实这一项目对社区的增值作用。

应用 API 目前是 Alpha 状态，我们希望在接下来的几周之内将其升级为 Beta 阶段，这期间我们会发布更多这方面的材料。