写在前边

Docker是个伟大的项目，它彻底释放了虚拟化的威力，让应用的分发、部署和管理都变得前所未有的高效和轻松！

如果你正在为以下问题困扰，就可以考虑使用Docker来对整个工程进行重构。

资源利用率问题

不同业务场景对资源的需求是不-样的，有CPU密集型、内存密集型、网络密集型，这就可能导致资源利用率不合理的问题。在大多数的企业中，我们经常能够看到服务器的资源闲置率非常高，而开发团队却经常面临无机器可用的情况。

混合部署交叉

影响对于线上服务，一台机器要混合部署多个服务，那么服务之间可能存在相互影响的情况。比如端口的冲突，CPU及内存的共同使用等问题，都有可能造成服务之间的冲突，从而导致莫名的问题。

扩/缩容效率低

当业务节点需要进行扩/缩容时，从机器下线到应用部署、测试，周期较长。当业务遇到突发流量高峰时，增加设备并部署后，可能流量高峰已经过去了。这些本身与设计无关，即使接口应用已经设计成无状态的，但是想要做扩容也是-件非常麻烦的事。

多环境代码不一致

大部分公司都会有由于过去内部开发流程的不规范而存在一些问题，业务提测的代码在测试环境测试完毕后，在线上部署时可能会进行修改、调整，然后打包上线。这就会导致测试的代码和线上运行的代码是不一致的，增加了服务上线的风险，也增加了线上服务故障排查的难度。

缺少稳定的线下测试环境

在测试过程中，会遇到一个问题，服务依赖的其他下游服务都没有提供稳定的测试环境，导致无法在测试环境模拟整个线上流程进行测试。所以有时候会用线上服务进行测试，这本身就存在着很高的潜在风险。一旦操作失误，就有可能造成不可估量的损失。

而Docker的出现在很大程度上解决了这些问题，那么我们一起来认识一下Docker 吧。

Docker简介

Docker是一个开源的引擎，可以轻松地为任何应用创建一个轻量级的、 可移植的、自给自足的容器。开发者在笔记本电脑上编译测试通过的容器可以批量地在生产环境中部署，包括VMs (虚拟机)、bare metal、OpenStack 集群和其他基础应用平台。

Docker的目标：

提供轻量简单的建模方式；

职责的逻辑分离；

快速高效的开发生命周期；

鼓励使用面向服务的架构，即单个容器运行单个应用。

Docker原理

Docker是一个客户端一服务器(C/S)架构的程序。Docker 客户端只需向Docker服务器或守护进程发出请求，服务器或守护进程将完成所有工作并返回结果。Docker提供了一个命令行工具Docker及一整套RESTful API,可以在同一台宿主机上运行Docker守护进程和客户端，也可以从本地的Docker客户端连接到运行在另一台宿主机上的远程Docker守护进程。

Docker依赖的Linux的内核特性包括Namespaces命名空间和Control groups(c groups)控制组。

Namespaces命名空间：

PID (process ID),进程ID隔离;

NET (network)，管理网络端口;

IPC ( InterProcess Communication),进程间通信;

管理跨进程通信的访问;

MNT (Mount)，管理挂载点;

UTS (UNIX Timesharing System),隔离内核和版本标识；

Control groups(c groups),控制组。

Control groups(c groups)控制组:

资源限制;

优先级设定;

资源度量;

资源控制及资源分配;

Docker容器的能力包括:

文件系统隔离——每个容器都有自己的root文件系统，可以独立挂载外部文件系统。

进程隔离——每个容器都运行在自己的进程环境中，相互之间互不干扰。

网络隔离——容器间的虚拟网络接口和IP地址都是分开的。

资源隔离和分组——使用cgroup将CPU和内存等资源独立分配给每个Docker容器。

更轻量级的虚拟化

Docker项目的目标是实现轻量级的操作系统虚拟化解决方案。我们先来看一下虚拟机与Docker的架构对比，

从下到上理解上图

