Kubernetes 1.16：主要创新概述

今天，星期三， 发生 Kubernetes 的下一个版本 - 1.16。 根据我们博客的传统，这是我们谈论新版本中最重大变化的十周年纪念日。

用于准备本材料的信息取自 Kubernetes 增强跟踪表, 变更日志-1.16 以及相关问题、拉取请求和 Kubernetes 增强提案 (KEP)。 那么，我们走吧！...

节点数

K8s 集群节点（Kubelet）方面出现了真正大量值得注意的创新（处于 alpha 版本状态）。

首先，所谓的 «临时容器» （临时容器），旨在简化 pod 中的调试过程。 新机制允许您启动特殊容器，这些容器在现有 Pod 的命名空间中启动并存活很短的时间。 它们的目的是与其他 Pod 和容器交互，以解决任何问题并进行调试。 为此功能实施了一个新命令 kubectl debug，本质上类似于 kubectl exec：仅代替在容器中运行进程（如 exec）它在 pod 中启动一个容器。 例如，此命令会将新容器连接到 pod：

kubectl debug -c debug-shell --image=debian target-pod -- bash

有关临时容器（及其使用示例）的详细信息可以在 对应的KEP。 当前的实现（在 K8s 1.16 中）是 alpha 版本，转移到 beta 版本的标准之一是“针对至少 2 个版本的 [Kubernetes] 测试 Ephemeral Containers API”。

NB：从本质上讲，甚至从名称上看，该功能类似于现有的插件 kubectl 调试关于我们 已经写了。 预计随着临时容器的出现，单独的外部插件的开发将停止。

另一项创新—— PodOverhead - 旨在提供 计算 pod 间接成本的机制，根据所使用的运行时的不同，可能会有很大差异。 举个例子，作者 这个KEP 结果是 Kata 容器，需要运行来宾内核、kata 代理、init 系统等。 当开销变得如此之大时，它就不能被忽视，这意味着需要有一种方法将其考虑到进一步的配额、规划等。 为了实现它在 PodSpec 添加字段 Overhead *ResourceList （与中的数据比较 RuntimeClass，如果使用的话）。

另一个值得注意的创新是 节点拓扑管理器 （节点拓扑管理器），旨在统一微调 Kubernetes 中各个组件的硬件资源分配的方法。 这一举措是由各种现代系统（来自电信、机器学习、金融服务等领域）对高性能并行计算和最大限度地减少操作执行延迟的日益增长的需求所推动的，为此它们使用先进的 CPU 和硬件加速能力。 到目前为止，Kubernetes 中的此类优化已经通过不同的组件（CPU 管理器、设备管理器、CNI）实现，现在它们将添加一个单一的内部接口，统一方法并简化新的类似（所谓的拓扑）的连接。感知 - Kubelet 端的组件。 详细信息 - 在 对应的KEP.

拓扑管理器组件图

下一个功能 - 在容器运行时检查容器 (启动探针)。 如您所知，对于需要很长时间才能启动的容器，很难获得最新状态：它们要么在真正开始运行之前被“杀死”，要么最终陷入很长一段时间的僵局。 新检查（通过名为的功能门启用 StartupProbeEnabled) 取消（或者更确切地说，推迟）任何其他检查的效果，直到 pod 完成运行为止。 因此，该功能最初被称为 pod 启动活跃度探针延迟。 对于启动时间较长的 Pod，您可以以相对较短的时间间隔轮询状态。

此外，对 RuntimeClass 的改进在测试版状态中立即可用，增加了对“异构集群”的支持。 C 运行时类调度 现在，每个节点完全没有必要支持每个 RuntimeClass：对于 pod，您可以选择一个 RuntimeClass，而无需考虑集群拓扑。 以前，为了实现这一目标（以便 Pod 最终位于支持其所需一切的节点上），有必要为 NodeSelector 和容忍分配适当的规则。 在 KEP 它讨论了使用示例，当然还有实现细节。

Сеть

Kubernetes 1.16 中首次（alpha 版本）出现的两个重要网络功能是：

