如果我们想要构建和运行一个现代的云基础设施，那么理解Docker和Kubernetes是必不可少的。本文主要给大家介绍Docker和Kubernetes技术以及它们之间的区别和联系。

一、Docker

1.1 容器（Container）简介

容器是打包软件的一种方式，包括打包应用程序的所有代码、库和依赖关系等。它们提供了一个轻量级的虚拟环境，可以将一组进程和资源(如内存、CPU、磁盘等)与主机和任何其他容器隔离。隔离保证了容器内的任何进程都不能看到容器外的任何进程或资源。

1.2 Docker原理

linux下的容器技术使用了Linux的内核机制：namespace (ipc、uts、mount、pid、network和user) 和cgroups (在现有内核实例之上提供抽象层，以创建类似于虚拟机的隔离环境)。其中，namespace实现了对内核全局资源的隔离；而cgroup则用来限制、控制和统计一组进程及将来的子进程所使用的物理资源，包括cpu, memory, disk等。

1.2.1 namespace

namespace是Linux内核的一个特性，它对内核资源进行分组，以便一组进程看到一组资源，同时另一组进程看到另一组资源。也就是说内核资源被包装在namespace中，并且它们只对运行在同一个namespace中的进程可见，对其他namespace中的进程不可见。目前namespace支持的类型包括以下六种：

我们依次来介绍以下他们的作用：

（1）NET:

NET namespace为容器提供系统网络协议的视图(如IP地址、路由表、端口号等)。基于此，不同容器都有各自独立的网络协议栈视图，如网络接口、IP地址、端口、路由表等。

（2）PID(Process ID):

PID namespace为容器提供它们自己的进程视图，包括一个独立的init (PID 1)，它是所有进程的祖先。基于此，不同容器都有各自的PID为1的init进程。

（3）MNT:

MNT namespace为容器提供了系统上的“文件系统挂载”视图。因此，不同的容器中，可以看到不同的文件系统层次结构视图，且可以独立操作（读写）而互不影响。

（4）UTS (UNIX Timesharing System):

UTS namespace允许容器拥有自己的主机名和NIS域名，它们独立于其他容器和主机系统。

（5）IPC(Interprocess Communication):

IPC namespace负责在每个容器内运行的进程之间隔离IPC资源。

（6）USER:

USER namespace 用于在每个容器中隔离用户。它的功能是允许不同的容器拥有不同的UID(用户ID)和GID(组ID)范围视图。

我们来总结一下，当Docker创建一个容器时，它会创建新的以上六种namespace的实例，然后把该容器中的所有进程放到这些namespace之中，使得容器这个父进程只对自己创建的子进程有感知，而对于宿主机的和其他容器创建的进程一无所知，从而产生一种它就是一个独立的系统的“错觉”。

1.2.2 cgroups

control groups这是一个Linux内核特性，用于隔离和管理不同的资源，如CPU、内存、磁盘I/O、网络等的消耗。 cgroups还可以确保单个容器不会耗尽其中某一个资源，从而避免整个系统的崩溃。

1.3 Docker的组成

一个完整的Docker系统由以下6个部分组成，分别是：

Docker Client:

这是CLI(命令行接口)工具，用于配置Docker并与之交互。每当开发人员或用户运行docker命令（内部封装了Docker Client）时，Docker Client就会将这些命令发送到docker守护进程(dockerd)， dockerd会负责执行这些具体的命令。

Docker Daemon:

这是作为docker守护进程运行的Docker服务器。这个守护进程侦听API请求并管理Docker对象(images、containers、networks和volumes)。守护进程还可以与其他守护进程通信来管理Docker服务。

Images（镜像）:

Images是用于创建Docker容器的只读模板或者快照。这些Images可以从镜像仓库获取。镜像仓库分为公有镜像仓库和私有镜像仓库。Docker Hub 是市面上主流的公有镜像仓库。除了公有镜像仓库以外，很多企业为了节省网络带宽和提高镜像资源使用率，也会配置自己的私有镜像仓库，提供给企业内部员工使用。

Docker file:

Docker file用来创建Docker Image。具体Docker file的语法大家可以参考相关的文档。

Containers（容器）:

容器是镜像的运行实例。我们可以通过docker命令进行如下操作：

• 创建、运行、停止、移动或者删除容器
• 将容器连接到一个或多个网络（Network）
• 向容器添加存储（Volume）
• 根据容器的当前状态创建新的镜像（Image）

Docker Registries:

Docker Registries用来保存和管理容器镜像。Docker Hub是任何人都可以使用的公共的Docker Register，默认情况下Docker被配置为在Docker Hub上寻找镜像。当我们使用docker pull或docker run命令时，所需的镜像就会从我们配置的Docker Register拉取到本地。当我们使用docker push命令时，我们自己的镜像会被推到我们配置的Docker Register。

1.4 Docker的优势

（1）可以在云平台之间无缝迁移你的应用

（2）消除环境的不一致

（3）高效的分发你的应用

（4）易于扩展应用程序

（5）轻量级

（6）启动速度快

