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侵入容器和特定语言的应用框架。

（编辑：核心网）

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