本文为 K8sMeetup中国社区、Caicloud 工程师 翻译和校稿：邓德源、任玉泉、郑佳金、郭维、包梦江、侯星辉、蔡通、郑文彪、杨朝乐、刘搏

Kubernetes 1.8 被定位为稳定版本，社区主要投入在稳固已有的功能上。稳定性提升主要集中在几个方向。应用负载相关功能已经迁移到 apps/v1beta2，意味着功能已经基本趋于稳定，很有可能会直接成为 v1 版本。安全相关的核心功能 RBAC 升级至 v1，并且高级审计功能升级至 beta，日趋成熟。节点层面在 1.8 中持续集中在提高底层稳定性，尽管同时有部分新功能推出。

发布稳定版并不意味着 Kubernetes 停止新功能的的开发，实际上在 ​​Kubernetes 1.8 ​​中有非常多新功能发布，部分功能甚至是“里程碑”式的功能；我们可以从这些功能看到 Kubernetes 的长期发展情况。

越来越稳！Kubernetes 1.8.0 版本发布_Pod

Cluster Lifecycle 层面对 kubeadm 添加了 self-hosted 功能，意味着可以将 Kubernetes 运行在 Kubernetes 上，即自举。自举被认为是系统”优雅”的一种体现，实际上 Kubernetes 在很早期就开始尝试自举，现在 kubeadm 直接添加此功能，无疑是更近一步。另外，尽管没有对外发布，kubeadm 社区也一直在尝试直接部署高可用（HA）Kubernetes 集群。可以预见 kubeadm 在会进一步解决 Kubernetes 最为诟病的部署问题，降低使用门槛。

存储功能的更新是本次发布更新相对较多的模块，也是才云科技非常重视并且持续投入的小组。首先，Kubernetes 的存储模型已经稳定，在 1.8 的发布中开始增加更多的扩展性和附加功能，例如支持挂载选择，支持 StorageClass 参数化等。快照、扩容、本地存储无疑是存储模块本次发布的亮点，尽管目前都是 alpha，甚至是 pre-alpha。由于文件系统扩容方案暂未统一，扩容在本次发布中只支持 GlusterFS，但才云科技已经在 ceph、cinder 上进行了 prototype，相信在 1.9 中可以在社区中推出。本地临时存储在经过 1.7 和 1.8 两次迭代已经处于稳定的 alpha 版本，后续方案不会再改变，我们会持续增强其稳定性。本地持久化存储由于需要与调度讨论设计，进展较慢。快照现在处于 prototype 阶段，Kubernetes 对使用中的 Volume 快照会出现不一致的情况。

另外一个值得注意的情况是 SIG 的融合。目前，Kubernetes Node、Storage、Scheduling 等小组在合作形成 Resource Group，旨在使 Kubernetes 能够支持更多类型的应用。Auth、Node 等小组合作成立 Container Identity Group，确保容器在对外通信时的安全、可靠。在各个小组的合作下，Kubernetes 现在提出了 Device Plugin、CPU Manager、HugePage、Resource Claas，可以支持多样化的硬件。Kubernetes 1.8 是此类 Group 的成立后的首次较大范围功能发布，期待后续更多的进展。

下面看一下 Kubernetes 1.8 中都有哪些发布内容。

发布主题

Kubernetes 通过兴趣小组（SIG）管理社区与开发，下面根据兴趣小组来解读 ​​Kubernetes 1.8​​ 的发布内容。

SIG Apps

SIG Apps 的工作集中在 Kubernetes API 上，提供多种管理不同类型应用的基本工具。

在 1.8 的发布版本中，SIG Apps 将应用相关的一些 API 迁移到了 apps/v1beta2，包括 DaemonSet，Deployment，ReplicaSet 和 StatefulSet。在 apps/v1beta2 中，也有部分内容被弃用或者行为发生变更，这样做的目的在于给开发者提供一个稳定且一致的 API 集合，方便开发者基于 Kubernetes 构建应用。在后续的发布中，SIG Apps 会逐步推动该版本走向稳定版本。

