Kubernetes 1.14:主要创新概述

Kubernetes 1.14:主要创新概述

今夜 发生 Kubernetes 的下一个版本 - 1.14。 根据我们博客的传统,我们正在讨论这个精彩的开源产品新版本的关键变化。

用于准备本材料的信息取自 Kubernetes 增强跟踪表, 变更日志-1.14 以及相关问题、拉取请求、Kubernetes 增强提案 (KEP)。

我们先从 SIG cluster-lifecycle 的重要介绍开始: 动态故障转移集群 Kubernetes(或更准确地说,自托管 HA 部署)现在 可以创造 使用熟悉的(在单节点集群的上下文中)命令 kubeadm (init и join)。 简而言之,为此:

  • 集群使用的证书被转移为秘密;
  • 可以在 K8s 集群内使用 etcd 集群(即摆脱之前存在的外部依赖) etcd 操作符;
  • 记录提供容错配置的外部负载均衡器的建议设置(将来计划消除这种依赖性,但现阶段还没有)。

Kubernetes 1.14:主要创新概述
使用 kubeadm 创建的 Kubernetes HA 集群的架构

实施细节可以参见 设计方案。 这个功能确实是期待已久的:alpha 版本预计会在 K8s 1.9 中出现,但现在才出现。

API

团队 apply 一般而言 声明式对象管理 通过了 из kubectl 在 api 服务器中。 开发商自己简短地解释了他们的决定: kubectl apply - 在 Kubernetes 中使用配置的基本部分,然而,“它充满了错误并且难以修复”,因此需要将该功能恢复正常并转移到控制平面。 当今存在的问题的简单明了的例子:

Kubernetes 1.14:主要创新概述

有关实施的详细信息位于 KEP。 目前的准备情况是 alpha(计划在下一个 Kubernetes 版本中升级到 beta)。

提供 alpha 版本 机会 使用 OpenAPI v3 方案 为 CustomResources 创建和发布 OpenAPI 文档 (CR) 用于验证(服务器端)K8s 用户定义资源(CustomResourceDefinition,CRD)。 为 CRD 发布 OpenAPI 允许客户端(例如 kubectl)在您这边执行验证(在 kubectl create и kubectl apply)并根据方案(kubectl explain)。 详细信息 - 在 KEP.

预先存在的日志 现已开放 与国旗 O_APPEND (而不是 O_TRUNC)以避免在某些情况下丢失日志,并方便使用外部实用程序截断日志以进行轮换。

同样在 Kubernetes API 的上下文中,可以注意到, PodSandbox и PodSandboxStatus 添加runtime_handler 记录有关的信息 RuntimeClass 在 pod 中(在有关文本中了解更多信息) Kubernetes 1.12 版本,该类以 alpha 版本的形式出现),并在招生 Webhooks 中 实施的 能够确定哪些版本 AdmissionReview 他们支持。 最后,Admission Webhooks 规则现在是 可以被限制 命名空间和集群框架使用它们的范围。

PersistentLocalVolumes,自发布以来一直处于测试状态 K8s 1.10, 声明 stable(GA):此功能门不再禁用,并将在 Kubernetes 1.17 中删除。

机会 使用名为的环境变量 向下API (例如,pod 名称)作为安装目录的名称 subPath,以新领域的形式开发 subPathExpr,现在用于确定所需的目录名称。 该功能最初出现在 Kubernetes 1.11 中,但在 1.14 中仍处于 alpha 版本状态。

与之前的 Kubernetes 版本一样,针对积极开发的 CSI(容器存储接口)引入了许多重大更改:

CSI

可用(作为 alpha 版本的一部分) 支持 调整 CSI 卷的大小。 要使用它,您需要启用名为的功能门 ExpandCSIVolumes,以及特定 CSI 驱动程序中对此操作的支持。

alpha 版本中 CSI 的另一个功能 - 机会 直接引用(即不使用 PV/PVC)pod 规范中的 CSI 卷。 这 取消了使用 CSI 作为专用远程数据存储的限制,为他们打开通往世界的大门 局部临时卷。 用来 (文档中的示例) 必须启用 CSIInlineVolume 功能门。

与 CSI 相关的 Kubernetes“内部”也取得了进展,这些进展对于最终用户(系统管理员)来说并不那么明显......目前,开发人员被迫支持每个存储插件的两个版本:一个 - “在老方法”,在 K8s 代码库内部(在 -tree 中),第二个 - 作为新 CSI 的一部分 (阅读更多相关信息,例如, 这里)。 这会造成一些不便,这是可以理解的,随着 CSI 本身的稳定,这些不便需要得到解决。 由于以下原因,不可能简单地弃用内部(树内)插件的 API 相关 Kubernetes 政策.

这一切导致了 alpha 版本达到了 迁移过程 内部插件代码,在 CSI 插件中以 in-tree 的形式实现,因此开发人员的担忧将减少到支持其插件的一个版本,并且与旧 API 的兼容性将保持不变,并且在通常情况下可以宣布它们已过时。 预计到 Kubernetes 的下一个版本 (1.15),所有云提供商插件都将迁移,该实现将获得 beta 状态,并默认在 K8s 安装中激活。 详细信息请参见 设计方案。 这次迁移还导致 放弃 来自特定云提供商(AWS、Azure、GCE、Cinder)定义的数量限制。