（7）易于维护

正是docke的以上特性和优势，docker获得了越来越多的开发者的青睐。然而，随着应用程序越来越复杂，单个应用程序跨越和使用多个容器越发平常，如何协调和管理这些容器成为一个棘手的问题：

• 多个容器之间如何协调和调度？
• 应用程序中的不同的容器之间如何彼此通讯？
• 多个容器执行个体的规模如何调整？

而要解决这些问题，就需要借助Kubernetes了。

二、kubernetes

2.1 Kubernetes简介

Kubernetes是由google在2014年开源的生产级别的容器编排系统。Kubernetes不仅是一个容器编排系统，还是一个微服务或者云原生（弹性伸缩）的平台， Kubernetes提供了服务注册与发现、负载均衡、服务自愈、横向扩展、日志监控、集群自愈和容错、弹性伸缩、存储卷挂载的能力。

2.2 Kubernetes的架构

一个 Kubernetes 集群由一组被称作节点的机器组成。节点分为主节点和工作节点。每个集群至少要有一个主节点和工作节点。

主节点管理集群中的工作节点和 Pod 。多个主节点用于为集群提供故障转移和高可用性。工作节点负责托管应用程序组件中的 Pod。

这张图表展示了包含所有相互关联组件的 Kubernetes 集群。

Control Plane Components（控制平面组件）: Control Plane Components组件提供了集群的控制平面，它们负责集群的全局活动，包括：调度、检测和响应集群事件等功能（例如，当不满足部署的replicas字段时，启动新的pod）

• kube-apiserver: kube-apiserver是主节点上负责提供 Kubernetes API 服务的组件，它是 Kubernetes 控制面的前端。kube-apiserver用于控制集群的所有REST命令的入口点。它处理REST请求、验证它们并执行相应的业务逻辑。kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之，通过部署多个实例可以实现扩缩。
• etcd: etcd 是兼具一致性和高可用性的key-value数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
• Controller-manager: Controller-manager运行Contrller来处理集群中的常规任务。这些控制器包括:节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)。服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的namespace创建默认帐户和 API 访问令牌

从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。

• Scheduler: 该组件负责监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。Scheduler组件的调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置等。
• cloud-controller-manager：cloud-controller-manager是 kubernetes 1.8 的 alpha 特性。在未来的kubernetes版本中，这是将 Kubernetes 与任何其他云集成的最佳方式。cloud-controller-manager允许您将集群链接到cloud provider的API中，并将与云平台交互的组件与仅与集群交互的组件分离开来。当然了，如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要cloud-controller-manager。

Node Components: Node组件运行在每个节点上，负责维护运行的pods并为它们提供Kubernetes运行时环境。

• kubelet: kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
• kube-proxy: Kube-proxy是集群中每个节点上运行的网络代理。kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果操作系统提供了数据包过滤层并可用的话，kube-proxy会通过它来实现网络规则。否则，kube-proxy 仅转发流量本身。
• Container runtime: Container runtime是负责运行容器的软件。Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)的软件。但近年来，Docker 已发展成为默认的容器运行环境。

2.3 Kubernetes的优势

Kubernetes 为您提供：

• 服务发现和负载均衡
• Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
• 存储编排
• Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。
• 自动部署和回滚
• 您可以使用 Kubernetes 描述已部署容器的期待状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
• 自动二进制打包
• Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
• 自我修复
• Kubernetes 可以重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
• 密钥与配置管理
• Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在应用配置中暴露密钥。

三、Kubernetes和Docker比较

谈到 Kubernetes 与 Docker 的比较时，往往会落入“非此即彼”的陷阱：应该使用 Kubernetes 还是 Docker？

事实上，不必进行选择，Kubernetes 和 Docker 基本上是不同的两种技术。事实上，如果一定要比较，将 Kubernetes 与 Docker Swarm 进行比较更为恰当。

Kubernetes 与 Docker 之间的根本区别在于，Kubernetes 旨在跨群集运行，而 Docker 在单个节点上运行。Docker让你只需编写一次代码即可在任何地方运行；而 Kubernetes 则让你可从单一控制界面协调和管理所有容器资源。这有助于跨运行容器的所有 Kubernetes 节点实现联网、负载均衡、安全性和缩放。Kubernetes 还具有命名空间等内置隔离机制，使你可以按访问权限等对容器资源进行分组。这些结构使 IT 部门更易于为开发人员提供自助式资源访问权限，并且即使在最复杂的微服务体系结构上，开发人员也可以在不模拟其开发环境中的整个应用程序的情况下进行协作。

简而言之，结合使用 Kubernetes 和 Docker 可以：

• 使你的基础结构更加可靠，并使应用程序更具高可用性。
• 使你的应用程序更具可缩放性。如果你的应用开始逐渐产生越来越多的负载，并且需要横向扩展才能提供更好的用户体验，则只需启动更多容器或向 Kubernetes 群集添加更多节点即可。

参考资料：

https://kubernetes.io/docs/concepts/overview/components/

https://azure.microsoft.com/zh-cn/topic/kubernetes-vs-docker/