Kubernetes v1.19 正式发布
共 5807字，需浏览 12分钟
·
2020-08-27 21:43
原文链接：https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive/
终于，我们迎来了 Kubernetes 1.19 版本，这是2020年的第二个版本，也是迄今为止最长的发布周期，总共持续20周。它由33项增强功能组成。12个增强功能进入稳定版，18个增强功能进入测试版，13个增强功能进入alpha版。
由于 COVID-19、George Floyd 抗议以及我们作为发布团队经历的其他一些全球性事件，因此1.19版本与常规版本完全不同。由于这些事件，我们决定调整我们的时间表，并让 SIG、工作组和贡献者有更多的时间来完成任务。额外的时间也让大家有时间关注 Kubernetes 项目之外的生活，并确保他们的精神状态更加良好。
贡献者是 Kubernetes 的核心，Kubernetes 的行为准则要求人们都很优秀，尽管我们的世界动荡不安，但我们从社区中看到的只是伟大和谦卑。
主要主题
将 Kubernetes 支持窗口增加到一年
长期支持（LTS）工作组在2019年初进行的一项调查显示在当前的9个月支持期内，很大一部分 Kubernetes 用户未能升级。这一点以及调查中的其他反应表明，如果将补丁支持期延长至12-14个月，则30%的用户能够将其部署保持在支持的版本上。无论用户使用的是自建版还是商业发行版，情况都是如此。因此，延长支持期将导致超过 80% 的用户使用受支持的版本，而不是现在的 50-60%。一年一度的支持期可为用户提供所需的缓冲期，并且更符合熟悉的年度规划周期。从 Kubernetes 1.19 版本开始，支持窗口将延长到一年。
储存容量追踪
传统上，Kubernetes 调度器基于这样的假设：集群中任何地方都可以使用额外的持久性存储，并具容量无限。拓扑约束解决了第一点，但到目前为止，Pod 调度仍然没有考虑剩余的存储容量可能不足以启动一个新的 pod。存储容量追踪是一个新的 Alpha 特性，它通过为 CSI 驱动程序添加一个 API 来解决这个问题，以报告存储容量，并在 Kubernetes 调度器中为 Pod 选择节点时使用该信息。该功能可作为支持本地卷和其他容量限制较大的卷类型的动态预配置的基础。
通用临时存储
Kubernetes 提供了卷插件，其生命周期与 Pod 绑定，可用作临时空间（例如内置的 emptydir 卷类型），也可以将一些数据加载到 Pod 中（例如内置的configmap 和 secret 卷类型）。新的通用暂存卷 alpha 功能允许任何现有的支持动态供应的存储驱动程序被用作 ephemeral 卷，并将该卷的生命周期绑定到 Pod。它可以用来提供不同于根磁盘的临时存储，例如持久内存或者该节点上的独立本地磁盘。支持所有用于卷供应的 StorageClass 参数。支持PersistentVolumeClaims 支持的所有功能，如存储容量跟踪、快照和还原以及卷的大小调整。
CSI Volume 健康监测
CSI 健康状况监控的 Alpha 版本随 Kubernetes 1.19一起发布。该功能使 CSI 驱动程序能够与 Kubernetes 共享来自底层存储系统的异常卷状况，以便将其作为事件报告在 PVC 或 Pod 上。此功能是 Kubernetes 进行程序检测和解决单个卷健康问题的基础。
Ingress 升级为 GA
就将 Ingress API 推向 GA 而言，API 本身在 Beta 版中已经存在了很长时间，以至于通过使用和采用（包括用户和负载均衡器/Ingress 控制器提供商），它已经达到了事实上的 GA 状态。在没有全面替代的情况下放弃它不是一个可行的方法。它显然是一个有用的 API，并且捕获了一组不平凡的用例。在这一点上，似乎更谨慎的做法是将当前的 API 声明为社区将支持的 V1 版本，同时开发 V2 Ingress API 或具有超集功能的完全不同的 API。
结构化日志
在 v1.19 之前，Kubernetes 控制平面中的日志记录无法保证日志消息和这些日志中对 Kubernetes 对象的引用有任何统一的结构。这使得对日志的解析、处理、存储、查询和分析变得困难，并迫使管理员和开发人员在大多数情况下依靠基于一些正则表达式的临时解决方案。由于这些问题，任何基于这些日志的分析解决方案都很难实现和维护。
新的 klog 方法
这个 Kubernetes 版本为 klog 库引入了新的方法，该方法提供了用于格式化日志消息的更结构化的接口。每个现有的格式化日志方法（Infof，Errorf）都通过结构化方法（InfoS，ErrorS）进行匹配。新的日志记录方法将日志消息作为第一个参数，将键值对列表作为可变参数的第二个参数。这种方法允许逐步采用结构化日志记录，而无需一次将所有 Kubernetes 转换为新的API。
Kubelet 的客户端 TLS 证书轮转
kubelet 使用私钥和证书对 kube-apiserver 进行认证。证书是在 kubelet 首次启动时通过集群外机制提供给它的。自 Kubernetes v1.8 以来，集群已经包含了一个（beta）流程，用于获取初始的证书/密钥对，并在证书到期临近时进行轮转，在 Kubernetes v1.19 中，这个功能可以稳定下来了。
在 kubelet 启动过程中，将对文件系统进行扫描，以查找由证书管理器管理的现有证书/密钥对。如果有可用的证书/密钥，则将加载它。如果没有，则 kubelet 会检查配置文件中的编码证书值或 kubeconfig 中的文件引用。如果证书是一个 bootstrap 证书，则它将用于生成密钥，创建证书签名请求并向 API服务器请求签名的证书。
当到期临近时，证书管理器会负责提供正确的证书，生成新的私钥和请求新的证书。随着 kubelet 请求证书的签名是其启动过程的一部分，并且不断地对来自 kubelet 的证书签名请求进行自动批准，以使集群变得易于管理。
其他更新
毕业至稳定
Seccomp(https://github.com/kubernetes/enhancements/issues/135)
Kubelet 客户端 TLS 证书轮转(https://github.com/kubernetes/enhancements/issues/266)
限制节点对 API 的访问(https://github.com/kubernetes/enhancements/issues/279)
重新设计事件 API(https://github.com/kubernetes/enhancements/issues/383)
Ingress 升级到 V1 版本(https://github.com/kubernetes/enhancements/issues/1453)
CertificateSigningRequest API(https://github.com/kubernetes/enhancements/issues/1513)
在没有Docker的情况下构建Kubelet(https://github.com/kubernetes/enhancements/issues/1547)
主要变化
节点拓扑管理器(https://github.com/kubernetes/enhancements/issues/693)
新的端点 API(https://github.com/kubernetes/enhancements/issues/752)
将 Kubernetes 支持窗口增加到一年(https://github.com/kubernetes/enhancements/issues/1498)
其他显着特性
运行多个调度配置文件(https://github.com/kubernetes/enhancements/issues/1451)
CertificateSigningRequest API(https://github.com/kubernetes/enhancements/issues/1513)
不变的 Secrets 和 ConfigMap(https://github.com/kubernetes/enhancements/issues/1412)
发行说明
在我们的发行说明(https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md)中查看 Kubernetes 1.19 发行版的完整详细信息。
可用性
Kubernetes 1.19可以在GitHub(https://github.com/kubernetes/kubernetes/releases/tag/v1.19.0)上下载。要开始使用 Kubernetes，请查看这些交互式教程(https://kubernetes.io/docs/tutorials/)或使用带有 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个。
生态系统更新
CNCF 刚刚结束了它的第一届虚拟 KubeCon。所有讲座均为点播，凡是注册的人都可以参加，现在还来得及!
认证 Kubernetes 安全专家(CKS)将于11月推出！CKS专注于集群与系统加固、最小化微服务漏洞和供应链的安全。
CNCF发布了第二份《云原生开发现状》，显示使用容器和无服务器技术的云原生开发者数量大规模增长。
Kubernetes.dev，一个专注于 Kubernetes 贡献者的网站已经推出。它将贡献者文档、资源和项目活动信息集中到一个中心位置。
项目速度
Kubernetes DevStats 仪表盘(https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1)说明了公司主要贡献者的贡献明细，以及一套令人印象深刻的预配置报告，从个人贡献者到拉动请求生命周期时间。如果你想从 Kubernetes 和 CNCF 社区收集数字、事实和数据，它是最好的开始。
在4月到8月的这个发布周期中，有382家不同的公司和超过2464名个人为Kubernetes 做出了贡献。查看 DevStats(https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All&from=1585692000000&to=1598392799000)，可以了解更多关于 Kubernetes 项目和社区的整体速度。
- END -
推荐阅读
点亮，服务器三年不宕机
