Kubernetes 设计概览及详细设计

Kubernetes 设计概述（Kubernetes Design Overview）

原文：Kubernetes Design Overview

Kubernetes 是一个设计为跨多个主机的，容器化应用的系统，为应用提供部署，维护和扩展的基本机制。

Kubernetes 建立了健壮性比较强的声明式原语来维持用户所需的状态。我们将这些原始镜像作为Kubernetes提供的主要价值。例如自动重启，重新调度和复制容器之类的自我修复机制，这不仅仅需要协调，还需要主动的控制器。

Kubernetes 主要针对由多个容器组成的应用程序，例如弹性分布式为服务。它也被设计为便于将非容器化应用集迁移到 Kubernetes中。因此，它包括了将松散耦合和紧密耦合的容器分组的抽象（Pod），并且提供容器能够使用熟悉的方式找到彼此以及通信的方式（同一个Pod使用相同的网络栈）。

Kubernetes 使用户能够让集群运行一组容器（Pod）。系统自动选择主机来运行这些容器。虽然 Kubernetes的调度程序目前非常简单，但我们预计它会随着时间的推移逐渐复杂化。调度是一项策略丰富的拓扑感知的工作负载的特定功能，可显著地影响着可用性，性能和容量。调度器需要考虑个人和集体资源的需求，服务质量要求，硬件、软件、政策约束，亲和力和反亲和力规范，数据位置，工作负载均衡间的k干扰，截至日期等。必要时，工作负载特定的要求将通过 API 公开。

Kubernetes 旨在运行在许多云提供商以及物理主机上。

单个 Kubernetes 集群不打算跨越多个可用区域。相反，我们建议构建更高级别的层来复制跨多个区域的高可用性应用程序的完整部署（有关更多详细信息，可参阅多集群文档和集群联邦的提案）。

最后，Kubernetes 立志成为一个可扩展，可插拔的构建模块的 OSS 平台和工具包。因此，在架构上，我们希望 Kubernetes 能够作为可插拔的组件和层的集合来构建，并且能够使用替代的调度程序，控制器，存储系统和分发机制，并且我们正朝着这个方向发展。此外，我们希望其他人能够扩展 Kubernetes 的功能，例如具有更高级别的 PaaS 功能或多集群层，而无需修改核心 Kubernetes 源。因此，其 API 不仅仅是（或者甚至主要）针对最终用户，而是针对工具和扩展开发人员。它的 API 旨在作为工具，自动化系统和更高级别 API 层的开放式生态系统的基础。因此，没有 “内部” 组件间 API。所有的 API 都是可见和可用的，包括调度器，节点控制器，复制控制器、管理器，kubelet 的 API 等使用的 API。并没有打破透明性 - 为了处理更复杂的情况，可以访问完全透明，以可组合的方式的使用较低级别的 API。

有关 Kubernetes 架构的更多信息，请参考架构。

Kubernetes 架构（Kubernetes architecture）

原文： Kubernetes architecture

正在运行的 Kubernetes 集群在分布式存储解决方案的顶部包含节点代理（kubelet）和主要组件（API，调度程序等）。这张图显示了我们期望的最终状态，尽管我们仍在努力地做一些事情，比如让 kubelet 本身（我们所有的组件都是真正的）在容器中运行，并使调度器 100% 可插拔。

Kubernetes Node 节点（The Kubernetes Node）

在查看系统的体系结构时，我们将其分解为在工作节点上运行的服务以及组成集群级别控制平面的系统。

Kubernetes 节点具有运行应用程序容器所需的服务，并可从主系统进行管理。

当然，当每个节点都运行Docker。Docker负责下载镜像和运行维护容器。

kubelet

kubelet 管理 Pod，及其容器，镜像，存储卷等。

kube-proxy