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

Kubernetes：Kubernetes 1.10 的第一个 Beta 版本来了

由 Nick Chase (Mirantis) 撰写 |

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

具体来说，Kubernetes 1.10 将包含生产就绪版本的 Kubelet TLS Bootstrapping、API Aggregation 和更详细的存储指标。

其中一些特性可能看起来很熟悉，因为它们在之前的版本中曾以更早的阶段出现。每个阶段都有特定的含义：

  • stable：与“通用可用”相同，此阶段的特性已通过充分测试，可在生产环境中使用。
  • beta：此特性已存在足够长时间，团队确信该特性本身有望成为稳定特性，并且任何 API 调用不会改变。你可以使用和测试这些特性，但不建议将其包含在关键任务生产环境中，因为它们尚未完全固化。
  • alpha：新特性通常在此阶段引入。这些特性仍在探索中。API 和选项在未来版本中可能会改变，或者特性本身可能消失。绝对不适用于生产环境。你可以从 下载最新版本的 Kubernetes 1.10。要向开发社区提供反馈，请在 3 月 9 日之前在 Kubernetes 1.10 milestone 中创建 issue 并标记相应的 SIG。

以下是需要关注的内容，但请记住，尽管这是撰写本文时的当前计划，但始终存在一个或多个特性可能会推迟到未来版本发布的可能性。我们将从身份认证开始。

身份认证 (SIG-Auth)

  1. Kubelet TLS Bootstrap (stable)：Kubelet TLS bootstrapping 作为 Kubernetes 1.10 版本中可用于生产环境的“主打”特性，它为新的 kubelet 提供了创建证书签名请求的能力，使你无需手动添加安全证书或使用自签名证书（这会消除证书的许多好处）即可向集群添加新节点。
  2. Pod Security Policy 迁移到自己的 API 组 (beta)：Pod Security Policy 的 Beta 版本允许管理员决定 Pod 可以在哪些上下文环境中运行。换句话说，你有能力阻止非特权用户在特定命名空间中创建特权 Pod -- 即可以执行诸如写入文件或访问 Secrets 之类操作的 Pod。
  3. 限制节点对 API 的访问 (beta)：同样在 Beta 阶段，你现在可以限制节点对 API 的调用仅限于该特定节点，并确保节点只调用自己的 API，而不是其他节点上的 API。
  4. 外部 client-go 凭证提供程序 (alpha)：client-go 是用于访问 Kubernetes API 的 Go 语言客户端。此特性增加了添加外部凭证提供程序的能力。例如，Amazon 可能希望创建自己的 authenticator 来验证与 EKS 集群的交互；此特性使他们无需将 authenticator 包含在 Kubernetes 代码库中即可完成此操作。
  5. TokenRequest API (alpha)：TokenRequest API 为改进服务账户令牌提供了基础；此特性允许创建不持久化在 Secrets API 中、面向特定受众（如外部 secret 存储）、具有可配置过期时间以及可绑定到特定 Pod 的令牌。

网络 (SIG-Network)

  1. 支持可配置的 Pod resolv.conf (beta)：你现在可以专门控制单个 Pod 的 DNS，而无需依赖整个集群的 DNS。
  2. 尽管此特性名为 将默认 DNS 插件切换到 CoreDNS (beta)，但这在此周期中并未真正发生。社区已努力了几个版本，旨在从包含 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 Aggregation (stable)：Kubernetes 允许通过创建自己的功能并注册函数来扩展其 API，使其可以与核心 K8s 功能一起提供服务。此功能在 Kubernetes 1.10 中将升级到“stable”阶段，因此你可以在生产环境中使用它。此外，SIG-CLI 正在添加一个名为 kubectl get 和 describe 应与扩展良好配合 (alpha) 的特性，以便由服务器而非客户端返回此信息，从而提供更流畅的用户体验。
  2. 支持自托管 authorizer webhook (alpha)：早期版本的 Kubernetes 带来了 authorizer webhooks，这使得在命令执行前自定义权限强制成为可能。然而，这些 webhooks 需要驻留在某个地方，而此新特性使得在集群内部托管它们成为可能。

