docker&Kubernetes入门篇

以Docker为代表的容器技术的出现，终结了DevOps中交付和部署环节因环境、配置及程序本身的不同而造成的动辄几种甚至十几种部署配置的困境，将它们统一在了容器镜像之上。如今，越来越多的企业或组织开始选择以镜像文件作为交付载体。容器镜像之内直接包含了应用程序及其依赖的系统环境、库、基础程序等，从而能够在容器引擎上直接运行。于是，IT运维工程师无须再关注开发应用程序的编程语言、环境配置等，甚至连业务逻辑本身也不必过多关注，而只需要掌握容器管理的单一工具链即可。

容器降低了部署的复杂度，但以容器格式运行的应用程序间的协同以及大规模容器应用的治理却成为一个新的亟待解决的问题，这种需求在微服务架构中表现得尤为明显。微服务通过将传统的巨大单体应用拆分为众多目标单一的小型应用以解耦程序的核心功能，各微服务可独立部署和扩展。随之而来的问题便是如何为应用程序提供一个一致的环境，并合理、高效地将各微服务实例及副本编排运行在一组主机之上，这也正是以Kubernetes为代表的容器编排工具出现的原因。

下面详细介绍下docker组成

Docker容器技术有3个核心概念：容器、镜像和镜像仓库（Docker Registry）。如果把容器类比为动态的、有生命周期的进程，则镜像就像是静态的可执行程序及其运行环境的打包文件，而镜像仓库则可想象成应用程序分发仓库，事先存储了制作好的各类镜像文件。运行Docker守护进程（daemon）的主机称为Docker主机，它提供了容器引擎并负责管理本地容器的生命周期，而容器的创建则要基于本地存储的Docker镜像进行，当本地缺失所需的镜像时，由守护进程负责到Docker Registry获取。Docker命令行客户端（名为docker）通过Docker守护进程提供的API与其交互，用于容器和镜像等的对象管理操作

任何拥有Docker运行时引擎的主机都能够根据同一个镜像创建并启动运行环境完全一致的容器，在容器中添加新数据或修改现有数据的结果都存储在由容器附加在镜像之上的可写顶层中。因此，同一Docker主机上的多个容器可以共享同一基础镜像，但各有自己的数据状态。

删除容器会同时删除其创建的可写顶层，这将会导致容器生成的状态数据全部丢失。Docker支持使用存储卷（volume）技术来绕过存储驱动程序，将数据存储在宿主机可达的存储空间上以实现跨容器生命周期的数据持久性，也支持使用卷驱动器（Docker引擎存储卷插件）将数据直接存储在远程系统上

拥有独立网络名称空间的各容器应用间通信将依赖于名称空间中可使用设备及相关的IP地址、路由和iptables规则等网络配置。Linux内核支持多种类型的虚拟网络设备，例如Veth、Bridge、802.q VLAN device和TAP等，并支持按需创建虚拟网络设备并组合出多样化的功能和网络拓扑。Docker借助虚拟网络设备、网络驱动、IPAM（IP地址分配）、路由和iptables等实现了桥接模式、主机模式、容器模式和无网络等几种单主机网络模型。如图
显示了Docker默认的桥接网络拓扑。

为了兼容OCI规范，Docker项目自身也做了架构调整，自1.11.0版本起，Docker引擎由一个单一组件拆分成了Docker Engine（docker-daemon）、containerd、containerd-shim和runC等4个独立的项目，并把containerd捐赠给了CNCF。containerd是一个守护进程，它几乎囊括了容器运行时所需要的容器创建、启动、停止、中止、信号处理和删除，以及镜像管理（镜像和元信息等）等所有功能，并通过gRPC向上层调用者公开其API，可被兼容的任何上层系统调用，例如Docker Engine或Kubernetes等容器编排系统，并由该类系统负责镜像构建、存储卷管理和日志等其他功能。然而，containerd只是一个高级别的容器运行时，并不负责具体的容器管理功能，它还需要向下调用类似runC一类的低级别容器运行时实现此类任务。containerd又为其自身和低级别的运行时（默认为runC）之间添加了一个名为containerd-shim的中间层，以支持多种不同的OCI运行时，并能够将容器运行为无守护进程模式。这意味着，每启动一个容器，containerd都会创建一个新的containerd-shim进程来启动一个runC进程，并能够在容器启动后结束该runC进程