本文超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes:Kubernetes 1.10 的第一个 Beta 版本发布

Kubernetes 社区发布了 Kubernetes 1.10 的第一个 Beta 版本,这意味着您现在可以试用一些新功能,并在正式发布之前向发布团队提供反馈。该版本目前计划于 2018 年 3 月 21 日发布,目标是包含十几个全新的 Alpha 功能以及二十多个更成熟版本的现有功能。

具体来说,Kubernetes 1.10 将包含可用于生产环境的 Kubelet TLS 引导、API 聚合和更详细的存储指标。

其中一些功能看起来很熟悉,因为它们在先前版本中处于早期阶段。每个阶段都有特定的含义

  • 稳定版:与“正式发布”相同,此阶段的功能已经过全面测试,可以在生产环境中使用。
  • 测试版:该功能已经存在足够长的时间,团队有信心将其作为稳定功能包含在内,并且任何 API 调用都不会更改。您可以使用和测试这些功能,但不建议将它们包含在关键任务生产环境中,因为它们尚未完全成熟。
  • Alpha版:新功能通常在此阶段引入。这些功能仍在探索中。API 和选项在未来版本中可能会更改,或者该功能本身可能会消失。绝对不适用于生产环境。您可以从 下载最新版本的 Kubernetes 1.10。 要向开发社区提供反馈,请在 Kubernetes 1.10 里程碑中创建一个问题,并在 3 月 9 日之前标记相应的 SIG。

以下是需要注意的内容,但您应该记住,虽然这是本文撰写时的当前计划,但始终有可能一个或多个功能可能会延迟到未来版本发布。我们将从身份验证开始。

身份验证 (SIG-Auth)

  1. Kubelet TLS 引导 (稳定版):Kubelet TLS 引导可能是 Kubernetes 1.10 版本的“头条新闻”,因为它可用于生产环境。它使新的 kubelet 能够创建证书签名请求,从而使您能够将新节点添加到集群中,而无需手动添加安全证书或使用自签名证书(自签名证书消除了拥有证书的许多好处)。
  2. Pod 安全策略移至其自己的 API 组 (测试版):Pod 安全策略的 Beta 版本允许管理员决定 Pod 可以在哪些上下文中运行。换句话说,您能够阻止非特权用户在特定命名空间中创建特权 Pod(即可以执行诸如写入文件或访问 Secret 之类的操作的 Pod)。
  3. 限制节点对 API 的访问 (测试版):同样在 Beta 版中,您现在可以将对节点上 API 的调用限制为仅限于该特定节点,并确保节点仅调用其自己的 API,而不调用其他节点上的 API。
  4. 外部 client-go 凭据提供程序 (Alpha 版):client-go 是用于访问 Kubernetes API 的 Go 语言客户端。此功能添加了添加外部凭据提供程序的功能。例如,Amazon 可能希望创建自己的身份验证器来验证与 EKS 集群的交互;此功能使他们能够在无需将身份验证器包含在 Kubernetes 代码库中的情况下执行此操作。
  5. TokenRequest API (Alpha 版):TokenRequest API 为服务帐户令牌的急需改进奠定了基础;此功能支持创建未持久化在 Secrets API 中的令牌,这些令牌针对特定受众(例如外部密钥存储),具有可配置的到期时间,并且可绑定到特定 Pod。

网络 (SIG-Network)

  1. 支持可配置的 Pod resolv.conf (测试版):您现在可以专门控制单个 Pod 的 DNS,而不是依赖于整个集群 DNS。
  2. 虽然该功能被称为 将默认 DNS 插件切换到 CoreDNS (测试版),但这实际上不是在这个周期中发生的事情。社区一直在努力将包含 dnsmasq 的 kube-dns 切换到 CoreDNS(另一个 CNCF 项目,活动部件更少),已经发布了几个版本。在 Kubernetes 1.10 中,默认值仍然是 kube-dns,但是当 CoreDNS 达到与 kube-dns 的功能奇偶校验时,团队将考虑将其设为默认值。
  3. 服务的拓扑感知路由 (Alpha 版):分发工作负载的能力是 Kubernetes 的优势之一,但到目前为止一直缺少的一件事是能够使工作负载和服务在地理位置上保持紧密联系以减少延迟。拓扑感知路由将有助于解决这个问题。(此功能可能会延迟到 Kubernetes 1.11。)
  4. 使 NodePort IP 地址可配置 (Alpha 版):不必在 Kubernetes 集群中指定 IP 地址是很棒的——直到您确实需要事先知道其中一个地址是什么,例如设置数据库复制或其他任务。您现在可以专门配置 NodePort IP 地址来解决这个问题。(此功能可能会延迟到 Kubernetes 1.11。)

Kubernetes API (SIG-API-machinery)

  1. API 聚合 (稳定版):Kubernetes 可以通过创建您自己的功能并注册您的函数来扩展其 API,以便它们可以与核心 K8s 功能一起提供服务。此功能将在 Kubernetes 1.10 中升级到“稳定版”,因此您可以在生产环境中使用它。此外,SIG-CLI 正在添加一项名为 kubectl get 和 describe 应该与扩展一起正常工作 (Alpha 版) 的功能,以使服务器(而不是客户端)返回此信息,从而获得更流畅的用户体验。
  2. 支持自托管授权 webhook (Alpha 版):早期版本的 Kubernetes 为我们带来了授权 webhook,这使得在执行命令之前自定义权限的实施成为可能。然而,这些 webhook 必须存在于某个地方,而这项新功能使它们能够托管在集群本身中。

