（译）Kubernetes 1.10 Beta 发布

（译）Kubernetes 1.10 Beta 发布

Kubernetes 社区发布了 Kubernetes 1.10 的第一个 Beta 版本，因此用户现在就可以对 1.10 中的部分新功能进行试用，在官方发布正式版本之前，可以向发布团队提交试用反馈。这次发布预计是在 2018 年 3 月 21 日，其中包含了超过一打的 Alpha 功能以及不止两打的更加成熟的特性。

Kubernetes 1.10 的众多特性中，需要强调的是：生产就绪的 Kubelet TLS Bootstrap 功能、API 聚合以及详细的存储指标。

本文提到的一些功能可能让人觉得面熟，这是因为他们在之前的版本就已经出现，随着功能的逐步成熟，我们会为他定义不同的阶段：

Stable（稳定版）：等价于“Generally available”，处于这一阶段的功能经过了完善的测试，可以用于生产环境。Beta：这类功能已经出现了一段时间，开发团队认为这类功能一定能够提升到稳定阶段，任何 API 调用都不会发生变更。可以使用和测试这类功能，但其完善程度有限，因此不建议用在生产环境的关键任务之中。Alpha：新功能从这一阶段开始，这类功能还在摸索期间。API 和配置项可能会随着版本发生变化，甚至这些功能本身也有移除的风险。很明显，不应该在生产环境中投入使用。

可以从https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md下载 Kubernetes 1.10。在 3 月 9 日之前，还可以在 Kubernetes 1.10 里程碑上提交 Issue(注 1)给开发社区，并打上合适的 SIG 标签。

下面的内容是用户更关心的，但是需要注意，这只是成文期间的计划，在发布之时可能发生变更。

首先说说认证问题。

认证（SIG-Auth）

Kubelet TLS Bootstrap（注 2） 进入稳定阶段：Kubelet TLS Bootstrap 可能是这次发布中的头条信息，这是因为这一功能可以交付生产环境进行使用了。他为新加入的 Kubelet 提供了一个创建认证签名请求的功能，这样在加入新节点的时候，就不用手工加入证书或者自行签署证书，免除了很多手工过程特有的不便之处。Pod Security Policy（Pod 安全策略）有了自己的 API 组（注 3），Pod 安全策略的 Beta 版本，让管理员来决定 Pod 运行的上下文，换个说法就是，可以禁止无权用户运行特权 Pod，可以在特定 Namespace 中进行文件访问或访问 Secret 这样的操作。限制节点的 API 访问（Beta）（注 4），现在可以把针对节点的 API 调用限制在指定节点上，这样就可以保障让节点只调用自己的 API，而不会越权访问其他节点的 API。Client-go 的外部认证提供者（alpha）(注 5)：Client-go 是用于访问 Kubernetes API 的 Go 语言客户库。这一功能提供了使用外部认证提供者的能力。例如 Amazon 可能想要创建其自有的认证体系，来给 EKS 集群的交互提供认证能力。现在就可以在不变更 Kubernetes 代码的情况下完成这一任务了。TokenRequest API（注 6），这个 API 让 Service Account Token 有了一个上升空间；这一功能使得 Token 的创建过程不再是 Secret API 中的持久化过程，其目标是特定场景的应用（例如外部 Secret 存储），具备可配置的有效期，并可以绑定到特定 Pod。

网络（SIG-Network）

