【深度】Kubernetes v1.16 最值得工程师关注的改动

昨天，Kubernetes 发布 2019 年的第三个新版本 1.16，才云第一时间对新版本重要更新做了精选整理，之后这篇文章被 CNCF 转发。经过一天的升级体验和对文档的细致阅读，才云现推出 Kubernetes v1.16 深度解读，以飨读者！

发布 | 才云 Caicloud

编译 | littlepoint & zls & bot

审核 | ddysher

随着周三官方发布的 Kubernetes v1.16 进入普遍可用状态，相信很多读者已经体验了由新版本带来的诸多新变化。在官方文档中，开发团队表示 新版本主要围绕以下四个主题 ：

CRD 正式步入通用可用性（GA）；
Admission webhook 正式步入 GA；
关于 metrics 的改动；
大量和 Volume 相关的改进。

以上我们已在昨天做了详细介绍（点击跳转）。

而除此之外，Kubernetes v1.16 中的其他更新，如对 Windows 支持的改进、API 变化等，也非常有价值，它们显示了开发团队对增强 Kubernetes 可扩展性的一贯努力。

在这篇文章中，才云工程师将从实践角度出发，总结对新版本的心得。

节点

新版本对 K8s-clusters 节点（Kubelet）做了很多相关改进和创新，如 Ephemeral Containers（短暂容器）、节点拓扑管理器和 startup probe（启动探测）等。

首先，Ephemeral Containers 是为了简化调试 Pod 而设计的。新的机制允许你在运行的 Pod 中添加短暂存活的容器。通过这个特殊的容器，你可以访问其他的 Pod 及里面的容器，以此来进行调试和解决问题。

kubectl debug使用了这个功能，实质上有点类似于kubectl exec：只是把在容器中执行命令替换成了在 Pod 中启动新的容器。例如你可以通过以下命令在 Pod 中创建一个新的容器：

这个特性目前（K8s v1.16）处于 Alpha 阶段，在经历两个 releases 后可能会进入 Beta 阶段。

其次， 节点拓扑管理器是一个新的 Kubelet 组件，旨在协调资源分配决策，以提供优化的资源分配，提高性能 。它的出现源于各类现代系统（来自电信、机器学习、金融服务等领域）对高性能并行计算和尽量减少执行操作延迟的需求日益增长。

第三个值得介绍的创新是启动期间检查容器（startup probe） 。众所周知，对于长期运行的容器，我们很难获取其当前状态：它们要么在实际操作之前就被“干掉”，要么长期处于死锁中。

新的检查（通过名为 StartupProbeEnabled 的特性门户开启）取消——或者说推迟——其他检查的有效性直至 Pod 启动完毕。因此，该特性一开始被称为 pod-startup liveness-probe holdoff。对于启动已久的 Pods，现在用户有可能在相对较短的时间内查询其状态。

此外，新版本也增加了对 RuntimeClass 的改进和对“异构集群”的支持（Beta）。通过 RuntimeClass 调度，现在每个节点都不必支持每个 RuntimeClass：对于 Pods，用户可以选择 RuntimeClass，而无需考虑集群拓扑。

网络

在版本发布前夕，很多工程师已经在社交网络上表达了对 IPv4/IPv6 双栈的期待。

新版本对 Kubernetes Pod、节点和服务提供 IPv4/IPv6 双栈支持和感知 。这为 Kubernetes 集群添加了 IPv4/IPv6 双栈功能，包括了解每个 Pod 的多个 IPv4/IPv6 地址分配和集群之间本地 IPv4-to-IPv4、IPv6-to-IPv6 的通信。

下面是在 Pod 列表中输出两种类型的 IP 地址（IPv4 和 IPv6）的示例：

在新版本中，Endpoint 现在有一个全新的 API：EndpointSlice API。

新 API 解决了现有 Endpoint API 的性能/伸缩问题，这些问题会影响控制平面中的不同组件，如 apiserver、etcd、endpoints-controller、kube-proxy 等。它被添加至 Discovery API 组，并且能够在由数千个节点组成的集群中为每个服务提供数万个后端端点。

为了实现这一点，每个 service 映射到 N 个对象 EndpointSlice，每个对象默认包含不超过 100 个 endpoints（该值可配置）。

EndpointSlice API 还提供了未来扩展的可能：每个 Pod 支持多个 IP 地址、endpoints 的新状态（不只是 Ready 和 NotReady）、endpoints 的动态子集。

改进对 Windows 的支持

Beta：增强 Windows 容器的工作负载标识选项

新版本对 Active Directory 组托管服务帐户（gMSA）的支持即将步入 Beta 阶段，因此 Alpha 阶段引入的某些注释已被弃用。

gMSA 是一种特定类型的 Active Directory 帐户，它使 Windows 容器能够跨网络传输身份标识并与其他资源通信。Windows 容器现在可以通过身份验证访问外部资源。

此外，gMSA 还提供了自动密码管理、简化服务主体名称（SPN）管理以及跨多个服务器将管理委托给其他管理员的能力。

Alpha 中新增对 RunAsUserName 的支持。RunAsUserName 是一个字符串，指定 Windows 中的 windows identity（或用户名）来运行容器的 entrypoint，它是 securityContext 新引入的 windowsOptions 组件的一部分。