基础设施(Infrastructure)：一般是服务器或者云主机。

虚拟机管理系统(Hypervisor)：利用Hypervisor, 可以在主操作系统之上运行多个不同的从操作系统，可以构建在基础设施上，也可以构建在操作系统上。

客户机操作系统(Guest Operating System)：假设运行3个相互隔离的应用，则需要使用Hypervisor启动3个客户机操作系统，也就是3个虚拟机。这些虚拟机都非常大，也许有900MB,这就意味着它们将占用2.7GB的磁盘空间。更糟糕的是，它们还会消耗很多CPU和内存资源。

各种依赖：每一个客户机操作系统都需要安装许多依赖。

应用：安装依赖之后，就可以在各个客户机操作系统分别运行应用了，这样各个应用就是相互隔离的。

再来看一下Docker的架构，

虚拟机和Docker的对比:

Docker容器可以在秒级实现，比虚拟机的方式不只快了一倍，任何虚拟机都不太可能在秒级启动完成。

Docker对系统资源的利用率很高，一.台主机上可以同时运行数千个Docker 容器。如果把服务器比作码头，则虚拟机就好比码头上的仓库，不能随便移动，而Docker就好比集装箱，操作灵活，运载方便。

容器除了运行其中应用，基本不消耗额外的系统资源，所使用的资源完全是使用宿主机上的资源。

传统虚拟机方式运行10个不同的应用就要启动10个虚拟机，而Docker只需要10个隔离的应用即可。

Docker容器可以跨平台运行，不需要额外的操作系统支持，按需装载。

小编之前整理过的Docker实战笔记，点击即可参阅哦~~~

网络模式

当Docker 进程启动时，会在主机上创建一一个 名为docker0的虚拟网桥，此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。

Docker有以下四种网络模式：

host模式，docker run时使用–net-host指定。

container模式，docker run时使用–net=container:NAME or. ID指定。

none模式，docker run时使用–net-none指定。

bridge模式，docker run时使用–net-bridge指定，默认设置。

link

link是在两个contain之间建立一种父子关系，父container中的Web可以得到子container db上的信息。

通过link的方式创建容器，我们可以使用被link容器的别名进行访问，而不是通过IP，解除了对IP的依赖。

不过，link 的方式只能解决单机容器间的互连，多机的情况下，需要通过别的方式进行连接。

在运行一个容器时，使用-link-container_name or id:name选项可以在此容器的/etc/hosts文件中增加一个额外的name主机名，这个名字为container_name的容器的IP地址的别名。这使得新容器的内部进程可以访问主机名为name的容器而不用知道它的IP。

内网是走docker0的网桥，互相之间是Ping得通的，但是docker run建立容器时，它的IP地址是不可控制的，所以Docker用link的方式使Web能够访问到db中的数据。

跨主机访问

跨主机的容器访问目前市面上主流的解决方法有flannel、 weave、 Pipework、 Open vSwitch等。下面就来分别认识一下这几种方案。

Open vSwitch

Open vSwitch是一个高质量的、多层虚拟交换机，使用开源Apache 2.0许可协议，由Nicia Networks开发，主要实现代码为可移植的C代码。它的目的是让大规模网络自动化可以通过编程扩展，同时仍然支持标准的管理接口和协议(例如，NetFlow. SFlow. SPAN、RSPAN、CLI、LAAP、802.1ag)。

Weave

Weave是由Zettio公司开发的，它能够创建一个虚拟网络，用于连接部署在多台主机上的Docker容器，这样容器就像被接入了同一个网络交换机-样，那些使用网络的应用程序不必去配置端口映射和链接等信息。外部设备能够访问Weave 网络上的应用程序容器所提供的服务，同时已有的内部系统也能够暴露到应用程序容器上。Weave能够穿透防火墙并运行在部分连接的网络上。另外，Weave 的通信支持加密，所以用户可以从一个不受信任的网络连接到主机。

Flannel

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

Docker数据卷

