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

NIY： 需要内置的add-on的管理器 ，从而能够自动添加自宿主的组件和动态配置到集群，在运行的集群中提取出功能。

• Add-ons应该是一个集群服务，作为集群的一部分进行管理
• 它们可以运行在kube-system命名空间，这么就不会与用户的命名进行冲突

API server作为集群的网关。根据定义，API server必需能够被集群外的客户端访问，而Node和Pod是不被集群外的客户端访问的。客户端认证API server，并使用API server作为堡垒和代理/通道来通过/proxy和/portforward API访问Node和Pod等Clients authenticate the API server and also use it

TBD：The CertificateSigningRequest API，能够启用认证创建，特别是kubele证书。

理想情况下，核心层API server江仅仅支持最小的必需的API，额外的功能通过聚合、钩子、初始化器、和其它扩展机制来提供。注意，中心化异步控制器以名为Controller Manager的独立进程运行，例如垃圾收集。

API server依赖下面的外部组件：

• 持久化状态存储 (etcd，或相对应的其它系统;可能会存在多个实例)
• API server可以依赖：
• 身份认证提供者
• The TokenReview API实现者 实现者
• The SubjectAccessReview API实现者

2.1.2 执行

在Kubernetes中最重要的控制器是kubelet，它是Pod和Node API的主要实现者，没有这些API的话，Kubernetes将仅仅只是由键值对存储(后续，API机最终可能会被作为一个独立的项目)支持的一个增删改查的REST应用框架。

Kubernetes默认执行独立的应用容器和本地模式。

Kubernetes提供管理多个容器和存储卷的Pod，Pod在Kubernetes中作为最基本的执行单元。

Kubelet API语义包括：

The Pod API，Kubernetes执行单元，包括：

1）、Pod可行性准入控制基于Pod API中的策略(资源请求、Node选择器、node/pod affinity and anti-affinity, taints and tolerations)。API准入控制可以拒绝Pod或添加额外的调度约束，但Kubelet才是决定Pod最终被运行在哪个Node上的决定者，而不是schedulers or DaemonSets。

2）、容器和存储卷语义和生命周期

3）、Pod IP地址分配(每个Pod要求一个可路由的IP地址)

4）、将Pod连接至一个特定安全范围的机制(i.e., ServiceAccount)

5）、存储卷来源：

• emptyDir
• hostPath
• secret
• configMap
• downwardAPI
• NIY：容器和镜像存储卷 (and deprecate gitRepo)
• NIY：本地存储，对于开发和生产应用清单不需要复杂的模板或独立配置
• flexVolume (应该替换内置的cloud-provider-specific存储卷)

6）、子资源：绑定、状态、执行、日志、attach、端口转发、代理

• NIY：可用性和引导API 资源检查点

容器镜像和日志生命周期

• The Secret API，启用第三方加密管理
• The ConfigMap API，用于组件配置和Pod引用
• The Node API，Pod的宿主

a、在一些配置中，可以仅仅对集群管理员可见

• Node和pod网络，业绩它们的控制(路由控制器)
• Node库存、健康、和可达性(node控制器)

b、Cloud-provider-specific node库存功能应该被分成特定提供者的控制器

• pod终止垃圾收集
• 存储卷控制器

c、Cloud-provider-specific attach/detach逻辑应该被分成特定提供者的控制器，需要一种方式从API中提取特定提供者的存储卷来源。

• The PersistentVolume API

d、NIY：至少被本地存储所支持

• The PersistentVolumeClaim API

中心化异步功能，诸如由Controller Manager执行的pod终止垃圾收集。

当前，控制过滤器和kubelet调用“云提供商”接口来询问来自于基础设施层的信息，并管理基础设施资源。然而，kubernetes正在努力将这些触摸点(问题)提取到外部组件中，不可满足的应用程序/容器/OS级请求(例如，PODS，PersistentVolumeClaims)作为外部“动态供应”系统的信号，这将使基础设施能够满足这些请求，并使用基础设施资源(例如，Node、和PersistentVolumes)在Kubernetes进行表示，这样Kubernetes可以将请求和基础设施资源绑定在一起。

对于kubelet，它依赖下面的可扩展组件：

• 镜像注册
• 容器运行时接口实现
• 容器网络接口实现
• FlexVolume 实现(”CVI” in the diagram)

以及可能依赖：

• NIY：第三方加密管理系统(例如：Vault)
• NIY：凭证创建和转换控制器

2.2 应用层：部署和路由

应用管理和组合层，提供自愈、扩容、应用生命周期管理、服务发现、负载均衡和路由— 也即服务编排和service fabric。这些API和功能是所有Kubernetes分发所需要的，Kubernetes应该提供这些API的默认实现，当然可以使用替代的实现方案。没有应用层的API，大部分的容器化应用将不能运行。

Kubernetes’s API提供类似IaaS的以容器为中心的基础单元，以及生命周期控制器，以支持所有工作负载的编排(自愈、扩容、更新和终止)。这些应用管理、组合、发现、和路由API和功能包括：

• 默认调度，在Pod API中实现调度策略：资源请求、nodeSelector、node和pod affinity/anti-affinity、taints and tolerations. 调度能够作为一个独立的进度在集群内或外运行。

NIY：重新调度器 ，反应和主动删除已调度的POD，以便它们可以被替换并重新安排到其他Node

（编辑：核心网）

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