支持对 Pod 中resolv.conf的配置（注 7）：现在可以在 单个 Pod 中绕开集群 DNS 进行 DNS 控制。虽然这一功能被称为缺省 DNS 插件切换为 CoreDNS（Beta）（注 8），但是在这一阶段内还不会发生。社区正在投入工作，进行 kube-dns（也包括 dnsmasq）到 CoreDNS 的迁移，CoreDNS 是 CNCF 的另外一个项目，这一项目已经运行了一段时间，结构上更为紧凑。在 Kubernetes 1.10 中的缺省 DNS 仍然会是 kube-dns，但是当 CoreDNS 完成和 Kube-DNS 的匹配，团队就会尝试令其作为缺省 DNS 服务器。拓扑感知的服务路由(Alpha)（注 9），Kubernetes 的长处就是分布工作负载的能力。但是目前为止，都缺少一个功能，让工作负载和服务能够在地理上尽量靠近以降低延迟。拓扑感知的路由功能就有效的改善了这一状况（这一功能会延迟，在 1.11 版本中发布）。可以对 NodePort 的 IP 地址进行配置（注 10）：在 Kubernetes 集群中，不必指定 IP，这种情况多数时候是个好事——除非你要提前获得地址。现在用户就可以配置 NodePort 的 IP 地址了（这一功能也会延迟到 1.11 版本中）

Kubernetes API（SIG-API-machinery）

API 聚合（Stable）（注 11）：Kubernetes 中，用户可以实现自己的功能，然后进行注册，之后就可以用类似核心 K8S 功能的方式进行使用了。这一能力在 Kubernetes 1.11 中升级到了 Stable 阶段，这意味着可以进入生产环境的应用之中了。另外 SIG-CLI 正在加入一个功能，让 服务端对 Kubectl 的 Get 和 Describe 操作返回扩展信息（Alpha）（注 12），以提供更好的用户体验。支持自运行的授权 Webhook（Alpha）（注 13）：前面的 Kubernetes 中提供了授权 Webhook 功能，这一功能可以在命令执行之前对权限的应用进行定制。然而这些功能的实现必须有个运行环境，这个新功能可以在集群之中运行 Webhook 进程。

存储（SIG-Storage）

存储指标提供了更多的内部状态（Stable）（注 14）：对于 Kubernetes 这样的分布式系统来说，获得系统在任何时间的内部情况，不论是对于除错，还是自动化工作，都是十分必要的。这一版本提供了稳定的对于存储系统的内部信息的输出，例如加载和卸载的时间、处于某一状态的存储卷数量、孤立状态的 Pod 目录等。设计文档（注 15）中包含了完整的指标列表。挂载名称空间的挂载传播（Beta）（注 16） 让容器以 rslave模式进行挂载，这样在在容器中能够看到主挂载。还可以用rshared进行挂载，这样容器内的挂载就反映了主机的挂载命名空间。这一功能的缺省值是rslave。本地临时存储容量隔离（Beta）（注 17），没有这种支持的时候，节点上每个使用临时存储的 Pod 都是从同一个池子进行拉取的，并分配为best-effort模式；换句话说，Pod 永远不会知道到底有多少可用空间。这个功能让 Pod 有办法给自己的存储进行空间保留。外置的 CSI 卷插件（Beta）（注 18）：Kubernetes 1.9 宣布了 CSI，这一标准为厂商定义了向 Kubernetes 集群提供存储的具体方式。这一功能让驱动过程外置成为一种可能。厂商可以不必依赖社区的审查和批准来自行控制自己的插件。本地持久卷（Beta）（注 19）：可以在本地盘上创建PersistantVolume ，不仅限于网络卷。阻止删除被 Pod 使用的 PVC（注 20），阻止删除绑定在 PVC 上的 PV（注 21）：Kubernetes 的过去版本中，可以删除被 Pod 使用的存储，然后就会造成很多问题，这一改动进行了校验，阻止了这种情况的发生。[加入在线调整 PV 尺寸的能力（Alpha）（注 22）]：可以在不影响现有数据的情况下增大现有卷。这也对FlexVolume 的扩容支持（Alpha）（注 23）有效；FluxVolume 是一个 FluxVolume 插件实现的厂商支持的卷实现。拓扑感知的卷调度（Beta）（注 24）：可以在持久卷定义中加入拓扑限制，以此影响调度器中对相关容器的调度。这一功能还把 PVC 绑定的初始化过程延迟到 Pod 调度之后，这样卷绑定决策就能够在已知 Pod 部署情况的条件下做到更好。目前这一功能对本地持久卷很有用，对动态供给卷的支持还在开发。