Alpha：改进 kubeadm 的设置和节点连接体验

新版本引入了对 kubeadm 的 Alpha 支持，使 Kubernetes 用户能够像连接 Linux 节点一样，轻松将 Windows 工作节点连接（和重置）到现有集群。

用户可以使用 kubeadm 准备一个 Windows 节点并将其添加到集群中。当操作完成时，节点将处于就绪状态，并能够运行 Windows 容器。

Alpha：引入对容器存储接口（CSI）的支持

新版本还为 out-of-tree 程序引入了 CSI 插件支持，使 Kubernetes 集群中的 Windows 节点能够为基于 Windows 的工作负载利用持久存储功能。

这为 Windows 工作负载提供了除 FlexVolume 和 in-tree 存储插件外的更多选择。此功能通过主机 OS 代理实现，支持代表容器在 Windows 节点上执行特权操作。

Scheduler

这方面有两个显著变化（Alpha）：

EvenPodsSpreading 。该特性允许用户能够通过 Pod “公平分配”负载，而不是使用应用程序逻辑单元（如 Deployment 和 ReplicaSet）调整分配。它将扩展 Pods 现有分发功能，这些功能现在受 PodAffinityand PodAntiAffinity 的限制，这使管理员可以实现更好的可访问性和优化资源消耗。

BestFit Policy 。在使用加速器设备的 Kubernetes 上运行工作负载时，默认的调度器会在节点之间散布 Pod，从而导致扩展资源的碎片化，对需要调度较多资源的 Pod 产生不利影响。为扩展资源，BestFit Policy 可以通过 RequestedToCapacityRatio 优先级函数调度 Pod，减少集群上资源的碎片化。

此外，新版本还提供了在主 Kubernetes（out-of-tree）开发树之外为调度程序创建用户自己的插件的机会。

其他重要变化

在 Kubernetes v1.16 中，大家可以注意到新版本正在努力提供和 Prometheus 等生态项目一致的命名和高质量 metrics。

它们现有的差异是由多种原因造成的，比如生态中的一些 metrics 更早出现。但现在，开发团队觉得是时候该统一标准了！目前该计划的实现处于 Alpha 阶段，之后这一点有计划推进至 Beta（v1.17）和 GA（v1.18）。

最后，我们再梳理一下其他的重要变化：

重新设计 API 响应中的数据压缩机制。新版本推出 transparent request compression：客户端发送 Accept-Encoding: gzipin，如果大小超过128 KB，报头接收一个 gzip 压缩的响应；
HPA 可以根据外部指标把 Workload（Deployment 等）的副本数调度到 0。如果扩展基于 objects / 外部 metrics，那么当工作负载空闲时，用户可以自动把副本数调度到 0 来节省资源；
New client - k8s.io/client-go/metadata。这是一个用于“通用化”对象访问的 Client。它的设计目的是方便从集群资源资源中获取元数据（或分段元数据），再在 garbage collection 和配额的类别中对它们进行操作；
Kubernetes 现在可以在没有 in-tree 云厂商的情况下构建（Alpha）；
新版本实验性功能：在操作期间应用 kustomize 补丁，并添加到 kubeadm init、joinand、upgrade 中（Alpha）；
apiserver - readyz 的新端点允许用户导出准备就绪信息。API 服务器有一个标记——maximum-startup-sequence-duration，允许用户调整它的重启；
在升级到 CoreDNS 时，kubeadm 现在可以自己迁移其 CoreDNS 配置；
对应 Docker 镜像中的二进制 etcd 现全局可执行，这允许用户不需要 root 特权就能运行此镜像。此外，etcd 迁移镜像已经不再支持 etcd2 版本。

总结

综合来看，新版本做出的最具影响力的改动还是 CRD 步入 GA。针对这个改动，很多业内人士指出 Kubernetes 并不安于容器编排，它已经瞄准虚拟机、“大数据”平台乃至机器学习框架，最终目标极有可能是“一切皆可编排”。

CNCF 的执行董事 Dan Kohn 在接受媒体采访时曾表示：我认为 Kubernetes 的愿望是 Kubernetes 会变得“无聊”，而且我认为这很可能会发生。因为它会被内置在任何地方，就像 Linux 一样，是个假定的“默认值”。

结合国内外市场近期对 Kubernetes 的诸多“大动作”，Kubernetes 的“临界点”或许已经到来！

资料来源：

[1] https://kubernetes.io/blog/

[2] https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#v1160-beta1

[3] https://habr.com/ru/company/flant/blog/467477/?

完

感谢关注才云科技（公众号 ID：Caicloud2015），更多产品案例，欢迎访问 https://caicloud.io。

关于才云科技

杭州才云科技有限公司（Caicloud）是一家基于容器技术和人工智能，引领新一代智能云计算平台和 AI 服务的公司。才云科技独家研发的基于 Kubernetes 的企业级智能容器云平台 Caicloud Compass （获 CNCF KCSP 认证）、基于 TensorFlow 的人工智能中台 Caicloud Clever 及开箱即用的 AI 模型解决方案 Caicloud Cabernet 现已在国内 500 强企业成功落地，并在电商、金融、新零售、制造、运营商、教育等行业均有成熟解决方案。才云科技总部位于中国杭州，在北京、上海、成都、深圳、南京设有分支机构。