今天，我们正式发布Kubernetes 1.15版本，这也是我们在2019年发布的第二个版本！Kubernetes 1.15包含25项增强功能，其中2项为稳定版、13项为beta测试版，另有10项为alpha测试版。本次版本的主题为：
持续性改进。项目的可持续性水平并不仅仅取决于功能。因此，我们通过多项SIG致力于提升测试覆盖率、确保各基础要素的稳定性、改善核心功能集的稳定水平，并努力在完善现有功能的同时处理尚未解决的积压性问题。
可扩展性。社区一直在要求我们进一步提升可扩展性水平，因此本次版本中包含更多与CRD以及API Machinery相关的开发成本。本次升级周期中的大多数增强功能来自SIG API Machinery及其相关领域。
关于核心 Kubernetes API 的可扩展性
与 CustomResourceDefinitions紧密相关的数据一致性与原生行为无疑是本轮开发工作中的关注重点。我们希望帮助用户顺畅完成交互，而无需考虑具体使用 CustomResource 抑或是 Golang 原生资源。通过一系列重大步骤，我们正努力在下一版本周期中发布 CRD 与 admission webhook 的通用版本。
以此为指导，我们重新审视了 CRD 当中基于 OpenAPI 的验证模式。而且从 1.15 版本开始，我们将基于所谓“结构模式”对每一种模式进行限制性检查。具体来讲，我们将强制要求 CustomResource 中的各个字段皆符合非多态及完整性要求。未来，我们将要求所有结构模式——特别是以下列出的各项新功能——皆以 NonStructural 状态的形式列出。非结构模式将在 v1beta1 API 组当中暂时继续起效，但在可预见的未来，我们将要求一切严肃的 CRD 应用皆迁移至新的结构模式。
beta：CustomResourceDefinition Webhook 转换
自 1.14 版本开始，CustomResourceDefinitions 已经能够支持多个 beta 形式的版本。而在 Kubernetes 1.15 当中，其能够进一步在不同版本之间实现即时转换，且具体方式与用户所熟悉的原生资源一样。CRD 的转换通过集群管理员部署在集群之内的 webhook 实现。此项功能已经在 Kubernetes 1.15 版本中被提升为 beta 版，这意味着 CRD 将在各类严肃 CRD 应用当中得到进一步推广。
beta：CustomResourceDefinition OpenAPI 发布
长久以来，OpenAPI 中的原生类型范式一直通过 /openapi/v2 交付，很多组件都在使用这些范式，特别是在 kubectl 实施意见验证、kubectl 解释以及基于 OpenAPI 的客户端生成器当中。
用于 CRD 的 OpenAPI 发布机制将在 Kubernetes 1.15 版本中以 beta 测试形式亮相，但目前仅适用于结构模式。
beta：CustomResourceDefinitions 删减
删减功能，是指对发送至 Kubernetes API 的对象当中的未知字段进行移除的操作。如果未在 OpenAPI 验证模式当中指定字段，则该字段即被视为未知。这项功能既关乎数据一致性，又与安全相关联。其强制要求将 CRD 开发者所指定的数据结构永久保存至 etcd 当中。这是一种原生资源行为，并将从 Kubernetes 1.15 版本的 beta 测试版开始适用于 CRD。
删减可通过 CustomResourceDefinition 中的 spec.preserveUnknownFields: false 被激活。未来即将发布的 CRD apiextensions.k8s.io/v1 变种将强制执行删减操作（但允许用户明确关闭此项功能）。
删减还要求 CRD 开发者提供完整的结构验证模式，包括顶级以及其它一切 CRD 版本。
alpha：CustomResourceDefinition默认设置
CustomResourceDefinitions 获得了默认设置支持能力。所谓默认设置，是指在 OpenAPI 验证模式当中利用 default 关键字指定的选项。对于被发送至 API 的对象，默认设置将在系统从 etcd 读取这些对象时为未指定的字段提供默认选项。
默认设置在 Kubernetes 1.15 版本中以 alpha 测试形式支持结构模式。
beta：Admission Webhook 重新定位与改进
对于需要对 Kubernetes API 进行扩展的项目而言，对 admission webhook 的变异与验证正成为一种愈发主流的处理方式。截至目前，webhook 变异只需要以字母排序方式进行一次调用。这意味着较早运行的 webhook 无法根据稍后调用的 webhook 的输出结果做出反应。在 Kubernetes 1.15 版本当中，这一情况将有所改善：
用户可以通过指定 reinvocationPolicy: IfNeeded 确保 webhook 变异至少进行一次重新调用。如果后续的 webhook 变异对对象做出修改，那么较早的 webhook 将能够对变更做出反应。
这就要求 webhook 具有类似于 idem-potent 的行为，从而应对二次调用。
目前我们还没有计划添加更多调用轮，因此 webhook 编写者仍然需要谨慎地思考已提交对象是否发生了变更。最后， webhook 验证将通过调用验证承诺不变量是否仍然不变。
我们还对 admission webhook 做出了一点小小调整，特别是 objectSelector 将排除某些来自 admission（即 webhook 服务器的任意端口，而不只是端口 443）且包含特定标签的对象。
集群生命周期的稳定性与可用性改进
对 Kubernetes 的安装、升级与配置流程进行强化，一直是 SIG 集群生命周期在本轮升级周期中的关注重点。我们针对裸机工具与生产就绪用户故事进行了 bug 修复，例如在 1.15 版本当中为高可用性用例提供更高优先级。
kubeadm 为集群生命周期的基本构建块，其将继续获得有效引导生产集群所必需的功能与稳定性提升。Kubeadm 已经进入 beta 测试阶段，实现了高可用性提升，允许用户利用已经非常熟悉的 kubeadm init 与 kubeadm join 命令对高可用性控制面板进行配置与部署。我们还专门设计出一款全新测试套件，用以确保这些功能随时间推移而始终保持稳定。
证书管理在 1.15 版本中也将变得更加强大，kubeadm 现在可以在证书（升级时）到期之前对其进行无缝轮换。
在 1.15 版本当中，kubeadm 配置文件 API 也将由 v1beta1 升级为 v1beta2。
最后，让我们庆祝 kubeadm 终于拥有了自己的徽标！
CSI 的持续改进
在 Kubernetes 1.15 版本当中，SIG 存储将继续致力于将树内存储卷插件迁移至容器存储接口（简称 CSI）。SIG 存储亦努力将 CSI 与树内结构之间的功能对应起来，包括大小调整以及内联存储卷等功能。SIG 存储还引入了一些原本 Kuebernetes 存储子系统中所不存在的全新 alpha 功能，例如存储卷克隆。
存储卷克隆允许用户在配置新存储卷时，将另一 PVC 指定为“DataSource”。如果底层存储系统支持此项功能并在其 CSI 驱动程序当中启用了“CLONE_VOLUME”功能，则新存储卷将成为源存储卷的克隆。
其它值得关注的功能更新
在 Kubernetes Core 中支持 Go 模块。
继续为云供应商的提取与代码组织需求做好准备。云服务供应商的代码已经被移动至 kubernetes/legacy-cloud-providers，旨在降低后续删除与外部使用难度。
Kubectl 的 get 与 describe 现可与各扩展成功协作。
节点现可支持第三方监控插件。
发布新的 alpha 测试版本调度框架，用于管理各调度插件。
用于在不同容器用例当中触发 hook 命令的 ExecutionHook API 现在进入 alpha 测试阶段。
继续弃用 extensions/v1beta1、apps/v1beta1 以及 apps/v1beta2 APIs；这些扩展将在 1.16 版本中被彻底淘汰！