SIG Auth

SIG Auth 负责 Kubernetes 认证，授权和集群安全策略相关的工作。

在 Kubernetes 1.8 中 SIG Auth 主要专注于稳定之前的发布中引入的功能。RBAC（基于角色的访问控制）功能已经提升到 v1，advanced auditing （高级审计）功能已经发布 beta 版本。Encryption of resources at rest （静态资源加密）功能依旧是 alpha 版本，开始尝试集成外部的密钥管理系统。

SIG Cluster Lifecycle

SIG Cluster Lifecycle 负责部署升级和删除集群的用户体验。

在 1.8 发布中，SIG Cluster Lifecycle 继续关注于扩展 kubeadm 的功能，它既是一个面向用户的集群管理工具，也作为一个构建单元提供给高层次的系统。从 1.8 版本开始，kubeadm 支持一个新的升级命令，并且对集群控制组件的 self hosting 提供 alpha 支持。

SIG Node

SIG Node 负责 Pod 和 Host 主机之间资源交互的组件，以及管理节点上 Pod 的生命周期

对于 1.8 版本，SIG Node 继续专注于支持更广泛的工作负载类型，包括支持硬件和对性能敏感的工作负载，如数据分析和深度学习，同时不断增强 Node 的可靠性。SIG Network 负责 Kubernetes 中的网络组件，API 和插件。

SIG Network

SIG Network 负责 Kubernetes 中的网络组件，API 和插件。

对于 1.8 版本，SIG Network 增强了 NetworkPolicy API，以支持 Pod 出口流量策略，以及允许策略规则匹配源或目标 CIDR 的匹配条件。这两个增强特性都被设计为 beta 版本。 SIG Network 还专注于改进 kube-proxy，除了当前的 iptables 和 userspace 模式，kube-proxy 还引入了一个 alpha 版本的 IPVS 模式。

SIG Storage

存储兴趣组主要包含存储和各种存储卷插件。

1.8 中，存储兴趣组扩展了 kubernetes 存储 API，不再只是简单的提供可使用的卷，又新增了卷扩容和快照功能。 除了这些 alpha/prototype 特性， 存储兴趣组主要聚焦在让用户更好的控制他们的存储，提供了如下能力：能设置临时存储 requests & limits ，能指定挂载选项， 暴露更多存储指标信息， 改善 Flex driver deployment。

SIG Scheduling

SIG Scheduling 主要负责通用调度器和调度相关组件。

在 1.8 的发布版本中，SIG Scheduling 通过引入 Pod 优先级和抢占特性扩展了共享集群的概念。这些特性允许在单一集群中混合运行不同类型的应用和任务，提高了集群的利用率和可用性。这些特性目前都是 alpha 版本。SIG Scheduling 还将逐步优化调度相关的内部 API，让其他组件和外部调度器能够轻松的使用这些 API。

SIG Autoscaling

SIG Autoscaling 主要负责弹性伸缩相关的组件，比如 Horizontal Pod Autoscaler 和 Cluster Autoscaler。

在 1.8 的发布版本中，SIG Autoscaling 主要在提升现有组件的稳定性和功能。比如新版的 Horizontal Pod Autoscaler 将支持自定义指标，Cluster Autoscaler 提升了性能和错误报告能力。

SIG Instrumentation

SIG Instrumentation 负责指标的输出和收集。

在 1.8 版本中，SIG Instrumentation 的工作重心是支持新版本 HPA API，将所依赖的 API 和组件升级到稳定版本，包括：resource metrics API，custom metrics API 和 metrics-server（metrics-server 将会在替代 heapster 在默认监控流水线中的作用）。

SIG Scalability

SIG Scalability 负责可扩展性测试，测量和改进系统性能，并回答有关可扩展性的问题。

对于 1.8 版本, SIG Scalability 集中于在持续集成（CI）环境中自动化大型集群可扩展性测试。除了定义可扩展性测试的具体过程之外，SIG Scalability 还为当前可扩展性阈值创建了文档，并定义了跨系统的一组新的服务级别指标（SLI）和服务级别目标（SLO)。