节点管理（SIG-Node）

Kubelet 的动态控制（Beta）（注 25）：Kubernetes 中对现存集群的变更是比较方便的，例如增加复制数量或者暴露服务等。这一功能则让对 Kubernetes 自身的变更（或者说幕后的 Kubelet）而无需停止 Kubelet 成为可能。CRI 验证测试套件（Beta）（注 26）：Kubernetes 的容器运行时提供了 Docker 之外的（例如 Rkt 甚至是运行 Virtlet 的虚拟机）运行容器的选择。现在提供了一系列的验证测试，来确认 CRI 的实现的有效性，让开发者更方便的查找问题。可配置的 Pod 进程命名空间共享（Alpha）（注 27）：虽然 Pod 能够轻易地分享 Kubernetes 的命名空间，但是因为 Docker 的问题，进程或者 PID 命名空间是一个更困难的情况。这一功能让用户可以用 Pod 参数来决定容器使用自己的操作系统进程还是共享一个进程。CRI 中加入对 Windows 容器配置的支持（Alpha）（注 28）：起初，容器运行是接口是为基于 Linux 的容器设计的，不可能为基于 Windows 的容器提供支持。这一功能解决了这一问题，可以指定WindowsContainerConfig了。容器除错（Alpha）（注 29）：如果有合适的工具，为容器除错很容易，但是没有呢？这一功能提供了一种可能性：在容器中运行没有内置在镜像中的除错工具。

其他变更

Deployment（SIG-Cluster Lifecycle）：支持进程外或代码外的云供应商（Beta）（注 30），Kubernetes 现在已经获得了广泛采用，越来越多的云供应商希望运行 Kubernetes。为了让这一进程更加方便，社区努力将供应商指定的二进制内容进行分离，便于供应商自行替换。Kubernetes On Azure（SIG-Azure）：Kubernetes 具有集群伸缩能力，在负载过高时能够自动向集群中加入节点，但是目前这一能力在 Azure 中尚未实现。现在为 Azure 添加了 cluster-autoscaler 支持（Alpha）（注 31）。另外添加 Azure 虚拟机伸缩集的支持（Alpha）（注 32），使用 Azure 自己的自动伸缩能力来实现资源的调整。

可以在 https://github.com/kubernetes/kubernetes/releases 下载 Kubernetes 1.10 Beta，另外再次强调（社区也是如此希望），有反馈请在 3 月 9 日之前，向 1.10 里程碑上提交 Issue 给合适的 SIG。

注

https://github.com/kubernetes/kubernetes/milestone/37https://github.com/kubernetes/features/issues/43https://github.com/kubernetes/features/issues/5https://github.com/kubernetes/features/issues/279https://github.com/kubernetes/features/issues/541https://github.com/kubernetes/features/issues/542https://github.com/kubernetes/features/issues/504https://github.com/kubernetes/features/issues/427https://github.com/kubernetes/features/issues/536https://github.com/kubernetes/features/issues/539https://github.com/kubernetes/features/issues/263https://github.com/kubernetes/features/issues/515https://github.com/kubernetes/features/issues/516https://github.com/kubernetes/features/issues/496https://docs.google.com/document/d/1Fh0T60T_y888LsRwC51CQHO75b2IZ3A34ZQS71s_F0g/edit#heading=h.ys6pjpbasqduhttps://github.com/kubernetes/features/issues/432https://github.com/kubernetes/features/issues/361https://github.com/kubernetes/features/issues/178https://github.com/kubernetes/features/issues/121https://github.com/kubernetes/features/issues/498https://github.com/kubernetes/features/issues/499https://github.com/kubernetes/features/issues/531https://github.com/kubernetes/features/issues/304https://github.com/kubernetes/features/issues/490https://github.com/kubernetes/features/issues/281https://github.com/kubernetes/features/issues/292https://github.com/kubernetes/features/issues/495https://github.com/kubernetes/features/issues/547