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界说的扩散。

（编辑：湖南网）

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