容器中管理数据主要有两种方式:

数据卷(Data Volumes);

数据卷容器(Data Volumes Dontainers )。

数据卷

数据卷是一个特殊的目录，它将主机目录直接映射进容器，可供一个或多个容器使用，如下图所示：

数据卷设计的目的就是为了数据的持久化，它完全独立与容器的生命周期。因此，容器删除时，不会删除其挂载的数据卷，也不会存在类似的垃圾机制对容器存在的数据卷进行处理。

数据卷的特性：

数据卷在容器启动时初始化，如果容器使用的镜像在挂载点包含了数据，这些数据会复制到新初始化的数据卷中。

数据卷可以在容器之间共享和重用。

可以对数据卷里的内容直接修改，修改会马上生效，无论是容器内操作还是本地操作。

对数据卷的更新不会影响镜像的更新。

数据卷会一直存在，即使挂载数据卷的容器已经被删除。

数据卷容器

一个目录或者一个容器通过挂载数据卷就可以实现容器与外部系统的交互了，但是如果多个容器想实现数据的共享又该怎么办呢？

Docker提供了一种挂载数据卷的容器，叫作数据卷容器，其他容器能够通过挂载这个容器实现数据共享，如下图所示

Kubernetes

Swarm为Docker自行开发的容器调度工具，2017 年成为Docker平台的内建工具。不过，有鉴于Kubernetes已成为最受欢迎的容器调度工具，再加上Docker用户也希望能够更方便地使用Kubernetes，让Docker终于宣布支援Kubernetes。

容器调度工具的竞争局面中，Kubermnetes 可以说是站稳龙头，不只各家厂商抢着支援，连Docker都开始支援Kubernetes,包含企业版Docker、支持Windows与Mac的Docker社群版，以及Moby专案，用户可自行选择通过Kubernetes或Swarm来调度及管理容器任务。

那么Kubernetes到底是什么?为什么连Docker官方都宣布开始支持？我们一起来一探究竟。

Kubernetes (k8s) 是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看作Kubernetes内部使用的低级别组件。Kubernetes 不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

使用Kubernetes可以:

自动化容器的部署和复制;

随时扩展或收缩容器规模;

将容器组织成组，并且提供容器间的负载均衡;

很容易地升级应用程序容器的新版本;

提供容器弹性，如果容器失效就替换它，等等。

K8s集群组件如下：

etcd：一个高可用的K/V键值对存储和服务发现系统。

flannel：实现跨主机的容器网络的通信。

kube- apiserver：提供Kubernetes集群的API调用。

kube- controller-manager：确保集群服务。

kube- scheduler：调度容器，分配到Node。

kubelet：在Node节点上按照配置文件中定义的容器规格启动容器。

kube-proxy：提供网络代理服务。

Kubernetes的主要概念如下。

Pods

Pod是Kubernetes的基本操作单元，把相关的一个或多个容器构成一个Pod,通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Minion (Host) 上，看作一个统一管理单元，共享相同的volumes、network namespace/IP和Port空间。

Services

Services也是Kubernetes 的基本操作单元，是真实应用服务的抽象，每一 一个服 务后面都有很多对应的容器来支持，通过Proxy的port和selector服务决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问接口，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。

Replication Controllers

Replication Controller确保任何时候Kubernetes集群中有指定数量的Pod副本(replicas) 在运行，如果少于指定数量的Pod副本(replicas )，Replication Controller会启动新的Container，反之会“杀死”多余的以保证数量不变。Replication Controller使用预先定义的Pod模板创建pods，一旦创建成功，Pod模板和创建的pods没有任何关联，可以修改Pod模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods。

Labels

Labels是用于区分Pod、Service、 Replication Controller的key/value键值对，Pod、 Service、Replication Controller 可以有多个Label,但是每个Label的key只能对应一个value。Labels 是Service和Replication Controller运行的基础，为了将访问Service的请求转发给后端提供服务的多个容器，正是通过标识容器的Labels 来选择正确的容器。同样，Replication Controller也使用Labels来管理通过Pod模板创建的一组容器，这样Replication Controller可以更加容易、方便地管理多个容器，无论有多少容器。