本次发布的scalability validation report：

​​https://github.com/kubernetes/features/blob/master/release-1.8/scalability_validation_report.md​​

主要内容

Workload API (apps/v1beta2)

Kubernetes 1.8 中添加了 apps/v1beta2，这个版本中包含了 DaemonSet，Deployment，ReplicaSet 和 StatefulSet。这些 API 将在未来的版本中逐步走向稳定。

API 的添加和迁移

  • DaemonSet，Deployment，ReplicaSet 和 StatefulSet 的当前版本是 apps/v1beta2。
  • 在 apps/v1beta2 中，StatefulSet 增加了 Scale 子资源。
  • apps/v1beta2 中的所有类型都添加了相应的 Condition 类型。

行为变更

  • 对于 apps/v1beta2 中的所有类型，因为与 kubectl apply 和 strategic merge patch 不兼容，因此 spec.selector 默认被禁用。用户必须要显式设置 spec.selector，并且如果 spec.selector 与 spec.template 中的 labels 不匹配，那么这个对象是无效的。
  • 由于这些类型的控制器对于 selector 的处理方式不一致，因此在 apps/v1beta2 中这些类型的 selector 将不能修改。这个限制可能会在将来被移除，但是也有可能会保留到稳定版本。如果用户有些代码依赖了可变的 selector，那么这些代码可以继续使用 apps/v1beta1 版本的类型，但是还是应该开始修改这些代码，不再依赖可修改的 selector。
  • Extended Resource 是除了 kubernetes.io 以外的合法域名。Extended Resource 的值必须是整数。用户可以使用任意合法的资源名，比如 [aaa.]my-domain.bbb/ccc， 而不是继续使用 Opaque Integer Resource。Extended Resource 不是动态的，因此在 request 和 limit 中，同样的 Extended Resource 的值必须是相同的。
  • 由 kubeadm init v1.8 版本创建的默认的 Bootstrap Token 默认会在 24 小时后被删除，防止集群重要信息泄漏。 用户可以通过 kubeadm token create 创建一个新的 Bootstrap Token 或者通过给 kubeadm init 设置 –token-ttl 0 让 Bootstrap Token 不会过期。默认的 Token 可以通过 kubeadm token delete 删除。
  • kubeadm join 现在将 TLS 启动交给 kubelet 完成，而不是自己实现该过程。kubeadm join 会将启动用的 KubeConfig 文件写到 /etc/kubernetes/bootstrap-kubelet.conf。

默认值

  • StatefulSet 和 DaemonSet 的 spec.updateStrategy 默认值在 apps/v1beta2 中为 RollingUpdate。如有必要，用户可以手动设置为 OnDelete。
  • selector 默认被禁用。
  • apps/v1beta2 中相关类型的 spec.revisionHistoryLimit 的默认值均为 10。
  • CronJob 的 spec.successfulJobsHistoryLimit 默认值为 3，spec.failedJobsHistoryLimit 的默认值为 1。

Workload API (batch)

  • CronJob 已经迁移到了 batch/v1beta1。
  • batch/v2alpha.CronJob 已经被废弃并且在将来的版本中被移除。
  • Job 现在能通过 spec.backoffLimit 设置失败策略。该字段的默认值为 6。
  • batch/v2alpha1.ScheduledJobs 已经被移除。
  • Job 控制器现在分批创建 Pod，而不是之前的一次性创建。
  • Job 现在可以设置一个较短的 spec.ActiveDeadlineSeconds。

Scheduling

  • [alpha] 支持 Pod 优先级和 PriorityClass
  • [alpha] 支持 Pod 基于优先级的抢占
  • [alpha] 按条件给 node 打 taint

