Docker产生的原因

研发本地开发的代码，交付运维部署到生产环境时，会由于环境、配置等各种非代码因素的原因无法顺利发布，每次发版时需要浪费人力物力去排查问题。

Docker的简介

Docker属于容器，而容器就是将软件打包成标准化单元，以用于开发、交付和部署。以前是代码即应用，现在是运行环境、代码，才是应用，不会出现本地可以运行，但是生产却无法运行。一次构建处处运行，减少人工运行成本。

图1：Docker将除内核外的内容统一打包 图2：图解Docker

虚拟机和Docker区别

虚拟机模拟的是整套环境，包括硬件、环境。虚拟机的启动时长是分钟级，而docker可以做到秒级。虚拟机资源占用多、冗余步骤多、启动慢。

虚拟机时在一个操作系统里运行另外一种操作系统，比如在Windows系统里面运行Linux,应用程序无感知。因为虚拟机看上去和真实系统一模一样，而对于底层系统来说，虚拟机就是一个普通文件，不需要了就删除，对其他部分毫无影响。

图3：虚拟机案例

容器和虚拟机区别，容器不再是整套环境的模拟，而是需要的库资源和设置，和应用代码绑定在一个环境中。

传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。

图4：虚拟机容器对照

镜像简介

Docker包括三个基本概念：镜像、容器、仓库。

镜像（Image）——一个特殊的文件系统，即可直接在OS上运行的代码和环境

容器（Container）——镜像运行时的实体，正在对外提供服务的实体

仓库（Repository）——集中存放镜像文件的地方

容器镜像是轻量的、可执行的独立软件包 ，包含软件运行所需的所有内容：代码、运行时环境、系统工具、系统库和设置。镜像解决的问题是，弹性扩容数十台集群的机器，不可能通过人手工去维护，而是通过镜像去复制粘贴到不同服务器上去。

Docker - Build, Ship, and Run Any App, Anywhere

Build（构建镜像）：镜像就像是集装箱包括文件以及运行环境等等资源。

Ship（运输镜像）：主机和镜像仓库间运输，这里的仓库就像是超级码头一样。

Run （运行镜像）：运行的镜像就是一个容器，容器就是运行程序的地方。

Docker运行过程也就是去仓库把镜像拉到本地，然后用一条命令把镜像运行起来变成容器。所以，我们也常常将Docker称为码头工人或码头装卸工，这和Docker的中文翻译搬运工人如出一辙。

容器服务K8S

Kubernetes是Google在2014年开源的一个容器集群管理系统，Kubernetes简称K8S。K8S用于容器化应用程序的部署，扩展和管理。K8S提供了容器编排，资源调度，弹性伸缩，部署管理，服务发现等一系列功能。

容器解决了研发环境和生产环境一致性的问题。而Kubernetes目标是让批量部署容器化应用简单高效。

容器K8S特点

【1】自我修复：在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

【2】弹性伸缩：使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

【3】自动部署和回滚：K8S采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务。

【4】服务发现和负载均衡：K8S为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。

【5】机密和配置管理管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用。

【6】存储编排：挂载外部存储系统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。

【7】批处理：提供一次性任务，定时任务；满足批量数据处理和分析的场景。

图5：K8S架构

Masternode:统一入口由Master节点的APIServer实现。

scheduler：是负责调度策略

Controller Manager:作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

Worknode就是对应的部署了同样业务代码的节点。

Kube_proxy提供网络代理等负载均衡功能。

pod是worknode节点上运行的多个实例，实现高可用、弹性扩展。因为是无状态服务，如果实例异常无法使用，实例漂移之后，可以不依赖任何数据。有状态服务则是依赖网络IP，存储的数据。

图6： Controller Manager图解

Controller Manager中的Replication Controller，称为副本控制器。副本控制器的作用即保证集群中一个RC所关联的Pod副本数始终保持预设值。

Controller Manager中的Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。

图7：K8S图解

Pod是kubernetes中你可以创建和部署的最小也是最简单位。一个Pod代表着集群中运行的一个进程，可能由一个或者多个容器组合在一起共享资源。

为什么k8s使用Pod在容器之上再封装一层呢？

一个很重要的原因是Docker容器之间的通信受到网络机制的限制。在Docker的世界中，一个容器需要通过link方式才能访问另一个容器提供的服务（端口）。大量容器之间的link将是一个非常繁重的工作。通过Pod的概念将多个容器组合在一个虚拟的“主机”内，可以实现容器之间仅需通过Localhost就能相互通信了。

Ingress是用户访问域名之后，解析成IP，分发给对应Service。而Service则是容器对外统一暴露的接口，隐藏容器内部的实现逻辑。由于容器是无状态服务，当pod服务异常重启新的pod替代时，会产生新的IP地址。

node则是pod所运行的主机,可能是物理机，也可能是虚拟机。