传统部署时代： 早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。

虚拟化部署时代： 作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。

因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代： 容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。

容器当下大家比较熟知的是docker，而Kubernetes可以看作docker的管理工具。

为什么需要Kubernetes？

真正的生产型应用会涉及多个容器。这些容器必须跨多个服务器主机进行部署。容器安全性需要多层部署，因此可能会比较复杂。但 Kubernetes 有助于解决这一问题。简单来说，就是Kubernetes 可以帮助开发者构建跨多个容器的应用服务、跨集群调度、扩展这些容器，并长期持续管理这些容器的健康状况。

专业术语：

主机（Master）： 用于控制 Kubernetes 节点的计算机。所有任务分配都来自于此。

API SERVER:用户不论用命令行还是图形界面，请求都发送至api server，内部系统与外部用户也通过相同的api通信

etcd：存储集群的配置和状态，主节点通过etcd查询节点，容器与容器的状态参数

Controllers:从api server获取到所需状态，控制节点的当前状态，有差异就解决

Scheduler:监听来自api的新请求，对节点进行排名，把pod部署到合适的节点，不合适就先挂着不部署

 

节点（Node）：负责执行请求和所分配任务的计算机。由 Kubernetes 主机负责对节点进行控制。

 

容器集（Pod）：被部署在单个节点上的，且包含一个或多个容器的容器组。同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。容器集会将网络和存储从底层容器中抽象出来。这样，您就能更加轻松地在集群中移动容器。

Kubelet：运行在节点上的服务，1.监视来自api的任务，执行任务，并向主节点报告。2.监视pod，pod有问题会向控制程序报告，控制程序会改变分配策略。

Container Runtime：容器运行时从镜像库拉取镜像。

kube-proxy：让每个节点获得他的IP地址，实现负载均衡。

复制控制器（Replication controller）：用于控制应在集群某处运行的完全相同的容器集副本数量。

 

当pod有问题时，kubernetes会创造一个和原来一样的pod，但是IP不一样。service用来解决这个问题。

服务（Service）：将工作内容与容器集分离。Kubernetes 服务代理会自动将服务请求分发到正确的容器集——无论这个容器集会移到集群中的哪个位置，甚至可以被替换掉。

 

Kubernetes 工作的简单流程：

主机(master)接收开发者的命令，自动选择从属节点(node)进行分发，之后它将在该节点分配资源，并指派容器集来完成任务请求。

当 kubernetes 将容器集调度到一个节点上时，该节点上的 kubelet 会发送指令让 docker 启动指定的容器。kubelet 随后会不断从 docker 收集这些容器的状态，并将这些信息汇集至主机。