Kubernetes v1.15 重磅发布 | 新版本亮点 & 紧急升级说明

2019-06-20

作为上海 KubeCon 前发布的最新版本,Kubernetes v1.15 由 25 个增强功能组成:2 个进入稳定,13 个进入 Beta,10 个进入 Alpha。


新版本紧紧围绕两大主题展开——可扩展性和持续改进


可扩展性。社区一直呼吁 Kubernetes 更好地支持可扩展性,因此新版本包含更多关于 CRD 和 API Machinery 的工作,大多数增强功能来自 SIG API Machinery 及相关领域;


持续改进。项目的持续改进不仅与功能有关,许多 SIG 一直致力于提高测试覆盖率,确保基础功能的可靠、核心功能集的稳定以及现有功能的完善和清理工作。


01 围绕核心 Kubernetes API 的可扩展性


围绕 CRD 而新开发的主要目的是确保数据一致性和更贴近原生行为。用户不应去关注交互是使用 CustomResource 还是原生 Kubernetes 对象资源。如今,开发团队正努力在下一版本发布 CRD 的 GA 版本和 admission webhooks 的 GA 版本。


在这个方向上,团队重新考虑了在 CRD 中使用基于 OpenAPI 的验证模式,并且从 v1.15 开始,团队根据 structural schema 的限制检查资源定义。这基本上强制了 CustomResource 中每个字段使用非多态和完整类型。


接下来,团队将会要求具有 structual schemas,尤其是对于所有新功能,包括下面列出的功能,在  NonStructural 这个 Condition 中列出违规行为。非 structural schemas 在 v1beta1 API 组中暂时保持工作。但是,未来,所有的 CRD 应用都会被要求迁移到 structural schemas 中。


Beta:CustomResourceDefinition Webhook 转换


自 v1.14 起,团队在多个版本的 Beta 阶段中支持了 CRD。而在 Kubernetes v1.15 中,它们可以即时在不同版本之间进行转换,就像用户长期使用 Kubernetes 原生对象资源一样。CRD的转换是通过集群管理员在集群内部署的 webhook 实现的。此功能在 Kubernetes v 1.15 中被升级为 Beta 版,将 CRD 升级到一个全新的易于使用的水平。


Beta:CustomResourceDefinition OpenAPI Publishing


kube-apiserver 在 /OpenAPI/v2 上为 Kubernetes 原生类型提供 OpenAPI 规范已经有很长一段时间了,它们被许多组件使用,尤其是在 kubectl 客户端验证、kubectl 解释和基于 OpenAPI 的客户端生成器。

用于 CRD 的 OpenAPI 发布将以 Kubernetes v1.15 作为测试版提供,但仅适用于 structural schemas。


Beta:CustomResourceDefinitions Pruning


Pruning 是自动删除发送到 Kubernetes API 对象中的未知字段。如果未在 OpenAPI 验证模式中指定字段,则该字段是未知的。这是一个和数据一致性以及安全相关的功能。它强制只将 CRD 开发人员指定的数据结构持久化到 etcd 中。这是 Kubernetes 原生对象资源行为,也可用于 CRD,从 Kubernetes v1.15 开始,它进入测试阶段。


在 CustomResourceDefinition 中,通过 spec.preserveUnknownFields: false 来激活 Pruning。未来从属于 apiextensions.k8s.io/v1 的 CRD 可能会强制执行 Pruning 。


Pruning 要求 CRD 开发人员提供完整的结构验证模式,无论是顶级还是所有版本的 CRD。


Alpha:CustomResourceDefinition 默认值


CustomResourceDefinitions 设置默认值。默认值是使用 OpenAPI 验证模式中的 default 关键字指定的。在发送到 API 的对象中以及从 etcd 读取时,为未指定的字段设置默认值。


对于 structural schemas,默认值将在 Kubernetes v1.15 中以 Alpha 形式提供。


测试版:Admission Webhook 重构和改进


使用 Mutating and validating admission webhooks 来扩展 Kubernetes API 变得越来越主流。到目前为止,mutating webhooks 只按字母顺序调用过一次。早期运行的 webhook 无法对调用链中后调用的 webhook 的输出做出反应。使用 Kubernetes v1.15 的发布,情况将发生变化:


通过指定 reinvocationPolicy: IfNeeded ,mutating webhook 可以通过指定选择加入至少一次重新调用。如果后来的 webhook 修改了对象,那么早期的 webhook 将获得第二次机会。


这要求 webhooks 具有类似于 idem-potent 的行为,可以应对第二次调用。


如果没有计划添加另一轮调用,那么 webhook 作者仍然需要小心他们实现的认可对象所做的更改。最后,调用 webhook 来验证所承诺的变更已经完成。


团队允许 webhook 有更多更小的更改,特别是 objectSelector ,用于从 admission webhook 中排除具有特定标签的对象,并且在 webhook 中使用任意端口(不再限定 443 端口)。


02 集群生命周期稳定性和可用性改进


SIG Cluster Lifecycle 现周期的主要任务是使 Kubernetes 安装、升级、配置更稳健,因此在 1.15 版本中,Bug 修复和生产就绪的用户场景(如高可用性用例)被列入高优先级。