Storage

  • [stable] 挂载选项
  • 把指定挂载选项能力从 beta 提升到稳定版
  • 在 PersistentVolume spec 中加入一个新的变量 MountOptions , 去指定挂载选项，从而代替原有的设置别名的方式
  • 在 StorageClass spec 中也加入 MountOptions，从而允许为动态提供的卷配置挂载选项。允许 k8s 管理员控制他们集群里面使用的挂载选项
  • [stable] 为 RWO 卷比如 iSCSI 和 FC 提供 Attach/Detach
  • [stable] 暴露存储使用信息
  • 通过 kubernetes metric API 暴露 PV 还剩下多少存储空间可用
  • [stable] 卷插件信息
  • 通过 kubernetes metric API 暴露执行某些操作的成功或者延迟信息，操作包括：mount/unmount/attach/detach/provision/delete
  • [stable] 修改 Azure File, CephFS, iSCSI, Glusterfs 相应的 PV spec ，从而让他们可以引用命名空间资源
  • [stable] 支持 iSCSI 卷插件中定制每个卷 iSCSI initiator 名字
  • [stable] 支持 FC 卷标识符的 WWID
  • [beta] StorageClass 回收策略
  • 运行配置 StorageClass 中的回收策略，不像以前那样，对于动态提供的卷，默认只能是 delete
  • [alpha] 卷扩容
  • 运行通过 kubernetes API 对 volume 进行扩容
  • alpha 版本中，只对特定的 volume 进行扩容，但是并没有做文件系统扩容
  • alpha 版本中，只实现了 Gluster 的扩容
  • [alpha] 为本地临时存储提供隔离和管理功能
  • 对于新资源 ephemeral-storage, 运行设置容器的 requests/limits 和节点预留
  • ephemeral-stroage 包含了容器可能使用的所有磁盘空间
  • [alpha] 挂载空间传播
  • pod 声明中，为 container 的 VolumeMount 新加一项 VolumeMount.Propagation
  • 这一新增项可以被设置为 Bidirectional, 从而让容器的某个挂载传播到主机或者其他容器中
  • [alpha] 改进 Flexvolume 部署
  • 简化 Flex volume driver 的部署
  • 自动发现并初始化新的 driver 文件，而不是像以前一样，必须要求重启 kubelet 和 controller-manager
  • 提供一个 DaemonSet 样例，可以被用来部署 Flexvolume drivers
  • [prototype] 卷快照
  • 允许通过 kubernetes API 触发创建卷快照
  • 因为不支持快照前停止服务，所以，快照有可能数据不一致
  • 这个项目不在核心 kubernetes repo 里面，在 https://github.com/kubernetes-incubator/external-storage/tree/master/snapshot 这里

Node Component

kubelet

  • [alpha] Kubelet 现在支持使用新的 CPU 管理器替代的容器级 CPU 关联策略。
  • [alpha] 应用程序现在可以通过在容器资源请求中使用新的 hugepages 资源来请求预先分配的 hugepages。
  • [alpha] 增加对 Kubelet 动态配置的支持
  • [alpha] 增加 CRI 校验测试集和 CRI CLI
  • [alpha] 增加硬件设备插件的 API
  • [stable] 支持 CRI-O，已经通过所有的 e2es

自动扩展和度量指标

  • Horizontal Pod Autoscaler 对自定义度量指标升级到 beta 版本。关联的度量指标的 APIs 升级到 v1beta1版本。升级前查看需要的操作。
  • 推荐使用 metrics-server 作为提供资源度量指标 API 的组件。它可以部署为插件，类似于 Heapster 的部署方式。

集群自动扩展器

  • 集群自动扩展器升级为 GA
  • 扩展集群支持 1000 个节点
  • Pod 优雅停止时间为 10分钟
  • 处理区域库存和故障
  • 改良监控和错误报告