• Поддержка 双网络堆栈 - IPv4/IPv6 - 及其在 Pod、节点、服务层面的相应“理解”。 它包括 Pod 之间、从 Pod 到外部服务的 IPv4 到 IPv4 和 IPv6 到 IPv6 互操作性、参考实现（在 Bridge CNI、PTP CNI 和 Host-Local IPAM 插件内），以及与运行的 Kubernetes 集群反向兼容仅限 IPv4 或 IPv6。 实施细节在 KEP.

  在 pod 列表中显示两种类型（IPv4 和 IPv6）的 IP 地址的示例：

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• 端点的新 API - 端点切片 API。 它解决了现有 Endpoint API 的性能/可扩展性问题，这些问题影响控制平面中的各种组件（apiserver、etcd、endpoints-controller、kube-proxy）。 新的 API 将添加到 Discovery API 组中，并将能够为由数千个节点组成的集群中每个服务上的数万个后端端点提供服务。 为此，每个服务都映射到 N 个对象 EndpointSlice，每个端点默认不超过100个（该值是可配置的）。 EndpointSlice API 还将为其未来的发展提供机会：支持每个 pod 的多个 IP 地址、端点的新状态（不仅 Ready и NotReady），端点的动态子集化。

上一版本中提供的版本已达到测试版 终结者, 命名为 service.kubernetes.io/load-balancer-cleanup 并附加到每个服务的类型 LoadBalancer。 删除此类服务时，它会阻止实际删除资源，直到完成所有相关平衡器资源的“清理”。

API机械

真正的“稳定里程碑”是在 Kubernetes API 服务器及其交互领域。 这很大程度上归功于 转入稳定状态者，无需特殊介绍 自定义资源定义 （CRD），自 Kubernetes 1.7 遥远的日子以来（现在是 2017 年 XNUMX 月！），它就处于测试状态。 相关功能也具有相同的稳定性：

• “子资源” 同 /status и /scale 对于自定义资源；
• 转型 CRD 版本，基于外部 webhook；
• 最近提出的 （在 K8s 1.15 中）默认值 （默认） 和自动字段移除 （修剪） 对于自定义资源；
• 机会 使用 OpenAPI v3 架构创建和发布用于在服务器端验证 CRD 资源的 OpenAPI 文档。

Kubernetes 管理员早已熟悉的另一种机制： 准入网络钩子 - 也长期处于测试状态（自 K8s 1.9 起），现已宣布稳定。

另外两个功能已达到测试版： 服务器端应用 и 观看书签.

alpha 版本中唯一重大的创新是 放弃 从 SelfLink — 表示指定对象并作为其一部分的特殊 URI ObjectMeta и ListMeta （即 Kubernetes 中任何对象的一部分）。 他们为什么要放弃它？ 以简单的方式激励 声音 因为缺乏真正的（压倒性的）理由让这个领域仍然存在。 更正式的原因是为了优化性能（通过删除不必要的字段）并简化 generic-apiserver 的工作，该服务器被迫以特殊方式处理此类字段（这是在对象之前设置的唯一字段）已连载）。 真正的过时（在测试版内） SelfLink 将在 Kubernetes 版本 1.20 和最终版本 1.21 中实现。

数据存储

与之前的版本一样，存储区域的主要工作是在该区域中观察到的 CSI 支持。 这里的主要变化是：

• 第一次（alpha 版本） 出现 Windows 工作节点的 CSI 插件支持：当前的存储工作方式也将取代 Kubernetes 核心中的树内插件和 Microsoft 基于 Powershell 的 FlexVolume 插件；

  
  在 Kubernetes for Windows 中实现 CSI 插件的方案

• 机会 调整 CSI 卷大小，早在 K8s 1.12 中就引入了，现已发展到 beta 版本；
• 通过使用 CSI 创建本地临时卷的能力，实现了类似的“升级”（从 alpha 到 beta）（CSI 内联卷支持).

在上一个版本的 Kubernetes 中引入 卷克隆功能 （使用现有的PVC作为 DataSource 创建新的 PVC）现在也已获得测试状态。

调度器

调度方面的两个显着变化（均为 alpha 版本）：

• EvenPodsSpreading - 机会 使用 Pod 而不是逻辑应用程序单元来“公平分配”负载 （如 Deployment 和 ReplicaSet）并调整此分布（作为硬要求或软条件，即优先级）。 该功能将扩展计划中的 Pod 的现有分发功能，目前该功能受到选项的限制 PodAffinity и PodAntiAffinity，让管理员在这方面有更精细的控制，这意味着更好的高可用性和优化的资源消耗。 详细信息 - 在 KEP.
• 使用 最佳适合政策 в RequestedToCapacityRatio 优先级函数 在 Pod 规划期间，这将允许 申请 装箱 （“打包在容器中”）适用于基本资源（处理器、内存）和扩展资源（例如 GPU）。 有关更多详细信息，请参阅 KEP.

  
  调度 Pod：在使用最佳匹配策略之前（直接通过默认调度程序）及其使用（通过调度程序扩展程序）