Kubernetes集群包括两种类型资源:

Master节点——协调控制整个集群。

Nodes节点——运行应用的工作节点。

Master负责集群的管理,协调集群中的所有行为/活动。例如，应用的运行、修改、更新等。节点(Node)作为Kubernetes集群中的工作节点，可以是VM虚拟机、物理机。每个Node上都有一个Kubelet,用于管理Node节点与Kubernetes Master 通信。每个Node节点上至少还要运行container runtime (比如Docker或者rkt)。

在Kubernetes上部署应用程序时，会先通知master启动容器中的应用程序，master 调度容器在集群的节点上运行，Node节点使用master公开的Kubernetes API与主节点进行通信。最终用户还可以直接使用Kubernetes API与集群进行交互。

在传统的概念当中，Docker 是简单易用的，Kubernetes 是复杂强大的，如果部署起来需要花费很长的时间，但是事实不是这样的。如果是前期测试或者尝鲜，可以使用单机搭建Kubernetes来了解整体的运行情况，这个工具就是Minikube。

Minikube的特点:

Minikube是-种方便在本地运行Kubernetes 的工具。Minikube是可以在VM中运行单节点的Kubernetes集群。Minikube是为了开发或测试在本地启动一个节点的kubernetes集群。可以工作在Windows、Linux、 MacOS下。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

私有云整体架构

不管是大公司还是小公司，都希望有一套自己的私有云平台，能够最大化利用资源，而基于Docker,使得构建这样的私有云平台变得更加容易。

接下来看一下私有云平台的架构，如下图所示。

基础设施

顾名思义，就是指现有的服务器，以及由服务器构建的宿主机、存储和网络等资源。一般由硬件设备组成，处于所有应用的最底层。

容器层

基础设施之上提供了整个容器初始化层，容器初始化层包含Kubernetes、 Agent、 IP地址管理：之前已经重点介绍了Kubernetes。Agent部署在宿主机上，用于系统资源和底层基础设施的管理，包含监控采集、日志采集、容器限速等。IP地址管理用于管理整个网络系统的IP资源。

资源管理

容器层之上是资源管理层，包含容器管理、扩容管理、版本控制、上线发布、 权限控制和资源池管理等模块。能够根据资源的使用情况进行动态的分配，以满足更高并发的需求。

应用层

运行用户提交的业务实例，可以是任意编程语言。现在比较流行的是Java、Python、NET Core和PHP等语言。平台能够为各种语言提供可运行的环境，并且支持一键部署。

基础组件

云平台为容器运行环境提供必备的基础组件，包含服务发现、镜像中心、日志中心、监控中心。服务发现用于将指定的请求路由到特定的服务上，镜像中心用于管理所有业务镜像，日志中心用于收集、分析业务中产生的日志数据，监控中心用于监控所有应用的运行状态，发现问题时及时告警处理。

统一门户

可视化的UI门户页面，规范化整个业务流程，简洁的用户流程，可动态管理整个云环境的所有资源。

后记

Docker作为微服务中非常重要的一环，能够实现线上线下保持一致的环境， 避免对特定云供应商的依赖。能够有效地降低运维团队的负担，当访问量增大时，能够通过横向扩展集群的规模，做到弹性伸缩。

对于小型团队来说，借鉴别的团队成功的经验非常重要，使用Docker，可以快速地应用其他团队的经验，也可以将自己团队的经验共享给其他团队。

Kubernetes具备完善的集群管理能力，包括多层次的安全防护和准入机制，多租户应用支撑能力，透明的服务注册和服务发现机制，内建负载均衡器，故障发现和自我修复能力，服务滚动升级和在线扩容，可扩展的资源自动调度机制，多粒度的资源配额管理能力。

Kubernetes还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。