K8s跟Docker的关系

一、docker简介

镜像（Image）：就相当于是一个 root 文件系统。比如官方镜像 ubuntu:16.04 就包含了完整的一套 Ubuntu16.04 最小系统的 root 文件系统。

容器（Container）：镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

仓库（Repository）：仓库可看成一个代码控制中心，用来保存镜像。

Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。

从虚拟化来看

  上图是Docker容器（可用k8s管理的玩意儿）与传统虚拟化方式的不同之处，传统的虚拟技术，在将物理硬件虚拟成多套硬件后，需要再每套硬件上都部署一个操作系统，接着在这些操作系统上运行相应的应用程序。而Docker容器内的应用程序进程直接运行在宿主机(真实物理机)的内核上，Docker引擎将一些各自独立的应用程序和它们各自的依赖打包，相互独立直接运行于未经虚拟化的宿主机硬件上，同时各个容器也没有自己的内核，显然比传统虚拟机更轻便。 每个集群有多个节点，每个节点可，我们的kuberbete就是管理这些应用程序所在的小运行环境（container）而生。

从部署角度

 图2是在这些具体运行环境上进行真实应用部署时的情况，传统方式是将所有应用直接部署在同一个物理机器节点上，这样每个App的依赖都是完全相同的，无法做到App之间隔离，当然，为了隔离，我们也可以通过创建虚拟机的方式来将App部署到其中（就像图1上半部分那样），但这样太过繁重，故比虚拟机更轻便的Docker技术出现，现在我们通过部署Container容器的技术来部署应用，全部Container运行在容器引擎上即可。

二、K8s简介

 k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

一个K8S系统，通常称为一个K8S集群（Cluster）。

这个集群主要包括两个部分：

• 一个Master节点（主节点）
• 一群Node节点（计算节点）

Master节点包括API Server、Scheduler、Controller manager、etcd。

• API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。
• Scheduler负责对集群内部的资源进行调度，相当于“调度室”。
• Controller manager负责管理控制器，相当于“大总管”。

Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。

• Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。
• Service，一个Service可以看作一组提供相同服务的Pod的对外访问接口。
• Docker，创建容器的。
• Kubelet，主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。
• Kube-proxy，主要负责为Pod对象提供代理。
• Fluentd，主要负责日志收集、存储与查询。

三、k8s跟docker的关系

k8s是一个编排容器的工具，其实也是管理应用的全生命周期的一个工具，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且可以做到故障自愈，例如一个服务器挂了，可以自动将这个服务器上的服务调度到另外一个主机上进行运行，无需进行人工干涉。

k8s可以更快的更新新版本，打包应用，更新的时候可以做到不用中断服务，服务器故障不用停机，从开发环境到测试环境到生产环境的迁移极其方便，一个配置文件搞定，一次生成image，到处运行。。。
在k8s里面，集群调度的最小单元就是一个pod，一个pod可以是一个容器，也可以是多个容器，例如你运行一个程序，其中使用了nginx，使用mysql了，使用了jetty，那么可以将这三个使用在同一个pod中，对他们提供统一的调配能力，一个pod只能运行在一个主机上，而一个主机上可以有多个pod。

为什么要使用pod，为什么不能直接使用容器呢？使用pod，相当与一个逻辑主机，还记得创建一个vm，在vm上运行几个进程么，其实道理是一样的，pod的存在主要是让几个紧密连接的几个容器之间共享资源，例如ip地址，共享存储等信息。如果直接调度容器的话，那么几个容器可能运行在不同的主机上，这样就增加了系统的复杂性。