Kubernetes 1.26 正式发布
Kubernetes 1.26 已正式发布。此版本总共包含 37 项功能变化,其中:11 项增强功能正在升级到 stable 阶段,10 项增强功能正在升级到 beta 阶段,16 项增强功能正在进入 alpha 阶段,此外还有 12 项功能已被标记为弃用或删除。
Kubernetes v1.26 的主题是 Electrifying。团队希望通过此版本认识到 Kubernetes 赖以开发和使用的所有这些构建块的重要性,同时提高人们对考虑能源消耗足迹的重要性的认识:“环境的可持续性是任何软件解决方案的创造者和使用者不可回避的问题,而像 Kubernetes 这样的软件的环境足迹,我们相信会在未来的版本中发挥重要作用。”
主要变化:
容器镜像注册表的更改
在之前的版本中,Kubernetes 改变了容器注册表,允许将负载分散到多个 Cloud Provider 和 Region 中,这一改变减少了对单个实体的依赖,并为大量用户提供了更快的下载体验。
此版本的 Kubernetes 是第一个专门在新的registry.k8s.io
容器镜像注册表中独家发布的版本。在(现在是遗留的)k8s.gcr.io
镜像注册表中,不会发布 v1.26 的容器镜像标签,只会继续更新 v1.26 之前版本的标签。有关这一重大变化的动机、优势和影响的更多信息,可参阅 registry.k8s.io:更快、更便宜和普遍可用。
移除 CRI v1alpha2
随着容器运行时接口 (CRI) 的采用和 dockershim 在 v1.24 中的移除,CRI 是 Kubernetes 与不同容器运行时交互的唯一受支持和记录的方式。每个kubelet都要与该节点上的容器运行时协商使用哪个版本的CRI。
在之前的版本中,Kubernetes 项目建议使用 CRI 版本v1
,但 kubelet 仍然可以协商使用 CRI v1alpha2
,该版本已被弃用。
Kubernetes v1.26 放弃了对 CRI v1alpha2
的支持。这意味着Kubernetes 1.26中不支持containerd次要版本1.5和更早的版本;如果你使用containerd,你需要在将该节点升级到Kubernetes v1.26之前升级到containerd版本1.6.0或更高版本。这同样适用于任何其他只支持v1alpha2的容器运行时:如果这对你有影响,你应该联系容器运行时供应商寻求建议,或者查看他们的网站,了解如何前进的额外指示。
Storage 改进
这个版本继续添加(和删除)符合迁移目标的功能,以及对 Kubernetes 存储的其他改进。
- Azure File 和 vSphere 的 CSI 迁移升级到 stable
- Delegate FSGroup to CSI Driver 升级到 stable
- In-tree GlusterFS 驱动程序删除
- In-tree OpenStack Cinder 驱动程序删除
Signing Kubernetes 发布工件升级到 beta
该功能在 Kubernetes v1.24 中引入,是提高 Kubernetes 发布过程安全性的重要里程碑。所有发布的工件都使用 cosign 进行了无密钥签名,二进制工件和图像都可以得到验证。
对 Windows 特权容器的支持升级到 stable
特权容器支持允许容器以类似于直接在主机上运行的进程的权限运行。在 Windows 节点中支持此功能,称为 HostProcess containers,现在将升级为 Stable,实现从特权容器访问主机资源(包括网络资源)。
更多详情可查看官方公告。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Linux 6.1 正式发布,带有 MGLRU、初始 Rust 支持
Linus Torvalds 宣布 Linux 6.1 内核系列正式发布! Linux 6.1 内核系列集成了改进的页面回收代码的多代 LRU (MGLRU) 、初始的 Rust 语言支持(仍在构建中)、新的 AMD 平台管理框架、各种开源图形驱动程序改进、Btrfs 性能优化、Kernel Memory Sanitizer、Maple Tree 数据结构的引入以及许多其他硬件驱动程序工作。 有关每项Linux 6.1新功能的细节,请查看咱们 OSC 对应的报道: 初始的 Rust 基础设施已被合并到 Linux 6.1 Linux 6.1 内核合并面向 LoongArch 架构的 CPU 特性 Linux 6.1 将迎来 MGLRU 和 Maple Tree 支持 Linux 6.1 迎来 Btrfs 异步缓冲写入补丁,吞吐量翻倍 Linux 6.1 引入新功能,更容易辨认出故障的 CPU Linux 6.1 引入 VirtIO 块“安全擦除”、vDPA 功能配置 Linux 6.1 Perf 新增 AMD CPU 内存报告和 Cache-To-Cache 功能 此外,公告中并没有提...
- 下一篇
每日一博 | 跨机房 ES 同步实战
作者:谢泽华 背景 众所周知单个机房在出现不可抗拒的问题(如断电、断网等因素)时,会导致无法正常提供服务,会对业务造成潜在的损失。所以在协同办公领域,一种可以基于同城或异地多活机制的高可用设计,在保障数据一致性的同时,能够最大程度降低由于机房的仅单点可用所导致的潜在高可用问题,最大程度上保障业务的用户体验,降低单点问题对业务造成的潜在损失显得尤为重要。 同城双活,对于生产的高可用保障,重大的意义和价值是不可言喻的。表面上同城双活只是简单的部署了一套生产环境而已,但是在架构上,这个改变的影响是巨大的,无状态应用的高可用管理、请求流量的管理、版本发布的管理、网络架构的管理等,其提升的架构复杂度巨大。 结合真实的协同办公产品:京办(为北京市政府提供协同办公服务的综合性平台)生产环境面对的复杂的政务网络以及京办同城双活架构演进的案例,给大家介绍下京办持续改进、分阶段演进过程中的一些思考和实践经验的总结。本文仅针对ES集群在跨机房同步过程中的方案和经验进行介绍和总结。 架构 1. 部署Logstash在金山云机房上,Logstash启动多个实例(按不同的类型分类,提高同步效率),并且和金山云机房...
相关文章
文章评论
共有0条评论来说两句吧...