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

带你了解Kubernetes架构的设计意图、Kubernetes系统的架构开发演进过程，以及背后的驱动原因。

1、背景

各种平台都会遇到一个不可回避的问题，即平台应该包含什么和不包含什么，Kubernetes也一样。Kubernetes作为一个部署和管理容器的平台，Kubernetes不能也不应该试图解决用户的所有问题。Kubernetes必须提供一些基本功能，用户可以在这些基本功能的基础上运行容器化的应用程序或构建它们的扩展。本文旨在明确Kubernetes架构的设计意图，描述Kubernetes的演进历程和未来的开发蓝图。

本文中，我们将描述Kubernetes系统的架构开发演进过程，以及背后的驱动原因。对于希望扩展或者定制kubernetes系统的开发者，其应该使用此文档作为向导，以明确可以在哪些地方，以及如何进行增强功能的实现。如果应用开发者需要开发一个大型的、可移植的和符合将来发展的kubernetes应用，也应该参考此文档，以了解Kubernetes将来的演化和发展。

从逻辑上来看，kubernetes的架构分为如下几个层次：

• 核心层(Nucleus)： 提供标准的API和执行机制，包括基本的REST机制，安全、Pod、容器、网络接口和存储卷管理，通过接口能够对这些API和执进行扩展，核心层是必需的，它是系统最核心的一部分。
• 应用管理层(Application Management Layer )：提供基本的部署和路由，包括自愈能力、弹性扩容、服务发现、负载均衡和流量路由。此层即为通常所说的服务编排，这些功能都提供了默认的实现，但是允许进行一致性的替换。
• 治理层(The Governance Layer)：提供高层次的自动化和策略执行，包括单一和多租户、度量、智能扩容和供应、授权方案、网络方案、配额方案、存储策略表达和执行。这些都是可选的，也可以通过其它解决方案实现。
• 接口层(The Interface Layer)：提供公共的类库、工具、用户界面和与Kubernetes API交互的系统。
• 生态层(The Ecosystem)：包括与Kubernetes相关的所有内容，严格上来说这些并不是Kubernetes的组成部分。包括CI/CD、中间件、日志、监控、数据处理、PaaS、serverless/FaaS系统、工作流、容器运行时、镜像仓库、Node和云提供商管理等。

2、系统分层

就像Linux拥有内核(kernel)、核心系统类库、和可选的用户级工具，kubernetes也拥有功能和工具的层次。对于开发者来说，理解这些层次是非常重要的。kubernetes APIs、概念和功能都在下面的层级图中得到体现。

2.1 核心层：API和执行(The Nucleus: API and Execution)

核心层包含最核心的API和执行机。

这些API和功能由上游的kubernetes代码库实现，由最小特性集和概念集所组成，这些特征和概念是系统上层所必需的。

这些由上游KubNeNETs代码库实现的API和函数包括建立系统的高阶层所需的最小特征集和概念集。这些内容被明确的地指定和记录，并且每个容器化的应用都会使用它们。开发人员可以安全地假设它们是一直存在的，这些内容应该是稳定和乏味的。

2.1.1 API和集群控制面板

Kubernetes集群提供了类似REST API的集，通过Kubernetes API server对外进行暴露，支持持久化资源的增删改查操作。这些API作为控制面板的枢纽。

遵循Kubernetes API约定(路径约定、标准元数据等)的REST API能够自动从共享API服务(认证、授权、审计日志)中收益，通用客户端代码能够与它们进行交互。

作为系统的最娣层，需要支持必要的扩展机制，以支持高层添加功能。另外，需要支持单租户和多租户的应用场景。核心层也需要提供足够的弹性，以支持高层能扩展新的范围，而不需要在安全模式方面进行妥协。

如果没有下面这些基础的API机和语义，Kubernetes将不能够正常工作：

认证(Authentication): 认证机制是非常关键的一项工作，在Kubernetes中需要通过服务器和客户端双方的认证通过。API server 支持基本认证模式 (用户命名/密码) (注意，在将来会被放弃)， X.509客户端证书模式，OpenID连接令牌模式，和不记名令牌模式。通过kubeconfig支持，客户端能够使用上述各种认证模式。第三方认证系统可以实现TokenReview API，并通过配置认证webhook来调用，通过非标准的认证机制可以限制可用客户端的数量。

• The TokenReview API (与hook的机制一样) 能够启用外部认证检查，例如Kubelet
• Pod身份标识通过”service accounts“提供
• The ServiceAccount API，包括通过控制器创建的默认ServiceAccount保密字段，并通过接入许可控制器进行注入。

授权(Authorization)：第三方授权系统可以实现SubjectAccessReview API，并通过配置授权webhook进行调用。

SubjectAccessReview (与hook的机制一样), LocalSubjectAccessReview, 和SelfSubjectAccessReview APIs能启用外部的许可检查，诸如Kubelet和其它控制器。

• REST 语义、监控、持久化和一致性保证、API版本控制、违约、验证
• NIY：需要被解决的API缺陷：
• 混淆违约行为
• 缺少保障
• 编排支持
• 支持事件驱动的自动化
• 干净卸载

NIY： 内置的准入控制语义、同步准入控制钩子、异步资源初始化 — 发行商系统集成商，和集群管理员实现额外的策略和自动化

NIY：API注册和发行、包括API聚合、注册额外的API、发行支持的API、获得支持的操作、有效载荷和结果模式的详细信息。

NIY：ThirdPartyResource和ThirdPartyResourceData APIs (或她们的继承者)，支持第三方存储和扩展API。

NIY：The Componentstatuses API的可扩展和高可用的替代，以确定集群是否完全体现和操作是否正确：ExternalServiceProvider (组件注册)

The Endpoints API，组件增持需要，API服务器端点的自我发布，高可用和应用层目标发行

The Namespace API，用户资源的范围，命名空间生命周期(例如：大量删除)

The Event API，用于对重大事件的发生进行报告，例如状态改变和错误，以及事件垃圾收集

NIY：级联删除垃圾收集器、finalization, 和orphaning

（编辑：核心网）

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