kubernetes 1.8

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 模式。

 API Machinery

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

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

转载: https://blog.csdn.net/qq_34463875/article/details/78250552