Auth

  • [GA] RBAC 的 API 组已经从 v1beta1 提升到 v1。没有引入 API 相关的修改。
  • [beta] Advanced auditing 已经从 alpha 到 beta。和 alpha 相比 webhook 和 logging policy 格式相关的部分有所变化，可能需要修改。
  • [beta] Kubelet certificate rotation through the certificates API（通过证书 API 轮换证书）功能已经从 alpha 变为 beta。RBAC 针对 certificates controller（证书控制器）配置的 cluster role（集群角色）已经被创建，用于访问 kubelet 等的通用证书 API。
  • [beta] SelfSujectRulesReview 是一个用于让一个用户了解他在一个 namespace 下有什么权限的 API，已经被加入到了 authorization.k8s.io 这个 API 组内。这个批量查询是为 UIs 根据用户来展现和隐藏一些功能而设计的。并且这个 API 能让用户快速的了解他们自己的权限。
  • [alpha] 基于 1.7 版本的工作之上允许对 secrets 等资源加密，将 resource 加密用的 key 存储到外部的 KMS 系统中。该机制的实现除了支持最初基于文件的存储外还允许和各种 KMS 系统集成。Google Cloud KMS 插件已经添加进来，一旦 Google 端的集成完成就能够使用。
  • Websocket 请求现在可以通过在 websocket subprotocol base64url.bearer.authorization.k8s.io 中 设置 bearer token 来通过 API server 的认证。
  • Advanced audit 现在能够正确的报告 impersonated user（模拟用户）的信息。
  • Advanced audit 策略现在支持匹配子资源和资源名称，但是顶级资源不再能匹配子资源。举个例子，”pods” 不再能匹配对 logs 子资源的请求。要使用 “pods/logs” 去匹配子资源。
  • 之前一个被删除 service account 或者 bootstrapping token secret 会被认为有效直到它们真的被回收。现在当 deletionTimestamp 一被设置它们就会失效。
  • –insecure-allow-any-token 参数已经从 API server 删除。使用这个参数的用户应当使用 impersonation 头替代它进行调试。
  • NodeRestriction admission 插件现在允许一个节点驱逐绑定到自己身上的 pods。
  • OwnerReferencesPermissionEnforcement admission 插件为了在一个 owner reference （所有者引用）上设置 blockOwnerDeletion ，现在需要对 referenced owner（被引用的所有者）的 finalizers 子资源具有 update 权限。
  • 在 authorization.k8s.io API 组下的 SubjectAccessReview API 现在允许提供用户的 uid。
  • 在 kubelet 轮换它的客户端证书后，它将关闭跟 API server 的链接去强制使用新证书握手。之前 kubelet 会保持已经存在的连接始终开启，即使连接使用的证书已经过期并且被 API server 拒绝连接。
  • PodSecurityPolicies 现在能够指定一个白名单，用于记录允许作为主机数据卷的路径。
  • API server 的认证现在缓存了成功认证的 bearer token 几秒钟。
  • OpenID Connect 认证插件现在能够在 username 和 groups 两个 claim 前添加自定义的前缀，或者使用默认的前缀。通过 –oidc-username-prefix 和 –oidc-groups-prefix 两个参数设置。举个例子，认证插件能够将用户名为 “jane” 的用户映射为 “google:jane”，通过设置 “google:” 这个 username 前缀。
  • bootstrap token 认证插件现在能够在 tokens 中配置除了 system:bootstrappers 之外的 groups。
  • Advanced audit 允许记录失败的登陆请求。
  • kubectl auth reconcile 子命令已经被添加用来应用 RBAC 资源。当传入一个文件包括 RBAC roles，rolebindings，clusterroles，或者 clusterrolebindings，该命令能够计算出覆盖的权限并且添加遗漏的规则。

Cluster Lifecycle

kubeadm

  • [beta] 一个新的 upgrade 子命令允许你使用 kubeadm 自动的升级一个 self-hosted 的集群。
  • [alpha] 通过 kubeadm init 可以简单的创建一个实验性的 self-hosted 集群. 通过配置 SelfHosting 特性为 true: –feature-gates=SelfHosting=true 来开启这个功能。
  • 注意: 在下一个发布版本，即 1.9 版本，Self-hosting 会作为部署控制组件的默认方式。
  • [alpha] 一个新的 phase 子命令支持运行 kubeadm init 流程的子任务。结合更易获取的配置，kubeadm 现在开始容易整合到高级的部署平台中，比如 kops 和 GKE。
  • 注意: 这个命令目前放在 kubeadm alpha phase 子命令里，在未来版本一定会放到顶级命令中。

