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

8、工作量编排： “工作流”是一个非常广泛的和多样化的领域，通常针对特定的用例场景(例如：数据流图、数据驱动处理、部署流水线、事件驱动自动化、业务流程执行、iPAAS)和特定输入和事件来源的解决方案，并且通常需要通过编写代码来实现。

9、配置特定领域语言：特定领域的语言不利于分层高级的API和工具，它们通常具有有限的可表达性、可测试性、熟悉性和文档性。它们复杂的配置生成，它们倾向于在互操作性和可组合性间进行折衷。它们使依赖管理复杂化，并经常颠覆性的抽象和封装。

10、Kompose：Kompose是一个适配器工具，它有助于从Docker Compose迁移到Kubernetes ，并提供简单的用例。Kompose不遵循Kubernetes约定，而是基于手动维护的DSL。

11、ChatOps：也是一个适配器工具，用于聊天服务。

支撑Kubernetes

1、容器运行时：Kubernetes本身不提供容器运行时环境，但是其提供了接口，可以来插入所选择的容器运行时。

2、镜像仓库：Kubernetes本身不提供容器的镜像，可通过Harbor、Nexus和docker registry等搭建镜像仓库，以为集群拉取需要的容器镜像。

3、集群状态存储：用于存储集群运行状态，例如默认使用Etcd，但也可以使用其它存储系统。

4、网络：与容器运行时一样，Kubernetes提供了接入各种网络插件的容器网络接口(CNI)。

5、文件存储：本地文件系统和网络存储

6、Node管理：Kubernetes既不提供也不采用任何综合的机器配置、维护、管理或自愈系统。通常针对不同的公有/私有云，针对不同的操作系统，针对可变的和不可变的基础设施。

7、云提供者：IaaS供应和管理。

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定义的扩散。

（编辑：晋中站长网）

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