作为集群生命周期构建工具,kubeadm 高效创建生产集群的功能和稳定性将进一步提高,它已将高可用性(HA)功能列入 Beta,允许用户使用熟悉的 kubeadm init 和 kubeadm join 命令来配置和部署 HA 控制平面。官方也已设计了一个全新的测试套件,以确保这些功能随着时间推移保持稳定。


此外,证书管理在 1.15 版本中也变得更加强大,在升级时,kubeadm 现在可以自动把所有证书在其过期前进行更新。有关如何管理证书的信息,请查看 kubeadm 文档。


kubeadm 配置文件 API 现已从 v1beta1 移动到 v1beta2。最后,kubeadm 现在终于有自己的标志啦



03 CSI 持续改善


在 Kubernetes v1.15 中,SIG Storage 将继续发力,以支持将内置的卷插件迁移到 Container Storage Interface(CSI),它会继续为 CSI 增加内置的卷插件的功能特性,包括调整大小、内联卷等功能。除此之外,SIG Storage 也在 CSI 中引入了新的 Alpha 功能,如卷克隆,这在 Kubernetes 存储子系统中尚不存在。


卷克隆允许用户在配置新卷时将另一个 PVC 指定为 “DataSource”。如果底层存储系统支持此功能并在其 CSI 驱动程序中实现了“CLONE_VOLUME”功能,那么这个新卷将成为源卷的克隆。


04 紧急升级说明


API Machinery

  • k8s.io/kubernetes 和已发布的组件(如 k8s.io/client-go 和 k8s.io/api)现在包含 Go modules 文件,包括依赖版本信息。


Apps

  • Hyperkube 短别名已从源代码中删除,因为 Hyperkube docker 镜像当前创建了这些别名。


AWS

  • system:aws-cloud-provider 不再自动创建在 v1.13 中弃用的集群角色。用户使用 AWS 云提供商进行部署时,应将授予 kube-system 分区中的 aws-cloud-provider 服务帐户所需权限作为部署的一部分。


Azure

  • kubelet 现在可以在 Azure 上不带身份地运行。示例:{"vmType": "vmss", "useInstanceMetadata": true, "subscriptionId": "";
  • 多个Kubernetes集群现在可以共享同一个资源组;
  • Azure Cloud 提供商的云配置现在可以使用在 kube-system 命名空间中的 Kubernetes secret azure-cloud-provider 初始化。


CLI

  • kubectl scale job 自 v1.10 以来已弃用,已被删除;
  • kubectl exec 已弃用的 --pod/-p 已被删除。自 Kubernetes v1.12 起,该标志已被标记为已弃用。


生命周期

  • 对已弃用的 kubeadm v1alpha3 配置的支持已被完全删除;
  • kube-up.sh不再支持“centos”和“本地”提供商。


网络

  • 已弃用的标志 --conntrack-max 已从 kube-proxy 中删除。此标志的用户应切换到 --conntrack-min 和 --conntrack-max-per-core 使用;
  • 已弃用的 kube-proxy 标志 --cleanup-iptables 已被删除。


Node

  • 已废弃的 kubelet 安全控制 AllowPrivileged、HostNetworkSources、HostPIDSources 和 HostIPCSources 已被删除。执行这些限制应通过准入控制(例如 PodSecurityPolicy)来实现;
  • 已弃用的 kubelet 标志 --allow-privileged 已被删除。请从你的 kubelet 脚本或清单中删除对该标志的任何使用;
  • 现在,kubelet 仅收集节点、容器运行时、kubelet、Pod 和容器的 cgroups metrics。


存储

  • CSI 卷不再设置 Node.Status.Volumes.Attached.DevicePath 字段。你必须更新依赖于此字段的任何外部 controllers;
  • CSI alpha CRD 已被删除;
  • 因为 StorageObjectInUseProtection admission plugin 是默认启用的,所以现在默认启用的 admission 插件是 NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,StorageObjectInUseProtection。请注意,如果你之前未设置该 --admission-control 标志,则你的集群行为可能会更改(更为标准)。


05 总结


对于新版本的突出特点,THE NEWS STACK 把它们总结为:新版本更重视通过自定义资源定义功能实现可扩展性


Kubernetes v1.15 和 2018 年的四个更新版本一样,非常重视项目的稳定性和可扩展性,这一点可以从两个新的稳定功能以及自定义资源定义的大量增加(CRDs)得到证实。


例如,v1.15 新增 Go modules 支持,这允许 Kubernetes 核心开发人员以及希望构建第三方扩展的人使用最新的 Go 特性。而 kubectl 的 get 和 describe 现在可以很好地使用扩展,意味着第三方 API 扩展和 CRD 可以为 kubectl 提供自定义输出,以避免 kubectl 必须有代码来解析这些资源。


现在 Kubernetes v1.15 已经可从 GitHub 下载,您也可以使用 kubeadm 轻松安装 v1.15。


GitHub:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#kubernetes-v115-release-notes


官方博客:

https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/

结合谷歌十年容器实践,基于国内大型企业落地经验打造 的容器集群智能云平台。

立即体验