美国时间 9 月 18 日,Kubernetes 迎来了 2019 年的第三个新版本 1.16。根据 Release Note 介绍,Kubernetes v1.16 由 31 个增强功能组成:8 个进入稳定,8 个进入 Beta,15 个进入 Alpha。
此次发行版源自数百名技术与非技术贡献者的共同努力,随着 Kubernetes 社区的不断发展,我们的发布过程也代表着开源软件开发协作领域的又一惊人成功。
Kubernetes 仍在不断获得新用户,快速成长本身则创造出积极反馈周期,吸引更多贡献者提交代码,最终建立起强大且极具活力的社区群体。截至目前,Kubernetes 拥有超过 32000 名个人贡献者,社区成员总量则超过 66000 人。
这里,我们整理了 Kubernetes 1.16 的亮点内容详细介绍给大家。
核心主题
Kubernetes 1.16 新版本中主要更新了以下几个核心内容。
Custom resources
:CRD 是服务于一种新的资源类型,主要是对 Kubernetes 的一种扩展机制,目前已得到了广泛的使用。自 1.7 版本以来,CRD 已经在 Beta 版中可用。在 1.16 版本中,CRD 正式步入通用可用性(GA)。Admission Webhook
:Admission Webhooks 作为 Kubernetes 的扩展机制也被广泛使用,并且自 1.9 版本以来已经在 Beta 版中可用。在 1.16 版本中,Admission Webhook 也正式步入通用可用性(GA)。Overhauled metrics
:Kubernetes 之前广泛使用一个全局 Metrics Registry 来注册需要公开的各项指标。通过实现 Metrics Registry,Metrics 可以以更透明的方式注册。而在这之前,各类稳定性要求都禁止使用 Kubernetes Metrics 。Volume Extension
:新版本中有很多与 Volume 和 Volume 修改相关的增强功能。CSI 规范中的 Volume 调整支持正在转向 Beta 版,它允许任何 CSI 规范的 Volume Plugin 都可以调整大小。
其他增强
自定义资源达到通用可用性
CRD 已经成为 Kubernetes 生态系统扩展的基础。从重新设计第三方资源原型开始,最终在 1.16 中通过 apiextensions.k8s.io/v1 实现了 GA,且整合了大量 Kubernetes 发展过程中积累的 API 相关演化经验。当转换到 GA 时,我们的首要重点是 API 客户端的数据一致性。
当您升级到 GA API 时,您会注意到一些以前可选的护栏已经成为必需的或默认的行为。比如结构模式、删除未知字段、验证和保护 *.k8.io 组对于确保 API 的使用寿命非常重要,而且现在更难以意外遗漏。
default 是 API 演化的另一个重要部分,默认情况下,CRD.v1 将启用该支持。这些以及 CRD 转换机制的组合足以构建随时间演变的稳定 API,就像 Kubernetes 本地资源在不破坏向后兼容性的情况下发生了变化一样。
CRD API 的更新不会就此结束。我们对任意子资源、API 组迁移以及更高效的序列化协议等特性都有一些想法,但是这里的变化本质上是可选的,并且与 GA API 中已有的特性互补。
利用 Windows 增强开启新的大门
Beta:增强 Windows 容器的工作负载标识选项
Active Directory Group Managed Service Account (GMSA) 支持正在逐步升级到beta版,而在 Alpha 版支持中的某些注释将被弃用。
GMSA 是一种特定类型的 Active Directory 帐户,允许 Windows 容器通过网络传输身份标识并与其他资源通信。
Windows 容器现在可以通过身份验证访问外部资源。此外,GMSA 还提供了自动密码管理、简化的服务主体名称 (SPN) 管理以及跨多个服务器将管理委托给其他管理员的能力。
Alpha:使用 kubeadm 改进设置和节点连接体验
引入对 kubeadm 的 alpha 支持,使 Kubernetes 用户能够轻松地将 Windows 工作节点加入(并重置)到现有集群,操作方式与 Linux 节点一样。
用户可以使用 kubeadm 来准备和添加 Windows 节点到群集。操作完成后,该节点将处于 Ready 状态并能够运行 Windows 容器。此外,我们还将提供一组 Windows 的特定脚本,旨在配合节点添加的其它资源与 CNI 安装需求。
Alpha:引入对容器存储接口 (CSI) 的支持
引入对树外提供者的 CSI 插件支持,使 Kubernetes 集群中的 Windows 节点能够利用持久存储功能运行基于 Windows 的工作负载。
这极大地扩展了 Windows 工作负载的存储选项,使用户能在 FlexVolume 和 in-tree 存储插件之外拥有新的选择。此功能通过主机 OS 代理实现,该代理支持代理容器在 Windows 节点上执行特权操作。
引入 Endpoint 切片
Kubernetes 1.16 版本还包含一项令人兴奋的全新 Alpha 功能:Endpoint 切片。这为 Endpoint 资源提供了一个可伸缩和可扩展的替代方案。在后端,这些资源在 Kubernetes 内部的网络路由中扮演着重要的角色。
每个网络 Endpoint 都在这些资源中受到追踪,kube-proxy 利用如上 Endpoint 生成代理规则,允许 Pod 在 Kubernetes 中如此轻松地相互通信。
提供更强大的可扩展性
Endpoint 切片的一个关键目标是为 Kubernetes 服务提供更强大的可扩展性。对于现有 Endpoint资源,单个资源必须包含表示与某项服务相关联的所有 Pod 的网络 Endpoint。
随着服务扩展至数千个 Pod,相应的 Endpoint 资源变得非常大。如果简单地对服务添加或删除一个Endpoint 可能带来可观的成本。
随着 Endpoint 资源的更新,代码中与该 Endpoint 相关的部分都需要获取一份关于该资源的完整副本。群集中的每个节点运行 kube-proxy 时,需要将副本发送到每个节点。在小范围内,这不是问题,但随着集群变大,影响会变得越来越明显。
比如,在一个拥有 5,000 个节点和 1MB Endpoint 对象的集群中,任何更新都会导致大约 5GB 的传输(这足以填满一张DVD光盘)。考虑到 Endpoint 在部署期间频繁滚动更新等事件,这将是一笔巨大的资源浪费。
使用 Endpoint 切片,服务的网络 Endpoint 可以拆分为多个资源,从而显着减少大规模更新所需的数据量。默认情况下,每个 Endpoint 切片最多包含 100 个 Endpoint。
例如,我们拥有 20,000 个网络 Endpoint,分布在拥有 5,000 个节点的集群上。利用 Endpoint 切片更新单个 Endpoint 的效率会更高,因为每个 Endpoint 仅包含网络 Endpoint 总数的一小部分。
相较于以往将大 Endpoint 对象传输至各个节点的方式,现在我们只需要传输已经变更的小型 Endpoint 切片。实际效果就是,现在更新操作的数据传输量仅相当于以往的约二百分之一。
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/b5eba0fcb85aa5bafb5eabc75e538ff3.png)
Endpoint 切片的第二个主要目标,是提供一种在各种用例中具有高度可扩展性和实用性的资源。Endpoint 切片的一个关键添加还涉及新的拓扑属性。默认情况下,这将填充 Kubernetes 中使用的现有拓扑标签,用以指示 region 与 zone 等属性。当然,这个字段也可以填充自定义标签以及更专业的用例。
Endpoint 切片还实现了更大的地址类型灵活性。每个都包含一个地址列表。多地址初始用例同时支持具有 IPv4 和 IPv6 地址的双栈 Endpoint。
Kubernetes 文档提供了有关 Endpoint 切片的更多信息。作为 Kubernetes 1.16 中的 Alpha 功能,默认情况下不会启用,但大家可以参阅说明文档了解如何在集群中启用他们。
其他值得注意的功能更新
Topology Manager 拓扑管理器是一种新的 Kubelet 组件,旨在协调资源分配决策,以提供优化的资源分配;
IPv4 / IPv6 双栈可以将 IPv4 和 IPv6 地址分配给 Pod 和 Service;
Cloud Controller Manager Migration提供更多迁移扩展选项;
继续弃用 extensions/v1beta1,apps/v1beta1 和 apps/v1beta2 API。这些扩展已在 1.16 中遭到淘汰!
来源:灵雀云
原文:http://j.mp/2Qj4WUc
题图:来自谷歌图片搜索
版权:本文版权归原作者所有
投稿:欢迎投稿,邮箱: editor@hi-linux.com
你可能还喜欢
点击下方图片即可阅读
使用 Kind 在 5 分钟内快速部署一个 Kubernetes 高可用集群