Kubernetes 1.19 版本终于来啦!这是2020年的第二个版本,也是迄今为止最长的发布周期,总共持续20周。它由33项加强功能组成。12个加强功能进入稳定版,18个加强功能进入测试版,13个加强功能进入alpha版。git
长期支持(LTS)工做组在2019年初进行的一项调查显示在当前的9个月支持期内,很大一部分Kubernetes 用户未能升级。这一点以及调查中的其余反应代表,若是将补丁支持期延长至12-14个月,则30%的用户可以将其部署保持在支持的版本上。不管用户使用的是自建版仍是商业发行版,状况都是如此。所以,延长支持期将致使超过 80% 的用户使用受支持的版本,而不是如今的 50-60%。一年一度的支持期可为用户提供所需的缓冲期,而且更符合熟悉的年度规划周期。从Kubernetes 1.19 版本开始,支持窗口将延长到一年。github
传统上,Kubernetes 调度器基于这样的假设:集群中任何地方均可以使用额外的持久性存储,并具容量无限。拓扑约束解决了第一点,但到目前为止,Pod 调度仍然没有考虑剩余的存储容量可能不足以启动一个新的 pod。存储容量追踪是一个新的 Alpha 特性,它经过为 CSI 驱动程序添加一个API 来解决这个问题,以报告存储容量,并在 Kubernetes 调度器中为 Pod 选择节点时使用该信息。该功能可做为支持本地卷和其余容量限制较大的卷类型的动态预配置的基础。正则表达式
Kubernetes 提供了卷插件,其生命周期与 Pod 绑定,可用做临时空间(例如内置的 emptydir 卷类型),也能够将一些数据加载到 Pod 中(例如内置的configmap 和 secret 卷类型)。新的通用暂存卷 alpha 功能容许任何现有的支持动态供应的存储驱动程序被用做 ephemeral 卷,并将该卷的生命周期绑定到 Pod。它能够用来提供不一样于根磁盘的临时存储,例如持久内存或者该节点上的独立本地磁盘。支持全部用于卷供应的 StorageClass 参数。支持 PersistentVolumeClaims 支持的全部功能,如存储容量跟踪、快照和还原以及卷的大小调整。bootstrap
CSI 健康情况监控的 Alpha 版本随 Kubernetes 1.19 一块儿发布。该功能使 CSI 驱动程序可以与Kubernetes 共享来自底层存储系统的异常卷情况,以便将其做为事件报告在 PVC 或 Pod 上。此功能是 Kubernetes 进行程序检测和解决单个卷健康问题的基础。api
就将 Ingress API 推向 GA 而言,API 自己在 Beta 版中已经存在了很长时间,以致于经过使用和采用(包括用户和负载均衡器 Ingress 控制器提供商),它已经达到了事实上的 GA 状态。在没有全面替代的状况下放弃它不是一个可行的方法。它显然是一个有用的 API,而且捕获了一组不平凡的用例。在这一点上,彷佛更谨慎的作法是将当前的 API 声明为社区将支持的 V1 版本,同时开发 V2 Ingress API 或具备超集功能的彻底不一样的 API。安全
在 v1.19 以前,Kubernetes 控制平面中的日志记录没法保证日志消息和这些日志中对 Kubernetes 对象的引用有任何统一的结构。这使得对日志的解析、处理、存储、查询和分析变得困难,并迫使管理员和开发人员在大多数状况下依靠基于一些正则表达式的临时解决方案。因为这些问题,任何基于这些日志的分析解决方案都很难实现和维护。服务器
这个 Kubernetes 版本为 klog 库引入了新的方法,该方法提供了用于格式化日志消息的更结构化的接口。每一个现有的格式化日志方法(Infof,Errorf)都经过结构化方法(InfoS,ErrorS)进行匹配。新的日志记录方法将日志消息做为第一个参数,将键值对列表做为可变参数的第二个参数。这种方法容许逐步采用结构化日志记录,而无需一次将全部 Kubernetes 转换为新的API。负载均衡
kubelet 使用私钥和证书对 kube-apiserver 进行认证。证书是在 kubelet 首次启动时经过集群外机制提供给它的。自 Kubernetes v1.8 以来,集群已经包含了一个(beta)流程,用于获取初始的证书/密钥对,并在证书到期临近时进行轮转,在 Kubernetes v1.19 中,这个功能能够稳定下来了。微服务
在 kubelet 启动过程当中,将对文件系统进行扫描,以查找由证书管理器管理的现有证书/密钥对。若是有可用的证书/密钥,则将加载它。若是没有,则 kubelet 会检查配置文件中的编码证书值或kubeconfig 中的文件引用。若是证书是一个 bootstrap 证书,则它将用于生成密钥,建立证书签名请求并向 API服务器请求签名的证书。测试
当到期临近时,证书管理器会负责提供正确的证书,生成新的私钥和请求新的证书。随着 kubelet请求证书的签名是其启动过程的一部分,而且不断地对来自 kubelet 的证书签名请求进行自动批准,以使集群变得易于管理。
如下功能迎来稳定版
重大变化
其余重要变化
发行说明
在咱们的发行说明(https://github.com/kubernetes... Kubernetes 1.19 发行版的完整详细信息。
可用性
Kubernetes 1.19能够在GitHub(https://github.com/kubernetes...。要开始使用 Kubernetes,请查看这些交互式教程(https://kubernetes.io/docs/tu... KinD(Docker中的Kubernetes)的 Docker 容器“节点”运行本地 Kubernetes 集群。您还可使用kubeadm 轻松安装1.19 。
发布团队
这个版本的发布是经过数百人的努力,他们贡献了技术和非技术内容。特别感谢 HashiCorp 的高级开发人员倡导者T aylor Dolezal 领导的发布团队。34位发布团队成员协调了发布的各个方面,从文档到测试、验证和功能完整性。
随着 Kubernetes 社区的发展,咱们的发布过程表明了开源软件开发中协做的惊人表现。Kubernetes 继续以快速的速度得到新用户。这种增加创造了一个积极的反馈循环,更多的贡献者提交代码创造了一个更有活力的生态系统。迄今为止,Kubernetes 已经有超过49,000名我的贡献者,以及一个超过3,000人的活跃社区
发布 Logo
全部人都启发了这个 Kubernetes 1.19 版本 Logo!这个版本有点像是一场马拉松比赛,也证实了当世界是一个狂野的地方,咱们能够汇集在一块儿,作难以想象的事情。
之因此选择“强调爪子-本地化”做为发布主题,是由于它捕捉了发布团队尽管世界情况良好的积极前景。1.19徽标中显示的字符表明了咱们发行团队中每一个人的个性,从emo到peppy,甚至更多!
关于设计师:汉娜贝丝·拉格洛夫(Hannabeth Lagerlof)是位于加利福尼亚州洛杉矶的视觉设计师,她在环境和图形设计领域拥有普遍的背景。汉娜贝斯(Hannabeth)创造艺术和用户体验来激发联系。您能够在Twitter上以@emanate_design的身份找到Hannabeth。
从长远来看
这次发布的内容也与加强功能方面有所不一样。传统上,咱们有3-4周的时间,从呼吁加强功能到加强功能冻结,这段时间结束后,贡献者能够确认某项功能是否会成为周期的一部分。此次发布周期很特殊,咱们有五个星期的时间来完成同一个里程碑。延长的时间给了贡献者更多的时间来计划和决定他们各自功能的毕业。
贡献者实现功能的里程碑从一般的5周延长到7周。贡献者们多了40%的时间来研究他们的功能,从而减小了疲劳,有更多的时间来思考如何实现。咱们还注意到,最后一刻的忙碌也大大减小了。这个周期的异常请求数量也减小了--6个,而上一个发布周期是14个。
生态系统更新
项目速度
Kubernetes DevStats 仪表盘(https://k8s.devstats.cncf.io/...,以及一套使人印象深入的预配置报告,从我的贡献者到拉动请求生命周期时间。若是你想从 Kubernetes 和 CNCF 社区收集数字、事实和数据,它是最好的开始。
在4月到8月的这个发布周期中,有382家不一样的公司和超过2464名我的为Kubernetes 作出了贡献。查看 DevStats(https://k8s.devstats.cncf.io/...,能够了解更多关于 Kubernetes 项目和社区的总体速度。