另外， 提出 能够在主 Kubernetes 开发树之外（树外）创建自己的调度程序插件。

其他变化

另外，在 Kubernetes 1.16 版本中，您还可以注意到 倡议 带来 可用指标的完整顺序，或者更准确地说，根据 官方规定 到 K8s 仪器。 他们很大程度上依赖于相应的 普罗米修斯文档。 由于各种原因出现了不一致（例如，一些指标只是在当前指令出现之前创建的），开发人员决定是时候将所有内容统一为单一标准，“与 Prometheus 生态系统的其他部分保持一致”。 目前该举措的实施处于 alpha 状态，将在后续版本的 Kubernetes 中逐步提升至 beta (1.17) 和 stable (1.18)。

此外，还可以注意到以下变化：

• Windows支持开发 с 的出现 适用于该操作系统的 Kubeadm 实用程序（alpha 版本）， 机会 RunAsUserName 对于 Windows 容器（alpha 版本）， 改进 组托管服务帐户 (gMSA) 支持最高测试版本， 支持 挂载/附加 vSphere 卷。
• 回收 API响应中的数据压缩机制。 以前，HTTP 过滤器用于这些目的，这施加了许多限制，导致默认情况下无法启用它。 “透明请求压缩”现在有效：客户端发送 Accept-Encoding: gzip 在标头中，如果其大小超过 128 KB，它们会收到 GZIP 压缩的响应。 Go 客户端自动支持压缩（发送所需的标头），因此它们会立即注意到流量的减少。 （其他语言可能需要稍作修改。）
• 成为可能 根据外部指标将 HPA 从零 Pod 扩展到零。 如果您基于对象/外部指标进行扩展，那么当工作负载空闲时，您可以自动扩展到 0 个副本以节省资源。 对于工作线程请求 GPU 资源，并且不同类型的空闲工作线程的数量超过可用 GPU 数量的情况，此功能应该特别有用。
• 新客户- k8s.io/client-go/metadata.Client — 用于对对象的“通用”访问。 它旨在轻松检索元数据（即小节 metadata）从集群资源中获取并使用它们执行垃圾收集和配额操作。
• 构建 Kubernetes 现在你可以 没有传统（“内置”树内）云提供商（alpha 版本）。
• 转到 kubeadm 实用程序 添加 实验性（alpha 版本）能够在操作期间应用自定义补丁 init, join и upgrade。 了解有关如何使用该标志的更多信息 --experimental-kustomize，参见 KEP.
• apiserver 的新端点 - readyz, - 允许您导出有关其准备情况的信息。 API 服务器现在也有一个标志 --maximum-startup-sequence-duration，允许您调节其重新启动。
• 两 Azure 的功能 宣布稳定：支持 可用区 （可用区）和 跨资源组 （RG）。 此外，Azure 还添加了：
  • 身份验证支持 AAD 和 ADFS；
  • 摘要 service.beta.kubernetes.io/azure-pip-name 指定负载均衡器的公共IP；
  • 机会 设置 LoadBalancerName и LoadBalancerResourceGroup.
• AWS 现在有 支持 适用于 Windows 上的 EBS 和 优化 EC2 API 调用 DescribeInstances.
• Kubeadm 现已独立 迁移 升级CoreDNS版本时的CoreDNS配置。
• 二进制文件 等 在对应的Docker镜像中 已经完成了 world-executable，它允许您运行此映像而无需 root 权限。 另外，etcd 迁移镜像 停止 etcd2 版本支持。
• В 集群自动缩放器 1.16.0 改用 Distroless 作为基础镜像，提高了性能，添加了新的云提供商（DigitalOcean、Magnum、Packet）。
• 使用/依赖软件的更新：Go 1.12.9、etcd 3.3.15、CoreDNS 1.6.2。

PS

另请阅读我们的博客：

• «Kubernetes 1.15：主要创新概述“;
• «Kubernetes 1.14：主要创新概述“;
• «Kubernetes 1.13：主要创新概述“;
• «Kubernetes 1.12：主要创新概述“。

来源： habr.com