Kubernetes 1.19正式发布!


我们终于正式推出了Kubernetes 1.19版本,也是在2020年内推出的第二套发行版。我们经历了Kubernetes诞生以来最长的发行周期,长达20周。新版本包含33项增强功能,其中12项已经迈进稳定版本,18项处于beta阶段,另有13项处于alpha阶段。

受到COVID-19疫情、弗洛伊德抗议事件以及其他一系列全球问题的影响,此次1.19版本与常规版本存在很大差别。在事件的影响下,我们决定调整时间表,保证各特别兴趣小组、工作组以及贡献者有更多的时间以完成工作。更宽松的时间设置也让人们能够在Kubernetes项目之外更多关注生活,保证自己拥有更好的心理状态。

贡献者是Kubernetes的核心,而不能说Kubernetes是贡献者们的核心。《Kubernetes行为准则》提醒人们彼此成就。尽管如今的世界动荡不安,但我们的社区仍然保持伟大、同时保持谦卑。

核心主题

将Kubernetes支持周期增加至一年

根据2019年初由长期支持(LTS)工作组进行的一项调查来看,相当一部分Kubernetes最终用户在目前的9个月支持期内无法顺利完成升级。调查中的回应显示,如果能够将补丁程序的支持周期延长至12到14个月,将有30%的用户能够让自己的部署始终跟上新版本的升级。而且这一结论对于自构建版本乃至商业发行版似乎同样适用。在支持期延长之后,将有超过80%的用户享受到受支持版本,这一比例远优于目前的50%到60%。一整年的支持期将为最终用户提供必要的缓冲时间,而且也与大家所熟知的年度规划周期更加协调。因此从Kubernetes 1.19版本开始,支持周期将正式延长为一年。

存储容量追踪

在传统上,Kubernetes调度程序拥有一项前提性的假设,即在集群中的任意位置都可以使用附加的持久性存储,且对应无限的存储容量。虽然拓扑约束能够实现假设的前一半,但到目前为止,后半部分还没有着落——即无法在Pod调度过程中,计算剩余的存储容量是否足够启动这个新的Pod。在1.19版本中,存储容量追踪作为一项全新alpha功能亮相,通过为CSI驱动程序添加API来报告存储容量解决了这个老大难问题,同时也能够在为Pod选择节点时,将这部分信息显示在Kubernetes调度程序当中。在这项功能的基础之上,容量有限的本地存储卷及其他卷类型有望实现真正的动态预配置。

临时通用卷

Kubernetes提供多款卷插件,其生命周期与Pod相绑定,可作为临时空间使用(例如内置的emptydir卷类型)或用于将某些数据加载至Pod当中(例如内置的ConfigMap与Secret卷类型,或者所谓「CSI内联卷」)。新的临时通用卷alpha版允许将支持动态预配置的任意现有存储驱动器指定为临时卷,并将该卷的生命周期与Pod绑定起来。由此即可实现独立于root磁盘之外的临时存储,例如持久性内存或者作为节点上的独立本地磁盘。PersistentVolumeClaims所支持的全部功能也将在临时通用卷中获得支持,包括存储容量追踪、快照/还原以及卷大小调整等。

CSI卷运行状况监控

CSI运行状况监控的alpha版随此次Kubernetes 1.19共同发布。此功能让CSI驱动程序得以与Kubernetes共享来自底层存储系统的卷异常状况,并可将问题报告为PVC或Pod上的事件。此功能也将成为Kubernetes实现程序检测与解决个别卷运行状况问题的基础。

Ingress迎来GA版本

Ingress API此前长期处于beta阶段,而各类用例(既包括用户直接使用,也包括负载均衡器/Ingress控制器提供程序的间接使用)对它的依赖及实际使用也让其早已达到事实上的GA状态。事实证明,Ingress是一款重要的API,支撑起一系列强大的用例。考虑到这一点,我们决定以社区的名义将现有API认定为受官方支持的V1版本,同时将以更谨慎的心态继续开发V2 Ingress API版本(或者是将其中一部分功能超集整理为新的独立API)。

结构化日志

在1.19版本之前,Kubernetes控制平面中的日志记录功能无法保证日志消息以及日志内对于各Kubernetes对象的引用保持统一的结构。这导致日志记录的解析、处理、存储、查询及分析变得非常困难,也迫使管理员及开发人员在很大一部分情况下,只能通过自行编写的正则表达式临时解决问题。也正是这样的状况,导致Kubernetes上的各类基于日志的分析型解决方案难以实现、也难以维护。

新的klog方法

在最新版本中,Kubernetes向klog库中引入了新的方法,能够为日志消息格式提供结构化程度更高的接口。现在,所有现有日志格式化方法(Infof、Errof)都能够与结构化方法(InfoS、ErrorS)相匹配。新的日志记录方法会将日志消息作为第一参数,并将一份键值对列表作为一项可变第二参数。以此为基础,你可以逐步引入结构化日志记录,且无需一次性将整个Kubernetes指向新的API。

用于Kubelet的客户端TLS证书轮替

Kubelet使用私钥与证书向kube-apiserver进行kubelet认证。其中的证书,将在首次启动时通过集群外部机制被交付至kubelet。自Kubernetes 1.18版本起,集群开始引入一项beta过程,用于获取初始证书/密钥并在证书到期时进行轮替。在此次1.19中,这项机制正式进入稳定版本。

在kubelet的启动过程中,文件系统中的现有证书/密钥对将接受扫描,用以查找由证书管理器管理的现有证书/密钥对。如果有证书/密钥对可用,则进行加载。如果没有,则kubelet会在配置文件中检查kubeconfig内的编码证书值或文件引用。如果使用的是引导证书,则使用该证书生成密钥、创建证书签名请求并向API服务器请求一份经过签名的证书。

在证书到期后,证书管理器将负责提供正确的新证书、生成新的私钥并请求新证书。由于kubelet会在启动过程中请求证书签名,并不断对来自kubelet的证书签名请求进行自动批准,因此整个集群的可管理性将大幅提升。

其他更新

以下功能迎来稳定版

  • Seccomp
  • Kubelet客户端TLS证书轮替
  • 限制节点对API的访问
  • 重新设计Event API
  • Ingress毕业为V1稳定版
  • CertificateSigningRequest API
  • 无需Docker构建Kubelet


重大变化

  • 节点拓扑管理器
  • 新的端点API
  • 将Kubernetes支持周期延长至一年


其他重要变化

  • 运行多个Scheduling Profiles
  • CertificateSigningRequest API
  • 不可变Secrets与ConfigMaps


发布说明

关于Kubernetes 1.19发行版的完整信息,请参阅我们的发布说明

立即使用

Kubernetes 1.19目前已在GitHub上开放下载。要立即使用Kubernetes,请参阅交互式教程或使用KinD(Kubernetes in Docker)配合Docker容器“节点”运行本地Kubernetes集群,也可以使用kubeadm轻松安装1.19版本。

原文链接:Kubernetes 1.19: Accentuate the Paw-sitive

0 个评论

要回复文章请先登录注册