存储 (SIG-Storage)

  1. 内部状态的详细存储指标 (稳定版):对于 Kubernetes 等分布式系统,了解系统内部随时发生的情况尤其重要,无论是出于故障排除目的还是仅仅出于自动化目的。此版本普遍提供了存储系统内部发生情况的详细指标,包括挂载和卸载时间、处于特定状态的卷数量以及孤立 Pod 目录数量等指标。您可以在此设计文档中找到完整列表
  2. 挂载命名空间传播 (测试版):此功能允许容器将卷挂载为 rslave,以便在容器内可以看到主机挂载,或者挂载为 rshared,以便容器内的任何挂载都反映在主机的挂载命名空间中。此功能的默认值为 rslave。
  3. 本地临时存储容量隔离 (测试版):如果没有此功能,节点上使用临时存储的每个 Pod 都将从同一个池中提取,并且存储分配基于“尽力而为”;换句话说,Pod 永远无法确定它有多少可用空间。此功能使 Pod 能够保留自己的存储。
  4. 树外 CSI 卷插件 (测试版):Kubernetes 1.9 宣布发布容器存储接口,它为供应商提供了一种向 Kubernetes 提供存储的标准方式。此功能使他们能够创建位于“树外”或 Kubernetes 核心之外的驱动程序。这意味着供应商可以控制他们自己的插件,而不必依赖社区进行代码审查和批准。
  5. 本地持久存储 (测试版):此功能支持使用本地连接的磁盘创建 PersistentVolume,而不仅仅是网络卷。
  6. 防止删除 Pod 使用的持久卷声明 (测试版) 和 7. 防止删除绑定到持久卷声明的持久卷 (测试版):在以前版本的 Kubernetes 中,可以删除 Pod 正在使用的存储,从而导致 Pod 出现严重问题。这些功能提供了防止这种情况发生的验证。
  7. 您的持久卷(Persistent Volume)存储空间不足了吗? 如果是,您可以使用在线调整 PV 大小支持(alpha)来扩大底层卷,而不会中断现有数据。 这也与新的FlexVolume 调整大小支持(alpha)协同工作;FlexVolume 是通过FlexVolume插件实现的供应商支持的卷。
  8. 拓扑感知卷调度(beta):此功能使您能够在 PersistentVolume 上指定拓扑约束,并让调度程序评估这些约束。 它还会延迟初始 PersistentVolumeClaim 绑定,直到 Pod 已被调度,以便卷绑定决策更智能,并考虑所有 Pod 调度约束。 目前,此功能对于本地持久卷最有用,但动态配置支持正在开发中。

节点管理 (SIG-Node)

  1. 动态 Kubelet 配置(beta):Kubernetes 可以轻松地对现有集群进行更改,例如增加副本数量或使服务可通过网络访问。 此功能使得更改 Kubernetes 本身(或者更确切地说,在后台运行 Kubernetes 的 Kubelet)成为可能,而无需关闭运行 Kubelet 的节点。
  2. CRI 验证测试套件(beta):容器运行时接口 (CRI) 使在 Kubernetes 上运行 Docker 以外的容器(例如 Rkt 容器,甚至使用 Virtlet 的虚拟机)成为可能。 此功能提供了一套验证测试,以确保这些 CRI 实现符合要求,使开发人员能够更轻松地发现问题。
  3. 可配置的 Pod 进程命名空间共享(alpha):尽管 pod 可以轻松共享 Kubernetes 命名空间,但由于 Docker 缺乏支持,进程或 PID 命名空间一直是一个比较困难的问题。 此功能使您能够在 pod 上设置一个参数,以确定容器是获得自己的操作系统进程还是共享一个进程。
  4. 在 CRI 中添加对 Windows 容器配置的支持(alpha):容器运行时接口最初是针对基于 Linux 的容器设计的,并且无法使用 CRI 实现对基于 Windows 的容器的支持。 此功能解决了这个问题,使得指定 WindowsContainerConfig 成为可能。
  5. 调试容器(alpha):如果您拥有合适的实用程序,则很容易调试容器。 但是,如果您没有呢? 此功能使您能够在容器上运行调试工具,即使这些工具未包含在原始容器镜像中。

其他变更

  1. 部署 (SIG-Cluster Lifecycle):支持进程外和树外云提供商(beta):随着 Kubernetes 的普及,越来越多的云提供商希望使其可用。 为了更轻松地做到这一点,社区正在努力提取特定于提供商的二进制文件,以便更容易地替换它们。
  2. Azure 上的 Kubernetes (SIG-Azure):Kubernetes 有一个集群自动缩放器,如果运行的工作负载太多,它会自动将节点添加到您的集群,但到目前为止,它在 Azure 上不可用。为集群自动缩放器添加 Azure 支持(alpha)功能旨在解决此问题。 与之密切相关的是,添加对 Azure 虚拟机规模集的支持(alpha)功能利用 Azure 自身的自动缩放功能来提供资源。 您可以从 下载 Kubernetes 1.10 beta 版。 同样,如果您有任何反馈(社区希望您提供反馈),请在 3 月 9 日之前向1.10 里程碑添加问题并标记相关的 SIG。
    _
    (非常感谢社区成员 Michelle Au、Jan Šafránek、Eric Chiang、Michał Nasiadka、Radosław Pieczonka、Xing Yang、Daniel Smith、sylvain boily、Leo Sunmo、Michal Masłowski、Fernando Ripoll、ayodele abejide、Brett Kochendorfer、Andrew Randall、Casey Davenport、Duffie Cooley、Bryan Venteicher、Mark Ayers、Christopher Luciano 和 Sandor Szuecs 为审查本文的准确性提供的宝贵帮助。)