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

当前，控制过滤器和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

持续运行应用：这些应用类型应该能够通过声明式更新、级联删除、和孤儿/领养支持发布(回滚)。除了DaemonSet，应该能支持水平扩容。

1. The Deployment API，编排更新无状态的应用，包括子资源(状态、扩容和回滚)
2. The DaemonSet API，集群服务，包括子资源(状态)
3. The StatefulSet API，有状态应用，包括子资源(状态、扩容)
4. The PodTemplate API，由DaemonSet和StatefulSet用来记录变更历史

终止批量应用：这些应该包括终止jobs的自动剔除(NIY)

• The Job API (GC discussion)
• The CronJob API

（编辑：西安站长网）

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