存储 (SIG-Storage)

  1. 内部状态的详细存储指标 (stable)：对于像 Kubernetes 这样的分布式系统，了解系统内部在任何给定时间发生的事情尤为重要，无论是出于故障排除目的还是仅为了自动化。此版本提供了存储系统内部正在发生的详细指标的通用可用性，包括诸如挂载和卸载时间、特定状态下的存储卷数量以及孤儿 Pod 目录数量等指标。你可以在此设计文档中找到完整列表。
  2. 挂载命名空间传播 (beta)：此特性允许容器将存储卷挂载为 rslave，以便在容器内部看到主机挂载点；或者挂载为 rshared，以便容器内部的任何挂载反映在主机的挂载命名空间中。此特性的默认值为 rslave。
  3. 本地临时存储容量隔离 (beta)：如果没有此特性，节点上每个使用临时存储的 Pod 都从同一个池中获取资源，并且存储分配是“尽力而为”的；换句话说，Pod 永远不知道自己确切有多少可用空间。此功能使 Pod 能够保留自己的存储。
  4. 树外 CSI 存储卷插件 (beta)：Kubernetes 1.9 宣布发布 Container Storage Interface，它为供应商提供了向 Kubernetes 提供存储的标准方式。此功能使他们能够创建位于“树外”，即在常规 Kubernetes 核心之外的驱动程序。这意味着供应商可以控制自己的插件，无需依赖社区进行代码评审和批准。
  5. 本地持久化存储 (Beta): 此功能允许使用本地附加磁盘创建 PersistentVolumes，而不仅仅是网络卷。
  6. 防止删除正在被 pod 使用的 Persistent Volume Claims (Beta) 和 7. 防止删除已绑定到 Persistent Volume Claim 的 Persistent Volume (Beta): 在 Kubernetes 之前的版本中，可以删除 pod 正在使用的存储，这给 pod 带来了巨大的问题。这些功能提供了验证，可以防止这种情况发生。
  7. Persistent Volume 存储空间不足？如果是这样，您可以使用 添加对 PV 在线扩容的支持 (Alpha) 来在不中断现有数据的情况下扩展底层卷。这也与新的 添加 FlexVolume 扩容支持 (Alpha) 一起使用；FlexVolumes 是通过 FlexVolume 插件实现的供应商支持的卷。
  8. 拓扑感知卷调度 (Beta): 此功能使您能够指定 PersistentVolumes 的拓扑约束，并由调度器评估这些约束。它还将初始 PersistentVolumeClaim 绑定延迟到 Pod 被调度之后，以便卷绑定决策更智能，并考虑所有 Pod 调度约束。目前，此功能对于本地持久卷最有用，但动态供给的支持正在开发中。

节点管理 (SIG-Node)

  1. Kubelet 动态配置 (Beta): Kubernetes 使修改现有集群变得容易，例如增加副本数或通过网络提供服务。此功能使得可以在不关闭运行 Kubelet 的节点的情况下更改 Kubernetes 本身（或者更确切地说，是运行 Kubernetes 后台工作的 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 有一个集群自动扩缩器 (cluster-autoscaler)，当您运行过多工作负载时，它会自动向集群添加节点，但到目前为止，它在 Azure 上尚不可用。将 Azure 支持添加到集群自动扩缩器 (Alpha) 功能旨在解决这个问题。与此密切相关的是，添加对 Azure 虚拟机规模集的支持 (Alpha) 功能利用 Azure 自身的自动扩缩能力来提供资源。您可以从 下载 Kubernetes 1.10 Beta 版。再次，如果您有反馈（社区希望您有），请在 3 月 9 日之前向 1.10 里程碑 添加一个 issue 并标记相关的 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 在审阅本文以确保准确性方面提供的宝贵帮助。）_