此外,还支持具有 CSI 的块设备(CSIBlockVolume) 转入 到测试版。

节点/Kubelet

推出 Alpha 版本 新端点 在 Kubelet 中,设计用于 返回关键资源的指标。 一般来说,如果之前 Kubelet 从 cAdvisor 接收有关容器使用情况的统计信息,那么现在这些数据通过 CRI(容器运行时接口)来自容器运行时环境,但也保留了与旧版本 Docker 的兼容性。 以前,Kubelet 中收集的统计信息是通过 REST API 发送的,但现在端点位于 /metrics/resource/v1alpha1。 开发商的长期战略 是最小化 Kubelet 提供的指标集。 顺便说一句,这些指标本身 现在他们打电话 不是“核心指标”,而是“资源指标”,被描述为“一级资源,如cpu、内存”。

一个非常有趣的细微差别:尽管与使用 Prometheus 格式的各种情况相比,gRPC 端点具有明显的性能优势 (请参阅下面的基准之一的结果),作者更喜欢 Prometheus 的文本格式,因为这个监控系统在社区中有明确的领导地位。

“gRPC 与主要监控管道不兼容。 Endpoint 仅适用于向 Metrics Server 传送指标或监控与其直接集成的组件。 在 Metrics Server 中使用缓存时 Prometheus 文本格式的性能 够好了 鉴于 Prometheus 在社区中的广泛采用,我们更喜欢 Prometheus 而不是 gRPC。 一旦 OpenMetrics 格式变得更加稳定,我们将能够使用基于原型的格式来接近 gRPC 性能。”

Kubernetes 1.14:主要创新概述
在新的 Kubelet 端点中使用 gRPC 和 Prometheus 格式进行指标比较的性能测试之一。 更多图表和其他详细信息可以在 KEP.

其他变化包括:

  • 现在的 Kubelet(一次) 试图阻止 在重新启动和删除操作之前容器处于未知状态。
  • 当使用 PodPresets 现在到初始化容器 添加 与常规集装箱的信息相同。
  • 库贝莱特 开始使用 usageNanoCores 来自 CRI 统计提供程序,以及 Windows 上的节点和容器 添加 网络统计。
  • 操作系统和架构信息现在记录在标签中 kubernetes.io/os и kubernetes.io/arch 节点对象(从 beta 转移到 GA)。
  • 能够为 pod 中的容器指定特定的系统用户组(RunAsGroup,出现在 K8s 1.11) 先进的 测试版之前(默认启用)。
  • du 和 find 在 cAdvisor 中使用, 取而代之 关于 Go 的实现。

CLI

在 cli-runtime 和 kubectl 中 添加 -k 标志用于集成 自定义 (顺便说一下,它的开发现在是在一个单独的存储库中进行的),即处理来自特殊 kustomization 目录的其他 YAML 文件(有关使用它们的详细信息,请参阅 KEP):

Kubernetes 1.14:主要创新概述
简单文件使用示例 定制 ( kustomize 的更复杂的应用程序是可能的 覆盖)

另外:

  • 添加者 新团队 kubectl create cronjob,其名字不言而喻。
  • В kubectl logs 现在你可以 结合-f (--follow 用于流日志)和 -l (--selector 用于标签查询)。
  • Kubectl 学到了 复制通配符选择的文件。
  • 给团队 kubectl wait 添加--all 选择指定资源类型的命名空间中的所有资源。

他人

以下功能已获得稳定 (GA) 状态:

Kubernetes 1.14 中引入的其他更改:

  • 默认 RBAC 策略不再允许 API 访问 discovery и access-review 未经身份验证的用户 (未经验证).
  • 官方 CoreDNS 支持 由...提供 仅限Linux,因此当使用kubeadm在集群中部署它(CoreDNS)时,节点必须只能在Linux上运行(使用nodeSelectors来解决此限制)。
  • 现在默认 CoreDNS 配置 使用 转发插件 而不是代理。 另外,在 CoreDNS 中 添加 readinessProbe,它会阻止适当的(未准备好服务)pod 上的负载平衡。
  • 在 kubeadm 中,分阶段 init или upload-certs, 成为可能 加载将新控制平面连接到 kubeadm-certs 密钥所需的证书(使用标志 --experimental-upload-certs).
  • 适用于 Windows 安装的 alpha 版本已经出现 支持 gMSA(组托管服务帐户)- Active Directory 中也可以由容器使用的特殊帐户。
  • 对于 G.C.E. 活性 etcd 和 kube-apiserver 之间的 mTLS 加密。
  • 使用/依赖软件的更新:kubeadm 中支持 Go 1.12.1、CSI 1.1、CoreDNS 1.3.1、Docker 18.09,支持的最低 Docker API 版本现在为 1.26。

PS

另请阅读我们的博客:

来源: habr.com

添加评论