kops

  • [alpha] 支持裸机（非云提供商）环境。
  • [alpha] kops 现在支持 作为服务运行。
  • [beta] GCE 支持从 alpha 升级为 beta。

Cluster Discovery/Bootstrap

  • [beta] Bootstrap Tokens 这种认证和鉴别方法进一步优化。使用 Bootstrap Tokens 去添加新的节点变的容器很多。

Multi-platform

  • [alpha] 一致的 e2e 测试套件开始支持 arm, arm64, 和 ppc64le 架构。

Cloud Providers

  • [alpha] 支持可插拔的，out-of-tree 及 out-of-core 的云提供商的功能得到了显著的改善。

Network

network-policy

  • [beta] 基于 CIDR 的 NetworkPlicy 策略支持。
  • [beta] NetworkPolicy 中支持 EgressRules。

kube-proxy ipvs 模式

  • [alpha] kube-proxy 支持 ipvs 模式。

kube-apiserver

  • 修复了 APIService 自动注册的问题。该问题曾影响添加或删除 API 组的 HA API 的滚动重启。
  • [Alpha] Kubernetes API 现在支持指定条件的列表查询。客户端可以指定返回结果的数量，并且如果存在更多结果，则会返回一个token令牌，用于重复调用直到所有的结果被检索到。归功于 etcd3 提供的功能，结果列表与不执行分块的列表调用相同。这允许服务器使用较少的内存和 CPU 响应非常大的列表。这个功能的入口是 APIListChunking 并且默认不开启。1.9 版本，所有 informer 将会默认使用它。
  • 忽视在 ResourceQuota 中超过宽限期即被标记为删除的pod。

Dynamic Admission Control

  • 当pod没有初始化时，Pod spec 是变化的。API server 要求pod spec 是有效的, 即使pod未初始化。更新未初始化的pod的状态是无效的。
  • 现在使用 alpha 的初始化功能要求开启 Initializers 功能入口。如果启用 Initializersadmission 插件，此功能门将自动启用。
  • [Action required] metadata.initializers.pending[x].name 的验证规则是收紧的. initializer 的名称需要包括至少三个由点分隔的段。根据构建规则，你可以用pending initializers 创建对象，并且不依赖API server去添加pending initializers。如果你这样做，更新现有的对象和配置文件中的initializer name，以符合新的验证规则。
  • 即使API服务器和节点在两个单独的网络中，webhook admission 插件也能正常工作。例如，在GKE中。webhook author可以使用服务等DNS名称作为共有名称去生成wehhook的服务器证书。
  • Action required:
  • 以前，为admission webhook重新生成server证书, CN的值可以被忽略。现在，必须把它设为webhook服务的DNS名称： <service.Name>.<service.Namespace>.svc.

Custom Resource Definitions (CRDs)

  • [alpha] CustomResourceDefinition API现在可以选择验证CRD spec提供的基于JSON模式的自定义对象
  • 你可以在 kube-apiserver 中通过 CustomResourceValidation 功能入口启用这个功能。

Garbage Collector

  • Garbage collector 现在支持通过 CustomResourceDefinition 或者 aggregated API servers 自定义API。Garbage collector controller 周期化的刷新，因此，期望在添加 API 与 Garbage collector开始管理它之间，有30秒的间隔。

Monitoring/Prometheus

  • [action required] 在 prometheus 的 apiserver_request_* 系列中，WATCHLIST 作为动词 WATCH。根据查询的级别，一个新的 “scope” 标签将被添加到所有的 apiserver_request_* 中，这个值可以是’cluster’, ‘resource’, 或者是 ‘namespace’。

Go Client

  • 添加客户端垃圾邮件过滤的支持

特别感谢：Caicloud 工程师男神们的给力翻译和校稿！