Kubernetes体系架构演进进程与背后驱动的缘故起因

发明、负载平衡和路由

1. The Service API，包罗集群IP地点分派，修复处事分派映射，通过kube-proxy可能对等的成果实现处事的负载平衡，自动化建设端点，维护和删除。NIY：负载平衡处事是可选的，假如被支持的化，则必要通过同等性的测试。
2. The Ingress API，包罗internal L7 (NIY)
3. 处事DNS。DNS行使official Kubernetes schema。

应用层可以依靠：

• 身份提供者 (集群的身份和/或应用身份)
• NIY：云提供者节制器实现
• Ingress controller(s)
• 调治器和从头调治器的更换办理方案
• DNS处事更换办理方案
• kube-proxy更换办理方案
• 事变负载节制器更换办理方案和/或帮助，出格是用于扩展宣布计策

2.3 管理层：自动化和计策执行

计策执行和高层自动化。这些API和成果是运行应用的可选成果，应该挺其余的办理方案实现。

每个支持的API/成果应用作为企业操纵、安详和管理场景的一部门。

必要为集群提供也许的设置和发明默认计策，至少支持如下的用例：

• 单一租户/单一用户集群
• 多租户集群
• 出产和开拓集群
• Highly tenanted playground cluster
• 用于将计较/应用处事转售给他人的分段集群

必要存眷的内容：

1. 资源行使
2. Node内部门割
3. 最终用户
4. 打点员
5. 处事质量(DoS)

自动化APIs和成果：

• 怀抱APIs (程度/垂直自动扩容的调治使命表)
• 程度Pod自动扩容API
• NIY：垂直Pod自动扩容API(s)
• 集群自动化扩容和Node供给
• The PodDisruptionBudget API
• 动态存储卷供给，至少有一个出厂价来历范例

1、The StorageClass API，至少有一个默认存储卷范例的实现

• 动态负载平衡供给
• NIY：PodPreset API
• NIY：service broker/catalog APIs
• NIY：Template和TemplateInstance APIs

计策APIs和成果：

授权：ABAC和RBAC授权计策方案

1、RBAC，实现下面的API：Role, RoleBinding, ClusterRole, ClusterRoleBinding

• The LimitRange API
• The ResourceQuota API
• The PodSecurityPolicy API
• The ImageReview API
• The NetworkPolicy API

打点层依靠：

• 收集计策执行机制
• 替代、程度和垂直Pod扩容
• 集群自动扩容和Node提供者
• 动态存储卷提供者
• 动态负载平衡提供者
• 怀抱监控pipeline，可能它的替代
• 处事署理

2.4 接口层：类库和器材

这些机制被提议用于应用措施版本的分发，用户也可以用其举办下载和安装。它们包罗Kubernetes官方项目开拓的通用的类库、器材、体系、界面，它们可以用来宣布。

1. Kubectl — kubectl作为许多客户端器材中的一种，Kubernetes的方针是使Kubectl更薄，通过将常用的非平时成果移动到API中。这是须要的，以便于跨Kubernetes版本的正确操纵，并促进API的扩展性，以保持以API为中心的Kubernetes生态体系模子，并简化其余客户端，尤其长短GO客户端。

• 客户端类库(譬喻：client-go, client-python)
• 集群联邦(API server, controllers, kubefed)
• Dashboard
• Helm

这些组件依靠：

• Kubectl扩展
• Helm扩展

2.5 生态

在有很多规模，已经为Kubernetes界说了明晰的边界。固然，Kubernetes必需提供陈设和打点容器化应用必要的通用成果。但作为一样平常法则，在对Kubernete通用编排成果举办补足的成果规模，Kubernetes保持了用户的选择。出格是那些有本身的竞争上风的地区，出格是可以或许满意差异需求和偏好的浩瀚办理方案。Kubernetes可觉得这些办理方案提供插件API，可能可以果真由多个后端实现的通用API，可能果真此类办理方案可以针对的API。偶然，成果可以与Kubernetes干净地组合在而不必要显式接口。

另外，假如思量成为Kubernetes的一部门，组件就必要遵循Kubernetes计划约定。譬喻，首要接口行使特定域说话的体系(譬喻，Puppet、Open Policy Agent)与Kubenetes API的要领不兼容，可以与Kubernetes一路行使，但不会被以为是Kubernetes的一部门。相同地，被计划用来支持多平台的办理方案也许不会遵循Kubernetes API协议，因此也不会被以为是Kubernetes的一部门。

内部的容器镜像：Kubernetes不提供容器镜像的内容。 假如某些内容被计划陈设在容器镜像中，则其不该该直接被思量作为Kubernetes的一部门。譬喻，基于特定说话的框架。

在Kubernetes的顶部

1、耐久化集成和陈设(CI/CD)：Kubernetes不提供从源代码到镜像的手段。Kubernetes 不陈设源代码和不构建应用。用户和项目可以按照自身的必要选择耐久化集成和耐久化陈设事变流，Kubernetes的方针是利便CI/CD的行使，而不是呼吁它们怎样事变。

2、应用中间件：Kubernetes不提供给用中间件作为内置的基本办法，譬喻：动静行列和SQL数据库。然而，可以提供通用目标的机制使其可以或许被轻易的提供、发明和会见。抱负的环境是这些组件仅仅运行在Kubernetes上。

3、日记和监控：Kubernetes自己不提供日记聚合和综合应用监控的手段，也没有遥测说明和警报体系，固然日记和监控的机制是Kubernetes集群必不行少的部门。

4、数据处理赏罚平台：在数据处理赏罚平台方面，Spark和Hadoop是尚著名的两个例子，但市场中还存在许多其余的体系。

5、特定应用运算符：Kubernetes支持通用种别应用的事变负载打点。

6、平台即处事 Paas：Kubernetes为Paas提供基本。

7、成果即处事 FaaS：与PaaS相同，但Faa侵入容器和特定说话的应用框架。

（编辑：湖南网）

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