Kubernetes系统架构演进过程与背后驱动的原因

8、集群创建和管理：社区已经开发了很多的工具，利润minikube、kubeadm、bootkube、kube-aws、kops、kargo, kubernetes-anywhere等待。 从工具的多样性可以看出，集群部署和管理(例如，升级)没有一成不变的解决方案。也就是说，常见的构建块(例如，安全的Kubelet注册)和方法(特别是自托管)将减少此类工具中所需的自定义编排的数量。

后续，希望通过建立Kubernetes的生态系统，并通过整合相关的解决方案来满足上述需求。

矩阵管理

选项、可配置的默认、扩展、插件、附加组件、特定于提供者的功能、版本管理、特征发现和依赖性管理。

Kubernetes不仅仅是一个开源的工具箱，而且是一个典型集群或者服务的运行环境。 Kubernetes希望大多数用户和用例能够使用上游版本，这意味着Kubernetes需要足够的可扩展性，而不需要通过重建来处理各种场景。

虽然在可扩展性方面的差距是代码分支的主要驱动力，而上游集群生命周期管理解决方案中的差距是当前Kubernetes分发的主要驱动因素，可选特征的存在(例如，alpha API、提供者特定的API)、可配置性、插件化和可扩展性使概念不可避免。

然而，为了使用户有可能在Kubernetes上部署和管理他们的应用程序，为了使开发人员能够在Kubernetes集群上构建构建Kubernetes扩展，他们必须能够对Kubernetes集群或分发提供一个假设。在基本假设失效的情况下，需要找到一种方法来发现可用的功能，并表达功能需求(依赖性)以供使用。

集群组件，包括add-ons，应该通过组件注册 API进行注册和通过/componentstatuses进行发现。

启用内置API、聚合API和注册的第三方资源，应该可以通过发现和OpenAPI(Savigj.JSON)端点来发现。如上所述，LoadBalancer类型服务的云服务提供商应该确定负载均衡器API是否存在。

类似于StorageClass，扩展和它们的选项应该通过FoeClass资源进行注册。但是，使用参数描述、类型(例如，整数与字符串)、用于验证的约束(例如，ranger或regexp)和默认值，从扩展API中引用fooClassName。这些API应该配置/暴露相关的特征的存在，例如动态存储卷供应(由非空的storageclass.provisioner字段指示)，以及标识负责的控制器。需要至少为调度器类、ingress控制器类、Flex存储卷类和计算资源类(例如GPU、其他加速器)添加这样的API。

假设我们将现有的网络存储卷转换为flex存储卷，这种方法将会覆盖存储卷来源。在将来，API应该只提供通用目的的抽象，即使与LoadBalancer服务一样，抽象并不需要在所有的环境中都实现(即，API不需要迎合最低公共特性)。

NIY：需要为注册和发现开发下面的机制：

• 准入控制插件和hooks(包括内置的APIs)
• 身份认证插件
• 授权插件和hooks
• 初始化和终结器
• 调度器扩展
• Node标签和集群拓扑

NIY：单个API和细粒度特征的激活/失活可以通过以下机制解决：

• 所有组件的配置正在从命令行标志转换为版本化配置。
• 打算将大部分配置数据存储在配置映射(ConfigMaps)中，以便于动态重新配置、渐进发布和内省性。
• 所有/多个组件共同的配置应该被分解到它自己的配置对象中。这应该包括特征网关机制。
• 应该为语义意义上的设置添加API，例如，在无响应节点上删除Pod之前需要等待的默认时间长度。

NIY：版本管理操作的问题，取决于多个组件的升级(包括在HA集群中的相同组件的副本)，应该通过以下方式来解决：

• 为所有新的特性创建flag网关
• 总是在它们出现的第一个小版本中，默认禁用这些特性，
• 提供启用特性的配置补丁;

在接下来的小版本中默认启用这些特性

• NIY：我们还需要一个机制来警告过时的节点，和/或潜在防止Master升级(除了补丁发布)，直到/除非Node已经升级。
• NIY：字段级版本管理将有助于大量激活新的和/或alpha API字段的解决方案，防止不良写入过时的客户端对新字段的阻塞，以及非alpha API的演进，而不需要成熟的API定义的扩散。

Kubernetes API server忽略不支持的资源字段和查询参数，但不忽略未知的/未注册的API(注意禁用未实现的/不活动的API)。这有助于跨多个版本的集群重用配置，但往往会带来意外。Kubctl支持使用服务器的Wagger/OpenAPI规范进行可选验证。这样的可选验证，应该由服务器(NYY)提供。此外，为方便用户，共享资源清单应该指定Kubernetes版本最小的要求，这可能会被kubectl和其他客户端验证。

服务目录机制(NIY)应该能够断言应用级服务的存在，例如S3兼容的群集存储。

与安全相关的系统分层

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!