Kubernetes 1.19正式发布！

最新推荐文章于 2024-03-04 11:55:03 发布

Docker_

最新推荐文章于 2024-03-04 11:55:03 发布

阅读量1.7k

点赞数

文章标签： java 编程语言 kubernetes 区块链分布式

原文链接：https://mp.weixin.qq.com/s/P3RiRFL_5Si2NCgVBndsjw#rd

版权

K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它？来这里，大型互联网公司一线工程师亲授，不来虚的，直接上手实战，3天时间带你搭建K8s平台，快速学会K8s，点击下方图片可了解培训详情，点击下方图片了解详情。

我们终于正式推出了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的证书签名请求进行自动批准，因此整个集群的可管理性将大幅提升。

其他更新

以下功能迎来稳定版